Every design manager knows the feeling of the last two weeks before reviews are due. Six people, a blank template each, and a year to reconstruct.
It is one of the most disliked parts of the job, and the usual explanation is that writing reviews is tedious. That is not quite it. Writing the review is the fast part. The slow part is finding out what happened.
The time is real and it is large
Managers routinely report spending several full weeks a year on performance management, and the aggregate numbers are startling once you multiply them out. Adobe famously calculated that its old annual review process consumed roughly 80,000 hours of manager time a year, equivalent to about 40 full-time employees doing nothing else, which is a large part of why they abandoned it.
The satisfaction numbers are worse than the time numbers. Survey after survey finds the overwhelming majority of managers unhappy with their own performance management system. That combination, enormous cost and near-universal dissatisfaction, usually means a process is solving the wrong problem.
Why design managers have it worse
Three things make this harder in design than in most functions.
The evidence is not written down anywhere. An engineering manager writing a review has a commit history, a ticket trail, review comments and incident records. The raw material exists whether or not anyone planned for it. A design manager has a Figma file that shows edits but not intent, a Linear ticket that shows a name but not a contribution, a Slack thread that has scrolled away, and a critique that lives only in the memory of whoever attended.
The work is joint. Almost nothing in a mature design org has one author. A flow was shaped by a researcher's finding, a systems designer's component, a critique from someone on a different team, and a content designer who fixed the actually confusing part. The record shows one name: whoever owned the file. Attributing fairly means reconstructing the room.
The best work leaves no artifact. The designer who killed a bad direction in week two saved six months of engineering. There is nothing to point at. Meanwhile a colleague who shipped four mediocre screens has four screens.
So the design manager does something engineering managers mostly do not: they go hunting. Scroll back through months of Slack. Open Figma version histories. Ask two other managers what they remember. Message the person and ask them to remind you what they did, which is a small indignity for everyone involved and produces a list biased toward what that person happens to recall and feel comfortable claiming.
What that time actually buys
Here is the uncomfortable part. All that reconstruction produces a document that is still mostly recency and salience.
People who study performance calibration describe the failure mode plainly: sessions run on memory and narrative rather than structured data, and the conversation defaults to advocacy, which rewards proximity and visibility rather than contribution. A week of archaeology does not fix that. It produces a slightly better-sourced version of the same bias, because you searched the places you thought to search, for the people you thought to search for.
The designers who do well are disproportionately the ones on visible surfaces, with well-connected managers, who are comfortable self-advocating. Everyone in the calibration room knows this. Nobody has a better instrument, so it happens again next cycle.
Where the hours actually go
Break the work into three parts, because they have very different value.
Gathering. Finding out what each person did. This is most of the time and none of the judgment. It is pure assembly: pulling scattered facts into one place.
Assessing. Deciding what it was worth against the ladder. This is the job. It requires knowing the person, the context, the difficulty of what they took on, and what the next level actually demands. Nothing should automate this.
Writing. Turning the assessment into something that lands and can be acted on. Genuinely skilled work, and much faster once the first two are done.
Most managers spend the bulk of their time on gathering, the part that requires the least of what makes them good at their job, and then rush the assessment because reviews are due Friday. The ratio is exactly backwards.
Getting the hours back
Make gathering continuous. This is the whole game. A record built as the work happens is a different object from one assembled in a panic, and not because it is more complete. It is less biased, because it was not filtered through what you could remember in November. Whatever form it takes, the property that matters is that entries land when the thing happens rather than when the deadline does.
Write it down when you notice it. The zero-infrastructure version: keep a running note per person and add one line whenever you see something worth remembering. Two minutes, ten times a quarter. Every manager who has done this says the same thing, which is that it changes review season completely and that they are bad at keeping it up. It is worth doing anyway, and worth admitting that a habit requiring twice-weekly discipline from a busy person will decay.
Ask for evidence, not a self-assessment. "What did you do this year" invites a persuasive essay, and rewards people who are good at writing persuasive essays about themselves. "Point me at the five things you are proudest of" invites artifacts, and artifacts are checkable.
Deliberately go looking for the invisible work. Before you write anything, ask specifically: who improved a system, who mentored someone, who changed a direction they did not own, who unblocked another team. These never surface on their own, because they leave no trace in the places you naturally look. Asking the question directly is the only reliable way to catch them, and the people it catches are usually the ones your process was about to underrate.
What not to build
A caution, because the obvious solution here fails badly.
Do not build a productivity dashboard for designers. The moment output volume becomes the record, you have recreated the artifact-counting problem with worse consequences: you will systematically promote the people doing the least valuable work, and your team will start optimizing for whatever they think is being counted.
The goal is evidence, not scoring. A record that shows a designer shaped direction on three initiatives they did not own, that their research changed another team's roadmap, and that a component they built is used by four squads gives a manager better material to judge with. It does not do the judging. That distinction is the entire difference between a useful instrument and one your team will correctly resent.
Review season will never be enjoyable. But most of what makes it awful is not the judgment. It is the two weeks of archaeology that come first, and that part was never a good use of a design manager's time.