Use when writing or calibrating a performance review for a direct report at any level
Scanned 9/8/2026
Install to Claude Code
npx -y skills add jeffreytse/grimoire-core --skill write-performance-review --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Write Performance Review?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/jeffreytse-write-performance-review)More formats (shields.io, HTML) on the badges page.
---
name: write-performance-review
description: Use when writing or calibrating a performance review for a direct report at any level
source: Kim Scott "Radical Candor" (2017); SBI Feedback Model (Center for Creative Leadership); Adobe Check-in Model
tags: [performance-review, feedback, leadership, sbi-model, talent-management, coaching]
verified: true
---
# Write Performance Review
Write a performance review that is honest, specific, and developmentally useful — not a vague summary or a surprise.
## Why This Is Best Practice
**Adopted by:** Adobe (replaced annual reviews with Check-ins), Microsoft (growth mindset reviews), Center for Creative Leadership SBI model used by 750K+ managers
**Impact:** Adobe eliminated annual reviews in 2012 and saw voluntary turnover drop 30% while performance accountability increased; vague reviews correlate with higher attrition than no reviews
**Why best:** A performance review fails when it is too vague to act on or contains surprises the employee was never given a chance to address. The best reviews summarize feedback already delivered, add calibration context, and set a direction for growth.
## Steps
1. **Gather evidence first** — Pull 1:1 notes, project outcomes, peer feedback, and work artifacts from the entire review period. Do not write from memory alone.
2. **Rate against the role scorecard** — Score each competency against the defined expectations for the level, not against peers. Calibration against peers happens in the calibration meeting, not in your written draft.
3. **Write accomplishments with impact** — For each major contribution, use the format: "Did [action] → resulted in [measurable outcome]." Avoid adjectives without evidence ("great collaborator").
4. **Write development areas using SBI** — Situation, Behavior, Impact. Be specific about what happened, not character traits. "In Q3 planning [S], estimates were regularly off by 50%+ [B], causing sprint commitments to slip 3 times [I]."
5. **Connect to career path** — Name the one or two capabilities that, if developed, would most accelerate the person's next step. Make this concrete: "Presenting to the executive team without prep notes" not "improve communication."
6. **Check for bias** — Re-read the review and ask: Would I write this same feedback for a different demographic? Replace "aggressive" with specific behavior. Replace "cultural fit" with a competency.
7. **Deliver before submitting to HR** — Read the review together in the meeting. Give the direct report time to respond and add their own notes. Never submit and then inform.
## Rules
- No surprises: every piece of feedback in the written review must have been delivered verbally at least once.
- Use specific evidence (dates, outcomes, quotes) for every rating, positive or negative.
- Separate performance from potential — they are different axes and require different interventions.
- Avoid sandwich feedback (positive–negative–positive); it buries the real message.
- The employee's self-review must be read before the manager writes their review.
## Examples
Instead of: "Sarah is a strong communicator who sometimes struggles with prioritization."
Write: "Sarah led the customer advisory board launch [accomplishment → increased NPS 12 points]. In Q2 sprint planning, unclear prioritization caused the billing feature to slip two weeks, affecting the Q2 launch. Development focus: practice saying 'no' to inbound requests with a documented rationale."
## Common Mistakes
- **Recency bias** — Only remembering the last 6 weeks of a 12-month period; fixed by reviewing notes from the entire cycle before writing.
- **Vague positives** — "Always goes above and beyond" gives no signal about what to keep doing and signals the reviewer didn't observe closely.
- **Inflation to avoid conflict** — Rating someone "meets expectations" when they don't helps no one and creates a legal and calibration problem at the next review.
## When NOT to Use
- Do not write a formal performance review for someone in their first 30 days on the job — a structured onboarding check-in is more appropriate when the role expectations have not yet been fully experienced.
- Do not use this process to document an active termination decision; once the decision is final, the review becomes a legal document and HR and legal counsel must lead the process.
- Do not write a written review when the manager has had no direct observational data on the employee's work for the review period — a secondhand review based only on hearsay produces unfair ratings and legal exposure.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!