First, because absolute feedback can be heavy, it requires full buy-in from all involved parties. Because of this, it may not be appropriate for all people and all teams to do absolute feedback with each other.
I have noticed during my time coaching that, for example, teammates that are on the autism spectrum or are otherwise neurodivergent have a difficult time answering open-ended questions. I recommend trusting your gut on whether this is appropriate for your team or not. Or— better yet— ask them if this is something they are able to participate in.
Next, absolute feedback may work better if you’re an IRL team. While I have done absolute feedback with teammates who are fully remote, it is only because the team fully trusted each other, which is easier done in-person. The bottom line is, your team must fully trust each other in order for this to be successful.
Good luck!
Make a copy of the appropriate template (above). Keep it only for yourself (the manager) until you’ve collected feedback from everyone else for the teammate.
What’s the difference between the general and engineering templates?
The general template includes generalized feedback questions (1-5, like, wish that.)
The engineering template includes more engineering-specific feedback questions (such as code quality, test coverage, etc.)
Copy the questions in the template and send them to the teammate who is receiving feedback. Ask them to fill in their scores and self-assess their performance. Then, ask them to send their answers back to you.
Here’s an example of the General Feedback Template being filled out: Sample of general feedback template in use
Then, take the same questions and send it to their immediate teammates / folks who work closely with them. Ask them to fill in the scores for each of their teammates and send them back to you.
At this point, you should still be the only person who has access to everyone’s scores. No one outside of you has access to this doc; they are only going to copy-paste the answers to you in Slack or Threads.
Once everyone has sent in their responses, copy-paste their responses into the document. Update the name so that FEEDBACK GIVER is the person giving feedback, and TEAMMATE is the person receiving feedback.
Then, summarize the overall good and needs improvement in the sections at the top so the teammate gets an “overall gist” of what their team thinks about working with them.
Finally, book a 15-20 minute appointment with the teammate and go over the feedback doc together, live. Only at that point should you share the doc with them.
Present the document live.
It is important to go over this document live and not send this ahead of time. The main reason is because you want to be there to process your teammate’s feelings in case they feel saddened, angered, or frustrated. Be there to support them and help them see that feedback is a gift!
Give them ~5 minutes to read the feedback they have received. Watch and make sure they don’t get triggered or defensive at any point.
Once they’re done reading, go over point by point which feedback they would like to accept, and decide what actions they can take to improve. For feedback they don’t accept, ask why and make sure it’s not because they are defensive. Write those actions down, assign due dates, and then paste them into their action tracker.
For further examples on how to create action items from feedback, please see: Example of recapping feedback during meetings.
Eventually, when your team is comfortable receiving feedback in public, you can try the feedback hot seat. The steps here are the same up until Step 5. Everyone pre-writes their feedback for the hot seat feedback receiver, and you copy-paste them in a doc.
The only difference is that the receiver will read the feedback live in front of all of the feedback givers. The receiver will choose the most controversial, tough feedback they’ve received to unpack in front of everyone else. Then, as they receive that critical feedback, if they choose to accept it, everyone collectively brainstorms actions that the feedback receiver can take to improve their performance.
A special thank-you goes to Nikita Zyulyaev, Senior Engineer at Mochary Method, for coming up with the engineering-specific questions. I appreciate you!
Regina Gerbeaux (@_rpgbx) is the executive coach to some of the fastest scaling startups in the world. She is also a founder currently interested in the food delivery and logistics space.
Regina was the first person trained by Matt Mochary (executive coach to the CEOs of Coinbase, Brex, and many more) in the Mochary Method Curriculum.
Her tactical templates and operational write-ups have been referenced and used by fast-scaling companies, including BioRender, Tembo, dYdX, and many more.