How hero culture quietly sneaks into our engineering teams and burns people out

It doesn’t start with ego or ambition. It starts with good intentions, late nights, and being told “we couldn’t have shipped without you.”

I never set out to be that developer.

You know the one. The person everyone pings when something breaks. The name that comes up in standup when prod is on fire. The person who somehow “always knows where the bug is.” I didn’t chase that role. I kind of tripped into it… and then stayed there way too long.

At first, it felt good. Being useful always does. You fix a gnarly issue, unblock a release, save the sprint. Someone says “you’re a lifesaver” in Slack. Another person drops a 🔥 emoji on your PR. Leadership notices. You go home tired but weirdly proud, like you just clutched a round you had no business winning.

And then it keeps happening.

Late nights turn into normal nights. Normal nights turn into weekends. You stop documenting things because “it’s faster if I just do it.” People stop touching certain parts of the codebase because “you know it best.” You’re not a rockstar developer… but you’re definitely playing the hero.

The uncomfortable part? No one asked you to do this. The system quietly rewarded it.

Somewhere along the way, hero culture stopped being about impact and started being about survival. Not just yours the team’s. Because when everything depends on one person stepping in, burnout isn’t a possibility. It’s the roadmap.

TL;DR:
Hero culture doesn’t show up wearing a cape. It shows up as praise, urgency, and good intentions. It feels like a win at first. Then it quietly turns into exhaustion, fragile teams, and a lot of people wondering why they’re so tired doing work they used to love.

Where hero culture actually comes from

Hero culture doesn’t start with arrogance. That’s the lie that makes it easy to dismiss.

Most of us didn’t wake up one day thinking, I want to be indispensable and slowly ruin my own boundaries. It starts way earlier, and way quieter. Usually with someone noticing that you care.

Early in your career, effort and outcome are tightly coupled. You grind, you learn fast, you fix bugs other people can’t yet. Someone senior says, “Nice catch.” A teammate thanks you for staying late. You feel seen. That feedback loop is powerful especially if you didn’t feel particularly confident walking in.

Tech culture pours fuel on that fire.

We grew up on stories about lone engineers pulling miracles out of thin air. Blog posts about tiny teams shipping impossible things. Hacker News threads romanticizing all-nighters. Conference talks that subtly frame exhaustion as dedication. Even the phrase “10x developer” implies that the right individual can outweigh the system around them.

And the thing is sometimes that is true in short bursts.

Early-stage teams, scrappy projects, tight deadlines. Being the person who steps up feels responsible. Noble, even. You’re not chasing praise. You’re preventing failure. You tell yourself you’ll slow down once things stabilize.

But stabilization never really comes.

The culture quietly shifts from “thanks for helping” to “we rely on you.” People stop double-checking your work. Certain files get mentally labeled as “yours.” Decisions start happening in DMs instead of design docs because it’s faster. You don’t push back, because you can handle it. And because part of you likes being trusted.

That’s the trap.

Hero culture thrives on good intentions mixed with bad incentives. It rewards speed over clarity. Fixes over foundations. People who jump in over people who step back and design guardrails. Nobody sits you down and says, “Please become a single point of failure.” It just… happens.

And once it does, unwinding it feels awkward. If you stop stepping in, are you letting the team down? If you ask others to take ownership, are you being difficult? If you document instead of fixing, are you slowing things down?

Those questions keep a lot of us stuck longer than we should be.

Hero culture isn’t born from ego. It’s born from care, mixed with a system that mistakes urgency for importance.

How teams accidentally reward it

Here’s the uncomfortable part: hero culture usually isn’t enforced by bad managers or toxic teammates. It’s reinforced by perfectly normal team behavior.

We praise the visible stuff.

The outage fix. The late-night deploy. The person who “jumped in and saved the release.” Those moments are easy to point at. They make for good standup updates and neat retrospective stories. Prevention, on the other hand, is boring. Nobody claps for a bug that never happened or an incident that didn’t make it to Slack.

So teams drift toward rewarding reaction instead of resilience.

If you’re the person who consistently steps in during chaos, you start standing out not because you’re the only one capable, but because you’re the one absorbing the pain. Over time, that gets mistaken for ownership. Then for reliability. Then for leadership.

Meanwhile, the incentives stay misaligned. Shipping fast beats documenting well. Closing tickets beats deleting complexity. Staying late looks like commitment; designing systems that don’t need you looks invisible.

And most teams don’t realize they’re doing this until it hurts.

By the time someone says, “Only you know how this works,” it sounds like a compliment. It’s not. It’s a warning sign that the system is quietly narrowing around one person.

Hero culture doesn’t need applause to grow. It just needs silence when the wrong behavior keeps getting rewarded.

How modern tooling makes it worse

If hero culture existed in a vacuum, it would already be a problem. But modern tooling doesn’t just enable it it supercharges it.

We’ve never had more leverage as individual developers. One person can spin up infra, wire CI, ship features, patch bugs, and roll back deployments without talking to anyone. Cloud consoles, infra-as-code, managed services, AI copilots they all lower the friction to “I’ll just handle it.”

And honestly? That’s incredible.

It’s also dangerous.

When tools remove coordination costs, they don’t remove responsibility. They just hide it. A Terraform change looks clean in a diff, but its blast radius can be massive. An AI-suggested refactor feels safe because it compiled, not because it was understood. Shipping solo becomes the path of least resistance, especially when involving others feels slower.

