Why the best technical teams make heroics unnecessary
There is always that person.
The one who fixes the outage in the middle of the night. The one who knows the legacy system nobody else will touch. The one who can look at a cryptic log file and remember the exact job that caused the same problem years ago.
In every technical team I have worked with, there has been a hero. Early in my career, I thought, “If I can just get more people like that, we will be unstoppable.”
Today, my quiet goal is different: use the hero, celebrate the hero, then replace the need for the hero.
Not the person. Keep the person. The problem is the system that treats heroics as normal. That is a fragile system.
How hero culture sneaks in
Hero culture rarely starts on purpose. It usually grows out of:
- time pressure, when the team decides there is no time to fix the underlying problem;
- legacy complexity that only one person understands;
- unclear ownership;
- reward structures that praise the late-night save instead of steady prevention.
Bit by bit, the team’s mental model becomes simple: hard things go to one person. Scary things go to one person. Production issues go to one person.
That person cares. They keep saying yes. Slowly, they become both the most valuable asset and the largest single point of failure in the organization.
That is not fair to the person, and it is not safe for the team.
The hidden costs of heroes
Heroics feel good. They make memorable stories about someone rewriting a job in an hour or staying all weekend to make an integration work.
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 they belong to someone else.
It breeds quiet resentment. Heroes burn out, other people feel sidelined, and everyone feels stuck.
It raises the risk profile. When the hero is out sick, on vacation, or ready to leave, a normal issue becomes a crisis.
If you lead a technical team, or any group responsible for a shared outcome, one of your jobs is to notice this pattern early and gently break it.
Change what you celebrate
Teams notice what gets praised. If every shout-out is about weekend saves and all-nighters, people learn that emergencies are the work that matters.
Start celebrating the quieter wins:
- the deployment that went smoothly;
- the document that lets another person run the job;
- the refactor that made a system simpler;
- the checklist that prevented a missed step.
This does not take anything away from the hero. It broadens what great work looks like.
Turn every save into a system improvement
When someone jumps in and fixes a problem, do not stop at “thank you.” Capture what happened. Ask one useful question:
How do we make sure the next person does not need to be a hero to handle this?
Then make one small change. It might be a runbook, a script, a clearer alert, or a simpler handoff. One improvement per crisis is enough to begin.
Over time, fire drills become design inputs.
Get knowledge moving
Hero culture depends on concentrated knowledge. Only one person knows the job. Only one person can deploy safely. Only one person understands the integration.
Spread that knowledge deliberately:
- pair people on the difficult parts;
- rotate support work with real backup;
- walk the team through a fix;
- record the explanation;
- write down the decision and the next step.
The message is simple: it is good that one person knows this. It is better when someone else can learn it too.
Redesign work so heroics are rare
Some systems practically ask for a hero. They have fragile deployments, undocumented steps, weak monitoring, and too much reliance on memory.
Ask:
- Where are we relying on memory instead of a repeatable process?
- What keeps causing last-minute panic?
- What complexity are we tolerating that could be removed?
Start small. One checklist. One automated step. One useful alert. Every bit of friction removed is one less hero moment waiting to happen.
Protect your heroes as people
Heroes are often high-ownership, high-conscience people who have trouble saying no. They can absorb work until they burn out.
Set limits. Give them backup. Support them when they push back. Reframe their role:
Your job is not to be the emergency button. Your job is to help us build a team that does not need one.
Give them room for strategic work, not just firefighting. This is kind, and it is good system design.
Make the boring day the win
In hero culture, the best stories are emergencies. In a resilient culture, the win is a quiet Tuesday: routine deployments, uneventful support, and people going home on time.
Ask the team:
What would it look like if a normal day here was boring in the best way?
Then work backward from that picture. It can become a practical roadmap.
Heroes are not the problem. Needing them is.
Celebrate the save. Fix the system. Spread the knowledge.
Fewer emergencies and more trust. That is the win.