Skip to content
Writing Style Library

Performance Review

A written evaluation of one person’s work over a period, against expectations, with direction for what is next.

Performance Review

Section titled “Performance Review”

A performance review is a written evaluation of one person’s work over a defined period, measuring it against expectations and goals, naming specific strengths and gaps, and setting direction for the next period. The document belongs to the manager: it is authored by the evaluator, not the subject, and it carries formal weight inside the organization. A performance review that does not cite specific behaviors or outcomes cannot be acted on, defended, or developed against - evidence is the load-bearing element.

The format divides into a backward-looking half (what the person did, measured against what was expected) and a forward-looking half (what should change, what goals are set, what development is needed). Both halves are necessary. A review that names only the past without setting direction is a verdict, not a developmental tool. A review that sets only future goals without evaluating the past has skipped the assessment that gives the goals their weight.

Unlike a retrospective, which is a collective team exercise examining how a team’s whole working process went over a period - surfacing what went well and what the team will change together - a performance review evaluates one individual’s contribution and growth. It is not a team document. The subject of a performance review is a person; the subject of a retrospective is a process. A manager running a performance review cycle and a team running a retrospective are asking fundamentally different questions of fundamentally different subjects.

Canonical template

Section titled “Canonical template”
# Performance Review: [Employee Name]


## Period
[Start date] to [End date]


## Reviewer
[Manager name and title]


## Summary
[One to two sentences naming the overall assessment. Be direct.]


## Performance Against Goals


### [Goal 1]
Rating: [Met / Partially Met / Not Met]
[Specific evidence of what the employee did or did not accomplish. Cite behavior or output.]


### [Goal 2]
Rating: [Met / Partially Met / Not Met]
[Specific evidence.]


## Strengths
- [Named strength, with a cited example from the period.]


## Development Areas
- [Named gap, with a cited example and why it matters for this role.]


## Goals for Next Period
- [Specific, measurable goal] - by [date or quarter]


