Hero Developers
Many teams eventually discover a certain type of developer who becomes the "go-to person" whenever something breaks. They react quickly, jump into crises without hesitation, and often restore systems just in time. This person is celebrated as a hero – but the presence of a hero usually signals deeper issues in the team or the product.
What Defines a Hero?
Hero developers don't stand out because they build robust systems. They stand out because they are needed to keep fragile systems alive. Typical traits include:
Perpetual Firefighting – They regularly deal with urgent issues but rarely address why the issues keep happening.
Exclusive Knowledge – Key parts of the codebase or infrastructure only make sense to them.
Speed Over Quality – They prioritise fast fixes that stabilize the moment, not the long-term health of the system.
Resistance to Sharing – Documentation, pair programming, and onboarding fall to the wayside.
Chronic Availability – They are always reachable, often at the cost of their personal time.
From the outside, this looks like dedication. In reality, it is a fragile, unsustainable dependency.
Why Hero Culture Is Harmful
Depending on a single person creates a dangerous bottleneck:
When the hero is unavailable, the team may be unable to respond to incidents.
Temporary fixes accumulate, making the system increasingly difficult to maintain.
Other team members lose opportunities to learn critical skills.
Important decisions get made in a hurry and outside of team processes.
The hero themselves risks burnout, stress, and stagnation – their expertise becomes tied to chaos rather than good engineering.
Hero culture often grows silently until the system becomes impossible to improve without major rewrites.
Hero roles emerge when teams lack shared ownership and resilience. Some common triggers:
-
No rotation for incident response.
Complex systems with few entry points for newcomers.
Rewarding short-term "rescue work" instead of long-term stability.
Teams working in silos or isolating "specialists."
In this environment, one person naturally becomes the keeper of unwritten knowledge.
Building Teams Without Heroes
Preventing hero dependency means building systems and teams that do not rely on individuals:
Spread knowledge through pairing, code reviews, and collaborative debugging.
Make documentation and runbooks first-class citizens.
Encourage sustainable engineering, not adrenaline-driven quick wins.
Actively involve multiple people during incidents to grow capability.
Do
post mortems to figure out what went wrong and what to improve.
Treat recurring emergencies as architectural problems, not as opportunities to showcase individual effort.
A healthy engineering culture ensures that no single person is required for the team to operate — and that reliability is a shared responsibility.
Articles