Gaining Feedback, Building Trust

A powerful means of building trust and collaboration within a team is to gather around a table and tell each other face to face ‘this is how your actions made me feel’, both the good and the bad.

The importance of feedback

Effective software development requires a robust feedback loop.  Test-driven development gives immediate feedback on ‘does this code do what I expect?’ Continuous Integration gives early feedback on ‘does this code work with the rest of the system?’  And early incremental delivery gives quick feedback on ‘is this code useful to the customer?’

All this feedback is about our code, but as Gerald Weinburg famously said, No matter how it looks at first, it’s always a people problem” – so it seems wise to put at least as much effort into getting feedback about how well we are collaborating with our team-mates.  Compared to the immediate and precise feedback of a good test,  the standard annual performance review is too far distant from the behaviour in question to be much use in guiding iteration and continuous improvement.  We need something better.

How it works

We decided to adopt a variation on Jurgen Appelo’s 360 degree meetings.  The key point is to bring the whole team together, face to face around a table, to give direct feedback.  First, each person writes down items of feedback.  Each item:

  • should be addressed to one team-mate,
  • can be ‘went well’, ‘puzzle’, or ‘could improve’,
  • should refer to a specific incident, meeting or piece of work, and
  • ideally should be framed in terms of how that behaviour made you feel at the time.

We then go around the group, and each person in turn delivers one item of feedback, until they have all been covered.  After each item, the feedback recipient may respond briefly to ask for clarification; however the focus should be on asking ‘what can I improve?’ from the feedback, not on ‘defending myself’ from criticism.

As an example, recently a team-mate raised a ‘puzzle’ that I often seem to make arbitrary business decisions while coding, rather than raising the question with our business representatives.  Talking things through, we surfaced many underlying reasons why I tend to do this, including a degree of intellectual arrogance and a lack of trust.  We agreed that in future, we will at least share our decisions on slack, where business owners can see them.

How it helped us

The team agreed to experiment with holding this feedback meeting weekly for a month, after which we asked ourselves ‘should we continue?’. There was unanimous consent that we wanted to; what was interesting was that each person spotted different benefits from the process:

  • Lots of ‘went well’ feedback reinforced positive behaviours, which people might otherwise stop doing as they might not know they were valued
  • Positive feedback also builds confidence and satisfaction working on the team
  • ‘Could Improve’ feedback relating to a specific incident feels easier to accept, as it is about behaviour on a single occasion, rather than a general criticism of you as a person.
  • Rapid, small pieces of feedback lead to iterative improvements
  • When one person gives me feedback privately, then I’m inclined to think ‘that person has a problem’, and not look to change my own behaviour.  By giving it in front of the whole team, then unless anyone disagrees with the feedback as given, I’m more likely to accept that I should try and change myself.
  • Subsequent performance reviews are fairer, easier to write, and less surprising
  • By being prepared to accept critical feedback in front of the team, each of us makes ourselves vulnerable to our team-mates.  Doing this builds up a powerful sense of trust and interdependence between team-mates, which helps the team gel and thus collaborate effectively.

As team members switched onto other teams, they spread the practice of weekly feedback sessions across the TIM Group development organisation.  Having seen the benefits, I highly recommend this practice to any team working together closely.

Doing this yourself

Just as with retros, it can be helpful first to jog memories about what the team has worked on over the last week or fortnight.  Gathering in front of a task board, or collectively making a list of what has just been done, often helps people remember events they have feedback to give on.

We discovered that the vast majority of feedback (90%), was positive, and quite often a meeting concluded with no negative feedback given.  I think this is helpful too, and helps build up the trust and confidence which makes it possible for constructive criticisms to be made.  

We started out with all team members physically present in the room, however as our teams become more and more distributed, we soon adapted to use a hangout for some or all participants, which works fine.

We were lucky to start from a position where the team members knew one another, and had a reasonable level of trust and a fairly flat hierarchy.  It worked for us even though I was officially line manager of two of the others in the team; the reciprocal nature of this tended to reduce the effect of hierarchy, since my reports could equally raise feedback for me, which would go to my own line manager afterwards for my performance review.  

Everyone in the meeting should be ‘part of the team’ and committed to common goals, and everyone present should be open to receiving feedback – it’s fine to have a team lead or manager in the meeting, as long as they are also receiving feedback.

So if your team works closely together, I really recommend trying weekly feedback meetings.  They are very simple to run, and need only take as long as necessary based on the amount of feedback people have; the benefits in increased trust and collaboration are noticeable.