How to Write Impactful Peer Feedback

Developers spend so much time focused on technical output that it’s natural to feel apprehensive when our organization asks us to write peer feedback. Some feel uncomfortable because writing peer feedback isn’t a skill they’ve practiced, and they know how important fair feedback is. Others worry that what they say will be taken badly, damaging a working relationship. And some might not know how to get started.

In this article, you’ll learn the basics of writing impactful peer feedback. The tips shared here are geared toward formal peer feedback as part of a review process, but they can also be useful for ongoing feedback outside of any process.

Note: Here, we’ll define peer feedback as: “written communication that you provide about a non-supervisory coworker with whom you’ve interacted in the recent past.” For this advice to be useful, your peer should be someone whose work has impacted yours and with whom you’ve had direct contact in the course of your role.

What You’ll Learn

• A framework for writing concise, impact-focused peer feedback.
• Tips to communicate critical and constructive feedback with empathy.
• Some words and phrases to avoid and what to write instead.

Why Peer Feedback Is Important

Why even share feedback with your peers? The most common reason why our organizations ask software developers to do this is to get input for a performance review. Peer feedback is often used as evidence or validation for an employee’s technical skill assessment or for how well they collaborate with others. Writing good feedback will help your colleague get a fair assessment so they can create a sensible growth plan.

That’s how your review helps the org, but there are better reasons for writing peer feedback that helps you and your peers.

The first is that this is an opportunity to invest in the growth of your peers. Feedback provides information about how their behavior impacts others (especially you!), reinforcing the things they do well and helping them adjust the areas that need improvement, helping them be more effective in their job.

It’s not just altruistic, however. Making your colleagues more effective gives you the opportunity to be more effective. When they collaborate with you better, your partnership becomes more efficient, producing work that complements yours and increasing overall output. Their growth might mean you need to spend less time helping them, freeing you to accomplish more on your own projects.

Now that you know why peer feedback is so important, it’s time to learn how to do it well.

The Feedback Writing Process

Good feedback is an iterative process that requires thought and preparation. The first step is to gather examples and observations of what your peer did with you during the feedback period. For the feedback to be meaningful and actionable, you need to tie it to specific examples of behavior. This step is easier if you work with the peer frequently, if the feedback period is short and if you have good notes and records for that period.

Since these observations are the “raw material” for the feedback, it’s important not to short-change the process, so start it as soon as you can to give yourself as much time to recall events as you can. Check in with other peers if you need help recalling specifics. And unless your involvement is a secret, don’t be embarrassed to reach out to your peer for additional information and context to jog your memory about older projects.

This is where you’ll encounter the first of several biases that you want to watch out for: recency bias. That’s when you subconsciously give extra importance to more recent events than earlier ones.

Unless instructed otherwise, it’s fairer to consider situations from throughout the entire feedback period. This way, your peer learns from their entire range of experience, and you’re not judging them solely on their last project.

The difficulty of keeping an accurate history and the fact that past events naturally lose relevance over time highlight why feedback is best delivered as soon as possible. For this reason, short evaluation periods are better in this regard.

Picking Events to Cover

Try to find events where your peer’s behaviors, actions or work had a direct effect on you so you can describe the impact from a personal perspective. These examples will generally fall into three buckets:

• Something had a very positive impact on you. Examples include: going out of their way to help debug a hard problem or covering an on-call shift so you could attend to a personal matter.
• The event was somewhat positive or neutral, but it could have been better if your peer had done something differently. Some examples of this are: They delivered their code on time, but it had a few bugs that you had to help fix. Or maybe they shared a technical design that received a large amount of pushback, which they could have avoided if they’d discussed it with you first.
• The third bucket includes things that have a real negative impact. This might include missed deliverables, not responding to pager shifts causing you to work after hours or breaking continuous integration in a way that prevented you from landing code to hit your deadlines. Depending on the severity of the impact, it’s both kinder and more effective to deliver that feedback to your peer or their supervisor at the time so they can address that behavior immediately.

Managing Concerns About Giving Peer Feedback

