You Need No Heroes

Shifting the Spotlight From Heroics to Health

It's another vacation-time short essay. This one is for engineering leaders who secretly know their "10x engineer" is actually a 1x engineer with a 10x problem.

---

It's 2 AM, the production system is on fire, and your overseas customers are screaming. But fear not! Like Batman emerging from the shadows, Steve—your Hero Engineer—swoops in, and saves the day before the sun goes up. Again.

In the morning, the office erupts in gratitude. Steve gets tens of Slack emoji reactions (35 x 🦸‍♂️)(17 x 🤩)(10 x 👏) and another story that will be retold at company retreats for years to come.

Everyone loves Steve.
Steve loves being loved.

Every company has such a Steve.
Or had one and miss them terribly.

But here's the uncomfortable truth: heroism in engineering is a symptom of a broken system, not a cure.

When Superpowers Hide Structural Weaknesses

Hero engineers thrive in chaos. They navigate spaghetti code, tribal knowledge, and ad hoc processes like wizards. But the real problem is that the system is designed for wizards.

That critical bug that only Steve can fix? It's probably in the code that Steve designed to be "elegant" and "efficient," which often translates to "undocumented and impossibly clever."

The more we rely on such individuals to save the day, the less motivation we have to fix the system that created the emergencies in the first place.

We've created a perverse incentive structure where the person who caused the fire gets celebrated for putting it out. We romanticize the firefighter while ignoring the fire hazard.

In Defense of Boring

When was the last time you thanked someone for a system that didn't break?

We don't throw parties for 99.99% uptime—we just expect it.
Yet we throw parades for the hero who gets us from 87% back to 99%.

This is backwards.

What if we flipped the script? What if the engineer who writes code so clear that an intern could maintain it gets the recognition? What if the architect who designs systems so robust they practically run themselves gets the promotion?

Here's the irony: excellent engineering should be boring. Predictable. Quietly effective.
Boring systems scale. Boring systems let you sleep.

In this world, the real heroes are the ones who eliminate the need for heroism in the first place.

The Bus Factor is About Ego

A Hero Engineer is a single point of failure, dressed up as a single point of genius.

But here's the uncomfortable truth: many Hero Engineers subconsciously resist being replaced because being irreplaceable feels important. They've tied their identity to being the only person who can solve certain problems. Creating systems that others can maintain feels like career suicide.

This is where leadership needs to step in with a radical reframe: the mark of a senior engineer isn't what only they can do—it's what they enable others to do.

The Growth Paradox

Here's what's truly tragic about hero culture: it stunts everyone's growth, including that of the hero’s.

The Hero Engineer gets stuck in firefighting mode, never getting time to work on interesting new problems. They become maintainers of their own mess. Meanwhile, other engineers never get the chance to tackle challenging problems.

---

Hero engineers are often your best problem solvers and most passionate builders. So stop chaining them forever to the same firehose of problems. It's a waste of their talent—and a recipe for burnout.

Let them mentor. Rotate them across domains. Challenge them to automate themselves out of the late-night pager duty rotation.

Let their impact compound through others, not just through late nights.

The Uncomfortable Questions

Here’s something to chew on during the vacation season: If your top engineer left tomorrow, what would break?

If your answer is “nothing,” congrats. You’ve built a resilient, scalable organization.
If your answer is “everything,” you’ve built a shrine, not a system.

Let me leave you with some questions that might haunt you:

For your Hero Engineers:

• Are they improving and simplifying, or just fixing?

• Are they mentoring others, or just staying busy?

• Are they solving problems, or just managing complexity they created?

For your systems:

• Do your SLOs reflect what your heroes can achieve, or what your systems can sustain?

• Would a new hire be able to understand and maintain your critical paths?

• Are you measuring and rewarding stability, or just recovery?

For your culture:

• Do you celebrate the engineer who prevents problems, or just the one who solves them?

• Are your promotion criteria based on heroics or on building scalable, maintainable systems?

Boring is New Brilliant

Reliability is not sexy. Documentation doesn’t get applause. Processes don’t post dramatic Slack messages at 2AM.

But that’s leadership. Quietly shifting the spotlight from heroics to health.
From saviors to systems.
From “Wow, they fixed it again” to “Wait, nothing broke.”

That's the kind of boring that builds businesses.

---

Call to action: next time someone saves the day, ask: could we have avoided needing a savior in the first place?