Every organization has one. The person who saves the day. The one who stays until midnight to fix what broke, who knows the workaround for the thing nobody documented, who carries institutional knowledge in their head like a loaded weapon.
Everyone calls them indispensable. Nobody asks why they need to be.
If your operation requires a hero to function, something broke upstream. The hero isn't the solution. The hero is the symptom.
You've seen the roster. The woman who's the only one who understands the billing system. The guy who hand-configures the servers because the documentation is three years stale. The director who personally approves every decision because no framework exists for anyone else to make them.
These people are talented, hardworking, and genuinely dedicated. They're also single points of failure dressed up as employee-of-the-month plaques.
When they take a vacation, things slow down. When they get sick, things stop. When they leave — and they always leave, eventually — the organization discovers it wasn't running on a system. It was running on a person. And people, unlike systems, don't come with backup copies.
The problem with heroics is that they feel good. They're dramatic, visible, and emotionally satisfying. Somebody stays late, saves the account, pulls the project back from the brink. There's a story to tell. There's gratitude. There's adrenaline.
Systems don't feel like that. Systems feel like nothing. When a system works, nobody notices. The invoice goes out on time. The backup runs at midnight. The new employee finds the documentation and ramps up without calling anyone. Nothing catches fire, so nobody gets to be the firefighter.
This is why organizations consistently reward heroics and underinvest in systems. We celebrate the save, not the structure that would have prevented the need for one. We promote the firefighter, not the person who removed the fire hazards. And so the cycle continues: build something fragile, wait for it to break, celebrate whoever patches it, repeat.
A real system — not a flowchart nobody follows — works without its creator present. If the person who built it has to be there for it to function, it's not a system. It's a performance. A real system handles the 90% that's predictable so humans can focus on the 10% that requires judgment. And a real system degrades gracefully when things break, because things will break. It contains failure and routes around it and makes recovery obvious. A hero-dependent operation does none of this. It just catastrophically fails the moment the hero is unavailable.
The question worth asking, every time someone saves the day, is why they needed to. Why was the server configured by hand instead of by code? Why does one person hold the client relationship instead of a team? Why is there no documentation, no process, no backup plan?
The answer is almost always the same: building the system felt less urgent than fighting the fire. And it will keep feeling less urgent, because there will always be another fire, because there is no system.
The hardest part of this isn't technical. It's cultural.
Heroes get stories. Systems get ignored. We're wired to admire courage under fire, not the quiet discipline of prevention. Every all-hands meeting is structured around the dramatic save. The engineer who documented everything so thoroughly that nothing went wrong doesn't get a standing ovation. The manager whose team was so well-structured that the quarter was uneventful doesn't get the case study. The IT director whose systems ran so smoothly that the board forgot IT existed doesn't get the promotion.
But those are the people building things that last.
Stop rewarding the save. Start rewarding the structure that made saving unnecessary. Hire people who document. Promote people who build processes others can follow. Invest in the boring infrastructure — the runbooks, the automated tests, the decision frameworks, the cross-training — that makes individual heroism optional.
Not because heroes are bad. Because needing them is a design flaw.
There's an old engineering principle: if a bridge requires constant maintenance by its original builder to stay standing, it's not a bridge. It's a sculpture.
Build bridges.