The busy heroes
How organizations mistake structural fragility for company culture
The room had been decorated, which is how you knew it was serious. In the years the company had occupied this building, the cafeteria had been decorated exactly three times: once for an acquisition, once for a product launch, and now for Steven.
Steven was turning thirty. Not in age - in tenure. Thirty years in the same company, most of them spent keeping its software systems alive. The evening was genuine: The founder, who rarely spoke at internal events anymore, abandoned his notes three minutes in and told the room about the night Steven had rewritten a payment interface in 2008 because a vendor’s update had quietly broken the invoicing chain and Monday was month-end close. The room laughed. Someone who had been there shouted something funny that Steven had said that night. Steven shook his head with a grin.
More stories followed. The ERP migration that nearly bricked the production environment, where Steven wrote a live patch while on the phone with the vendor, manually keeping order processing alive until morning. The CRM integration he built over a weekend because two newly procured systems had no way of talking to each other and the sales team needed pipeline data on Monday. The security incident where IT’s remediation plan would have taken the customer portal down for three days during peak season, and Steven found a way to patch it live in four hours. The room was amused and in awe in turns.
And then came the gift, a book. Not a purchased one. His team had spent months on it in secret: handwritten notes, emails, photos and stories from colleagues past and present. Thirty years’ worth of clippings. A retired manager had written a full page about almost not hiring Steven. A former intern, now a CTO elsewhere, contributed a note saying that watching him work a production incident taught her more than her degree. It was bound properly - cloth cover, his name embossed. When Steven opened it, the room went quiet. He read the first page, closed the book, and needed a moment.
Steven’s speech was heartfelt – and mostly about his wife. Not just about her being fine with him also being married to the company, not just about enduring his absences and schedules. But also about being genuinely into what he does, and that a few of the problems in the cool book were actually solved by her. The room applauded, some remembered how he struggled before he met her. She knew all eyes were on her for a moment, and she was comfortable with that. She knew who she married. She is his third wife.
After the formal part, the inner circle stayed. I wasn’t part of that. But Steven was told, in so many words, that he was family. That the company would not be what it is without him. This was sincere and, by any measure, true.
Every word spoken that evening was, in the room’s hearing, a celebration.
To my cynical ears, after over twenty years of measuring how work actually works, every story was also a record of Steven compensating for bad systems.
The 2008 invoicing rewrite was a vendor migration with no rollback path. The ERP patch was an implementation plan with no contingency. The CRM bridge was two systems procured without integration requirements. Each page of that book was a love letter, but each love letter also a maintenance log. This was thirty years of architecture gaps narrated as devotion.
A significant fraction of this company’s operations depended on the continued presence, health, and goodwill of one person who was never supposed to be a single point of failure – and has never been paid to be one.
This is hero dependency: the condition in which an organization’s capacity to function has quietly migrated into specific individuals, because the systems that were supposed to carry the load were never fully built. The hero is not the cause of the problem, but evidence of it.
Finding a true hero is inspiring. But it is also the exact location of a gap in the architecture.
To see how a hero gets made, you have to look at the room where the work was first designed, because that is where the gap gets created. I have described that room before and called what comes out of it truce documentation: a map of the work everyone agrees on not because it is true, but because it is the version nobody has to argue about. I have also described the other way the same gap opens: through altitude, where a process gets mapped at thirty thousand feet of abstraction and nobody disagrees because there is nothing specific enough to disagree about.
Either way, you end up with a fuzzy process map that shows that, yes, orders are received, products are shipped, and payments are received, but not how exactly. The map has holes, and no hole stays empty – because someone talented and exceptional scrambles to fill it.
Each hole is a management failure. Not in the sense that someone was negligent or unkind; Steven’s managers threw him a beautiful party and meant every word. It is a management failure in the structural sense: the decision to invest more in architecture rather than rely on a person was never made. Not once, over thirty years.
Steven was never in a position to make that decision. He was in a position to either let things fail or fix them himself, and he is the kind of person who keeps things running, which is a big part of why no one ever felt the urgency to build what would have made his heroism unnecessary. His competence and eagerness bought the organization out of its own architectural debt, every day, for three decades. And the better he got, the longer it could go unbuilt.
In the presence of heroes, organizations mistake their efforts for their own competence. You night think that this is merely a subjective observation, but it is actually measurable.
In one engagement I will draw on here, we mapped a large beverage company’s internal administrative processes all the way to the individual task level. When we counted how many of those tasks were carried by a system rather than a person, the number was 22 percent. Three quarters of this organization’s admin work was people, manually checking, remembering, following up. Not because the work required human judgment in each case, but because no one had ever built internal infrastructure that would do it better. The global average for comparable teams is roughly fifty-fifty. The organizations that run well are closer to seventy-thirty. This division was diametrically opposite of this.
That is what produces a hero. Not exceptional character alone, but having to do work in an architecture so thin that it demands exceptional character simply to function at a normal level.
The Copenhagen Psychosocial Questionnaire, or COPSOQ, can help quantify the cost of this by measuring cognitive load against clinical reference points. This is not a staff-satisfaction survey that asks people whether they feel stressed, and people answer the way people answer surveys. It is not a read on morale, it is closer to a blood screening – an objective measure of capacity.
Nearly everyone in the beverage operation above was operating at levels of overwhelm that are clinically considered unsustainable. About a quarter were at levels the literature associates with the onset of burnout. But the teams were not unhappy, not disengaged, not faltering. They were burning out comfortably: while being praised for it, while getting raises, just like Steven. And they were burning out not while working the market, engaging with customers, or innovating, but while doing menial internal administrative work that everyone else was delegating to software systems.
Before we mapped and measured, the organization did not know any of this. Not because someone hid it: the late nights were visible, the cancelled holidays were visible, and the appreciation of the heroes (a big part of this firm’s culture) was extremely visible. Every piece of evidence was in plain sight.
The issue was that the lack of supporting structures was seen as destiny, as the very nature of their work, as “that’s just how we do things here.” But when they saw the measurements and risks, especially the burnout risk numbers, the conversation changed, and fast. Not because the numbers were shocking (they were), but because numbers move heroism from identity into engineering, to a task that can be tackled.
When organizations describe their reliance on extraordinary people, they don’t reach for the language of risk. They reach for the language of praise.
“If it weren’t for Steven, half of this wouldn’t run” is not filed as poor process design; it is filed under culture. And the moment a structural fact gets filed under culture, it stops being visible as a structural fact, because culture is “who we are”, and risk is “what could make things break”, and those live in different drawers in the organizational mind.
Calling hero dependency “culture” gains the organization, gains management permission to do nothing. If heroism is culture it is identity, and you do not fix identity – you celebrate it. The hero story works so well because it is an emotional, relatable story about people, and the process story is a nerdy explanation of systems. A speech about Steven makes a room cry, a presentation about a well-designed escalation matrix makes it zone out. This emotional asymmetry between the two stories favors the one that preserves the problem.
You can run a risk assessment on a server with no backup, but you cannot run it on “we have amazing people who go above and beyond.” So the hero dependency does not appear on the risk assessment, not because anyone is negligent – risk assessors are conscientious people – but because the language available for describing the hero, the warm, grateful, anniversary-dinner language, is structurally incapable of rendering them as exposure. The risk is encoded in a vocabulary that reads as a virtue.
That is what makes it invisible: not secrecy, but translation.
And this is why a typical organization cannot really hear this. You can say, plainly, in a meeting, “you are dangerously dependent on Steven,” and the room will nod, and genuinely agree, and do nothing, because the sentence lands as another version of the compliment. “Yes, he really is invaluable.” You can say “you should invest in turning Steven’s capabilities into systems,” and at least one person will hear an attempt to replace him instead of to relieve him. And even if there is agreement that operational gaps should be filled with structures rather than someone’s weekends, the prevailing instinct will be to defer this, because things are stable for now, Steven is still there holding the fort, and they will get to it once all other priorities are resolved.
Heroism is not just a powerful aesthetic; it is also a powerful anesthetic.
Making hero dependency addressable means, in practice, dissolving the heroism. Not by attacking the hero, but by descending to the level of the work:
Map the actual tasks.
Document the actual workarounds.
Measure the actual load.
The instant you do this, the heroism resolves into its components, and they are not heroic at all - they are quite ordinary, sometimes even sad, or boring. A process gap here, an undocumented decision rule there, or a system limitation that someone has been routing around for years, with notebooks and keyboard shortcuts and modifier keys worn smooth.
Steven does not vanish in this view. Instead, he finally comes into true focus, for the very first time. He becomes visible not as a marvel but as what he structurally is: a person doing, every day, the work that an unfinished architecture left undone, and being celebrated for the size of the gap he agreed to stand in. A victim of a management failure so thoroughly dressed up as culture that even he doesn’t see it that way.
The state on the far side of this, once there is infrastructure that frees Steve up to do more valuable things, isn’t cool productivity, it is sovereignty: the condition of an organization that understands its own complexity thoroughly enough to discuss its capabilities and gaps without emotional terms, without heroes and villains.
Such an organization doesn’t lose its heroes, but sends them to new frontiers instead of the engine room, so that they can do their magic on work that not just needs it, but also deserves it.