Performance Reviews and Written Feedback

Learning outcomes

Once or twice a year, a box opens with your name on it and a blinking cursor inside. You have a few hundred words to account for six months of work, and the people who will read them, a manager building a case, a calibration committee comparing you against a rubric, peers you barely worked with, were mostly not in the room when the work happened. You type “Worked on the payments service. Helped with the migration. Was a good team player.” It is all true. It is also nearly useless, because none of it tells the reader what changed in the world because you were there. The blank box is not asking what you did. It is asking what difference it made, and to whom, in writing a stranger can act on.

After studying this page, you can:

• Rewrite an activity-list bullet as an impact statement that names the outcome and its effect on the business or team.
• Build a feedback line from the situation, the action, and the measurable result, so a reader can act on it without having been present.
• Quantify your impact where numbers exist, and describe it concretely where they do not, without inventing figures.
• Write about your own contribution plainly, owning it without arrogance and crediting collaboration without false modesty.
• Structure peer feedback with situation, behavior, and impact, keeping it factual rather than a character judgment.
• Write growth feedback that is specific and forward-looking, and assemble a balanced review that resists recency bias.

Before we dive in

The written performance cycle exists to solve one problem: impact is invisible by default. The work you did lives in merged pull requests, in incidents that quietly stopped happening, in a teammate who got unblocked on a Tuesday. None of that automatically reaches the person deciding your promotion, your rating, or your raise. Self-reviews, peer feedback, and promotion documents are the channel through which invisible work becomes visible, and like any channel they carry only what you put into them, in the form you put it.

This changes how you write. A status update to your own team can lean on shared context, because everyone already knows what the payments service is and why the migration mattered. A performance document cannot. It is read by people one or two steps removed, who skim many of these documents in a row, who need to compare you fairly against others, and who will not chase down the background you left out. The curse of knowledge, the trap of forgetting what your reader does not know, runs through this whole page, and it is covered as a general writing fault in the principles of clear prose. Here it has a specific shape: you know your impact, so you forget to state it, and the reader, who cannot see it, scores what is on the page.

Three documents make up the cycle, and they share one engine. A self-review is your own account of your work over the period. Peer feedback is what you write about a colleague, often gathered in a 360, where several people around someone contribute. A promotion document argues that your work has reached the next level. All three live or die on the same skill: making impact legible to a reader who was not there. Everything below is that one skill, taught from several angles. It is the written companion to the spoken side of this work, which lives in giving and receiving feedback.

Breaking it down

1. The impact frame: outcomes, not activity

Start with the single shift that does the most work, because every other section builds on it. The most common failure in a self-review is to list activity: the things you spent time on. “Worked on the payments service.” “Refactored the auth module.” “Attended the migration meetings.” Each names a place where your hours went, and stops there. The reader is left to guess whether any of it mattered, and a reader who has to guess usually guesses low.

The fix is the impact frame: write about the outcome and its effect, not the activity that produced it. The activity is the input; the impact is the output, the thing that is different in the world now. “Worked on the payments service” is an input. “Cut payment failures by about a third, recovering an estimated amount of lost revenue, by redesigning the retry logic” is an output, and it happens to contain the activity inside it, as the means to the end. You did not lose the work by reframing; you wrapped it in the reason it counted.

The reframe asks one question of every bullet: so what? You worked on the payments service, so what? Failures dropped. Failures dropped, so what? Revenue stopped leaking. Keep asking until you reach something the business or the team actually cares about, then write the sentence backwards from there, leading with the outcome and folding the activity in as the method.

Read down the right column and notice a pattern: every strong rewrite contains a verb of change (“cut,” “raised,” “moved,” “caught”) aimed at something a stakeholder cares about, and the original activity survives inside it as the method. The rewrite is not longer because it is padded; it is longer because it carries the information the original withheld.

2. Specificity and evidence: situation, action, result

The impact frame tells you to lead with the outcome. This section tells you how to make that outcome believable: with specifics. Vague praise and vague claims fail for the same reason: a reader cannot act on them, cannot verify them, and cannot weigh them against anyone else. “Great teammate” and “significantly improved performance” are both empty in the same way. They assert a conclusion and skip the evidence that would earn it.

The cure is a three-part skeleton that works for your own work and for feedback about others: name the situation (the context, so the reader knows the stakes), the action (what specifically was done), and the result (what changed, ideally measurable). A claim with all three is checkable; a claim missing one leaves the reader filling a gap you should have filled. “Great teammate” has none of the three. “When the on-call rotation was short two people during the holidays (situation), she covered nine extra shifts (action), keeping our response time within target through the freeze (result)” has all three, and now the praise is a fact the reader can stand on.

The same skeleton rescues your own bullets. “Improved performance” names only a fuzzy result. “After our checkout latency spiked past two seconds (situation), I profiled the path and added an index on the orders table (action), bringing it back under 300 milliseconds (result)” gives the reader the whole arc, and the number at the end is load-bearing: it converts a claim into evidence. Notice that this is the same arc the impact frame demands, just shown with its joints labeled, so the two ideas reinforce each other rather than compete.

