---
title: "Writing a performance review from your notes"
slug: writing-a-performance-review-from-your-notes
description: "How to write a performance review from your 1:1 notes: the sweep, sorting observations from reads, writing the arc, and feedback that lands on the work."
topic: managing-people-over-time
project: continuum
updated: 2026-09-15T06:53:21.358Z
canonical: https://roland.leth.ro/guides/writing-a-performance-review-from-your-notes
---

A lot of reviews get written from memory, and memory hands you the last few weeks. If you've kept notes on each person through the year, the review is a different job: editing what's already there. The page holds the dated observations and the reads that moved. The work is turning that into a document that describes the whole year and says something the person can act on.

This assumes you have the notes. If you don't yet, [the habit][track] and the [1:1 notes template][template] are where to start, and this page will still be here next cycle.

## The sweep

Re-read the person's page from the start, oldest entries first. Not the last month, the whole period, in order. It takes me about 15 minutes per person and it's most of the payoff: the February work that would've quietly dropped out of a review written from memory is back in, at the same time as events in October.

Check the dates as you go. A read whose newest evidence is a quarter old doesn't go into the review as a fact, it goes into the next 1:1 as a question, and the review waits for the answer if it can.

Why does the sweep work? Because of [what recency does][recency]: raters who kept structured diaries recalled more of what their people had done and produced ratings that were less inflated and better differentiated; the sweep is how the notes get to do that for you.

I do the sweep for everyone before I write anyone. Reading 6 pages back to back is the closest you'll get to one standard across the team, and it's a lot cheaper than the calibration meeting.

## Observations and reads

The notes hold two kinds of records, and the review needs both, in different places.

Observations are what happened, with a date: the design doc at half its usual depth, the migration flagged late by the person themselves, the incident handled at 2am and so on. In the review they appear as specifics, dated or at least placed in the year, and they're what makes a sentence believable to the person reading it.

Reads are what you made of it: ready for more scope, estimates run short when excited, loses momentum in the long middle. Each carries a confidence word and a last-confirmed date. In the review a read is a claim, and it needs its evidence next to it. A read with nothing under it is an opinion, which is fine in a 1:1 and pretty weak in a document that should help you understand and manage your team better.

So the sort is: pull the observations that matter into a list, group them under the reads they support, and drop any read that has nothing under it. What's left is the skeleton, and it's already in the order the year happened.

## The arc, not the average

A review written from memory describes a person as they are *now*, or as they were in the last thing you remember. A review written from notes can describe how they *changed*, which is the part nobody else can really write and, I think, the part worth the most to the person.

The arc is in the revisions. If a read moved from uncertain in March to certain in September, the review can say what moved it, with the dates: ready for more scope, likely, on the strength of asking for the migration in March; catching their own slips 2 weeks before you'd have, by May; certain by the mid-year check. That's a paragraph of a review, and it would be 3 lines on the page.

The same goes for the reads that didn't move, or moved the wrong way. A read that's sat at uncertain since spring, with nothing new confirming it, is a growth area you can name honestly: here's what I saw, here's what I haven't seen since, here's what would change my read. That's fairer than a verdict, and it tells the person what evidence you're waiting for; it makes _you_ better understand what you're waiting for.

## Feedback on the work

There's a reason to be careful with the person-level sentences, and it isn't politeness. The largest study of what feedback does, [Kluger and DeNisi's 1996 meta-analysis][kluger] of 607 effect sizes, found that feedback improved performance on average and lowered it in over a third of cases. _Over a third_. Their reading of the pattern: feedback that turns attention to the person (how they compare, what they *are*) tends to backfire, and feedback that stays on the task tends to work.

Your notes already make that distinction, if you kept them the way the [template][template] asks, because observations are task-level by construction. "The design doc was half its usual depth" is something the person can do something about. "Disengaging" is a read/opinion, and putting it in a review as a fact turns a document about the work into a document about the person, which is usually where that third of the cases mentioned above lives. So I keep the reads for the conversation, where I can say how sure I am and hear the other side, and put the observations in the document.

## What the notes can't fix

Notes take recency out of the review, but they don't take *you* out of it. [Scullen, Mount and Goff][scullen] found that more than half the variance in performance ratings came from the rater rather than the person rated, and no note-taking habit changes whose hand is holding the pen. 

Two things help at the margin: read the pages back to back, as above, so the same standard is in your head for everyone. And look at what kind of lines each page holds: if one person's is all misses and another's all wins, that's probably a fact about your attention before it's a fact about them, and the review should be written knowing it. It's not definitely so, but it's a sign to notice.

The other limit is the gaps. A page with nothing between April and August says you most likely weren't *looking*, not that nothing happened. Say so in the review, or better, go and find out before you write it. It _might_ happen that nothing really happened, but this is usually pretty rare and just like above, it's a sign to notice.

## How long this takes

The sweep should take about 15 minutes per person. The sort, maybe 10 or so, because the notes are already in the shape the review needs. The writing, whatever it takes, but it also starts from a skeleton of dated evidence rather than a blank page and a feeling, and that's most of the difference between a review the person recognises and one they argue with.

More guides in [Managing people over time][topic].

---

Full disclosure: I make [Continuum][continuum], a Mac app that does the sweep for you: it opens on the reads that have gone longest without fresh evidence, and every belief keeps its earlier versions underneath, dated, with the note that moved it, so the arc is on the page before you start writing. It never scores anyone, and nothing leaves your Mac. Free for up to three people; Pro is a one-time purchase if you'd rather not subscribe. The sweep above works on a folder of documents; the app is for when checking the dates is the part you'd stop doing.

[track]: /guides/how-to-keep-track-of-your-direct-reports "How to keep track of your direct reports"
[template]: /guides/one-on-one-notes-template "A 1:1 notes template"
[recency]: /guides/recency-bias-in-performance-reviews "Recency bias in performance reviews"
[kluger]: https://doi.org/10.1037/0033-2909.119.2.254 "Kluger & DeNisi (1996), The effects of feedback interventions on performance, Psychological Bulletin"
[scullen]: https://doi.org/10.1037/0021-9010.85.6.956 "Scullen, Mount & Goff (2000), Understanding the latent structure of job performance ratings, Journal of Applied Psychology"
[topic]: /guides/managing-people-over-time "Managing people over time"
[continuum]: /projects/continuum "Continuum: Manage Thoughtfully"
