Being aware and able to improve yourself is tricky at the best of times but without any feedback, how do you even know what to focus on next? Obviously, in tech, we’re quite familiar with the benefits of faster feedback so what if we use this principle on our own individual development? This is where the Speedback model comes in.

The problem(s)

  • Software engineers are constantly looking for opportunities for technical improvements but often overlook their own personal development.
  • Engineering Managers (or equivalent) are trying to get the best out of their people, recognising achievements and identifying areas of improvement.
  • Annual reviews often seek peer/360 feedback to support the self-reflection with external thoughts and opinions but it can be painful to get any responses.

A solution

I caught wind of a ‘speedback’ concept last Summer which creates a speed-networking environment but focused on personal feedback (hence the puntastic wordplay).

Speed-networking + faster feedback = Speedback

Ideally, this would be facilitated in a physical location with everyone present ready to rotate around the space. But, like many companies through the 2020-1 pandemic, we’ve shifted predominantly to remote working so this introduced a further challenge.

With this in mind, here’s how I approached it:

  1. Book a time when all members of the team are available, typically an hour but dependent on team size. For a team of six, an hour should cover it but 90 minutes will allow for any over-running.
  2. Inform the team in the description to prepare for each team-mate (you’ll probably need to remind them nearer the time too):
    – one behaviour observed that yield positive outcomes
    – one behaviour observed that could have been done differently/better
  3. Once you know who’s attending, create a schedule for each possible pair. I used Fixture List — choose Player participant type and Once Only meetings, enter all the names and generate the schedule.
  4. On the day, setup breakout rooms in Teams (or Zoom) for each sub-session. Ideally, this should be for each combination (e.g. Jon & Sarah) but you can try creating rooms for each pairing (Pair A, B, C) that can be updated each round (first, second, third). 
  5. As facilitator, you will be managing these breakout rooms for each round so you might benefit from an additional person supporting.
  6. Start the session, remind everyone of the format, to take notes where possible and answer any questions/concerns. Maybe break the tension with some banter or a quick icebreaker.
  7. Agree a suitable duration for each round. I found five minutes too short and 10 minutes quite loose — eight minutes seemed about right. MS Teams has a setting for enforcing this with a countdown timer in each breakout room.
  8. Allocate the pairs to their respective rooms and commence the speedback sessions.
  9. If you have odd numbers, there might be an odd one out on each round. Suggest they use that time to prepare or make notes whilst they’re fresh.
  10. Between each round, the facilitator will have to rearrange the breakout assignments. Propose more banter whilst this is actioned as it can be quite tedious in MS Teams/Zoom and will keep morale high.
  11. At the end of all breakout rounds, make sure everyone had time to give and receive all their feedback. If they ran out of time, suggest using one of the rooms during any remaining buffer time or arrange a follow-up call at a time that’s convenient.


I facilitated four of these sessions throughout August, first as a pilot with fellow tech leads then with minor iterations across three different engineering teams (with six or seven participants, myself included).

Every session had fantastic responses such as it was really useful to recieve some honest feedback from peers, recognition for areas they’re strong and suggestions for what to focus on next. They liked the dedicated time with each other, especially when they don’t typically get the opportunity for non-work chat. It was also perfect timing as it was right before the end of our annual review cycle so they had content to help reflect on the past year and what to focus on next.

Most teams praised the format and would like to make it a regular occurrence, possibly introducing to retrospective formats or ideally providing the feedback more frequently throughout the working day, e.g. after a pairing session, team meetings/workshops or observed through business/team contributions.

When it came to note-taking, many people struggled to keep up/multi-task — I’m quite fortunate to have gained the ability to scribe in the moment so appreciate I’m an exception to the rule. One suggestion was to make notes immediately after the session or even ask your team-mates to share any prepared notes straight after.

Some engineers find it difficult to give much constructive criticism (even when they know it can be anonymous) and especially when it’s face-to-face. To gain confidence with some teams, we focused on positive feedback for the first round with future sessions to balance both but we could also provide coaching on how to structure comments without causing tension.

To ensure the context was set with some inspiration and structure, it can be beneficial to outline some topics to focus on, for example, technical skills, soft skills, or specific examples of behaviours. 

As mentioned before, this model would be best suited for a physical room to eliminate the tedious UX of pair management between breakout rooms. For teams who are predominantly remote, there must be a better solution for organising the pairs in Zoom or Teams — maybe an extension, plugin or hack for the software would help.

On reflection, I was pleased with the results from the first iteration of introducing the speedback model to our teams. As we experiment with more formats, it’ll be interesting to see how the culture of feedback improves and how our engineers grow over the next 6–12 months. I highly encourage you to trial some of these concepts with your engineering teams and would love to hear how you get on.