3. Quantifying impact, and describing it when numbers are missing

The result in a situation-action-result line lands hardest when it is a number, so reach for one whenever it honestly exists. Numbers are dense and comparable: “cut build times from 20 minutes to 6” tells the reader the size of the win in four words, and a calibration committee can place it next to other wins. Latency, error rates, cost, time saved, revenue, adoption, the number of teams unblocked: when your work moved one of these, name the before and the after, and the impact becomes impossible to wave away.

But a hard rule sits underneath this: never invent a number. A figure that is actually a guess dressed as a measurement is worse than no figure, because when a sharp reader probes it and it collapses, every other claim in your document loses credit with it. If you have a real measurement, use it. If you have a defensible estimate, mark it as one, exactly the calibrated honesty taught in hedging and stance: “recovered an estimated amount of revenue” and “roughly a third fewer failures” are honest, and the hedge protects you rather than weakening you. Inventing “increased revenue by 1.2 million dollars” when you do not know the figure is not confidence; it is a liability.

Plenty of real impact has no number at all, and this is where many engineers freeze and fall back to vague claims. The move is to describe the impact concretely instead, in terms of what is now possible, prevented, or relied upon. You cannot put a number on a design document that became the team’s reference, but you can write “the on-boarding guide I wrote is now the first link every new hire is sent, and it cut the questions in our help channel noticeably.” You cannot quantify trust, but you can write “three teams now route their incident reviews through the template I built.” Concrete description is the qualitative twin of a number: it gives the reader something specific to picture and verify, which is the whole point of evidence.

4. Writing about your own work without arrogance or false modesty

A self-review forces a posture that English makes genuinely hard: you have to claim credit, in writing, about yourself, to people who will judge you on it. Two opposite failures wait here, and most writers fall into one out of fear of the other. Arrogance overclaims: “I single-handedly saved the launch,” when four people saved it and you were one. False modesty underclaims: “I just helped a little with the migration,” when you owned it, because claiming it plainly felt like bragging. Both misreport you, and both cost you, because a reader cannot reward a contribution you have hidden, and cannot trust a contribution you have inflated.

The way through is to own your part plainly and credit collaboration honestly, in the same sentence when you can. “I led the retry redesign, working closely with the data team on the rollout” does both: “I led” claims the part that was yours without apology, and “working closely with the data team” credits the part that was shared without erasing yourself from it. The test is accuracy, not modesty. State exactly what you did, no more and no less, and let “led,” “owned,” “contributed to,” and “supported” do precise work rather than reaching reflexively for the grandest or the meekest verb.

False modesty is the more common trap for careful, collaborative people, and it is worth naming why it is not actually humble. Writing “I just helped” about work you drove does not make you look generous; it makes the reader credit someone else for your outcome, or credit no one, which in a calibration room means the work scores as if it did not happen. Honest crediting is precise, not self-erasing: name what your collaborators did and name what you did, and the contrast makes both legible. The calibrated, neither-blunt-nor-timid voice this asks for is the written face of the stance work in hedging and stance.

5. SBI: a structure for peer feedback

When you write about a colleague rather than yourself, the danger shifts. The risk is no longer arrogance or modesty; it is the slide from describing what someone did to judging who they are. “He is disorganized” is a verdict on a person. It is hard to receive, easy to dispute, and impossible to act on, because it names a trait, not a behavior anyone can change. Useful peer feedback stays on the ground of observable behavior, and a small structure keeps it there.

That structure is SBI: situation, behavior, impact. Name the situation where it happened, so the feedback is anchored in a real moment rather than a general impression. Describe the specific behavior you observed, in factual terms, without interpretation. Then state the impact that behavior had, on you, the team, or the work. “In last week’s design review (situation), you presented only one option and moved straight to implementation (behavior), which made it hard for the rest of us to follow your reasoning or weigh alternatives (impact).” Every clause is something the other person can recognize and respond to, because none of it is a character claim.

The diagram reads as a pipeline because that is how the structure protects you: each stage constrains the next. Anchoring in a real situation stops you from generalizing (“you always…”); describing observed behavior stops you from interpreting (“you don’t care about…”); naming impact stops the feedback from being a bare complaint and gives the other person a reason the change matters. Skip a stage and the feedback drifts back toward a character verdict. The same SBI skeleton works for praise, not just criticism: “in the incident on Friday (situation), you posted clear status updates every ten minutes (behavior), which kept the rest of us from duplicating work and calmed the channel (impact)” is specific, evidenced praise rather than a vague “great under pressure.”

6. Growth feedback that is specific and forward-looking

The hardest written feedback to get right is the kind that asks someone to change. Two opposite failures appear again. Vagueness says nothing actionable: “could improve communication” gives the reader no idea what to do differently on Monday. Harshness says it cruelly: “your design reviews are a mess” wounds without guiding. Both fail the only test that matters for growth feedback, which is whether the person can do something specific with it.

