The Hero Trap

Why the best technical teams make heroics unnecessary

There's always that person.

The one who fixes the outage at 3:17 a.m. Who knows the legacy system nobody else will touch. Who can look at a cryptic log file and say, "Yeah, that's the Alekhine job from 2019. Check line 437."

In every technical team I've worked with, there's a hero. Early in my career, I thought, "If I can just get more people like that, we'll be unstoppable."

Today, my quiet goal is this: Use the hero. Celebrate the hero. Then replace the need for the hero.

Not the person. Keep the person. But the system that treats heroics as normal is a fragile system.

How Hero Culture Sneaks In

Hero culture rarely starts on purpose. It usually grows out of time pressure ("We don't have time to fix it right now. Just let Ron handle it"), legacy chaos ("Nobody really understands that part of the system… except Ron"), unclear ownership ("Who's responsible for this?" Silence, then: "…Ron?"), and reward structures that praise the late-night save instead of boring prevention.

Bit by bit, the team's mental model becomes: Hard things → Ron. Scary things → Ron. Production issues → Ron.

Ron is a good person. He cares. He keeps saying "yes."

And slowly, Ron becomes both the most valuable asset and the largest single point of failure in the entire organization.

That's not fair to Ron, and it's not safe for the team.

The Hidden Costs of Heroes

Heroics feel good. They make great stories: "Remember when the site was down and Jamie rewrote the job in an hour?" or "Remember when Atif stayed all weekend and made the integration work?"

But the bill shows up later.

Hero culture masks systemic problems—if many incidents end in a miraculous save, no one feels the urgency to fix the root cause. It blocks growth—people stop learning certain parts of the system because "that's Chris' area." It breeds quiet resentment—heroes burn out, non-heroes feel sidelined, and everyone feels stuck. And it raises the risk profile—when the hero is out sick, on vacation, or finally decides to leave, a normal issue becomes a crisis.

If you're leading a technical team - or really, any group of people who function as a team with prescribed outcome - one of your jobs is to notice this pattern early and gently break it.

So what do you actually do about it?

Change what you celebrate. Teams notice what gets praised. If every shout-out is about weekend saves and all-nighters, you're telling people that's what matters. Start celebrating the boring wins instead: the deployment that went smoothly, the doc that means anyone can now run the job, the refactor that made something simpler. You're not taking anything away from the hero—you're just broadening what "great work" looks like.

Turn every save into a system fix. When your hero jumps in and fixes something, don't just say thanks and move on. Capture what happened. Ask: "How do we make sure the next person doesn't need to be a hero to handle this?" Then make one small change—a runbook, a script, an alert, whatever. One improvement per crisis. That's it. Over time, your fire drills become design inputs.

Get knowledge moving. Hero culture loves knowledge concentration. "Only Morgan knows that job." "Only Lila can deploy safely." Your job is to spread that around. Pair people on the scary stuff. Rotate on-call with real support. After every hero fix, have them walk the team through it. Record it. Write it down. The message: "It's great that you know this. It's even better if others can too."

Redesign work so heroics are rare. Some systems practically beg for a hero—fragile deploys, tribal knowledge steps, zero monitoring. If everything's urgent, everything eventually needs saving. So ask yourself: where are we relying on memory instead of automation? What keeps causing last-minute panic? What complexity are we tolerating that we could just… remove? Start small. One checklist. One automated step. One alert. Every bit of friction you remove is one less hero moment waiting to happen.

Protect your heroes as people. They're usually high-ownership, high-conscience, and terrible at saying no. They'll absorb work until they burn out. So set limits for them: "You're not on call this week." Back them up publicly when they push back. Reframe their role: "Your job isn't to be the emergency button—it's to help us build a team that doesn't need one." Give them strategic work, not just firefighting. This isn't just kind. It's smart.

Make the boring day the win. In hero culture, the best stories are all emergencies. In a resilient culture, the win is a quiet Tuesday—routine deploys, uneventful on-call, people going home on time. I like to ask teams: "What would it look like if a normal day here was boring in the best way?" Then we work backward from there. That picture becomes the roadmap.

Conclusion

Heroes aren't the problem. Needing them is.

Celebrate the save. Fix the system. Spread the knowledge.

Fewer emergencies, more trust. That's the win.