====== 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.

===== How Hero Culture Forms =====
Hero roles emerge when teams lack shared ownership and resilience. Some common triggers:

  * No reliable documentation or [[:admin:runbooks|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.

===== 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.
    * 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 [[:guide:post-mortem|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 =====
  * [[https://hackernoon.com/thoughts-on-software-development-heroes-5ec656c2e31a|How To Prevent Coding "Heroes" From Destroying The Team]] (Fagner Brack, hackernoon.com, 2017-02-07)
  * [[https://blog.professorbeekums.com/heroes-in-software-development/|The Problem With Heroes In Software Development]] (Professor Beekums Blog, 2017-04-16)