Superhero Culture Is Not Team Culture

capes catch fire easily ( 15 minute read)

The story I use to move this article forward centers on a developer. This is just an example. Any role can fall into the patterns explained here, a product manager who is the only one who truly understands the client, a data analyst whose models nobody else can run, a QA engineer without whom nothing ships. The title changes. The dynamic does not.

The Hero?

There’s a developer on your team. Let’s call him Marcus. Marcus works until 2 AM. Marcus single-handedly rescued the last three releases from the jaws of catastrophe. Marcus knows every dark corner of the codebase, because he wrote most of it. Nobody else dares touch the parts he didn’t. Leadership loves Marcus. They reward Marcus. They hold Marcus up in all-hands meetings as the gold standard of what it means to be a committed engineer.

Marcus is burning your team to the ground, and nobody is talking about it.

This is the paradox at the heart of superhero culture in software development: the very behaviours that look like extraordinary performance are often the clearest symptoms of a deeply dysfunctional system. As an Agile coach, time and time again I have walked into organisations that told me their problem was velocity, or planning, or tooling. In most cases, the real problem was that they had, intentionally or by accident, built a culture that worshipped individual heroics, and in doing so, had quietly dismantled any chance of building a real team.

What Superhero Culture Actually Looks Like

Superhero culture does not announce itself. It grows organically, usually from the best of intentions, and it is reinforced by systems. Performance reviews, recognition programmes, and promotion criteria that were designed to celebrate excellence but ended up celebrating dependency. Here are its defining traits in a software context:

Knowledge is power, and power is hoarded. The superhero is the only person who truly understands the payment integration, the authentication layer, or why that one stored procedure has a comment that just says “DO NOT TOUCH! EVER!” This is rarely malicious. It is the natural consequence of moving fast without investing in shared understanding. But the effect is the same: a single point of failure wrapped in a human being.

Heroics are the release strategy. In superhero culture, releases are not planned, they are survived. When something goes wrong at 11 PM on a Friday (and something always goes wrong at 11 PM on a Friday), the call goes to one person. That person fixes it. The team exhales. The hero is thanked. The underlying conditions that caused the incident are quietly filed under “we’ll deal with it later,” which is to say, never.

The hero becomes the bottleneck. Pull requests queue up waiting for Marcus to review them. Architecture decisions stall until Marcus weighs in. Junior developers stop proposing solutions because their ideas get overridden anyway. The team’s throughput is capped not by process or tooling but by the bandwidth of one exhausted human.

Interruptions are currency. Because the hero is indispensable, they are perpetually interrupted. Every Teams message, every “do you have five minutes,” every escalation routes to the same person. Deep work becomes impossible. Cognitive load becomes unsustainable. The hero starts making mistakes, the same mistakes that less-burdened teammates would have caught in a proper review.

Bus factor of one. The most quietly terrifying metric in software development. If Marcus gets hit by a bus, or more realistically, if Marcus burns out, resigns, or takes a holiday, a significant portion of the organisation’s software capability disappears with him.

What Genuine Team Culture Looks Like

A high-performing Agile team does not produce heroes, heroics still occur but are situational. It produces something far more valuable and far less cinematic: reliability.

Knowledge flows continuously. Pair programming, mob sessions, thorough documentation, and deliberate cross-training are not overhead costs, they are the team’s insurance policy. No single person owns a domain. The codebase belongs to everyone, which means everyone is responsible for keeping it navigable. When someone leaves, the team loses a person, not a capability.

The process absorbs the pressure. In team culture, the release pipeline is designed, rehearsed, and automated so thoroughly that a 2 AM crisis is an edge case rather than a rite of passage. Incidents are handled by whoever is on call, not by whoever happens to be the most irreplaceable. Post-mortems focus on fixing systems, not praising the individuals who patched them.

Distributed ownership accelerates throughput. Because anyone on the team can review code, pick up a ticket, or debug a production issue, work flows in parallel rather than queuing behind a single gatekeeper. Velocity becomes a team measurement, not an individual one. Progress is visible, predictable, and sustainable.

Psychological safety over individual brilliance. In a genuine team culture, a junior engineer who spots a flaw in a senior’s design feels safe saying so, and is expected to. The best ideas are not the ones that came from the most senior person in the room; they are the ones that survived the scrutiny of the whole room. This is not consensus by committee. It is collective intelligence.

