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.

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.

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 reliable documentation or runbooks.
• 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.

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.
  • Try to merge code only if there is sufficient documentation.
• 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.

• How To Prevent Coding "Heroes" From Destroying The Team (Fagner Brack, hackernoon.com, 2017-02-07)
• The Problem With Heroes In Software Development (Professor Beekums Blog, 2017-04-16)