Somewhere in your company this week, an engineer is going to stay late fixing something that broke in production. The next day, people notice. There’s a thread in Slack, a few thank-yous, maybe a spot bonus, and a mention at the next all-hands.
Now picture the other engineer. The one who, six months ago, spent a boring extra week designing that same system so carefully that it simply never caught fire. No thread, no thank-yous, no mention at the all-hands. Nobody is up late because of the disaster they quietly prevented, because the disaster never happened, so there is nothing to point at.
We tell ourselves we reward competence at work. We don’t. We reward rescue.
The two are not the same thing, and we confuse them constantly. A rescue is a story. It has a clock, a crisis, a hero, and a happy ending you can watch unfold in real time. Prevention is the absence of a story. It is the meeting that didn’t blow up, the outage that never paged anyone, the bug that was never written. You cannot put “nothing happened” on a slide.
To be fair, sometimes the fire is real and nobody set it. Hardware dies, traffic spikes, the world is messy, and when something genuinely breaks I am very glad there is someone willing to run toward it. None of this is the firefighter’s fault. It’s the math: we pour attention on the person who fixes the visible disaster and almost none on the person who made it impossible. The same skill, the opposite reward.
And then there is the version that should bother us most. Sometimes the firefighter is the one who set the fire.
I watched this happen once. An engineer I knew moved fast and shipped a lot, breaking things along the way. He got recognized for closing the most bugs that quarter. Then he pulled a legendary all-nighter on a nasty concurrency problem in the query routing system, the kind where two requests arrive at the same instant and one gets sent to the wrong place. He was celebrated for it. What went unsaid is that he had built that query routing system himself, in a hurry, a few months earlier. The fire he heroically put out was one he had quietly set.
He wasn’t a villain. He was talented and well-meaning and I liked him, which is exactly what makes it unsettling. The system worked precisely as designed, and the design paid him to clean up his own mess while the engineer who would have taken a careful extra week, so it never broke at all, got nothing. A different person, the same lesson.
The pattern underneath all of it is simple. Prevention is invisible, so we reward the rescue.
Once you see it, you can’t unsee where it leads. If rescue is celebrated and prevention is invisible, then the rational career move, the one nobody says out loud, is to let small fires start so you can be seen putting them out. That is why so many teams feel permanently ablaze.
Before you blame bad managers, though, understand this isn’t stupidity. It’s how attention works. You genuinely cannot see the outage that didn’t happen, and a calm quarter gets normalized into “the expected state” almost instantly. The bias lives inside everyone holding the pen on promotions and reviews, which very likely includes you.
So trying harder to “notice the quiet people” won’t work. You will fail at it, because you are human and humans aren’t built for that kind of attention. What works is mechanism: rather than trusting yourself to notice, you wire the noticing into the system itself. A few that I’ve seen help:
- Make firefighting boring, without making it thankless. When something genuinely breaks and someone gives up their weekend, thank them and mean it. But a quiet quarter should get the same airtime as a dramatic save, so “kept it calm” becomes as promotable as “rode in at the last second.”
- Make prevention visible, in numbers and in words. Track something that makes the invisible countable: mean time between failures, planned work versus unplanned firefighting, how evenly on-call load is spread. And write the quiet wins down. When you catch a near-miss, write it up like a real incident. In retros, name the systems that just worked all quarter, and who built them that way.
- Put prevention questions into every design review. Make a few mandatory before anything ships: what are the top three ways this breaks and who gets hurt, how will we know if it broke, what happens at ten times the traffic. The point is forcing someone to say the failure modes out loud while there’s still time to design them away.
- Run a premortem before you build. Get the team together, pretend it’s six months later and the thing has failed badly, and ask what killed it. Imagining the failure as already real surfaces far more of it than asking “what could go wrong.”
None of these are perfect. Every proxy can be gamed, and none of them will ever feel as exciting as watching someone save the day at the last second. But imperfect and better beats vivid and wrong.
The most valuable work of your career will be the disasters that never happened, and no one will clap for them by instinct. So if you are a manager, a staff engineer, or anyone who decides who gets promoted, build something that claps for them on purpose.
I don’t think anyone has fully cracked this, so I’ll ask you instead: what have you actually seen work? What rewards the fire that never started? If you’ve seen something that works, I’d love to hear it.