The Myth of the Heroic Fix

-
“By failing to prepare, you are preparing to fail.” - Benjamin Franklin

In startup and tech culture, we celebrate the last-minute save. But heroics are often symptoms of earlier neglect.

Hero Culture thrives on moments like this: it's Friday at 4:47pm, a ticket has been sitting in review for two weeks, the stakeholder is impatient, and the engineer has a flight to catch, so someone pushes the deployment button because it's a small change and it's always fine. By 9pm there's a Slack thread, by 10pm it's a call, the engineer is somewhere over Ohio in airplane mode, and the one person who knows that part of the codebase is stepping outside a birthday dinner every fifteen minutes to check their phone. The fix takes forty minutes, the post-mortem takes two weeks, and the person who stayed up to save the night gets praised on Monday morning while the person who warned against Friday deployments three sprints ago is quietly forgotten. That's the thing about Hero Culture: it doesn't just tolerate this cycle, it depends on it.

Why did this need saving at all?

In startups in particular there is a cultural celebration of heroics. It's part of the mythology. Pulling all-nighters and facing "crunch time." The big celebration after launch that "we pulled it off." Our movies and tech folklore reinforce the idea of the brilliant individual savior. In reality, systems rarely fail suddenly. They decay gradually. 

There are a handful of root causes to this sort of "heroics" becoming part of the culture. We're talking about deferred maintenance, overcommitment, poor documentation, and unrealistic deadlines. This ties back to visibility bias and shipping over advancing, which I've already discussed on this blog recently. Heroics are often interest payments on prior avoidance. 

The cost of hero culture isn't hidden. In the short-term it's all praise, energy, and bonding. Long-term we see it show up as burnout, instability, fear-based urgency, and incentivized chaos. I saw it once at a startup where the product manager and I found ourselves frequently talking the engineering lead "off the ledge." The team itself begins to equate stress with importance. 

Mature, more healthy organizations take a different approach. They reward prevention, invest in boring stability, build slack into timelines, and normalize stopping before a crisis. To be honest, I've rarely seen this level of maturity in an organization. It requires a shift from reactive excellence to preventative discipline. It isn't very exciting. 

We need to rethink leadership in this context. It is not being the person who saves the day. It is, rather, designing systems that do not require saving. The best fix is the one no one ever notices because it was never needed. That kind of leadership is quiet, architectural, and often invisible. It invests in clarity, redundancy, feedback loops, and decision rights long before a crisis exposes their absence. Instead of celebrating the hero who patches the leak, we should value the leader who strengthened the foundation so the pressure never built in the first place. Over time, this shift moves an organization from reactive drama to durable resilience.

Some things to check on to know if your organization or team is suffering from Hero Culture:

  • How often do we rely on last-minute pushes?

  • Are crises predictable?

  • Who benefits from urgency?

  • Do we reward the people who warned us early?

Calm systems are not accidental. They are built. They are the product of leaders who choose discipline over drama, foresight over adrenaline, and prevention over applause. If you want fewer 10pm incident calls and fewer Monday-morning hero celebrations, start rewarding the people who slow things down at 4:47pm on Friday. Audit what you praise. Fund maintenance. Normalize saying “not yet.” The culture you tolerate compounds — either toward chaos or toward resilience. The question is not whether your organization will pay a price. It is whether you will pay it upfront in thoughtful design, or with interest in exhaustion and instability later.

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more