So the hero instinct kicks in again.

Why write a design doc when you can just implement it?
Why wait for review when you’re confident?
Why explain the system when you can fix it in half the time?

The tools reward speed, not shared understanding. They don’t push back when knowledge stays in one head. In fact, they make it easier to get away with it.

I’ve felt this firsthand. That moment where you think, I can ship this before anyone even finishes reading the message. It feels efficient. It feels competent. It feels like winning.

Until the team can’t follow what happened.
Until someone is scared to touch the config you wrote.
Until a “small change” breaks something nobody else knows how to debug.

Modern tooling didn’t invent hero culture but it removed the natural brakes that used to slow it down.

Velocity without alignment doesn’t scale. It just burns hotter and burns people out faster.

The burnout nobody brags about

Nobody posts about this part.

You don’t see blog posts titled “I saved prod again and now I’m completely drained.” Burnout doesn’t screenshot well. There’s no dopamine hit in admitting you’re tired of being the reliable one.

At first, exhaustion feels like momentum. You tell yourself you’re just in a busy phase. Once this release ships. Once this quarter ends. Once the system is more stable. Except the system is stable because you keep absorbing the chaos.

That’s when things get weird.

You start feeling guilty for stepping away. Nervous about vacations. Slightly on edge when someone else touches “your” part of the code. Not because you don’t trust your team but because you know how fragile the setup actually is. You built it quickly. You optimized for speed. You never had time to slow down and clean it up.

And now you’re carrying that knowledge alone.

Burnout here isn’t dramatic. It’s quiet. It shows up as irritation in code reviews. As relief when a meeting gets canceled. As the sense that everything depends on you and none of it is really yours.

Teams feel it too. Onboarding gets slower because nobody wants to explain the messy parts. People hesitate to make changes. Work queues up behind one person, and everyone pretends that’s fine because “they’re really good.”

That’s the part we don’t talk about: hero culture doesn’t just burn out heroes. It makes teams fragile. It trades short-term wins for long-term anxiety. And by the time someone says, “We should probably fix this,” everyone’s already tired.

Burnout isn’t a personal failure here. It’s a predictable outcome of a system that keeps rewarding people for lighting themselves on fire.

What i’m trying to unlearn now

Unlearning hero culture has been harder than falling into it.

Fixing things fast is a skill. Letting things slow down on purpose feels wrong at first. When you’ve spent years being the person who jumps in, not jumping in can feel like negligence. Like you’re breaking some unwritten rule about what a “good” engineer does.

So I started small.

Instead of fixing the issue immediately, I asked someone to pair. Instead of pushing the change, I wrote down what I was about to do. Instead of being the only one who knew how a system worked, I forced myself to explain it badly at first, then better.

None of that felt efficient. All of it felt uncomfortable.

But something shifted.

People stopped waiting for me. Systems stopped feeling fragile. I wasn’t the fastest person in the room anymore, but I also wasn’t the bottleneck. The team moved a little slower in the moment and a lot faster over time.

The biggest change, though, was internal.

I stopped measuring my value by how urgently I was needed. I stopped confusing stress with importance. Being replaceable stopped feeling like a threat and started feeling like relief.

I still care. I still jump in sometimes. I still enjoy solving hard problems. But I’m trying to build things that don’t require a hero to survive.

Because the real flex in engineering isn’t saving the day.

It’s building systems and teams that don’t need saving.

Being replaceable is not a weakness

For a long time, I thought being indispensable was the goal.

If people needed me, I was doing something right. If systems broke without me, that meant I mattered. That logic is seductive, especially in an industry that quietly ties worth to output and urgency.

But the longer I’ve been around, the clearer this becomes: teams that depend on heroes don’t scale. They survive… until they don’t.

Hero culture isn’t about bad people or inflated egos. It’s about environments that confuse short-term rescue with long-term health. About praising the person who runs into the fire while ignoring why the building keeps catching fire in the first place.

And the industry keeps feeding it. Faster tools. Smaller teams. More pressure to ship. More praise for speed, less patience for collaboration. AI will only amplify this. One person can now do the work of many which makes it even more important to ask whether they should.

The future of engineering isn’t fewer heroes. It’s fewer emergencies.

It’s teams where knowledge is shared, systems are boring, and nobody panics when one person is offline. It’s environments where taking a break doesn’t feel like abandonment, and where doing the right thing slowly is still valued.

I don’t want to be the hero developer anymore. I want to work on teams where heroics are unnecessary.

If that sounds less impressive good.
That probably means it’s working.

If this hit close to home, I’d love to hear your take. Were you ever the “go-to” person? Did it feel like a compliment… or a warning?

Helpful resources

• The myth of the rockstar programmer Scott Hanselman breaks down why idolizing individual devs hurts teams more than it helps. Still painfully relevant. https://www.hanselman.com/blog/the-myth-of-the-rockstar-programmer
• Google’s SRE book (free online) Especially the sections on toil, ownership, and reliability. A great counterpoint to hero-driven operations. https://sre.google/sre-book/table-of-contents/
• Bus factor (Wikipedia) Simple concept, uncomfortable implications. If your number is one, that’s not a flex. https://en.wikipedia.org/wiki/Bus_factor
• “We don’t need another hero” (research paper) A study on hero programmers and why teams perform better without them. https://arxiv.org/abs/1710.09055