The Hero Complex Is Killing Your Business!

When your vacation requires a backup plan for the entire company, you’ve got a problem. Here’s why we need to kill the ‘hero ops’ culture once and for all.

image credit pixabay.com

In 2014, I tried to take a proper vacation.

Not the one where you sneak a laptop into your carry-on and pretend the hotel Wi-Fi will magically “just work.” I mean a real, unplugged, email-off, Slack-mute vacation.

One of those mythical out-of-office experiences people post pictures of but somehow never really seem to take.

Two days in, I got a text: “Where’s the vendor contract?”
Then: “Can you approve this wire real quick?”
Then: silence, followed by a frantic call from a junior team member saying finance was stuck and customer ops was about to implode.

Cool, Cool. So much for the beach.

I wasn’t even the COO. Just the person who had stitched all the broken parts together over time, like Frankenstein’s monster, but with Google Sheets and duct tape. Somehow, I’d become a Single Point of Failure.

And I wasn’t alone.

The Glorification of “Essential Personnel”

In tech, we treat Single Points of Failure (SPOFs) like what they are: liabilities. You wouldn’t architect a cloud infrastructure where one server going down takes the whole system with it.

That’s rookie stuff. Red flags everywhere.

But in business ops? We do the exact opposite.

We celebrate it.

We reward the people who “know everything.” We write performance reviews that say “indispensable,” when what we really mean is “irreplaceable and unsustainably overloaded.” We convince ourselves that the linchpin employee is a blessing, not a ticking time bomb.

You want a real litmus test for operational maturity?

Count how many people in your org can disappear for 10 days, completely unreachable, and have things run just fine.

If the number is less than three, you don’t have a business. You have a hostage situation.

A Bit of History

In the early 20th century, factories used to rely on a single “line operator” who controlled the whole system. If they got sick or took a day off, production halted.

It wasn’t until lean manufacturing principles came along that businesses realized maybe it was better to distribute knowledge and standardize systems.

Go back to the 1970s and you’ll find Paul Baran and Donald Davies developing packet switching specifically to create “survivable communications networks” without single points of failure. Their work became the foundation of the internet itself.

Yet somehow, decades later, we’re building businesses that would make a 1970s computer engineer nervous. We’ve got distribution, redundancy, and fault tolerance in our code, but dependency, bottlenecks, and fragility in our org charts.

We architect systems that can survive nuclear war, but build companies that can’t survive Bob taking a two-week cruise to Alaska.

It’s a weird kind of regression.

The Data

Nearly half of all organizations (48%) have a formal business process management program in place, meaning more than half do not. Meanwhile, among small-to-midsize businesses, 45% still rely on paper records for critical data like customers, vendors, and contacts. Shockingly, 11% have no system at all for managing documents.

But here’s the one stat that should terrify you: most companies don’t keep their operations manuals or process documentation up to date. A 2024 Foxit study found that 97% of businesses have minimal or no document management processes in place.

In other words, most companies are just winging it, hoping the person who “knows how stuff works” never gets the flu, takes parental leave, or gets hit by a bus.

And I gotta tell you, no serious buyer wants to acquire a business that depends on whether one person shows up to work. 1 in 5 U.S. businesses fail in their first year, and a huge chunk of those failures come down to key person dependency.

Think about it from an investor’s perspective. Would you bet money on a company where the CEO can’t take a vacation? Where the lead developer is the only one who understands the codebase? Where the sales director is the only one with client relationships?

Of course not, that’s a liability.

The Three Flavors of Business Stupidity

After watching hundreds of companies make this same mistake, I’ve noticed it comes in three distinct flavors:

• The Knowledge Hoarder: This is the person who’s been around forever and somehow accumulated all the institutional knowledge. They know which client hates phone calls, where the backup files are stored, and why that one process works the way it does. When they’re gone, you realize your company has been running on tribal knowledge instead of systems.

• The Decision Bottleneck: Everything flows through them. They approve, they strategize, they put out fires. Sure, they’re good at it, but they’ve accidentally made themselves mission-critical for day-to-day operations. They can’t delegate because “nobody does it as well as I do.”

