The Incident Hero Trap

A strange thing happens in many technology organisations during incidents.

The same people keep appearing:

The pressure’s rising, and then someone says those critical 3 words:

“Get them in.”

You know the person. (Perhaps you are that person!).

They know the service, and its history. They know which harmless-looking config change from six months ago still matters. They know where they cut corners to get a feature out and never got time to redo it properly. They know which graph lies, which alert cries wolf and which log line is worth trusting.

They arrive, calm the room, steer the response and somehow the incident closes. Everyone feels relieved.

And that feeling of relief is exactly where the problem begins.

How heroes are made

My son plays football. For a while, he became the team’s goalkeeper almost by accident.

He did well early on, made some big saves, and the team’s confidence grew around him. Before long, he wasn’t just a goalkeeper. He was the goalkeeper.

Then one weekend he couldn’t play an important match.

Panic ensues!

Parents worried. The team felt exposed. Who would go in goal? What would happen now?

The match went ahead anyway. Another child stepped in. Yes – they conceded goals. But they also adapted, rallied together, winning the match.

The lesson was obvious: my son was valuable, but the team had quietly convinced itself no one else could do what he did. Perhaps conveniently never tried to get others in the goal when my son could sit on the bench and step in if things got totally out of hand.

This happens in engineering teams all the time.

My own hero story

I started my career as the kind of engineer most organisations reward.

I shipped quickly & solved problems fast. I got things done.

What I wasn’t good at was sharing knowledge.

I kept too much in my own head, inadvetantly, it seems just more efficient that way. Some of that was personal immaturity. Some of it was influenced by culture. We celebrated speed more than communication; delivery more than resilience.

So I accumulated context.

Examples of the context I was hoarding included: tiny decisions, architectural trade-offs, forgotten assumptions and fragile workarounds. I became the walking memory of systems that should never have depended on memory.

Then the first major incident came.

I was pulled in not because I was a brilliant incident responder, but because I was the only one carrying enough context to help.

We resolved it, and overnight, I had become ‘important’.

The seduction of hero status

If you’ve never experienced this, let me explain the emotional pull.

Walking into a Network Operations Centre (pre-covid time or incident bridge these days) during a serious incident and hearing:

“Thank God, Hamed is here.”

It feels great.

People brief you quickly. Decisions move faster. Senior leaders know your name. Your judgement carries weight. Promotions come easier. Influence grows.

You start to believe you are helping the organisation. And, sometimes you are.

But often you are also helping to preserve the very dependency that creates the chaos.

The hidden cost

Hero status has a short honeymoon period. And then real life arrives. Shout of any of these feel familiar:

• You can’t completely switch off during holidays because incidents might happen.
• You get called during evenings, weekends, birthdays.
• Sleep becomes fragmented.
• And, perhaps most profoundly, Your family grows, your responsibilities deepen, and suddenly the identity that once felt flattering now feels heavy.

Worse still, the team around you becomes less confident over time.

After all, why make the call when the hero can make it?

Why learn under pressure when someone else always steps in?

The hero gains confidence while everyone else quietly loses it.

That’s the vicious cycle.

The lie behind the myth

Most hero cultures are built on a false belief:

“We need this one person.”

Usually, you don’t.

The business functioned before them.

It will function after them.

And when they leave, a new hero often emerges with surprising speed.

That should tell us something important.

The issue was never the individual. It was the ecosystem.

Culture created the dependency. Incentives rewarded it. Leadership tolerated it because, in the short term, it looked efficient.

Incidents make engineers

There is another tension worth acknowledging.

Incidents are painful, but they are also educational.

Many of the best responders were forged in difficult moments. Real ambiguity. Real pressure. Real consequences.

We love Vanessa Huerta Granda’s quote ‘Incidents are where engineers are made’.

Vanessa Huerta Granda at SREcon Americas 2026.

So, in some sense, we might want fewer incidents because healthier systems matter.

But we also need responders to develop judgement, composure, communication skills and technical depth.

That means organisations must find ways to scale learning without relying on production pain as the only teacher.

This is where drills, simulations, shadowing, rotations and deliberate exposure become so powerful.

You cannot wait for one exhausted person to carry the burden until others somehow become ready.

A partial fix

As my co-founder and friend Joe wrote about recently, technical resilience is one piece of the puzzle. Investing time in the technical foundations of your systems will reduce the volume and ensuing stress associated with incidents. However, as he also noted, incidents will happen. And it’s essential that each time it’s not just one person putting on the proverbial cape.

Heroes are not the problem

Let me be clear.

Heroes are not bad.

Many are generous, capable people doing their best inside flawed systems.

The problem is not having heroes.

The problem is having too few of them.

A resilient organisation does not create one legendary responder. It creates twenty calm, capable people who can step forward when needed.

How can the organisation do this?

• It helps responders distribute context.
• It normalises and empowers decision-making.
• It encourages training under pressure before pressure (inevitably) arrives.
• And most importantly, it celebrates those who make others stronger, not just those who save the day.
• Invest in activities that enables developing expertise and domain knowledge like code reviews, pair programming, incident analysis sessions, involve more poeple in incident response.

A better question

Instead of asking:

“Who is our hero?”

Ask:

“How many people could lead us through the next incident with confidence?”

That question reveals everything.

And I’d love to hear your experience.

Have you seen hero dependencies emerge in your teams? Have you lived the burnout side of it? And what have you seen work when trying to scale capability instead of relying on individuals?

‍