Usually, you’ll be asked to provide feedback on both things that went well and things that did not go well. Many developers feel like they are pushed into an uncomfortable place where they have to say something negative about a coworker. Some feel like they’re being forced to “sell out” their peers.

The best practice to avoid these bad feelings is to frame the event as a growth situation. Instead of focusing on what they did wrong, think about what they could have done better.

For example, if the situation was a code change leading to a performance regression, the growth opportunity could be learning about the test tools to verify changes. This not only helps you keep your perspective but also makes for better overall feedback.

This mindset works especially well when you need to come up with growth feedback but are having trouble identifying any real misses on their part. It’s rare that anyone executes their work perfectly, so you can find something that went well but could have been even better.

For example, if your peer wrote a script that reduces the build steps for one platform of a multiplatform app, suggest that they could build on that by expanding it to the other platforms.

If there are no specific instructions, be sure to provide an even (or positive-biased) mix of reinforcing feedback (“you did X well”) and growth feedback (“you could do Y better”). Including both messages increases the odds that your peer will be receptive to your message and able to trust your growth suggestions so they can work on them and improve in the future.

What to Focus On

With examples of positive, neutral, and growth-needed interactions in hand, it’s time to format them into feedback. To make the feedback useful and to reduce the chance of misunderstanding, hurt feelings or argument, focus on the impact your peer’s actions had on you, the project or the organization.

Keeping the feedback in your own voice makes it authentic, which helps the reader accept it. After all, it’s easier to trust that the words come from a place of support if it sounds like it’s from someone we know rather than generic corp-speak. But that can be hard to do, so here’s a template to help you get started.

Here are some examples:

• Last March, Amy started a Modern Concurrency in Swift book club for the team. I learned several new techniques; as a result, I’ve made my code 10% smaller and a lot more reliable. I look forward to our next book.
• In version 3.1, Gus forgot to enable the Ice Cream widget feature flag, so our experiment went live to all our users. Fortunately, this was a minor change, but I had to stop the Fudge project to immediately revert the change and push out a temporary fix, losing three days. I showed Gus the experiment validator, so next time he should be sure to test changes in staging before releasing to production.

This template follows a lot of common feedback models that follow the pattern of describing a behavior, that behavior’s impact, and then a resolution. There are quite a few (trademarked and copyrighted) feedback models that you can find with an internet search, but they mostly boil down to a few points that you should consider when providing feedback:

• Be specific.
• Be timely and relevant.
• Focus on behavior and impact.
• Be personal.
• Be kind and empathic.

You’ll look at each of these next.

Be Specific

Specificity is important because concrete examples will help the receiver to recall the experience and to review it from your perspective. Your colleagues might dismiss or argue against general feedback because they can come up with counterexamples.

Furthermore, avoid adverbs like always and never. People rarely do something every time, and charging your feedback with those words can read like an accusation, causing your peer to reject your feedback. Instead, pick one clear example of when the behavior had an impact. If it was the build-up over time that caused an impact, lay out the specific frequency and time frame over which the event occurred.

For example, instead of “Matt always reviews my code on time, which is really helpful. He should keep that up.” Try something like “For each sprint of the waffle cone library, Matt reviewed my code within a day, allowing me to complete my tasks within their sprints. He should keep that up.”

This is specific to “each sprint of the Waffle Cone library“, which assumes the reader knows with enough specificity what those are. This is also specific to the impact: Instead of just labeling the behavior as “helpful”, it states that it allowed the writer to complete their work on time.

Be Timely and Relevant

Alongside specificity sits timeliness and relevance. The feedback should be about the work that happened within whatever period that you’re asked to consider for feedback. Don’t hold on to errors that happened in the past if your colleague hasn’t done them recently; they may have learned and grown from past mistakes.

It’s also not appropriate to provide feedback if there is no professional impact. If they planned a team outing and you did not like the lunch choice, it’s okay to politely let them know at the time, but it should not be part of formal peer feedback. (Unless the person’s job includes regularly ordering lunch — then it might be relevant).

