When Performance Reviews Depend on What You Remember

Performance reviews have a strange problem: by the time you sit down to write one, most of the work happened months ago. You remember the loud stuff, the production incident, the project that went sideways, whoever stepped up when things were falling apart. What's harder to remember is everything in between.

That's usually when a manager starts digging through Jira, GitHub, Slack, and old 1:1 notes trying to piece the last six months back together. Once you're doing that, memory starts filling in the gaps on its own.

Two engineers on the same team: one spends the last two weeks before review season firefighting a nasty incident, everyone remembers that one. The other spent three months quietly hardening a system nobody thought about until it stopped breaking. Come review time, the first person's work usually feels bigger. It probably wasn't. It's just what stuck.

Growing teams make this worse. The common industry benchmark for engineering managers is 5 to 9 direct reports, close enough to actually know the work. Past 12 or 15, the usual description is a manager turning into something closer to air-traffic control: tracking status instead of shaping outcomes. Memory alone was never built to cover that many people.

Where the Information Actually Lives

None of the information is actually missing. Jira has what was planned. GitHub has the real changes. Slack has the decisions behind them. The problem is these don't talk to each other, and neither does most of what a manager remembers three months later. A closed ticket won't tell you someone spent two days quietly bailing out another team. A commit history won't tell you someone caught a problem a week before it became everyone's problem.

You don't need a record of everything. You need to remember the handful of things that actually explain someone's performance:

• What they got done, beyond the ticket count
• Whether it unblocked someone else, or just got marked closed
• The stuff outside their assigned work: mentoring someone, fixing a process nobody owned
• Why something happened the way it did. A missed deadline after three shifted priorities isn't the same story as someone who quietly misses deadlines and says nothing.

Why More Metrics Won't Fix It

Metrics alone won't save you. Tickets closed, PRs merged, these are hints, not verdicts. Someone closing fewer tickets might be deep in a genuinely hard problem. Someone closing a ton of them might be quietly handing debt to whoever cleans up after them.

The Fix Is Mostly a Habit

Write things down as they happen. That's most of the fix. Not every task, just the outcomes that mattered. When something unusual shapes a result, jot down why, right then, not three months later trying to remember. Check back on it monthly instead of scrambling once a year.

Here's a decent test: could you explain someone's performance six months out, with actual evidence? If not, that's usually not about their work. It's about what got written down along the way.

By the time review season comes around, the evidence should already exist. The conversation is just where you hand it over.