## Overall Rating
[Rating label per the organization's scale]


## Additional Notes
[Anything material that does not fit the sections above]

When to use

Section titled “When to use”

At an annual or mid-year review cycle when a formal written evaluation is required; when an employee’s progress against goals must be documented for development or compensation decisions; when a probationary period has ended and continuation or role adjustment needs a written record; when a manager needs structured, documented feedback that goes beyond a 1:1 conversation; when building a paper trail to support a promotion case or performance improvement plan.

When not to use

Section titled “When not to use”

When the feedback is about how a team’s process worked, not how one individual performed - use a retrospective for team process reflection; when the goal is a real-time coaching conversation rather than a formal written record; when there is no defined period of work or no expectations the employee was held to.

Pairs well with

Section titled “Pairs well with”

coach, senior-consultant, candid, diplomatic, comparison-contrast

Often confused with

Section titled “Often confused with”

retrospective: A retrospective is a structured look back at a completed period of work - a sprint, a project, or a quarter - that surfaces what went well, what did not, and what the team will change. It is a collective team document: observations represent the whole team, the format runs on a regular cadence regardless of whether anything went wrong, and its product is a shared list of commitments for change with named owners. A performance review evaluates one named individual against their own goals and expectations, is written by their manager rather than collaboratively, and is tied to that person’s development and formal standing. When the question is “how did we work as a team?” a retrospective applies; when the question is “how did this person perform against their expectations?” a performance review applies.

Tells

Section titled “Tells”
  • Subject is a named individual evaluated against stated expectations or goals from a defined period
  • Written by the manager or evaluator, not the person being evaluated
  • Structured sections for backward-looking assessment (strengths and gaps) and forward-looking direction (next-period goals)
  • Specific behaviors or outputs are cited as evidence; general impressions do not appear without a grounding example
  • An overall rating or summary verdict appears, often tied to an organizational scale
  • Language is calibrated - neither harshly clinical nor vaguely warm, but precise and developmental
  • The development section names what changes, not just what fell short

Anti-patterns

Section titled “Anti-patterns”
  • Writing vague praise without citing a specific behavior or output (“great team player,” “strong communicator”) - A review without evidence cannot be acted on by the employee, defended by the manager, or used by the organization; specificity is the minimum unit of useful feedback.
  • Omitting the development or forward-looking section entirely - A performance review without direction for what comes next delivers a verdict but no development path; the forward section is what earns the review its place as a management tool, not just a grade.
  • Running a performance review instead of a retrospective when the feedback is about team process - A retrospective is a structured look back at how a team’s whole working process went over a period - it surfaces what the team will change collectively, with observations that belong to everyone; a performance review evaluates one individual and is owned by the manager, so applying the individual-evaluation frame to collective process questions produces a category error.
  • Filling the review with incident reports and compliance language borrowed from HR escalation documents - A performance review is a developmental and evaluative document, not a disciplinary record; incident-report language shifts the register to adversarial and undermines the developmental contract the format is built on.

Failure modes

Section titled “Failure modes”
  • Calibrated specificity over-extends into a legal audit - every statement is hedged with documentation language, every example is framed as evidence in a case, and the document reads as a brief for a tribunal rather than a developmental conversation - Test whether the review would still be useful to the employee if HR framing were stripped away; if only the audit language remains, the document has crossed from evaluation into indictment and needs to be rewritten at a human register.
  • Diplomatic framing over-extends into opacity - every rating is softened, every development area is buried in qualifications, and the reader cannot determine their standing or what they are actually expected to change - State the rating and the development area directly before adding framing; a reader who cannot name their verdict and their one key development item from a 10-minute read has received a document optimized for the manager’s comfort, not for their own development.

Instruction

Section titled “Instruction”
Write as a formal performance review. Evaluate a named individual against stated goals or
expectations from a defined period. Structure the document in two halves: a backward-looking
assessment (what was accomplished, what fell short, citing specific behaviors or outputs as
evidence) and a forward-looking section (goals for the next period, specific development areas).
Both halves are required - a review without a verdict is incomplete, and a review without
direction is only a verdict. Name strengths with cited examples. Name development areas with
the same specificity and say why each matters for the role. State the overall rating clearly
before adding any qualifying framing. Do not use vague praise without grounding examples.
Keep the register calibrated - neither clinical nor warm to the point of ambiguity; the purpose
is developmental clarity, not documentation of a case or avoidance of discomfort.

Template

Section titled “Template”

See the Performance Review template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Coach, Senior Consultant, Candid, Diplomatic, Comparison-Contrast

Avoid with

Section titled “Avoid with”

Playful, Reverent, Urgent

Often confused with

Section titled “Often confused with”

Retrospective

Examples

Section titled “Examples”

Performance Review: Maya Reyes

Section titled “Performance Review: Maya Reyes”

Period

Section titled “Period”

January 1 to June 30

Reviewer

Section titled “Reviewer”

Jordan Ashworth, Director of Engineering

Summary

Section titled “Summary”

Maya set out to close a real equity gap in the team’s daily rituals and hold operational quality steady while the team scaled from 6 to 11 engineers across four time zones. She closed the equity gap decisively; the operational discipline around the new process needed a production incident to force the fix instead of being planned in from the start.

Performance Against Goals

Section titled “Performance Against Goals”

Close the cross-timezone participation gap in daily team rituals

Section titled “Close the cross-timezone participation gap in daily team rituals”

Rating: Met

Maya diagnosed the problem with data before proposing a fix: Q1 data showed India-based engineers averaging 3.2 standups out of 5 per week against 4.6 for US-based engineers, traced to the meeting time - 9am Pacific, 9:30pm IST - not disengagement. She weighed three alternatives in the ADR (rotating the meeting, dropping standup, a paid third-party tool) before replacing the sync meeting with an async post to #team-standup and a weekly Thursday working session, ran it as a scoped 30-day trial, reported progress weekly to me and to peer EMs, and closed it with a retrospective. By the final two weeks, IST-based engineers were posting every weekday for the first time in this team’s history, and the team voted to extend the format permanently.

Hold operational discipline steady while the team scaled from 6 to 11 engineers

Section titled “Hold operational discipline steady while the team scaled from 6 to 11 engineers”

Rating: Partially Met

The trial exposed gaps in how the process was operationalized. On Day 11, an @mention flagging a blocked dependency went unanswered through triage because that morning’s pass had no dedicated @mention scan and missed it inside one of eleven posts; the blocked engineer escalated by direct message two hours later, and the incident did not fully close until 13:30 Pacific, four hours fifteen minutes after the original post. Triage load ran about 25 minutes per morning against a 10-minute target for most of the trial, and by Week 2 three engineers were posting past 200 words against a three-bullet, 60-second-skim goal. Maya fixed each issue as it surfaced - a dedicated mention scan the next morning, exemplar posts pinned to the channel - but none was accounted for in the original rollout plan.

Strengths

Section titled “Strengths”
  • Led with data, not instinct: the Q1 attendance split and the meeting’s own math - 14 minutes long, roughly 4 minutes of signal - made the ADR read as a decision record, not an opinion piece.
  • Ran the change as a bounded, reversible trial with a fixed end date and a named retrospective, so the permanent-adoption vote was a real decision, not a default.
  • Treated the Day 11 incident as a process gap to fix, not smooth over: it produced a specific checklist change, adopted before the next triage window.

Development Areas

Section titled “Development Areas”
  • On-call triage capacity was not scoped before launch. The 10-minute target reads as asserted, not tested against an 11-person channel’s likely volume, and that gap is what let the Day 11 incident happen. Capacity needs to be planned before rollout, not backfilled after someone is blocked for hours.
  • The three-bullet post-length ceiling had no enforcement at launch, only a stated norm - it held for a week, then eroded, the predictable result of a norm with no structural backstop. The fix that shipped - pinned exemplars, a Thursday demo - is a reminder, not a constraint; worth watching into H2.

Goals for Next Period

Section titled “Goals for Next Period”
  • Land the on-call triage decision from the Day 37 checkpoint (split the rotation or time-box the triage pass) and confirm triage time is back near the 10-minute target - by the next retrospective.
  • Replace the reminder-based post-length fix with a structural one, such as a bullet limit built into the /standup Slack shortcut - by end of Q3.
  • Complete the two-session Thursday attendance check committed to at the Day 30 retro, and bring the team a proposal if IST attendance falls below 3 of 4 - by the next retrospective.

Overall Rating

Section titled “Overall Rating”

Meets Expectations

Additional Notes

Section titled “Additional Notes”

The standup trial is unusually well-documented for a mid-year cycle: the ADR, the weekly status reports, and the retrospective form a paper trail I would support using in a promotion packet if this rigor holds through H2. The open question is not whether Maya can make a good structural call. It is whether she builds the operational guardrails in at launch, not after the first incident forces them.