How to Write Impactful Peer Feedback

Write to Your Audience

After writing, it’s always a good idea to reread and edit what you wrote. With something as directed and personal as peer feedback, it’s especially important that your message is received as you intend.

For it to be received properly, it’s important to know who the audience is for your feedback. Ultimately, the recipient should be your peer. In some organizations, you might share that feedback directly, while in others, you’ll give your feedback to their supervisor. That person might share the feedback directly, edit it or combine it with other feedback in a summary. It might or might not be anonymous.

If the feedback is not sent directly to your peer, you’ll need to make sure you provide enough context around each example for that person to understand the impact. The further away that person is from your work, the more you will have to include.

For example, if the peer is the only person in a large team that works with your project, their supervisor may not know very much about your work. When difficult tasks are done well, crises are averted and escalations are unnecessary, leads often don’t realize how much value their people have contributed. Peer feedback helps them get the recognition they earned.

Consider this feedback: “In October, Bill worked overnight to get us new designs for buttons on the Jellybean project. This let us complete work by the deadline, saving the project and allowing the team to book an extra 10% in sales. They were a lifesaver!”

This feedback implies Bill’s actions resulted in a 10% sales bump, but if Bill’s boss doesn’t know much about Jellybean, he might attribute Bill’s behavior to bad time management instead of going above and beyond.

Adding some additional context reduces that ambiguity:

“In October, the Jellybean project had additional requirements thrown at us by the sales team one week before the deadline. This required completely new button designs. Bill stepped up and worked overnight to get us the new designs so we could still meet the deadline. This saved the project and allowed the team to book an extra 10% in sales. They were a lifesaver!”

You’ll have to use your judgment on how well you know the audience and what they know about the work because adding too much detail can conflict with the next point regarding keeping your feedback concise.

Be Clear and Concise

As with any communication, clarity and brevity are important to ensure your message is understandable. Clarity is extra-important when writing peer feedback because it’s deeply personal — it’s about them! In some cases, the feedback is used as part of a review, even if it’s a very small part, that affects your peer’s finances, which raises the stakes.

Keeping your words clear to minimize the chance of misinterpretation not only strengthens the message but also shows the most empathy by keeping the emotional impact small.

If you keep the feedback as concise as possible and remove any extra details and words, you’ll remove chances for misunderstanding. Provide enough context that the reader understands what your peer did and its impact, but don’t enumerate all the downstream impacts — just the most important one or two effects.

Watch for Opiniated Language and Biases

One area that can help with making feedback more concise is to remove flowery, superlative, charged, opinionated or judgmental words. These include (but not limited to) words like: very, best, worst, always, never, greatest, best, rockstar, perfect, amazing, world-class, fine, meh.

Superlatives and other emotional descriptors let the reader know how you feel about a situation, but it’s hard to take action on them and give your peer the chance to grow. That’s because these aren’t precise measurements — they rely on your own judgment and biases.

Compare: “Bianca landed an amazing pull request for the Butterscotch factory.” to “Bianca’s Butterscotch pull request reduced the factory library load time by 20%“. Maybe their “amazing” solution actually doubled the binary size, and another team member wouldn’t call the decision “amazing” because they disagree with that trade-off, but it’s hard to argue with the simple fact of the impact the change had on the load time.

If you find such words, ask yourself, “Why is this example amazing, awesome, awful, etc”. Also, instead of “all the time, always, never” ask “when, exactly, did this happen?”

For feedback about things that happened once and didn’t leave a lasting impact, check your own reasons for including a one-off situation in their feedback. Does it reflect more about you, or is the example a symptom of a different behavior that should be addressed instead? Perhaps one that could provide better growth for your peer?

For example, let’s say Tamer once thoughtlessly approved a pull request that broke one of your features. Did this happen once, they learned from it and from then on didn’t repeat the mistake? Great! They’ve already gotten the feedback and learned from it — and you have a more effective teammate.

However, if that was the only code review example, but they’ve also submitted untested code that had catchable bugs and their design docs miss common use cases, that shows they have a pattern of inattentiveness. If you can then describe the impact of the pattern (increased work, loss of team reputation), you should address the inattentiveness pattern with the feedback.

Another important thing to check is that you don’t dilute your message in an attempt to soften it or to “be nice.” You might do this either by discounting the impact out of a fear of upsetting a team member or getting them in trouble, or by overstating a positive interaction because you think they deserve more credit. This instinct comes from a good place, but it’s detrimental to their growth because they won’t make a big enough improvement to meet their challenges.

For example, “It was really great that Jessie agreed to add the extra Strawberry features for a big client when we were trying to finish the Froyo project. Unfortunately, that added extra scope. We weren’t able to deliver the Freezer unit in sprint 4, so the project was delayed by a month. I would like to see them balance incoming requests better.”

You could make this feedback stronger by changing to something like: “When we were finishing the Froyo project, Jessie agreed to add extra Strawberry features for a big client. This resulted in us missing the deadline, adding a month to complete the task. I would like to see them practice pushing back on the product team for last minute requests or showing a better understanding of the feature priorities. That way, they can better meet our deadlines in the future.” This is more direct and actionable, but also a little “tougher”. The last line adds some growth reinforcement to keep it positive without softening the delivery.

You can be kind and empathic by focusing on growth and avoiding judgmental words, while still delivering tough feedback.