Heroics Aren't a Strategy

Heroics aren't a strategy. They're the receipt for the system you didn't build.

You've seen the LinkedIn post.

A founder, hunched over a laptop at 3am, fourth Diet Coke of the night, captioning the photo with something about grinding now and shining later, and shipping at dawn. Comments are full of fire emojis. People who barely know the founder are calling them a beast. The picture has 1,200 reactions. By morning the launch is live.

You've also been the founder. You shipped at 4am the Friday before that big customer demo. You patched the auth bug at 11pm on a Sunday. You were the one who stayed up to make sure the migration ran cleanly. Each one of those nights felt heroic in the moment and looks heroic in the company-history version of the story.

The story is wrong.

The 3am ship is not the badge of honor it gets framed as. The 3am ship is the visible signature of a structural problem. The team that requires its founder to ship at 3am is a team whose shipping infrastructure is broken. The shipping infrastructure has been broken for a long time, and the founder's body has been absorbing the cost, and the body has now absorbed enough that the cost is starting to show up as something else, somewhere else, in a way that's harder to trace back to the original failure.

There are three books that explain this in detail, written by people whose careers were spent watching the heroics-vs-infrastructure tradeoff play out across thousands of teams. The books have been sitting on every engineering manager's shelf for over a decade. Senior operators almost never read them, because the books are about engineering and the operator is a CEO.

The lessons apply to every operation, not just engineering ones. The reason your project is on its third heroic save is not that your team is bad. It's that you've been running an operation that was structurally going to require heroics, and heroics are not a renewable resource.

What Atul Gawande proved in 2009

Atul Gawande is a Boston surgeon and New Yorker staff writer who, for the last twenty years, has been the most-read public voice on healthcare systems thinking. In 2009 he published The Checklist Manifesto: How to Get Things Right. The book has sold over a million copies and is on the syllabus of every operations program.

The premise is short. Gawande studied surgical errors and found that the fields with the worst error rates were not the fields with the least-skilled people. They were the fields where the volume of necessary steps had outgrown what one human could reliably hold in their head. Aviation. Construction. Oncology. Cardiac surgery. The error rates correlated almost perfectly with the count of steps required to do the work correctly. More steps, more errors. Not because the people got worse, but because the human cognitive system has finite capacity, and once the count exceeded that capacity, mistakes happened.

The fix Gawande's research kept finding was the simplest possible piece of infrastructure. A checklist. Not a poster. Not a training. Not a culture campaign. A specific, written-down list of the steps that had to happen, in the order they had to happen, with checkboxes that someone actually checked, every time, no exceptions.

The most-cited study in the book is the WHO Surgical Safety Checklist trial. A 19-item checklist, used at induction, before incision, and before the patient left the operating room. Implemented across eight hospitals in eight countries. The trial measured outcomes for 7,688 patients. Major complications dropped 36%. Deaths dropped 47%. The surgeons hadn't gotten better. The hospitals hadn't bought new equipment. They'd added a piece of paper. The paper held the steps the surgeons couldn't reliably hold.

That paper is a piece of infrastructure. The reason it worked is that it converted a system that required heroic memory into a system that didn't. The variability in human attention got absorbed by the checklist. The team's average performance moved up to the level the checklist enforced.

Now look at how your team ships.

There is no checklist. The deploy steps live in a Slack thread from August 2024. The pre-launch QA happens because someone remembers to do it. The customer-comms triggers fire because you happen to think of them at 11pm. The team's average performance is gated by your memory, which means the team's performance falls every time you're tired.

That's not a discipline problem. That's a missing-checklist problem. Gawande named it. The fix is a piece of paper.

What the DORA research proved across 30,000 teams

In 2014 a researcher named Nicole Forsgren, working with Jez Humble and Gene Kim, started running an annual survey called DORA — DevOps Research and Assessment. Over six years, the project surveyed more than 30,000 engineering professionals across thousands of organizations. In 2018 they synthesized the findings in a book called Accelerate.

The book identified four metrics that, when measured together, explained almost all of the variation between high-performing and low-performing engineering teams. Lead time for changes. Deployment frequency. Mean time to restore service. Change failure rate.

The most counterintuitive finding, replicated across six years of survey data, was that the high-performing teams shipped more often, not less, and had fewer failures, not more. The trade-off most operators believed in — slower and safer versus faster and riskier — wasn't real. The teams that shipped daily had lower failure rates than the teams that shipped quarterly. The teams that recovered in under an hour had lower change-failure rates than the teams that took days to recover.

