Performance Review Rules

A performance review should let the reader recognize themselves in it — specific enough that they could reconstruct the actual events being described, and useful enough that they know exactly what to do differently going forward. A review made of vague adjectives fails both tests.

Evidence-based specifics

• Back every rating or claim with a specific example — a project, a decision, a moment — not a general impression. "Strong communicator" is an opinion; "Walked a skeptical customer through the outage postmortem and got their sign-off in one call" is evidence.
• Collect specifics across the full review period, not just the last few weeks before the review is due — recency bias is one of the most common distortions in performance reviews, and a review that only reflects the last month misrepresents the period it claims to cover.
• Where possible, cite something measurable (a metric moved, a deadline hit or missed, a deliverable shipped) alongside qualitative observations — numbers anchor an otherwise subjective assessment in something verifiable.

Behavior, not personality

• Describe what someone did, not who they are. "Missed the deadline because the dependency wasn't flagged early enough" is actionable; "isn't detail-oriented" is a character judgment that gives no path to improvement and tends to be received defensively regardless of accuracy.
• Avoid personality-trait language entirely where a behavioral description would do the same job — "aggressive," "difficult," "not a team player" describe an impression, not an event; replace each with the specific behavior that created that impression.
• Separate the impact of a behavior from a claim about intent. You can observe and state impact with confidence ("the late handoff blocked QA for two days"); you rarely have grounds to state intent ("didn't care about the deadline") and shouldn't present a guess as a fact.

SBI structure

• Structure feedback as Situation, Behavior, Impact: the specific context, exactly what the person did or said, and what resulted from it. This structure is what keeps feedback concrete and defensible instead of drifting into general impressions.
• Situation: name the specific context ("In the March release planning meeting..."), not a vague timeframe ("Recently, in meetings..."). A named, specific situation is what makes the feedback checkable and credible to the recipient.
• Behavior: describe the observable action, not your interpretation of it — "raised concerns about the timeline three times without proposing an alternative" rather than "was negative about the plan."
• Impact: state the concrete consequence — on the team, the project, the customer, or the person's own goals — so the recipient understands why the behavior matters, not just that it was noticed.

Balanced but honest

• Include genuine strengths and genuine areas for growth in every review — but never manufacture either to force artificial balance. A review that pads weak performance with invented strengths, or downplays strong performance to seem "well-rounded," misleads the reader about where they actually stand.
• Don't bury a serious concern inside a list of minor ones or soften it into ambiguity to avoid an uncomfortable conversation — if a concern is serious enough to include, state it plainly enough that the recipient can't reasonably read past it.
• Avoid the "feedback sandwich" pattern of burying a real criticism between two compliments as a formula — it trains recipients to discount the praise as a setup and often causes them to miss the actual point being made.

Forward-looking goals

• End substantive feedback with what should happen differently going forward, framed as a concrete goal or behavior change, not just a diagnosis of the past — a review that only assesses without pointing forward leaves the recipient knowing where they stand but not what to do about it.
• Make goals specific and checkable by the next review cycle ("Lead the next two design reviews independently" rather than "Build more leadership presence") so both manager and employee can assess progress without ambiguity later.
• Connect individual goals to what the person actually wants for their own growth where you know it, not only to what the organization needs from them — a goal section that's entirely organization-driven reads as purely evaluative rather than developmental.

The no-surprises rule

• Nothing in a formal, written performance review should be the first time the person is hearing it. Significant feedback — positive or negative — belongs in real-time or near-term conversations throughout the period; the formal review documents and summarizes, it doesn't introduce.
• If you catch yourself about to write feedback the person hasn't heard before, treat that as a signal to have the conversation first and put it in the review next cycle — a review is the wrong venue for someone's first exposure to a significant concern, since there's no room for real dialogue in a document.
• Where a written review will contain a rating or decision with real consequences (compensation, promotion, PIP), make sure the underlying reasoning was already communicated in some form before the person reads it in writing — the document should confirm, not ambush.

What to avoid

• Don't use comparative language against named peers ("not as strong as X on this") — compare the person against the expectations of their role and level, not against a colleague they didn't choose to be measured against.
• Don't write reviews from memory alone at the last minute — without notes gathered across the period, recency and availability bias will distort which examples make it in.
• Don't let a single incident, good or bad, dominate a review that's meant to cover a full period — weight the assessment by the pattern across the period, and note the single incident as an example within that pattern rather than as the whole story.