performance-review-writer

Performance Review Writer

Performance reviews are legally significant, career-defining, and often written in 20 minutes from memory. That gap causes recency bias, grade inflation, and feedback too vague to act on. This skill closes it.

Before Writing: Gather Evidence First

Collect raw material from four sources before writing a word: the employee's self-review, peer feedback verbatims, the role's defined expectations for their level, and a concrete list of their work from the review period (PRs merged, projects owned, incidents handled, cross-functional contributions). Budget 2-3 hours per direct report for gathering and writing, not 20 minutes. Do not write from memory. If the list is hard to reconstruct, that is itself a signal about visibility and documentation.

Rating Calibration

Start from the role expectations document, not a bell curve. Ask: did this person consistently meet, exceed, or fall short of the expectations defined for their level? If no level expectations document exists, write one before the review cycle, even a rough draft. Ratings applied without a standard are arbitrary. Sanity-check the distribution before submitting: if more than about a quarter of your team lands in the top rating band, recalibrate against the level expectations - either you have an exceptional team and can defend each case with evidence, or your bar has drifted.

Writing the Narrative

Open with a one-sentence summary of the overall rating and why. Then structure the body around 3-4 themes drawn from the evidence, not the review form's generic categories. For each theme: state the observation, cite a specific example, and name the impact. The format is 'In [context], [name] did [specific thing], which resulted in [concrete outcome].' A full narrative typically lands at 400-800 words - shorter usually means missing evidence, longer usually means unprioritized themes. Avoid adjectives without evidence - 'strong communicator' means nothing; 'drove alignment between design and engineering on the auth redesign, reducing decision latency by cutting a recurring 3-way meeting to async' means something. Spread the cited examples across the whole review period; if every example comes from the last 6 weeks, the review is documenting your recency bias, not their year.

Development Section

Every review includes one primary growth area and one specific suggested action for the next review period. Growth areas tied to a concrete next step are acted on; vague suggestions ('work on your influence') are not. Do not list more than two growth areas - that signals the manager has not prioritized.

Deliverable

Produce a complete review packet containing: the one-sentence rating summary, the 3-4 theme narrative with a cited example and named impact per theme, one primary growth area paired with a specific action for the next period, and the evidence list used (work items, peer verbatims, level expectations referenced) so the rating survives calibration questioning.

Quality bar

• Every evaluative claim is backed by a cited, specific example - no unevidenced adjectives survive.
• Examples span the full review period, not just the final 6 weeks.
• The rating traces directly to the level expectations document, not to a curve or a gut feel.
• The growth area is specific enough that the employee could start acting on it tomorrow without asking what it means.
• The review contains nothing the employee is hearing for the first time - surprises belong in earlier 1:1s, not the written record.

Common Mistakes to Avoid

Halo effect: one visible win or loss skewing the whole rating. Recency bias: events from the last 6 weeks overweighting 12 months of work. Leniency bias: avoiding hard ratings to sidestep a difficult conversation. If a rating requires a difficult conversation, the review is where it starts, not ends.