How to Write a Performance Review for a Direct Report

A self-review is your case for yourself. A performance review you write for someone else is a different document entirely: it is a rating you have to defend in a calibration meeting, evidence someone else may read months later, and, for the person receiving it, the single clearest signal all year about where they stand.

That combination makes the writing harder than it looks. Managers either over-hedge until the review says nothing, or write fast and generic and leave every rating unsupported. Both versions fail the person reading it and the manager who has to stand behind it later.

Write The Behavior, Not The Trait

“Great communicator” and “needs to be more proactive” are verdicts, not evidence. They tell the reader your opinion without showing the moment that formed it, so the employee cannot repeat what worked or fix what did not.

Before:

Sarah is a strong team player and communicates well, though she could be more proactive about flagging risks.

After:

When the API vendor missed two deadlines in March, Sarah organized a daily sync with the affected teams and kept the launch on schedule. On the Q2 migration, a scope risk surfaced in week three that reached me only after the sprint review; flagging it as soon as she noticed it would have given the team an extra week to plan around it.

The second version is longer, but it is the version that survives being read back to the person, and the version that would still make sense to someone who was not in the room. Trait words invite an argument; specific moments do not, because they already happened.

Make Every Rating Defensible With One Piece Of Evidence

If a rating cannot be traced to at least one concrete example, treat that as a sign the rating is not ready to send. A rating with evidence attached is one you can explain in a calibration meeting without reaching for memory, and one the employee can actually contest or accept on the same terms.

SHRM’s guidance for managers writing reviews makes the same point from the other direction: describe the conduct, not the individual, and keep observations tied to job impact rather than character. A rating of “needs improvement” attached to a named project and a specific gap is useful. The same rating attached to nothing is just a mood.

Separate What Happened From Why You Think It Happened

It is tempting to explain a shortfall by guessing at motive: “seems disengaged,” “doesn’t prioritize well,” “isn’t taking this seriously.” All three are theories about the person’s internal state, and none of them are things the employee can verify or dispute on the facts.

Before:

Doesn’t seem to prioritize the roadmap work and often seems checked out in planning meetings.

After:

Roadmap tickets assigned in the last two sprints have slipped past their estimate by three or more days each time. In the last two planning meetings, the roadmap items were not raised until I asked directly.

The rewrite drops the psychological read entirely and reports what was observed. If there is a real explanation, the employee now has room to give it; a review that states a verdict about someone’s motivation leaves them nothing to respond to except the accusation.

Write The Growth Path, Not Just The Verdict

A review that stops at the rating has done half the job. The other half is naming what changes next, specifically enough that both people would recognize success six months later.

To move to the next level, the code review turnaround needs to come down from an average of three days to one. I’d like to see that hold for two consecutive quarters, with the current backlog cleared by the end of this one.

This close is the part employees reread the most, because it is the part that tells them what to actually do differently, rather than just how they were graded on what already happened.

Since a draft written after a long day of reviews tends to run either too blunt or too soft, it is worth a rewrite pass before it goes out. A Wrivio Context for performance reviews could say:

Rewrite this performance review to replace trait adjectives with specific, dated examples. Keep every rating tied to at least one concrete instance. Report observed behavior only, never a guess at motive or personality. Keep the growth-path section specific and measurable. Do not soften a stated rating or add praise that is not in the draft.

Press Ctrl+Shift+Space, paste the draft into the overlay, and check the diff for anything that got vaguer instead of clearer, since that is the direction these drafts tend to drift.

Performance reviews contain another person’s evaluation and often their compensation trajectory, which is exactly the kind of sensitive document worth running in Local mode rather than sending to a cloud tool. Local mode processes the text on your PC and never sends it anywhere.

Read It As The Calibration Committee Would

Before sending, read the review once as the person who has to defend every rating in a room without the employee present. If a sentence would not survive the question “what specifically happened,” rewrite it or cut it. This is a stricter test than “does it read as fair,” and it is the one that actually protects the rating.

A review that passes it does the job a review is for: it tells the employee exactly where they stand and gives you language you can stand behind if anyone ever asks you to. Compare this to writing a self-review, where the same evidence-over-adjectives rule applies from the other side of the desk, or to giving critical feedback in writing more generally, outside the formal review cycle.

Common Questions

How long should a performance review be for one direct report?

Long enough to cover every rated category with at least one specific example, and no longer. Most useful reviews run 400 to 800 words per person; padding with generic praise does not make a short review more thorough, it just buries the parts that matter.

Should a performance review mention things that were never raised during the year?

No. A rating tied to an issue the employee is hearing about for the first time is unfair regardless of how accurately it is written. Raise problems when they happen; use the review to summarize a pattern, not to introduce one.

How do I write about a growth area without it reading as a punishment?

Pair the observation with a specific, achievable target and a timeframe, the same way a manager would explain a project plan. “Turnaround needs to improve” is a judgment. “Turnaround needs to come down to one day, held for two quarters” is a plan, and a plan reads very differently even when the underlying message is the same.

Is it okay to reuse the same review structure across a whole team?

A consistent structure across your team is good practice, since it makes ratings easier to compare fairly. What should never repeat is the evidence: if two reviews cite similar phrasing for different people’s work, that is usually a sign the specifics were skipped rather than genuinely written for each person.

What if I disagree with the rating my own manager wants me to give?

Write down the evidence you actually have and let the rating follow from it rather than the other way around. If the evidence does not support the rating you were asked to give, that gap is worth raising with your manager directly, in writing, before the review goes out.

Download Wrivio for Windows to turn a rushed review draft into one you can defend line by line.