Two properties make growth feedback usable. It must be specific, naming the exact behavior rather than a trait, and it must be forward-looking, pointing at what to do next rather than only at what went wrong. Compare the vague “could improve design reviews” with this: “in design reviews, presenting one option rather than the alternatives makes it harder to follow your reasoning; bringing two or three would help.” The second names the precise behavior (presenting a single option), states its impact (hard to follow), and hands over a concrete next action (bring two or three). It is honest about the problem and generous about the path forward, and those are not in tension.

The forward-looking half is what separates feedback from a complaint. A complaint ends at the problem; feedback continues to the fix. “You interrupt people in reviews” stops at the fault. “I have noticed you sometimes start responding before others finish in reviews; leaving a beat after each person would let more of their point land” carries the same observation into something the reader can practice. The softening here, the move from blunt verdict to constructive frame, is exactly the calibrated directness developed in hedging and stance: firm on the substance, gentle on the person.

Read the strong column and you will see the same two-part shape every time: a specific, observed behavior, then a concrete forward action. Even the praise row points forward (“doing the same for design docs”), because the most useful positive feedback tells someone what to keep doing and where to apply it next, not just that they were good.

7. The strengths-plus-growth shape, and beating recency bias

A full review is rarely one note; it is usually a shape. The reliable one is strengths plus areas for growth: lead with what the person did well, specifically and with evidence, then move to what would help them grow, specifically and forward-looking. This is not a trick to soften a blow. It is accurate, because almost everyone has both, and it is useful, because growth feedback is easier to act on when the reader knows their strengths are seen, and praise is more credible when it sits next to honest development notes rather than alone. The shape works for self-reviews too: own your wins plainly, then name where you want to grow, which reads as self-aware rather than either boastful or self-flagellating.

The deeper threat to a fair review is timing, not structure. Recency bias is the tendency to weight the last few weeks far more than the months before them, simply because they are fresh in memory. Write a review from memory alone and it quietly becomes a review of the last sprint: the big win from month two has faded, the small annoyance from last week looms large, and the document misrepresents the whole period. This distorts both self-reviews (you forget your own early wins) and peer feedback (you score the recent mood, not the year).

The defense is mechanical, not heroic: keep a running record through the period. A simple document, a note per week or per finished piece of work, capturing what happened and its impact while it is fresh, turns review-writing from a feat of memory into a feat of editing. When the box opens, you are not straining to recall month two; you are selecting from evidence you already wrote down. The record also feeds the impact frame directly, because the best time to capture a number or a concrete result is the moment it happens, not six months later when it has blurred into “worked on the payments service.”

Mental Model: write for the reader who was not in the room

Here is the reframe that ties every section together. The wrong model, the one that produces activity lists and vague praise, is that a performance document records what you know about your work. Under that model you write from inside your own head, where the impact is obvious, the context is assumed, and the result needs no spelling out, because you already know it. The document then reads perfectly to you and poorly to everyone else, for the exact reason your own draft always reads fine: your knowledge silently fills every gap you left.

The better model is that you are writing for a specific reader who was not in the room. Picture them concretely: a calibration committee member who has never seen your code, reading your self-review as the twentieth of thirty, with no time to chase context and a rubric to map you onto. Now every rule on this page becomes obvious rather than arbitrary. Lead with impact, because they cannot infer it. Name the situation, action, and result, because they were not there for any of it. Quantify or describe concretely, because they need evidence, not assertion. Credit honestly, because they cannot see who actually did what. Keep a record, because they are judging the whole period and you can only show them what you wrote down.

This single shift, from “what I know” to “what a specific absent reader can act on,” dissolves the page’s traps in one move. Activity lists vanish, because an absent reader cannot score hours. Vague praise vanishes, because they cannot verify a label. False modesty vanishes, because they will believe exactly what you put on the page and no more. Once you write for the reader who was not in the room, you stop reporting your work and start making it legible, which is the entire job of the written performance cycle.

Common mistakes

The first mistake is listing activity instead of impact: filling the box with the places your time went (“worked on the payments service,” “attended the migration meetings”) and never reaching what changed because of it. The fix is the so-what test: push every bullet until it names an outcome a stakeholder wanted, then lead with that.

The second mistake is vague praise: “great teammate,” “strong engineer,” “great under pressure.” These are conclusions with the evidence cut off, and a reader cannot act on a conclusion they cannot check. Replace the label with the situation, behavior, and impact that earned it.

The third mistake is false modesty that hides your contribution: writing “I just helped a little” about work you drove, out of a fear of bragging. It is not humble; it hands your credit to no one. Own your part plainly and credit collaboration honestly in the same breath.

The fourth mistake is feedback that is not actionable: growth notes so vague (“improve communication”) that the reader has nothing to do differently on Monday. Name the specific behavior and the specific next step, or the feedback is just a feeling.

The fifth mistake is harshness: stating a real problem so bluntly that it wounds instead of guides (“your design reviews are a mess”). The problem can be named firmly and the person treated gently at once; that split is the skill, not a contradiction.

The sixth mistake is recency bias: writing the whole period from memory and accidentally reviewing only the last few weeks. The early win fades and the recent annoyance dominates. Keep a record through the period and write from evidence, not recall.

Mastery Questions