Performance Reviews

A performance review should be the least surprising document someone reads all year. If it contains news, the problem is the six months of feedback that didn't happen before it. I run reviews as a written summary of conversations we've already had, anchored on evidence and the career ladder, and checked against the biases that make ratings say more about the reviewer than the person reviewed.

What Reviews Are For

Reviews try to do three jobs at once: calibrated feedback, growth planning, and decisions about pay and promotion. They pull against each other; the moment a conversation decides money, people stop listening for growth and start defending their rating. You can't fully separate them, because people deserve to know how feedback connects to pay, so I separate them in time. Growth happens in regular 1:1s and a mid-cycle check-in where nothing is decided. The review summarizes the period and states the outcome plainly; pretending it isn't about compensation when everyone knows it is just makes it feel dishonest.

No Surprises

Nothing in a review should be the first time the person has heard it. Corrective feedback and praise go in a 1:1 when the thing happens, so by review time the document is a summary. That's fairness as much as kindness: feedback six months late is feedback the person never had a chance to act on. An issue a manager discovers while writing the review goes into the next 1:1 as a conversation, and into the review only as context.

Write From Evidence, Against the Ladder

Reviews written from memory are reviews of the last six weeks and the strongest impression. I ask managers to keep a running doc per report through the period (what they shipped, decisions, incidents handled, peer feedback, moments they grew) so the evidence is already there at review time.

Each claim ties to the ladder and to a concrete example. "Strong technical leadership" tells the person nothing. "Led the migration design, wrote the RFC, and got three teams to agree on the cutover plan, which is what the senior level describes as influencing beyond the team" tells them what they did, why it mattered, and what level it's at. The ladder is the shared yardstick, and the example lets anyone check the claim.

Self Reviews and Peer Input

I ask for a self review first, because people remember work their manager never saw, and the gap between how someone sees their year and how their manager sees it is the most useful thing to talk about. Keep it short: what you did and its impact, what you learned, where you want to grow.

Peer input fills in what the manager can't observe. I ask a few peers, chosen with the person, specific questions ("what should they keep doing, and what one thing would make them more effective?") rather than for a rating, and their feedback goes in as evidence the manager has weighed, not anonymous quotes the person can't respond to.

Calibration and Its Pitfalls

Calibration is managers reviewing each other's ratings together, so that "exceeds expectations" means the same thing on every team. It's necessary: without it, ratings measure how generous each manager is. A large 2000 study by Scullen, Mount and Goff found that the rater's own idiosyncratic tendencies explained more than half the variance in performance ratings, more than twice as much as the actual performance of the person being rated. Calibration is how you correct for that.

It also goes wrong in predictable ways:

• The loudest advocate wins. A manager who argues well gets their people rated higher. The fix is to argue from the written evidence only, and to read it before anyone speaks.
• People nobody in the room knows get rated lower. Quiet, remote and newer engineers suffer here. Their manager's job is to bring evidence strong enough that it doesn't depend on reputation.
• Ratings get traded. "I'll give up one exceeds if you do." Calibration is about consistency, not about hitting a quota.
• Visibility gets confused with impact. The engineer who presents at the all-hands is not automatically having more impact than the one whose service never pages.

Recency and Halo

Two biases show up in nearly every review I've read.

Recency bias weights the last few weeks over the period: a rough final month after a strong five gets a review about the rough month. The running evidence doc, read top to bottom before writing a word, is the fix.

Halo bias lets one strong trait color everything: a brilliant engineer gets "strong collaboration" too, because criticizing someone you admire is hard. The horns effect does the same for one weakness. Rate each dimension of the ladder separately, with its own evidence, before forming an overall picture.

No Stack Ranking or Forced Distributions

A forced distribution requires managers to place a fixed percentage of their team in each rating bucket, whatever the team's actual performance. Stack ranking is its sharpest form: ranking everyone against each other and managing out the bottom slice.

I don't use either, and the case against them is practical. They tell a team of strong engineers that some of them must be failing, so people compete with their colleagues instead of collaborating, avoid joining strong teams where they'll rank lower, and hoard credit. Microsoft is the well-known case: it dropped stack ranking in November 2013 after years in which former employees described it as pitting colleagues against each other, and after a Vanity Fair investigation blamed it in part for the company's "lost decade."

Calibration aims for ratings to be consistent across teams. It doesn't aim for them to fit a curve. If a team really is full of strong performers, the ratings should say so.

Handling Underperformance Humanely

When someone isn't meeting the bar, the review is far too late to start. The work happens in 1:1s, early:

1. Name it clearly and specifically. What's the gap, with examples, against which part of the ladder. Vague concern helps nobody.
2. Look for the cause. Unclear expectations, the wrong project, a skill gap, something going on outside work. Many performance problems are management problems, and the honest first question is what I've done or failed to do.
3. Agree on what good looks like, and a timeline. Concrete outcomes, a few weeks to a couple of months, with regular check-ins and support: pairing, a mentor, a better-scoped project.
4. Write it down. Shared notes after every conversation, so both of you know exactly where things stand.

If it improves, say so loudly. If it doesn't, the outcome shouldn't be a surprise to either of you, and a respectful exit is more humane than a year of slow failure. A formal performance plan is a step I take only after the conversations above, never as the first anyone hears of a problem, and never as paperwork for a decision already made.

Write Reviews People Can Act On

The test of a review is whether the person knows what to do next after reading it. I check every draft against a few questions:

• Does every claim have an example?
• Is the most important message clear, or buried in qualifications?
• Are the growth areas specific enough to act on? "Communicate more" isn't; "write a design doc before starting work that touches another team's service" is.
• Is there one or two things to focus on, not ten?
• Would I be comfortable if the person read it over my shoulder while I wrote it?

Then I deliver it in person, give them time to read it before we discuss it, and leave the conversation open: a review starts the next period's conversation.

References

Reference

• Scullen, Mount and Goff: Understanding the Latent Structure of Job Performance Ratings, Journal of Applied Psychology (2000), where idiosyncratic rater effects accounted for 62% and 53% of rating variance against 21% and 25% for actual performance

In practice

• The Verge: Microsoft Kills Stack Ranking, Microsoft ending its forced-ranking system in 2013 after criticism that it set colleagues against each other