Our promotion packets used to reward shipped features almost exclusively. The engineers who kept the lights on quietly stopped applying for promotion at all.

Two years ago we noticed something in our promotion data: engineers whose primary work was reliability — on-call, incident response, toil reduction — were promoted at roughly half the rate of feature engineers at the same level, even when their peer feedback was equally strong.

The invisibility problem

A shipped feature has a demo, a launch note, a customer quote. A prevented incident has none of those things by definition — the best reliability work is the outage that never happened, the memory leak caught in staging, the alert that got quieter without anyone noticing it used to be loud. Our promotion committee, made up mostly of people evaluating work they could see, was structurally biased toward visible output.

What we changed in the packet

We added a required section to every promotion packet, for every discipline, not just reliability roles, that has to be filled in with specifics or the packet is returned.

promotion_packet.md — required section
---
## Prevented Impact
List 2-3 things that did NOT happen because of this person's work.
For each, answer:
  - What would have broken, and roughly when?
  - How do we know? (link postmortem, incident near-miss, or metric trend)
  - What did fixing it cost in effort vs. what an incident would have cost?
This section may not be left blank. "N/A" requires committee sign-off.
"I'd spent eleven months quietly fixing the thing that would have taken down billing at end-of-quarter, and it wasn't on my packet because I didn't think to write down something that didn't happen."

The result, eighteen months in

The promotion rate gap between reliability-focused and feature-focused engineers at the same level closed from roughly 2x to about 1.2x — not fully closed, but a real shift. Just as important, we started seeing prevented-impact sections in feature engineers' packets too, describing edge cases they'd guarded against, which told us the bias wasn't reliability-specific — it was a bias against invisible work generally, and reliability engineers had just been absorbing the worst of it.

  • Promotion committees evaluate what they can see; invisible reliability work needs a forcing function to become visible at all.
  • Requiring a specific, evidence-backed "prevented impact" section works better than asking managers to "remember to advocate" for it.
  • Check whether your promotion gap is reliability-specific or a broader bias against unglamorous, undemoed work — the fix differs.