Failure is a system problem, not a person problem. When something breaks, the question is not “who did this?” but “what conditions made this possible, and how do we change them?” This distinction sounds small. In practice, it is the difference between a team that learns and a team that hides.

Pitting Them Against Each Other in a Time-to-Market World

Here is where the argument gets pointed, because the most common defence of superhero culture is a business one: we are moving fast, we do not have time for all that process, Marcus ships things. This argument is seductive and wrong.

In the short term, yes, a superhero can move faster than a team. If you need one feature shipped in two weeks and you give it to Marcus, Marcus will ship it. He will also be the only person who knows how it works, it will not be properly tested, and the next time you need to change it, you will need Marcus again. You have not built capability. You have built a dependency.

In the medium term, the superhero model begins to collapse under its own weight. Technical debt accumulates around the hero’s shortcuts. The team around them atrophies, good engineers leave because they have no autonomy, junior engineers plateau because they have no real responsibility. Delivery timelines become unpredictable because they are tied to the availability and cognitive state of individuals rather than to a stable, observable process.

In the long term, superhero culture is a company-level risk. Organisations that depend on individuals rather than systems cannot scale. They cannot onboard quickly, cannot pivot efficiently, and cannot maintain quality as complexity grows. The hero either burns out or becomes a bottleneck so severe that the organisation has to restructure around them. I have seen both outcomes. Neither is good.

A team culture, by contrast, has a different curve. The upfront investment in shared practices, documentation, and collective ownership feels slow, and it is, initially. But the compounding returns are dramatic. Teams that invest in genuine collaboration ship more predictably, recover from setbacks faster, and improve their own processes over time. Time-to-market is not just about the speed of the next feature. It is about the sustainable throughput of the next hundred features.

The Agile Coach’s Diagnosis

When I walk into a team and start asking questions, I am always listening for a particular kind of answer. It sounds like this: “We would be fine, but we just really need Marcus to get through this sprint.”

That sentence, in whatever form it takes, is the diagnostic. A team that cannot function reliably without a specific individual is not a team. It is a person with supporting cast.

My job, in those situations, is not to blame the hero. Marcus is not the problem. Marcus is the symptom. The problem is a system that rewarded Marcus for being indispensable rather than for making the team stronger. The problem is a management culture that interprets late nights as commitment rather than as a signal that workload distribution is broken. The problem is retrospectives that celebrate rescues instead of asking why the rescue was necessary.

The path forward is not to make the hero less heroic. It is to build a team so capable that individual heroism becomes unnecessary, and honestly, a little bit boring. In a well-functioning Agile team, nobody works until 2 AM because nobody needs to. Features ship. Bugs get fixed. Incidents get resolved. And nobody gets a standing ovation for it, because it just works.

That, to me, is the highest expression of team culture. Not the dramatic save. The absence of the need for one.

When the System Demands a Hero

Before we go further, there is something that needs to be said plainly, because glossing over it would make this article dishonest.

Not every hero culture is born from bad management habits or lazy recognition patterns. Some of it is. But a significant proportion of the cases I encounter are not primarily cultural failures. They are structural ones. And the engineers carrying the weight know the difference, even if leadership does not.

Consider what actually happens in many engineering organisations. Sales commits to a delivery date without consulting the team. Product adds scope mid-sprint without removing anything. A key vendor misses an integration deadline and two weeks of planned work evaporates overnight. Headcount requests are frozen while the roadmap expands. A platform team that three squads depend on is perpetually under-resourced. And somewhere in the middle of all of this, Marcus stays until 2 AM, not because the culture celebrated heroics, but because if he doesn’t, a commitment the business made to a paying customer will be broken, and he knows it.

This is hero culture as a coping mechanism. And it is arguably more insidious than the purely cultural variant, because the heroics are entirely rational. From Marcus’s perspective, the right thing to do in the moment actually is to stay late. The system has been structured in a way that makes individual heroism the only available response to chronic structural misalignment.

The root causes here are different, and they sit higher in the organisation. Understaffing is a leadership decision. Unrealistic commitments are a sales and product governance failure. Chronic deadline compression is what happens when capacity planning is either absent or deliberately ignored in pursuit of short-term revenue. These are not team-level problems. They are business model problems that have been outsourced to the engineering team to absorb, and the currency they are paid in is overtime, burnout, and the slow erosion of everything that makes sustainable delivery possible.