The reason is structural. Teams that ship daily have necessarily built infrastructure that lets them. Automated tests. Reversible deploys. Feature flags. Monitoring that catches a regression in minutes. The infrastructure is what makes daily shipping possible. The infrastructure also catches the bugs the slower teams were ostensibly being careful about.

Heroics are correlated with the slow-and-risky quadrant. The team that ships once a quarter, in a fragile manual process, requiring a hero to push it across, is also the team with the highest failure rate. The team that ships ten times a day, in an automated, well-monitored pipeline, has the lowest failure rate, and nobody on it ever ships at 3am.

Forsgren's claim, drawn from 30,000 data points, is that high performance is a structural property of the team's infrastructure, not a personality property of the people inside it. You can't hero your way to high performance. You can only build your way to it.

What Continuous Delivery formalized in 2010

In 2010 two engineers named Jez Humble and David Farley published Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. The book defined a discipline. Within five years, every credible software organization in the world had adopted some version of it.

The premise is one principle, repeated for 500 pages. Software should always be in a deployable state. Every change should be small. Every change should be tested automatically. Every change should be released frequently. The combination eliminates the entire category of failure modes that come from large, infrequent, manual deployments.

What Humble and Farley were really arguing, behind the technical detail, is a philosophy of how organizations should treat the work of shipping. Most operators treat shipping as an event. Shipping is a release. Shipping is a launch. Shipping is the moment of truth. Continuous Delivery argues that shipping should be a non-event. The deploy is so routine, so automated, so reliably-correct, that nobody notices when it happens. The interesting work is the work the team does between deploys, on improvements that move the product forward. The deploy itself is plumbing.

Apply this lens to your operation right now.

You treat shipping as an event. Launch days are a thing on your calendar. Customer comms ramp up. The team gets nervous. You stay up late. The deploy itself is a multi-hour manual process that requires you to be in the building. Every launch generates a small wave of anxiety, then a small wave of relief, then a small wave of bug fixes that have to be heroically deployed in the days that follow.

Humble and Farley would identify your operation as a candidate for an entire structural rebuild. Not because the team is bad. Because the deploy is an event, and as long as it's an event, the rest of the failures will keep happening.

The teams that have moved past this state describe it the same way every time. The deploy is invisible. The launch is uneventful. The team works on the product. Shipping just happens, in the background, on a schedule, every day, and nobody loses sleep.

That's not a story about more advanced engineers. That's a story about better-built operating infrastructure.

Three structural moves that retire the heroics

You don't fix this by hiring more people. You fix it with three structural pieces.

1. Write the deploy checklist. Open a doc. Write down every step required to ship a release of your product, in the order they happen, in plain English. There will be 15-30 of them. Most of them are currently in your head, in old Slack threads, or in nobody's head at all. The checklist itself is the Gawande move. The first time you run a release with the checklist, the deploy will be 30% faster and 50% less stressful. The checklist absorbs the variability your memory was previously absorbing.

2. Find the smallest deployable unit. What is the smallest change you can ship in production safely. If the answer is "a major version, once a quarter," that's the structural failure. The DORA finding is that smaller changes have lower failure rates. The path to daily shipping is iterative, not heroic. Pick one thing. Make it shippable in a day. Then the next thing. The structural shift takes months. The first day you ship a small change is the day the operation starts becoming a different shape.

3. Treat the launch as a non-event. This is the Humble-and-Farley move applied to a non-engineering operation. The next launch you do, do it on a Tuesday morning, without a launch day, without customer comms ramping up, without a war room. Just ship it. See what breaks. Fix what breaks. Ship the next thing on Thursday. Most operators have never done this and are surprised, the first time they try it, by how much of the launch ritual was theater.

If you want a second voice in the room while you build the new operating cadence, that's exactly what a 6-Week Build Partnership is.

The reframe

The 3am hero ship is not a sign that your team is committed.

It's a sign that your shipping infrastructure cannot work without you absorbing the variability personally, every time, with your body, on a schedule that is structurally not sustainable.

Gawande told you the fix is a checklist. DORA proved that frequent shipping reduces, not increases, failure. Humble and Farley spent 500 pages explaining how to make the deploy a non-event.

You don't need a more disciplined team. You need a deploy checklist, a smaller-unit cadence, and a non-event launch.

The boring version is the one that ships forever. The heroic version is the one that ships until the hero burns out.

Build the boring version.