Every 6 months at work, I need to write performance reviews for the people I work with (who are all excellent). I find this really hard! Who am I to review how well someone is doing? I’ve only recently started to feel a little more comfortable writing peer feedback, and what’s helped me is to focus on saying things about the person’s work that are both positive and constructive. My goals in writing a performance review are to write something that will be useful for the person to read, and make sure that the higher-ups reading the review understand why that person’s work is important.

It’s very easy to write positive feedback that isn’t useful – “X is so great!” “I love working with X!” “X is one of the best developers I know!”. But positive feedback can (and should!) be useful. My goal is to write really specific positive feedback explaining exactly what about that person’s work is great.

Positive constructive feedback obviously isn’t the only kind of feedback but I find it’s the easiest starting point for me. For a broader view (which also talks about negative feedback) the radical candor blog has some good posts.

Here are 3 strategies for giving useful positive feedback! I obviously didn’t invent any of this – lots of people I work with give feedback in this style.

talk about their strengths!

It’s super useful to highlight what you see as someone’s strengths! Like if you tell someone that you think code review is a huge strength of theirs, it’s a great way to encourage them to continue investing time in code review. For example:

• X gives extremely useful code review and it helps folks on the team level up
• X has a lot of expertise in and is great at sharing that expertise which has really helped us move more quickly on Y project
• X is great at proactively working on systems that aren’t currently on fire, but are going to be on fire in 3-6 months if we don’t intervene. This means that as a team we spend way less time firefighting.

I like to give specific examples of how I see those strengths playing out in practice, like “X is really good at helping figure out tough technical decisions, we were really struggling to figure out what approach to take on Project Y and they asked helpful questions that let us figure it out”.

I also try to be careful about a couple of things – first, I think it’s important to highlight strengths that are actually a key part of the person’s job. If you’re talking about a programmer and your primary feedback is something like “X is really organized”, you can accidentally end up implying that they don’t have other skills that are more directly important to the job. Second, I think about what level the person is at and try to highlight things at the appropriate level. Like the kinds of strengths I’d talk about in an intern are different from what I’d talk about for a senior developer.

talk about their impact!

This is one of my favorite things to talk about! Why is this person’s work important to the organization? Did they do an especially good job on a specific project they worked on?

A few different possible kinds of impact to discuss:

• X did <specific project> and executed it really well. Here’s why that project is important and some of the specific contributions/decisions they made along the way that I thought were especially good. For example “built especially great tests early on, which helped other folks contribute with confidence” or “did $HARD_THING which normally wouldn’t be part of their job but really helped the project succeed”
• X helped me a lot, for example “I couldn’t have done project Y without X’s support, they helped me in these specific ways”. 1:1 mentoring is incredibly important but often not that visible to other people, so bringing it up in a perf review helps makes sure it’s recognized.
• X helps raise our standards as a team in some way, for instance “X knows a lot about accessibility and always brings it up in code review / advises other team members on best practices in a way. Our site would not be as accessible without X’s work.”

Sometimes when doing this I’ll hunt through the person’s pull requests / emails they’ve sent about their work to make sure that there isn’t some Big Important Thing they did 6 months ago that I’ve temporarily forgotten about.

I’ve also started asking “hey, do you have a document listing your recent successes that I can look through to make sure I haven’t forgotten anything?“. Some people keep one, and it’s really helpful when they do!

talk about the future!

In our perf review form there’s a “what could this person be doing better?” section. This is where more negative feedback often goes (“what didn’t go well last year?”). But there’s also a lot of room for positive feedback here! Of course the work this person is doing next year is going to be different from the work they did this year. So how could their next year be even more awesome than this year? What would that look like exactly?

Here are a few possible forms of this:

• Suggest a specific (maybe ambitious!) goal/milestone that you think would be great to reach.
• Point out something they’ve been doing in a small way (for example leadership work) and suggest that they do more of that next year.
• Suggest a focus area – “you’re doing a great job of A, B, and C, and I think focusing more on A next year would be good”
• Pick something you know the person wants to do/prioritize in the next year (that you agree is important) and suggest that to them!

In general I think the “what could be better?” section is a really great place to affirm / reinforce goals that I know the person has already, as well as to suggest things to them that I think they might like to work towards.

negative feedback shouldn’t show up for the first time in a perf review

Negative feedback is out of scope for this post but one principle I find useful is “don’t bring up negative things for the first time in a performance review”. If I come up with a new thought about something that hasn’t been going well (especially if it’s something I haven’t thought about in depth!), I think it’s better to mention to the person outside of the context of the perf review instead.

My view right now is that poorly-considered negative feedback is much more destructive than poorly-considered positive feedback, so I’m much more likely to include positive observations that I’m not 100% sure of than negative ones. I’ve written a bunch of performance reviews which contain no negative feedback, which I’m fine with. I’d much rather include no negative feedback than negative feedback that’s poorly thought through and unlikely to be helpful.

spending time on feedback is worth it

The perf review feedback form at work says “this should take about 30 minutes”. I don’t really think that’s reasonable – to really make sure I’ve remembered all of the interesting things someone has been up to in the last year I often end up looking through their pull requests, which takes quite a while. I think spending a few solid hours making sure I’ve really thought through the person’s contributions, what impact they’ve been having on the team/company, and what awesome things they could be doing next year is a good use of time.

I really appreciate it when I get really thoughtful + insightful feedback about my work from other people, and if I can do that at all for someone else I think that’s a really good thing.