And here is why this matters for the argument. If you acknowledge this honestly, the diagnosis shifts. The question is no longer just “why does your team culture reward heroics?” It becomes “why is your business model structurally dependent on individuals absorbing commitments that the system as a whole cannot honour?” These are related questions, but they implicate different rooms in the building. The first points to team leads and engineering managers. The second points to the C-suite, to sales leadership, and to the boardroom.

It also changes what we should be asking of Marcus. An engineer working in a structurally overloaded system who stays late to protect a customer commitment is not making a cultural mistake. They are making a short-term rational choice under conditions they did not create. The failure is not theirs. The failure belongs to the organisation that normalised those conditions and then built processes, roadmaps, and revenue forecasts on the assumption that someone will always find a way to absorb the gap.

But here is the critical point, and this is where structural acknowledgement must not become structural absolution. Identifying understaffing or sales-led overcommitment as a root cause does not make the hero dependency less dangerous. It makes it more so. A codebase that has accumulated a year of hero-driven shortcuts under deadline pressure is not safer because the pressure was externally imposed. A team that has lost three engineers to burnout because the roadmap was chronically misaligned with capacity is not healthier because the roadmap was set by sales. The downstream effects are identical regardless of the upstream cause.

What changes is the level at which the solution must be applied. If the culture is the problem, you fix the culture. If the structure is the problem, you have to fix the structure, and that means having different conversations, with different people, about different things. It means product leadership being honest about what a team can actually deliver in a quarter. It means sales learning to qualify commitments against delivery capacity before signing contracts. It means organisations understanding that every time they allow a structural gap to be closed by individual heroics, they are borrowing capability from a future state that will have less of it.

The most difficult version of this conversation is the one where an engineering leader has to walk into a room and say: “We cannot keep delivering on these commitments without either more capacity, reduced scope, or a longer timeline. What we cannot keep doing is relying on two engineers to bridge that gap indefinitely.” That conversation is hard. It involves risk. It may not be well received.

But it is the only conversation that addresses the actual problem rather than managing its symptoms. And in my experience, the organisations that are willing to have it, that are willing to treat delivery capacity as a real constraint rather than a variable to be overcome by individual effort, are the ones that eventually stop needing heroes.

The others keep promoting them.

Yes, But Our Situation Is Different - The Counterarguments, Debunked

Every time I present this argument to a leadership team, the room nods along right up until the moment it becomes personal. Then the defences come out. They are always confident, often articulate, and almost always wrong. Let me work through the most common ones.

(We’re a startup.) We don’t have time to build team culture right now.

This is the most popular objection, and it contains a grain of truth wrapped around a dangerous misunderstanding. Yes, early-stage startups and startup-like strcutures in larger organisations move fast, make decisions with incomplete information, and cannot afford the process overhead of a large engineering organisation. Nobody is asking a five-person seed-stage team to run formal architecture review boards.

But “we move fast” is not the same as “we can only function if one person holds all the knowledge.” Even at speed, you can pair on complex features. Even under pressure, you can write a README that explains why a critical service works the way it does. The practices that build team culture are not bureaucratic rituals, they are habits of communication, and they cost almost nothing except intention.

More pointedly: the team that builds a hero-dependent codebase in year one will spend years two through five paying for it. Technical debt is not merely about code quality. It is about the organisational capability that atrophied while everyone was waiting for Marcus to finish his sprint. The time you think you are saving now is being borrowed from a future team that will have to work twice as hard to understand what you built and why.

Our domain is genuinely complex. Not everyone can do what Marcus does.

This one is harder to dismiss outright, because it is partially true. Some domains -real-time trading systems, safety-critical embedded software, deeply specialised machine learning pipelines- do require rare expertise. There will always be some asymmetry of knowledge on a technical team.

But there is a meaningful difference between acknowledging expertise and institutionalising dependency. A team can have a resident expert in distributed systems without that expert being the only person who can deploy the service, review the code, or articulate the architectural decisions in a post-mortem. Expertise should be a resource the team draws on, not a door only one person holds the key to.

