Hero DE Burnout Cycle

Praising the engineer who fixes everything at 2am rewards the exact dependency that eventually takes the platform down with them.

It usually starts as a good thing. Someone’s faster, knows the quirks, gets paged and it’s fixed before anyone notices. So more gets routed to them. They become the path of least resistance for every urgent thing.

The cycle runs in four steps, and I’ve watched it three times:

• They fix everything, so they get assigned everything.
• Knowledge stops getting written down, because asking them is faster than docs.
• They burn out, quietly, because they can’t take a real holiday without something breaking.
• They leave. Now nobody can change the system without breaking it, and you’re hiring under pressure.

The frustrating part is that the hero gets rewarded the whole way through. The praise, the raise, the “what would we do without you.” Every bit of that reinforces the dependency.

What breaks the cycle is distributed ownership, built before you’re forced into it:

• Pair the hero with someone on every incident, so the fix gets witnessed.
• Have them write the runbook for the thing only they know, and treat that as real work, not overhead.
• Rotate the pager. The point is finding out what only one person can do, while they’re still around to teach it.

A team where any incident can be handled by two people is slower on paper and far more durable in practice.

The hero will be relieved. Most of them have been quietly waiting for permission to stop being indispensable.

Who’s the one person whose two-week holiday you quietly dread? Tell me what only they can do.