What Happens When Your Key Technical Person Walks Out the Door

A few weeks ago, I was on a call with a manufacturer’s operations lead. He’s 67 years old. He runs order fulfillment across three product lines using a combination of an ERP system, four Excel spreadsheets, and a mental model he’s built over two decades. When I asked if anyone else understood the process, he laughed.

“If I got hit by a bus,” he said, “they’d be screwed.”

He wasn’t bragging. He was worried. And he’s not alone.

I’ve had some version of this conversation with a dozen founders and operators in the last six months. The specifics change: sometimes it’s the lead developer who built the entire backend. Sometimes it’s the ops manager who knows which supplier to call when a shipment goes sideways. Sometimes it’s the CTO who left six months ago and nobody’s touched the deployment pipeline since.

The problem is always the same. Critical business knowledge lives in one person’s head. And nobody notices until that person leaves, retires, or gets sick.

The Bus Factor Is a Business Problem, Not a Technical One

Engineers call this the “bus factor,” the number of people who could get hit by a bus before a project stalls. It sounds morbid. It’s also one of the most accurate risk metrics I know.

Most startups have a bus factor of one. One person who understands the infrastructure. One person who knows why the billing logic works the way it does. One person who can debug the integration with your biggest customer’s API.

Founders tend to treat this as a hiring problem. “We just need to hire a backup.” But duplication isn’t the answer. You can’t clone two decades of context into a new hire’s brain during their first sprint.

The real fix is systemic. You need to move knowledge out of people’s heads and into your systems, your documentation, your processes, and increasingly, your AI tooling.

Here’s what I mean in practice.

Where Institutional Knowledge Goes to Hide

In my fractional CTO work, I see the same patterns over and over. Knowledge doesn’t disappear all at once. It hides in layers.

The spreadsheet layer. Almost every growing company has critical business logic living in Excel. Pricing calculations, inventory rules, customer tier classifications, order routing decisions. One manufacturer I worked with had their entire quoting process in a spreadsheet that took 15 hours per quote. The person who built it was the only one who understood the formulas. When we mapped it out and automated it, we cut that to 15 minutes. A 60x improvement. But the real win wasn’t speed. It was that the knowledge was now in a system anyone could maintain.

The tribal knowledge layer. This is the stuff that never got written down because it seemed too obvious at the time. Which deploy commands need to run in which order. Why that one microservice has a 30-second timeout instead of 10. What the actual SLA is with your payment processor versus what the contract says. This layer is the most dangerous because nobody realizes it exists until the person who holds it is gone.

The relationship layer. Your ops lead knows that when a shipment from Vendor X is late, you call Maria on her cell, not the main office number. Your senior developer knows that the client’s API documentation is wrong about the auth flow and you actually need to pass the token in the header, not the body. These small, specific pieces of knowledge are worth more than they look. Losing them means relearning through expensive trial and error.

How to Start De-risking Before It’s Too Late

You don’t need a six-month documentation project. That’s the enterprise approach, and it usually produces binders nobody reads. Here’s what actually works at startup scale.

Start with the “what if” audit. Pick your three most critical people. For each one, ask: if they gave two weeks’ notice tomorrow, what would break? Be specific. Not “things would be harder.” What specific system, process, or relationship would stop working? Write those down. That’s your risk map.

Record decisions, not just outcomes. Most companies document what they built but not why they built it that way. The “why” is where the real knowledge lives. When your team makes a technical decision, capture it in a lightweight Architecture Decision Record (ADR): what you decided, what you considered, and why you chose this path. It takes five minutes and saves months of confusion later.

Codify processes into systems. Every time someone says “just ask Dave, he knows how that works,” that’s a signal. The goal isn’t to eliminate Dave’s expertise. It’s to make sure the business doesn’t collapse when Dave goes on vacation. This could mean writing a runbook, building an internal tool, or using AI to help capture and organize the workflow.

This is where the current wave of AI tools gets genuinely interesting. Not the headline stuff about generating code faster, but the quieter, more practical use case: turning unstructured knowledge into structured systems. I’ve seen teams use AI to analyze existing spreadsheets and extract the business rules embedded in formulas. To generate documentation from codebases that haven’t been documented in years. To build chatbots that sit on top of internal wikis and actually make that knowledge accessible. These aren’t moonshot projects. They’re practical, and they compound over time.

Pair, don’t just document. Documentation is necessary but not sufficient. The fastest way to spread knowledge is to have people work together. Pair programming, shared on-call rotations, cross-training sessions where your senior person walks someone else through their workflow. This has a double benefit: it spreads knowledge and it exposes the gaps where knowledge only exists in one person’s head.

The Cost of Doing Nothing

I’ll be blunt. Most founders don’t address key person risk until after the key person leaves. By then, you’re in triage mode. You’re paying contractors premium rates to reverse-engineer systems your own team built. You’re losing deals because nobody knows how to run the quoting process. You’re spending three months rebuilding institutional context that took years to accumulate.

One company I worked with lost their lead operations person and it cost them an estimated $972,000 in the first year. Not in salary replacement. In wasted time across the entire team as 90 employees each lost about 1.5 hours per day to processes that nobody fully understood anymore.

That number sounds dramatic. It’s not. It’s math. And it’s the kind of math that doesn’t show up on a P&L until it’s too late.

The good news is that fixing this isn’t expensive. It just requires intention. A fractional CTO or technical leader can often map your key person risks in a single week, prioritize the highest-impact areas, and build a plan to systematically de-risk them. It’s one of the highest-leverage things you can do for your company’s resilience.

It’s Not About Replacing People

I want to be clear about something. De-risking key person dependencies isn’t about making people replaceable. Your best people are valuable precisely because of what they know and how they think. The goal is to make sure your business can survive and adapt when life happens, because it always does.

The best operators I know understand this instinctively. That 67-year-old operations lead? He wasn’t offended when we started mapping his processes. He was relieved. He’d been carrying the weight of being irreplaceable for years. Building systems around his knowledge didn’t diminish him. It freed him to focus on the work that actually needed his judgment, not the routine execution that just happened to live in his head.

If you’re reading this and thinking about your own team, start with that simple question: if your most critical person gave notice tomorrow, what breaks?

If the answer makes you uncomfortable, that’s worth a conversation. Reach out and let’s talk about what de-risking looks like for your situation. It’s usually simpler than you’d expect.