Feedback is key to any successful organisation but in my experience the way formal feedback is handled is not always optimal or doesn’t suit everyone. Below you can read about an experiment I’ve done to try to make things a bit better in my current setting.

The “normal” way of doing feedback

The way this traditionally works where I’m active at the moment is that people send out feedback requests to their teams and the feedback is handed back via email or an internal tool following this structure:

• Achievements
• Mastery
• Behaviour

Each category has the sub sections:

• Things to be proud of
• Things to improve

When feedback is sent, the manager is cc:ed on the email or can see the feedback in the tool, later on the person receiving the feedback sits down to go through the feedback together with the manager and come up with a plan for the next 6 months. At this point the feedback from the managers is also incorporated and any additional feedback that the manager might have solicited.

Flaws

I’ve found that this way of handling the feedback has some flaws:

• Unless asked for, there is no face to face communication about the feedback that the person receives.
• There is always room for misunderstandings in written feedback, especially in a multi-language organisation.
• There’s often a shotgun effect to the feedback you receive, since those giving feedback do not necessarily know what areas the person wants feedback on.
• Often people send out feedback requests to mailing lists. This means that everyone would receive 10-15 or more feedback requests. This can be overwhelming as it takes quite a bit of time to write well thought through feedback.

Personal growth as a team activity

As an experiment for improving the situation we are doing some significant changes to how feedback is done in the teams I’m working with at the moment.

Growth areas

First, we wanted to make sure everyone in the teams are aware of what their teammates have as their growth goals. To kick it off we had a session where everyone listed:

• Top 3 growth areas. This could be anything from Java, testing frameworks, Cassandra and BigTable knowledge to public speaking or mentoring.
• Up to 2 behaviours that they wanted feedback on. This could for instance be if they were interrupting too much, not speaking up enough or not being specific enough when doing code reviews.

Once everyone had written down their own improvement areas we went around the table and everyone told the team about the areas they wanted to improve in. This creates an opportunity for  a valuable conversation if several people had the same thing noted down. A consequence of this is that people could start looking after each other as new tasks came up. For instance, someone wants to grow their Cassandra skills a change was needed in the Cassandra cluster. The team could then help that person by giving them space and support when performing the task instead of having the person with the most knowledge pick it up and just get the job done.

Effectiveness Reviews

The inspiration for this part has come from Peer Reviews in S3 but we adjusted it to interface with the way we normally do feedback (see above). This was the process:

1. Think about 5-6 people who you would like feedback from. This can be members on your team, people you have collaborated with and preferably your manager.
2. Invite them all to a 1 hour meeting in a place and time of your choosing.
3. In preparation for the meeting a few things should happen.
   1. As the recipient of the feedback you should remind the feedback givers of your growth areas.
   2. Evereone (including the recipient) should start thinking about feedback.
   3. The recipient should consider inviting a neutral facilitator that can explain the setup and make sure the session stays on track.
4. The review would typically run like this:
   1. The facilitator starts by drawing the grid below on a whiteboard or several flip chart papers and explains the rules of engagement (see below).
      
   2. Appreciations:
      1. Everyone (including the recipient) is given 4 minutes to write appreciations connected to the 3 themes. 1 appreciation per post-it.
      2. The recipient goes first and puts up the appreciations for themselves and explains what the post-it says and what they mean.
      3. The feedback givers do the same and cluster appreciations that are similar. Here there is also the possibility to build on what have already brought up.
   3. Improvement areas are bigger themes where the person could improve to have an even greater impact (note that these are not actions that the person could take – that comes in the next step). The setup here is the same as for appreciations, write post-its, the recipient goes first and then the rest. Ideally the growth areas that you brought to the session should now be on the board.
   4. The time has now come to be concrete. For another 4 minutes the participants write up suggestions for actions connected to the improvement areas. Say for instance that you have an improvement area that is public speaking then suggested actions might be: “Do lunch and learns for the team”, “Take this public speaking class that I’ve heard is really good” or “Watch this TED talk that really helped me improve”.
   5. The session is now over. Time to thank the feedback givers for their contributions.
5. Following up from this session the person receiving the feedback creates a document where all the input is gathered and grouped into categories. You then book a time with your manager where you look at the feedback and decide what you want to focus on improving. It’s important to note here that just because someone else says you should improve in an area it doesn’t mean you need to. It’s up to you to decide how you want to grow.

Rules of engagement for the session

There should be a positive spirit to all pieces of feedback. If people start bringing up negative feedback and other people start building on it the session can quite easily turn into a bullying session that would be highly uncomfortable for the person receiving the feedback. Trust is key for the feedback to be received well. It’s the facilitators responsibility to bring the conversation back on track again if things are starting to go off the rails.

People in the session are welcome to ask clarifying questions if anything is unclear. They should however not start debating or question the feedback someone is giving.

How time consuming is this going to be?

Say that you are part of a team of 7 people and you are invited to the Effectiveness Review for 4 of them (probably the people you work closest with), then you have 1 hour spent on your own and 4 hours in the reviews for other people. You should spent a bit of time preparing for the sessions thinking about what feedback you want to give and then you need to summarise the feedback you receive. In total, in this scenario, I would guess you spend about 6 hours per person.

It’s worth noting though that this process was not designed to optimise the time people spend on feedback. It’s optimised to produce better and more meaningful feedback coupled with help with how to proceed with you own development. All of this in a setting where you as team members care, boost and look out for each other.

Learnings and next steps

When it was introduced, a few people on the team were skeptical and because of that wanted to stick with the old format. This was perfectly fine. What I wanted to provide was a variety of ways to gather feedback where people would pick the one they were most comfortable with. However, after attending the sessions for others people generally changed their minds and booked their Effectiveness Reviews.

Based on a survey I did with the team, I found out that the format above works really well and people want to keep doing it. When people had attended a session the need for a facilitator went down as people were familiar with the format and knew what to do. I’d still recommend having a facilitator to keep an eye on the rules of engagement and to be the time keeper.

We did this as a replacement for the annual feedback sessions that happens every 6 months. I can really see this being done more frequently (quarterly or even monthly) to have more continuous feedback. If you go for that you probably want to tweak the format a bit and feed in what you are currently working on and perhaps use your team to help guide you and keep you accountable to what you said you would do.