The One Person Who Can't Leave
- 7 min read
It’s 3 AM on a Saturday and your best developer is in Slack. Not because of a deadline. Not because there’s a fire. Because they’re the only person who knows how the payment system actually works, and the API changed again.
You’ve built a product that depends on one person.
It happens gradually. Sarah was your first engineer. She shipped the MVP. Then she built the billing system. Then she owned the infrastructure. She knows all the tradeoffs you made at 2 AM on a Tuesday before the Series A demo. She remembers why you’re on Heroku instead of AWS. She’s the person who can fix things when they break because she understands the code deeply enough to reason about it instead of just patching it.
So you promote her. Give her equity. Tell her she’s critical to the vision. And she is - which is exactly the problem.
The Invisible Chain
A founder told me this last month: “My CTO just threatened to leave. Not to get a raise. He just wanted to know if we could operate without him.”
The answer was no. Not for long anyway.
Here’s what actually happened: the company had 12 developers, but the critical decisions all funneled through one person. When a new engineer needed to ship a feature, they’d have to ask him. When something in production broke, he’d wake up at night to fix it. When the board asked about technical risk, he’d tell them they were fine - while managing a personal backlog of undocumented architecture decisions he hadn’t told anyone about.
The company had built a system where their most valuable person was also their most critical single point of failure.
This isn’t a technical problem. It’s a systems problem. And founders create it by accident, usually because they reward the behavior that creates it.
Why This Happens
You hire smart people. Sarah is the smartest. She solves problems faster than anyone else. So more problems flow to her. She becomes more central. More central means more visibility. Visibility leads to promotion. Promotion leads to more responsibility. More responsibility means she knows more than anyone else, which means more problems flow to her.
It’s a reinforcing loop. And the company celebrates it as meritocracy.
The dangerous part is that it feels right for the first 18 months. Sarah is shipping more than the rest of the team combined. The product is moving fast. The board is happy. Everyone thinks this is what good looks like.
Then Sarah gets burned out. Or gets an offer from someone else. Or just decides she’s tired of being on call for every production issue. And suddenly you realize that the speed you were celebrating came with a massive cost: you’ve built a system that can only move at the speed of one person’s attention span.
Worse, your junior engineers never got the chance to solve hard problems. They became dependent on Sarah for answers, which meant they stayed junior. So when Sarah leaves, you’re not just losing a person - you’re losing five years of apprenticeship that never happened to anyone else.
The Cost You’re Not Seeing
Let’s be concrete about what this is costing you:
Knowledge is trapped. When Sarah is the only person who understands the payment integration, no one else can make decisions about payment infrastructure. That means every question becomes a blocker that depends on her. Multiply that by 50 questions a month across the team, and you’re burning her decision-making capacity on context-switching instead of strategy.
Your team never levels up. Junior engineers learn by solving progressively harder problems with guidance, not by watching Sarah solve them while they wait for answers. If Sarah is solving all the hard problems, your junior developers are stalled at mid-level forever. They leave. And you’re constantly replacing people.
You can’t hire as fast as you need. Every new engineer who joins needs to be mentored into the codebase. If only Sarah can do that mentoring, you’re bottlenecked. If you need three new engineers to hit your growth target but Sarah can only effectively onboard one, you’re in trouble.
Your optionality disappears. You can’t pivot quickly because the pivot would require Sarah’s attention, and she’s already at capacity. You can’t explore a new market because you’d need to build something new and Sarah’s got the current product. You can’t take time off because things fall apart. Strategic flexibility becomes impossible.
All of this is invisible in your metrics. Your velocity looks fine. Your ship calendar looks fine. But you’ve actually built a company where your biggest person is your biggest constraint.
How to Fix It
This isn’t about firing your best people or spreading work thin. It’s about building systems that distribute knowledge and decision-making.
First: make decisions visible. Every significant technical decision - why you chose this library, why you’re on this cloud provider, why the API endpoint is designed this way - should be documented. Not in some dusty architecture doc. In the code, in ADRs (Architecture Decision Records), in comments, in runbooks. If Sarah is the only person who knows, you haven’t actually solved the problem - you’ve just made it explicit.
Second: develop people deliberately. This means Sarah should be explicitly teaching someone else to own each of the critical systems she owns. Not “helping them learn eventually.” Right now. Set aside time. Make it her job. If she owns payment integration, pick a junior engineer and make them own it within three months, with Sarah as a guide. This is how you create resilience.
Third: set boundaries on availability. On-call is healthy. Always-on is not. If Sarah responds to every Slack message about technical questions at 11 PM, she will never have time to think about the bigger picture, and your team will never learn to solve problems without her. Make her on-call for actual production issues, but off-call for “please explain how this works” questions.
Fourth: hire for distribution, not concentration. When you’re hiring the next engineer, don’t hire for “domain expertise in payment systems.” Hire for “someone who can become the expert by learning from Sarah while also shipping features in other parts of the system.” Concentration is fast in the short term. Distribution is what lets you actually scale.
Fifth: measure for it. Track how many decisions require Sarah’s input. How many production issues can the team solve without her? How many junior engineers got promoted in the last year? These metrics will tell you if you’re building a company or building a Sarah-dependent system.
Here’s the hard part though: Sarah might not want to give up the things that make her feel essential. Getting promoted from “hero engineer” to “multiplier of other engineers” is a real identity shift. Some people make it. Some don’t. You can build all the systems in the world, but if Sarah’s status and self-worth are tied to being the person everyone depends on, she’ll subconsciously find reasons to stay in the critical path.
The Reframe
Here’s the truth: if your best developer can’t take a week off without everything falling apart, they’re not actually your best developer.
The best developer is the one who made herself unnecessary. The one who documented her decisions, taught other people, and built systems that worked without her constant attention.
Shawn’s fractional CTO engagements often start exactly here - with a company that realizes they’ve accidentally built a single point of failure in their technical leadership. The fix isn’t to replace the hero. It’s to help them graduate from doing all the work to building a team that can do the work without them.
That’s how you actually scale.
Got a team full of people who depend on one person to make decisions? Let’s talk about building systems that distribute leadership and knowledge. Schedule a call