How to write a performance review that's fair and useful

A performance review should tell someone the truth in a way they can act on. Here is how to write a performance review built on evidence, structured clearly, and free of the biases that quietly make reviews unfair.

A review carries weight — it shapes raises, promotions, and how someone feels about a year of their work. That's exactly why so many of them go wrong: written under deadline pressure, padded with adjectives, and skewed toward whatever happened in the last three weeks. A fair review isn't about being harsh or being kind. It's about being accurate, specific, and consistent. Here's how to get there.

Start with a clear structure

Reviews read better and feel fairer when every section follows the same shape. A reliable structure:

1. Summary. Two or three sentences on the overall picture for the period. This is the headline, not a place to hide the verdict.
2. Strengths. What they did well, with specific examples and impact.
3. Growth areas. Where they need to improve, framed as next steps rather than character flaws.
4. Goals for next period. Two or three concrete, measurable things to focus on.

Use the same structure for everyone on the team. Consistency is half of fairness — it's much harder to accidentally favor one person when every review answers the same questions.

Choose evidence over adjectives

"Great communicator" tells the reader nothing they can verify or improve. The fix is to replace every evaluative adjective with the evidence that earned it. Ask of each sentence: what specifically did they do, and what happened as a result?

Compare:

• Vague: "Priya is a strong collaborator."
• Evidence-based: "When the billing migration stalled in Q2, Priya organized the three teams involved into a single weekly sync and wrote the shared status doc, which cut the cross-team back-and-forth and got us to launch two weeks early."

The second version is harder to argue with, more motivating to read, and far more useful if it's ever cited in a promotion case.

Beat recency bias on purpose

The biggest threat to a fair review is your own memory. Left alone, you'll over-weight the last few weeks and forget the strong stretch from eight months ago. This is recency bias, and it punishes people who peaked early and rewards those who happened to ship something right before review season.

To counter it, gather evidence from the whole period before you write a single sentence — old 1:1 notes, project retros, shipped work, peer comments, your own running notes. Lay the year out chronologically and you'll often find the story is different from the one in your head. (Our guide on how to prepare for a performance review covers exactly what to collect.)

If you can only remember the last month, you're not writing a review of the year. You're writing a review of the last month.

Example phrases you can adapt

Use these as scaffolding, then attach your own specifics. The phrasing matters less than the evidence you hang on it.

Strengths

• "Took ownership of the onboarding revamp end to end — scoped it, ran it, and shipped it without needing to be chased."
• "Consistently the person teammates go to when they're stuck; mentored two new hires through their first quarter."
• "Raised the data-quality issue early in the quarter when it would have been easy to stay quiet, and saved us a much larger cleanup later."
• "Handled the client escalation in March calmly and kept the relationship intact under real pressure."
• "Improved the deploy process so releases went from a weekly scramble to a routine non-event."

Growth areas

• "Tends to take on too much alone; delegating earlier would protect both the timeline and your own bandwidth."
• "Written updates sometimes assume context others don't have — adding a one-line summary up front would help."
• "Strong on execution; the next step is influencing direction earlier, before decisions are already made."
• "Estimates have run optimistic on the last two projects; building in buffer and flagging risk sooner would help."
• "Feedback in code review can come across blunt in writing; a little more framing would land it better with the team."

Keep it fair

Before you submit, reread the whole thing and check: Is every claim backed by something concrete? Would this language read the same if the person were a different gender or background? Are you holding them to the same bar as their peers? Is there anything in here that will be a genuine surprise — and if so, why are they only hearing it now? A review should never contain a surprise. If something needed saying, it should have been said in a 1:1 months ago, not buried in a form at year's end.