As already stated, your goal should be to focus on behavior: What your peer did and its impact, as well as what was the result.

For example, if they have a lousy demeanor and dismiss others’ ideas out of hand, don’t write “Rich is a meany who doesn’t listen to his peers.” This is inappropriate even if you phrase it in a less charged way: “As shown in meetings over the last two months, Rich doesn’t listen to his peers.”

This is a judgment statement about Rich’s character. This type of feedback also has two undesirable side effects: It’s likely to elicit a defensive reaction, and it doesn’t provide any room for growth.

Instead, try something along the lines of: “At the Gumdrop meeting, when Tammy suggested we use the Strawberry library, Rich rejected the idea without giving her a chance to explain the benefits. At the Sprinkles meeting, when I brought up switching databases, Rich quickly responded that it would take too long, even though I think we had a viable mitigation. When this happens, people on the team feel like our ideas are not valued and it makes it harder to contribute in the future.”

In this example, instead of focusing on what Rich is or does, you refer to specific behaviors he did and calls out the impact that it had. This also follows the guideline of being specific, relevant and personal.

Be Personal

Meaningful peer feedback should be based on how your peer’s behavior affected you directly or on interactions you directly observed. When feedback is based on indirect observation, you might lack important context. Furthermore, there generally isn’t time for a supervisor to gather enough information to make fair use of the information. It also dilutes the message.

Be Kind

Finally, and most importantly, be kind and empathic in your writing. Read over your feedback and ask yourself: How would I feel if I received this feedback? The purpose is to help your peers grow and be more effective in their roles. The result of the writing should never be to make yourself feel better, get revenge for a past wrong or show off your own coaching greatness.

As a simple rule: the content of your feedback should be about the impact of their behavior on you, your team or your project. The impact of your feedback should be on their growth.

With these rules in mind, you can take a few examples and turn them into feedback, and you’re done… Well, almost.

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.

Bringing Up Serious Issues

Sometimes, you have serious complaints about a peer, like major lapses in judgment, incompetent work, low output and violations of company policy. In that case, this style of peer feedback is probably not an appropriate place to raise the issue. Serious complaints are best addressed right away with a supervisor or HR partner. This format does not provide enough context, and most folks will take descriptions of a serious complaint as an attack and not be open to feedback about it.

Follow Guidelines and Templates

This advice, by nature of a web article, is generic. If your company provides specific guidance in terms of a template, framework or list of what to include, you should follow those instructions over anything listed here. Following company guidance is important for your feedback to be received effectively. In this case, that means conforming to the audience’s expectations. Make it easy for them to read and process what you have to say.

That also means that you should meet any deadlines that are part of a review cycle process. Timeliness ensures that your feedback will be more effective because it will have the proper amount of time for your peer’s manager to integrate it into a performance review or to be received by the peer when they are in the right mindset to accept the feedback.

Getting Feedback

If possible, and if you have time before a deadline, it’s helpful to get a second set of eyes to give you feedback on your feedback. See if you have access to a manager, mentor, or HR partner that can provide that for you. Just be careful that a lot of organizations consider peer feedback confidential information of the recipient, so use your judgment about whom you share it with.

Where to Go From Here?

Now that you’ve seen a general framework on how to structure the feedback, some things to include and what to avoid, the next obvious step is to go write some feedback for your colleagues.

If that feels high stakes, find a friendly colleague or two to practice on and ask for feedback on your feedback to them. Start with letting them know about something they do that has a positive impact on your work. Folks rarely bristle about the message when you say they did something nice.

Key Takeaways

• Focus on specific incidents that demonstrate your peers’ impact on you, your team or your project.
• Be kind and remember your feedback helps them grow.
• Feedback should be specific, timely, focused on impact, personal and empathetic.
• Before submitting, reread your words and check for biases and clarity.

Come join the forum and give us feedback on this article! Let us know if this had an impact on your peer feedback and indirectly on your peers. Please use a growth mindset and let us know what we could do to make this message even more useful in the next revision.