If your argument is that the work is so complex that knowledge-sharing is genuinely impossible, I would ask you to examine that belief carefully. In most cases, what is actually happening is that knowledge-sharing has never been seriously attempted, because the hero was always available, so the investment never felt urgent. Complexity is real. Impenetrability, in almost every case I have encountered, is a choice.

We tried cross-training and it slowed everything down.

This objection usually describes a real experience, which makes it feel more valid than it is. Yes, the first time you pair two engineers on a task instead of letting one sprint ahead alone, it will take longer. Yes, the first few code reviews from a developer unfamiliar with a module will be surface-level and frustrating. Yes, writing documentation takes time that could have been spent writing features.

What this argument mistakes is the unit of measurement. You are measuring the cost of knowledge transfer in a single sprint and ignoring the return on investment across every sprint that follows. The second time that developer touches that module, they are faster. The third time, they catch a bug the original author would have missed. The first post-mortem where two people understand the system well enough to diagnose the failure instead of one, that pays for six months of “slow” pair sessions.

Agile is not about moving fast in week one. It is about moving faster in week fifty than you did in week one, because you have built systems, habits, and shared understanding that compound over time. Slowing down to go faster is not a motivational poster slogan. It is a description of how compounding actually works.

But Marcus loves being the go-to person. It’s what motivates him.

I hear this one more than you might expect, and it deserves a compassionate but direct response: that is not a business strategy. That is a retention tactic masquerading as one.

There is a version of this that is genuinely worth taking seriously, intrinsic motivation matters, and engineers who feel ownership over their work produce better outcomes. But there is a profound difference between an engineer who is energised by mastery and ownership and an engineer whose identity is built around being irreplaceable. The former is an asset. The latter is a liability dressed in a motivational narrative.

Beyond the business risk, I would also ask: is this actually good for Marcus? An identity built on indispensability is fragile. It does not survive reorganisations, redundancies, or the slow erosion of being perpetually overloaded. Engineers who have never been given the opportunity to mentor, delegate, or share their knowledge have also been denied the opportunity to grow beyond their current role. Keeping Marcus in the hero position because he likes it is not looking after Marcus. It is keeping a talented person in a position that feels good in the short term and limits them in the long term.

But we have always worked this way. It is part of our culture.

Then your culture is the problem.

I say that without judgment, because culture is rarely designed, it emerges. Nobody sat down and decided to build a team that cannot function without two specific engineers. It happened gradually, through a thousand small decisions that each seemed reasonable at the time. Rewarding the late-night fix. Not investing in onboarding documentation because the deadline was tomorrow. Letting the expert review all the PRs because it was faster.

But “we’ve always done it this way” is not a defence of a practice. It is a description of inertia. The question is not how you got here. The question is whether the way you have always worked is actually producing the outcomes you want, sustainable delivery, team resilience, the ability to grow and onboard new engineers without a twelve-month learning cliff. If the honest answer is no, then the longevity of the practice is not a reason to preserve it. It is a reason the problem has had so long to compound.

Culture changes slowly, and it changes through behaviour before it changes through belief. You do not need to convince everyone that hero culture is bad before you start changing it. You need to start changing the incentives, the rituals, and the recognition patterns, and the beliefs will follow.

Leadership Advice

If you are a CTO, engineering manager, product leader, or team leader reading this and recognising your organisation in these pages, the levers are straightforward, even if they are not easy.

Stop rewarding heroics in isolation. Celebrate the team that shipped, not the individual who stayed latest. Introduce it into how you frame your all-hands, your performance reviews, and your public recognition.

Invest in knowledge distribution as a first-class engineering activity. Pair programming, architecture decision records, internal documentation, and cross-training are not optional luxuries. They are how you reduce your bus factor before the bus arrives.

Measure team health, not individual output. Story points per developer is not an Agile metric. Team throughput, cycle time, deployment frequency, and mean time to recovery are. These are the signals that tell you whether you are building a system or depending on a person.

And if you have a Marcus, have an honest conversation with him. Not to diminish what he has contributed, but to help him understand that the most lasting thing he can do for this team is to make himself replaceable.

That is what real seniority looks like. Not the inability to be substituted. The deliberate, skilled work of building something that thrives without you.

The cape looks good. But a well-run team never needed one.