• The Relationship Owner: They’ve got the connections. The big clients only talk to them. The key vendors won’t work with anyone else. It feels like an asset until you realize you’ve built your entire revenue stream on one person’s rolodex.

The problem isn’t that these people are bad at their jobs. The problem is that they’re too good at them.

---

The New Way to Screw This Up

We’ve got these shiny new tools now (chatbots, workflow automators, the whole nine yards) and somehow we’ve managed to make the SPOF problem worse.

Last month, I was consulting with this company, and their entire customer onboarding was running through some fancy-dancy automated system. It worked great until the guy who built it went on vacation, and the thing started sending welcome emails in what I can only describe as gibberish.

He’d been tweaking prompts and fixing edge cases for six months, but never wrote any of it down. We went from “Only Danny knows how to onboard customers” to “Only Danny knows how to keep the robot working.”

Progress?

The really dumb part is that these tools could fix the knowledge hoarding problem.
But no. We build black boxes that only one person understands, then act surprised when that person becomes indispensable again.

It’s like we took the single point of failure and wrapped it in code.

The fix isn’t rocket science. Document what the system does, not just how to use it. Make sure three people can troubleshoot when it goes sideways. And for the love of all that’s holy, don’t let one person be the sole keeper of all the weird little rules that make your business actually work.

Otherwise, you’ve just built a more expensive way to ruin your vacation.

Why We Keep Doing It

Three reasons, always the same:

• Ego: Being “the only one who can fix it” feels good. It gives you leverage. Job security. Makes you feel needed.

• Pace: Startups move fast. Documenting things feels like a luxury. “We’ll write it down later,” they say. (They never do.)

• Culture: We’ve built this myth of the startup hero. The person who knows all the logins, fixes bugs on weekends, and bleeds company colors. The problem is, when they bleed out, there’s no transfusion plan.

Think Like a Lazy Genius

You don’t need more meetings. Or a Notion doc no one reads.

You need to build a culture where your goal is not to be needed. Where bragging rights go to the person who can go fully dark for two weeks and come back to nothing on fire.

How?

• Enforce documentation like it’s code. Make it part of your deploy process. If it ain’t documented, it doesn’t exist.

• Rotate responsibilities. Let people take turns running standups or handling vendors. You’ll find gaps faster than any audit.

• Red team your ops. Pretend your lead ops person quits tomorrow. Who knows what? Who can step in? If the answer is “no one,” fix it before it’s not a drill.

Also: Stop praising martyrdom. Start celebrating systems.

A Final Thought from the Peanut Gallery

There’s a quote I keep coming back to, attributed to either Tim Ferriss or someone’s salty aunt:
“If your business depends on you, you don’t have a business. You have a job.”

In ops, we’ve taken that one step further. We don’t just have a job, we’ve built a personality around being the fixer, the go-to, the one who knows how to jiggle the handle just right.

But systems are scalable. People aren’t.

When someone says, “Only Neela knows how to do that,” don’t be flattered. Be worried.

And maybe cancel your vacation.

Or better yet, don’t.

Go anyway. Let it all break. Then come back and build it right.

---

Author Spotlight

We’re so grateful to Neela 🌶️ for allowing us to share her story here on Code Like A Girl. If you enjoyed this piece, we encourage you to visit her publication and subscribe to support her work!

---

Join Code Like a Girl on Substack

We publish 3 times a week, bringing you:

• Technical deep-dives and tutorials from women and non-binary technologists

• Personal stories of resilience, bias, breakthroughs, and growth in tech

• Actionable insights on leadership, equity, and the future of work

Since 2016, Code Like a Girl has amplified over 1,000 writers and built a thriving global community of readers. What makes this space different is that you’re not just reading stories, you’re joining a community of women in tech who are navigating the same challenges, asking the same questions, and celebrating the same wins.

Subscribe for free to read our stories, or support the mission for $5/month or $50/year to help us keep amplifying the voices of women and non-binary folks in tech.