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.
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.






Thank you for always taking the time Dinah and Code Like a Girl !!!!!
We are just so happy you want to share your beautiful stories with us.