Ask a senior engineer to list what they did this quarter and you'll get a clean list: the migration, the three services they shipped, the incident they resolved. Ask them what they actually spent Tuesday afternoon doing and, if they're honest, a lot of it was talking someone out of a bad idea in a way that left no trace anywhere a performance review would look.
That conversation is the job. It just isn't the artefact.
Promoted for the object, kept for the judgement
Performance frameworks are built around things that can be pointed at: the system designed, the outage resolved, the mentee promoted. That's not unreasonable — you need something to point at, and a genuinely good senior engineer produces plenty of those things. But it quietly trains everyone in the org to believe the artefacts are the job, when for anyone senior enough to be trusted with ambiguous problems, the artefacts are downstream of something less visible: the fifteen minutes in a design review where they said "this will work but we'll regret the coupling in eight months," and the room adjusted course because they said it.
Nobody writes that fifteen minutes into a doc. There's no ticket for "prevented a mistake that would have cost two sprints, six months from now, in a form specific enough to prove it would have happened." The counterfactual doesn't exist by definition, so the work that produced it is invisible by construction, not by neglect.
The senior engineers worth keeping are mostly being paid for the sentences they say in rooms, not the code they write in them.
Why this resists measurement, structurally
It's tempting to think this is a tooling problem — track the Slack threads, log the design review comments, build a dashboard for "judgement calls made." I don't think that survives contact with how judgement actually works. Good judgement is precisely the kind of thing that looks unremarkable in the moment it's exercised, because the whole point of catching a problem early is that it never becomes a problem large enough to be memorable. The engineer who prevents the outage produces silence. The engineer who resolves it produces a postmortem with their name on it. Both did valuable work; only one produced an artefact, and the incentive structure will reward the wrong one every time unless someone actively corrects for it.
There's also a selection effect that makes this worse over time. If judgement work is systematically under-recognised, the engineers most attuned to it — the ones who'd rather quietly prevent five small problems than visibly heroics their way through one big one — are exactly the ones a naive review process will underrate. You end up promoting on incident response and losing the people who made incidents rare in the first place.
What to do instead of trying to measure it
I don't think the fix is a better metric. I think it's changing who's in the room when judgement gets exercised, and building the habit of naming it out loud when it happens — not for credit-taking, but because naming it is the only way it becomes visible to anyone who wasn't in that specific fifteen minutes.
Concretely: when a senior engineer redirects a decision in a design review, someone — them, their manager, anyone present — should write one sentence into the doc's history: "changed direction here because X; the earlier approach would have cost Y." Not a full writeup. One sentence, attached to the artefact that would otherwise show no trace the redirection happened. Over a year, that sentence, repeated, is the only record that the invisible work occurred at all — and it's the difference between a performance review built on what's easy to see and one built on what actually kept the system healthy.
The alternative is what most orgs default to: rewarding the visible fire and quietly losing the people who were best at making sure there wasn't one.