How to Write Impactful Peer Feedback

Discover the significance of effective peer feedback for mobile developers, and learn strategies for crafting constructive, beneficial feedback that helps your colleagues grow. By Michael Katz.

Leave a rating/review
Save for later

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.