When building new teams or organizations from the ground up, we usually start with a handful of people who own every piece of the product. In the process of building systems in fast-paced environments, we often create “Hero”es. A hero is a person who pulls an all-nighter to fix broken systems, stepping in at the last minute to save us from a failed deployment and by doing so, they carry the weight of an entire organization on their shoulders. This behavior is often praised and seen as a good thing. But the dire reality is: If your org is constantly relying on hero, then your process is broken. Relying  on heroic feats of an individual is not a sign of a high-performing culture; it is an indication of systemic failure. As we scale up the systems and culture, this often works as an impediment. Before we start to improve the culture, moving from the creation of heroes to scalable systems and processes, we need to understand what actually creates heroes. process is broken systemic failure How We Create "Heroes" A hero is not born, but created due to the environment, based on need. While their intentions are almost often noble, the dynamic slowly spirals into a vicious cycle of structural dependency. Appreciation for "Firefighting": When leadership constantly praises and promotes individuals who stay late and save the company from Doom’s day, what they are unconsciously communicating is that we value crisis management more than crisis prevention.
Lack of Documentation and Decision Logging: In break-fast and build-fast environments, complexity grows faster than structure. Critical information is trapped in a few Hero's heads because there is no time or standardized process for documentation.
Knowledge Hoarding for Job Security: In addition to the above, individuals may unconsciously or consciously hoard information to feel validated, required, or "untouchable."
Running on Empty Tank: When a team doesn't have enough people, someone usually gets stuck holding the bag for an entire system. They become heroes by default just because there's nobody else around to share the work.
The Legend of "Lone Genius": We culturally romanticize and promote the solo mastermind who grinds out 80-hour weeks. High performers see this and feel pressured to act just to live up to an impossible standard.
Reactive Leadership: Instead of doing the hard work to fix bad code or hire more staff, managers just lean on their best expert to push things over the finish line. Appreciation for "Firefighting": When leadership constantly praises and promotes individuals who stay late and save the company from Doom’s day, what they are unconsciously communicating is that we value crisis management more than crisis prevention. Appreciation for "Firefighting" praises and promotes individuals Lack of Documentation and Decision Logging: In break-fast and build-fast environments, complexity grows faster than structure. Critical information is trapped in a few Hero's heads because there is no time or standardized process for documentation. Lack of Documentation and Decision Logging trapped Knowledge Hoarding for Job Security: In addition to the above, individuals may unconsciously or consciously hoard information to feel validated, required, or "untouchable." Knowledge Hoarding for Job Security unconsciously or consciously hoard information Running on Empty Tank: When a team doesn't have enough people, someone usually gets stuck holding the bag for an entire system. They become heroes by default just because there's nobody else around to share the work. Running on Empty Tank: enough The Legend of "Lone Genius": We culturally romanticize and promote the solo mastermind who grinds out 80-hour weeks. High performers see this and feel pressured to act just to live up to an impossible standard. The Legend of "Lone Genius" pressured Reactive Leadership: Instead of doing the hard work to fix bad code or hire more staff, managers just lean on their best expert to push things over the finish line. Reactive Leadership push things Why "Hero" Culture is Dangerous Understanding how a “hero” is created is one thing; we also must understand why relying on them is destructive. While it feels good for a hero to have a savior complex and organizations lauding such behavior, it is often a ticking bomb for the organization in the long term, for the following reasons. The Bus Factor: What happens if & when your hero quits, gets sick, or just wants to take a two-week vacation? The work comes to a halt because all the know-how intricacies are locked in their head.
Massive Bottlenecks: Heroes accidentally become California freeway-style human traffic jams. If the team can't move the needle without their approval, overall productivity stoops.
You Can't Scale Heroes: You can't grow a business on the back of one person's brilliance. You need boring, repeatable processes to actually expand.
Hidden RCA and Tech Debt: Every time a hero pulls off a "midnight save," they're essentially slapping a band-aid on a broken system. They are prioritizing fixing the problem ( speed ) over fixing it in right way ( doing it right ) , which just piles up technical debt and hides the RCA from leadership.
Inevitable Burnout: Running forever on 100 kmph ( or 100mph for American Folks ) is not Sustainable. Eventually, people crash, start making careless mistakes, or leave the company entirely out of sheer exhaustion.
Killing Team Morale: When one person gets all the glory, everybody else feels like an extra in a movie. It kills initiative. Plus, nobody wants to call out the "hero" when they mess up, so accountability goes right out the window. The Bus Factor: What happens if & when your hero quits, gets sick, or just wants to take a two-week vacation? The work comes to a halt because all the know-how intricacies are locked in their head. The Bus Factor Massive Bottlenecks: Heroes accidentally become California freeway-style human traffic jams. If the team can't move the needle without their approval, overall productivity stoops. Massive Bottlenecks: You Can't Scale Heroes: You can't grow a business on the back of one person's brilliance. You need boring, repeatable processes to actually expand. You Can't Scale Heroes: Hidden RCA and Tech Debt: Every time a hero pulls off a "midnight save," they're essentially slapping a band-aid on a broken system. They are prioritizing fixing the problem ( speed ) over fixing it in right way ( doing it right ) , which just piles up technical debt and hides the RCA from leadership. Hidden RCA and Tech Debt Inevitable Burnout: Running forever on 100 kmph ( or 100mph for American Folks ) is not Sustainable. Eventually, people crash, start making careless mistakes, or leave the company entirely out of sheer exhaustion. Inevitable Burnout: Killing Team Morale: When one person gets all the glory, everybody else feels like an extra in a movie. It kills initiative. Plus, nobody wants to call out the "hero" when they mess up, so accountability goes right out the window. Killing Team Morale: How to Actually Build Systems (And Stop Relying on Heroes) Transitioning away from "hero" culture doesn't mean firing or removing your best folks (read: "heroes"), but building a culture where we don't require heroes for the company to survive and thrive. It is about moving away from a reactive to a proactive environment using the following methods: Change What You Reward: Stop praising the firefighters. Start cultivating and promoting the culture and people who do the quiet, boring work of preventing the fires in the first place.
Force the Documentation: Get that tribal knowledge out of people's heads. Log your decisions and document your systems, every sprint as a line item.
Break the Info Hoarding: Cross-train your teams. Eliminate single point of failures, and the need to hoard knowledge just to feel secure at their job.
Kill the Lone Genius Myth: Celebrate team wins rather than solo, late-night heroics. If late-night incidents arise, create RCA and share it with teams to disseminate the knowledge
Look at the Long Game: Leaders need to stop using band-aid thinking to hit short-term deadlines and focus on long term strategy. Bite the bullet, refactor the code, hire the right people, and fix the underlying structural issues. Change What You Reward: Stop praising the firefighters. Start cultivating and promoting the culture and people who do the quiet, boring work of preventing the fires in the first place. Change What You Reward: Force the Documentation: Get that tribal knowledge out of people's heads. Log your decisions and document your systems, every sprint as a line item. Force the Documentation: Break the Info Hoarding: Cross-train your teams. Eliminate single point of failures, and the need to hoard knowledge just to feel secure at their job. Break the Info Hoarding: Kill the Lone Genius Myth: Celebrate team wins rather than solo, late-night heroics. If late-night incidents arise, create RCA and share it with teams to disseminate the knowledge Kill the Lone Genius Myth: Look at the Long Game: Leaders need to stop using band-aid thinking to hit short-term deadlines and focus on long term strategy. Bite the bullet, refactor the code, hire the right people, and fix the underlying structural issues. Look at the Long Game: The hero culture might work when you are figuring the GTM strategy or Product-Market Fit, but as you mature as a organization, it required a reliable and boring processes. When you shift your culture to reward fire prevention instead of fire fighting, you build a resilient, systems and  teams. The goal is not to penalize hard work or brilliance, but to channel energy into building sustainable systems that don't constantly demand personal sacrifices.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Stop Throwing AI at Broken Systems: Fix Your Engineering Culture First

Kill Heroes, Build Systems and Processes

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building a Custom Homebrew Formula: A Case on tfblueprintgen

The Bus Factor Score: How Many Team Members Can get Hit By a Bus Before the Team Fails?

Investigating the "Bus Factor" Risk in MongoDB, MariaDB, and More

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

Building a Custom Homebrew Formula: A Case on tfblueprintgen

The Bus Factor Score: How Many Team Members Can get Hit By a Bus Before the Team Fails?

Investigating the "Bus Factor" Risk in MongoDB, MariaDB, and More

10 Ways to Future-Proof Your Business With Cloud

10 Upcoming DevOps Conferences for 2018

101 Stories To Learn About Cloud Infrastructure

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps