How do you write a good performance review?

Most managers find writing performance reviews harder than the actual performance conversation. Not because the conversation is easier, but because the review is supposed to justify it. Research from Gallup found that only 14% of employees strongly agree their performance review inspires them to improve — and in one-third of cases, review feedback actually worsens performance. The problem is rarely the manager’s judgment. It’s the quality of evidence they’re working from.

TL:DR

• A good performance review documents what happened, not what you remember. It should be built on evidence gathered throughout the period, not assembled the night before.
• Structure matters: effective reviews address contribution and impact, observable strengths, development areas, and a clear outlook for the next period.
• Recency bias is the most common failure. The last four weeks crowd out the other eleven months.
• Vague reviews create more problems than they solve. “Good communication” doesn’t tell anyone what to do differently.
• AI tools can help assemble evidence and flag inconsistencies, but the judgment and the conversation still belong to the manager.

What should a performance review include?

A performance review should document what the person contributed, how they did it, where they’re strong, and where they should develop. Start with contribution (what they did and its impact), not with an overall assessment.

Most reviews fail at the evidence level, not the structure level. The template is fine. The problem is it gets filled out from memory. That gap almost always starts with the evidence available at writing time.

A review worth having covers four things:

Contribution and impact: specific examples of what they delivered, not just role responsibilities. “Owned the migration project” is more useful than “showed strong ownership.”

Strengths: observable behaviors, not personality traits. “Explains complex tradeoffs clearly in cross-functional meetings” is actionable. “Great communicator” is not.

Development areas: one or two concrete things to work on, with a mechanism for improvement. Not “needs to work on communication” — that’s a sentence with no path forward.

Outlook: a clear signal for the next period. What should be different in six months? If there’s a performance concern, it needs to be named here, not implied.

If you’re running Slack, review threads, project updates, and feedback exchanges are sitting in the channels where work happened. That’s your evidence base, not just the form the person submitted.

How do you gather evidence before writing a performance review?

The most common review mistake is starting to write without enough material. The review becomes a reconstruction of recent memory, which means the last few weeks dominate the whole period. A 2024 Betterworks survey of 2,000+ employees and organizational leaders found that 67% of managers base performance reviews primarily on the last 2–3 months of work, regardless of review period length. A six-month review becomes a six-week review by default.

Spend 15–20 minutes gathering before you write a word. Sources to pull from:

1. Feedback already collected: What did peers and direct reports say? What patterns show up across multiple reviewers?

2. Their own self-reflection: What did they identify as wins? What would they do differently? Self-assessments often surface context you didn’t have.

3. Work output: What did they actually ship, close, build, or resolve? For technical roles: closed issues, project milestones, code review comments. For commercial roles: pipeline quality, quota attainment, or client outcomes.

4. Meeting and async interactions: How do they show up in planning meetings, retrospectives, cross-functional discussions? Notes from 1:1s, Slack threads, and call recordings surface behaviors that don’t appear in project output.

5. Your own 1:1 notes: What came up during the year that was significant? If you’re not keeping running 1:1 notes, this is where that becomes obvious.

The goal is to enter the writing phase with three to five concrete examples per dimension. If you can’t find them, the review will be vague. Not because your judgment is off, but because you’re writing from memory rather than evidence.

How do you structure the performance review itself?

Keep it short enough to be useful. A four-page review that nobody re-reads creates less value than a two-paragraph summary that anchors a real conversation.

Step 1: Start with overall contribution

One paragraph. What did this person do during the period, and what was its impact? Name specific projects or initiatives. Connect contribution to team or company outcomes, not just activity.

Step 2: Name two or three observable strengths

Each strength should be paired with a specific instance: “When the platform migration hit delays in week four, she coordinated between three teams and kept the timeline intact. This pattern shows up consistently when ambiguity is high.”

Strengths without examples are compliments. Strengths with examples are useful.

Step 3: Name one or two concrete development areas

Be specific about the gap and what improvement looks like. “Needs to improve communication” is not actionable. “Presentations to leadership lack a clear recommendation upfront. Decisions come at the end rather than the beginning” tells the person what to work on.

One well-described development area is more useful than a list of vague improvement suggestions.

Step 4: State a clear outlook for the next period

What should be different in six months? What’s the key challenge they should take on? If they’re on a path toward promotion, say so clearly. If there’s a performance concern, it needs to be named explicitly here, not implied.

Vague outlooks create false expectations. If the message is “this is a concern,” write that.

Step 5: Check for recency bias before submitting

Read through what you’ve written. Do all the examples come from the last six weeks? If so, deliberately add at least one example from the first half of the period. You’re reviewing the full period, not the most recent sprint.

Also check: are development areas phrased as personality traits or as observable behaviors? “Sometimes difficult” should become “in cross-team planning meetings, she has pushed back on scope without acknowledging the tradeoffs from other teams’ perspectives.”

What are the most common mistakes in performance reviews?

Recency bias: reviewing the last few weeks rather than the full period. Fix this by gathering evidence at the start of the process, not when you sit down to write.

Vague language: “great attitude,” “strong performer,” “communication could improve.” These provide no guidance and protect no one if there’s ever a dispute. Make every claim specific and behavioral.

Sandwich feedback: opening and closing with positives to soften a critical middle. This makes the critical content easier to dismiss. If something needs to change, say it clearly.

No path forward: naming a development area without any guidance on how to address it. A development area without a next step is criticism, not development.

Misaligned expectations: the review surfaces a concern that was never communicated during the year. The development discussion should never be the first time someone hears their performance is a problem.

The best performance reviews are not surprises. If the conversation feels new to the person receiving it, something went wrong earlier in the year.

What does a strong performance review look like in practice?

Weak: Alice has been a strong contributor this quarter. She communicates well with the team and takes ownership of her projects. There are some areas where she could be more proactive.

Strong: Alice led the Q1 API migration end-to-end, coordinating between three teams and delivering two weeks ahead of schedule despite a scope change in week four. She’s the first call when cross-team dependencies stall, and that pattern shows up consistently. The development area: in planning discussions, she often advocates for her team’s timeline without surfacing the tradeoffs for adjacent teams. A shift toward presenting her recommendation alongside its impact on other work would make her significantly more effective in cross-functional planning — and better positioned for the senior IC track she’s expressed interest in.

The second version is longer, but it’s a document someone can act on. It’s also the document that protects both manager and employee if there’s ever a question about what was communicated and when.

Taito.ai’s performance module assembles signal from Slack, Fireflies, and Linear throughout the cycle, so review-writing starts with evidence rather than blank memory. If you’re evaluating how to build this into your process, the waitlist is open.