Occasional Bouts of Heroism
There was a concept at Google that I always had mixed feelings about. It is called the “No Heroes” rule1, and the argument goes like this: When an individual has to do a heroic task (ex: work 18 hours straight to prevent an outage) that effort is masking a systemic and institutional gap. The right response is to fix the system so heroism becomes unnecessary. In a mature, high performing engineering org, there should be no heroes.
No Heroes is generally the correct engineering doctrine in a mature organization. But I believe it is wrong as a theory of how institutions actually get things done, and is wrong about human nature.
Charlie Munger once described Google’s headquarters as a “very rich kindergarten.” Munching on snacks in the micro-kitchen, I couldn’t help but feel I was getting soft, and that the organization itself was getting soft. No Heroes removes the veneration of going hard, which over time selects for a different kind of employee. Google is an unusual place and was a privilege to work at, but a No Heroes ethos paired with a culture of comfort gets dangerous the moment the org has to get medieval and go from 0 to 1.
Even inside Google, I was often surprised to find that one engineer happened to know everything about a system and was the major driving force behind it. Most progress, even inside large institutions, is made by one person with the drive and skill to pull it off. The xkcd “Dependency” comic about modern infrastructure resting on “a project some random person in Nebraska has been thanklessly maintaining since 2003” is a joke and also true.
This is the double-edged sword. There is a concept I came across recently called the Bus Factor. It refers to the number of people who would need to disappear (get hit by a bus) before a project loses enough critical knowledge to continue. A 2015 study found that for 64% of the top 133 GitHub projects, the Bus Factor was below 22. Heroism without institutional backing produces fragility.
I am in many ways amenable to the Great Man of History theory. It is hard to operate in the startup world without believing at least parts of it. The founder is that great (wo)man, single-handedly pulling the company, and sometimes the world, along into something generational.
Startups, and the startup mindset, are organized entirely around heroism. It is all “cracked 10x engineers” and going Founder Mode, and it really does take a uniquely visionary and gritty individual to go from 0 to 1. The cost is that 24/7 heroism is often unsustainable, and a major cause of startup death is the founder giving up. Startups need at least some institutional scaffolding so that the company can survive a key person leaving. But Brian Chesky’s vision of Founder Mode is essentially that the founder-as-hero archetype should never end, even as a startup scales up even into IPO. So in the vision of Founder Mode, the company is the founder. The founder absolutely should understand the product best, but the same instinct, taken too far, can produce tyrannical micromanagement and cults of personality.
The military is a great example of holding “No Heroes” and “celebration of heroes” in tension simultaneously. Individuals join as they are, and the institution forges them into a disciplined whole greater than the sum of its parts. Individuals are made interchangeable, and the institution is designed to keep functioning regardless of who fills any one role. And yet military history is overwhelmingly a history of named individuals doing heroic, extraordinary things in service of the mission. Nobody gets a Medal of Honor in a mission where everything goes to plan. We have after action reports to root out systemic failures and learn from mistakes, but we also celebrate, honor, and encourage heroic acts of service.
Heroism and institution are complementary and must be calibrated to meet the moment. Google could probably use a few more heroes (Sergey Brin getting back in the weeds to build agentic coding is a great example of this). Open source probably needs fewer heroes and more structural support, so that critical infrastructure does not rest on one burned out maintainer. Startups could use more institutional scaffolding, so founders can survive long enough to build something durable. I do not have a clean rule for which mode any given organization needs. The hard judgement call is knowing which one your organization needs more of, and when.
Google SRE handbook on No Heroes: https://sre.google/resources/practices-and-processes/no-heroes/


