How to Build Operations That Don’t Fall Apart When Key People Are Unavailable

Here’s what happens in most small to mid-market manufacturers and service businesses. The owner takes a week off. The production manager calls out sick. The one person who keeps all the balls in the air in the office goes on PTO. And suddenly, the whole operation grinds to a halt.

Prefer listening? Check out this week’s Solo Session where I go even deeper on the topic.

Not because the rest of the team is incompetent. Not because they don’t care. But because the entire system was built around one or two key people, and nobody ever bothered to design it to work any other way.

I was in a conversation a few weeks back with a mid-market manufacturer where leadership openly acknowledged that most of the business decisions and process execution lived in two people’s heads. When either of those two people happened to be out, it was nearly impossible to keep things moving. Customers didn’t get what they needed. The internal team didn’t know what to prioritize. Projects stalled. And the moment those two people came back, they spent the first three days digging out from everything that piled up while they were gone.

This isn’t an unusual story. It’s the default in most organizations I walk into.

The Content Gap Nobody’s Filling

If you search for anything related to key person dependency, you’ll find two types of content. Insurance companies trying to sell you a key man policy in case something catastrophic happens, and M&A advisors talking about how key person risk tanks your valuation when it’s time to sell.

Both of those are real concerns. But they’re focused on the macro, the worst-case scenario. What happens if someone dies. What happens when you try to exit.

What I see every single day is something far less dramatic but far more expensive over time. It’s the everyday version. What happens when your best project manager goes on vacation. What happens when you’re tied up in a meeting for two hours. What happens when the person who “just knows how things work” is out sick on a Thursday and nobody can answer a basic customer question.

That’s the version nobody’s talking about. And it’s costing businesses a lot more than they realize.

What Key Person Dependency Actually Costs

I built our Cost of Chaos calculator partly because of this exact scenario. Leaders consistently underestimate what key person bottlenecks cost them because it doesn’t show up as one line item on a P&L. It’s death by a thousand cuts.

Think about what happens when someone brings a decision to the one person who “always handles this,” and that person is in a meeting. It’s not just one person waiting. The person who brought the problem has a team behind them, maybe two people, maybe ten, who can’t take any action until that decision comes back. And if it’s a customer-facing issue, there’s an external delay, a perception of slow service, maybe a missed deadline.

For a $15 to $50 million manufacturer, this adds up to a mid to high five-figure number easily, and it regularly extends well into six figures when you account for the ripple effects across the entire organization. Nobody writes a check for “key person dependency.” But the money is being spent every single day, distributed across wasted labor, delayed projects, frustrated customers, and opportunities that quietly slip away.

A Wedding, a Software Vendor, and a Box of Labels

Let me give you three quick examples of how this plays out.

1. The wedding that broke the system

I was working with a manufacturer that had two project managers coordinating large-scale client projects, multiple production pieces coming together over long timelines that needed to be delivered or installed. One of the project managers got married and went on their honeymoon. What happened? Those projects completely stalled. The person covering had no idea what the handoffs were, what was still in queue, what needed answers, or how to communicate with external clients. There was no visibility into the project status beyond what lived in the absent PM’s head. End result: upset customers, internal chaos, and a lot of “they should have done this” finger-pointing that solved nothing.

2. The vendor that almost lost a six-figure client

A client of mine was going through a software upgrade. The vendor was sunsetting their old version, so the upgrade was mandatory. My client had been given a specific pathway for deploying custom code, a process they’d followed for years. But internally at the vendor, there had been personnel changes, process changes, and technology changes that nobody communicated effectively. When my client submitted their customization request through the same channel they’d always used, the vendor pushed back and said they weren’t allowed to do it. After weeks of emails, ticket escalations, phone calls, and dead ends, they finally got a meeting with someone who actually understood the process. The fix? “Send it to this group instead of that group.” That was it. But the damage was done. Thousands of dollars burned in wasted meetings and internal chaos on both sides. And my client seriously considered dropping the software entirely, which would have been a six-figure-plus loss for that vendor. All because the right hand didn’t know what the left hand was doing after an internal change.

3. Dave didn’t read the job ticket

I was working through a root cause analysis with a client yesterday. The conversation quickly zeroed in on a recurring issue where the default conclusion was always “operator error.” Dave forgot to put the labels on the box. Simple, right? Dave’s the problem. Except when we actually investigated, we found that while the information was technically accessible, there was no clear definition of who owned the verification step. Dave didn’t know he was supposed to follow those specific instructions. No clarity. And if there’s no clarity, it’s impossible to be consistent. If you’re not consistent, you can’t hold anyone accountable. But everyone wanted to blame Dave because he “never reads the job ticket.”

Three different scenarios. Three different industries. Same root cause: the system wasn’t designed to function without specific people, and when those people were unavailable, whether for a wedding, a personnel change, or just a normal day where expectations weren’t clear, everything fell apart.

Why Technology Won’t Fix This

Most organizations, when they recognize a problem like this, reach for technology first. They see the symptom, find a tool that promises to solve it, buy it, implement it, and then watch as nobody uses it. Or people use it, but it doesn’t actually solve the root cause. Now they’ve added a compliance burden on top of the original problem.

This is why I come back to the same sequence every time: Planning, People, Process, Technology. Always in that order.

Planning means defining what we’re actually trying to solve. People means involving the ones closest to the work, soliciting the “how” from them, not dictating it. Process means getting clarity on what we do today, identifying gaps, and designing something better. Technology, if needed, enables the process. It doesn’t replace it.

When you start at the technology end, you amplify whatever you’re sitting on top of. If the foundation is broken, technology accelerates the dysfunction.

The Crawl Version of Getting Tribal Knowledge Out of Someone’s Head

Here’s where most people get stuck. They hear “document your processes” and picture a painful, months-long project. Binders full of SOPs that nobody reads. A consultant interviewing every department for six weeks. It sounds miserable, and it sounds expensive.

That’s because they’re thinking about it in the macro.

The crawl version lives in the micro. You don’t need to document everything. You need to document the decision you just made. When you recognize that you’re the person someone came to for an answer, write down what happened. Track it. If the same type of decision comes to you once a day or once every couple of days, that’s a signal: this needs a system.

Then you document how you came to that decision. People will say “well, it depends.” Great. If this, then that. You can build a decision tree the same way it runs in your own head. The natural conclusion you reach in two seconds feels like intuition, but it’s not. It’s a series of decision trees that were built over years of repetition and experience. All you need to do is make the invisible visible.

I see this play out with leaders all the time. They’ll say “so-and-so isn’t performing to expectations.” So I ask: have you told them what the expectations are? “Well, it’s on the job description.” So we pull up the job description, and I ask the leader to define success for that role. They rattle off five or six specific things. None of them are on the document. The gap between what’s in the leader’s head and what’s been communicated is enormous, and it’s so simple to close. But because we’re always thinking in the macro, we make it more complex than it needs to be.

Start in the micro. One decision at a time.

Empowerment Is Not a Free-for-All

When I encourage leaders to push decisions out of their own hands, I inevitably hear the same pushback: “We can’t just let everybody make all these decisions.”

Agreed. That’s not what I’m suggesting.

What I’m suggesting is boundaries and escalation. I like the Zappos example here because it’s easy for everyone to understand. Tony Hsieh built a culture where every frontline customer service person had a budget they could use at their discretion to surprise and delight customers. Someone’s loved one passes away, the rep sends flowers. A customer mentions a celebration, they send cookies. No manager approval needed. Within bounds, the person closest to the situation made the call.

The same principle applies to operations. Not every resolution needs to be a leadership decision. There should be some level of ownership at the level closest to the work, with clear boundaries and an escalation path for anything outside those bounds.

What I push back on is the leader who says “I want to know about everything.” That’s a trust problem, not an operational one. And if you don’t trust the team you have, that’s a much bigger issue that needs to be addressed before any system you build will succeed.

Run Fire Drills Before You Need Them

Here’s the part most people skip: testing.

You’ve documented some decision trees. You’ve pushed some responsibilities out to the team. You’ve built escalation paths. Now what?

Don’t wait for the real absence to find out if it works. Run a fire drill.

Start with a leadership meeting or any regular cadence where the key person is pulled away for an hour. Let the team know: I’m in this meeting, I’m incommunicado. Pretend I’m out having surgery and I can’t answer my phone. Then let the system run.

That stress test happens in a tightly controlled environment where the key person is still in the building, still accessible if something truly critical comes up. There’s very little actual risk. But you learn everything you need to learn. What worked? What didn’t? Where did someone get stuck? Where did the escalation path break down?

Then you expand. Go from one hour to two. Two to four. Four to a full day. That doesn’t mean the person physically leaves. It means they’re treated as unavailable so you can stress test the system before the real absence happens. By the time someone actually does go out for surgery, or a vacation, or gives their two weeks’ notice, the team has run through the drill enough times that they know exactly what to do.

It’s Simple. It’s Not Easy.

None of what I’ve described here is revolutionary. You can find this information in a dozen places. The frameworks are straightforward. The concepts are intuitive.

What’s hard is the prioritization, the implementation, and the long-term sustainability. Those three things are what make simple not easy.

That’s why I always come back to crawl, walk, run. It took a long time to build the level of key person dependency that exists in your organization today. It’s going to take some time to unwind it. But you don’t have to boil the ocean. Start with your biggest point of failure. If that’s you, start with yourself. Track how often you’re the gatekeeper. Document the first decision tree. Run the first fire drill. See what breaks. Fix it. Expand.

The goal isn’t to make any one person dispensable. It’s to build systems that don’t punish the entire organization when someone is simply unavailable. Because people will always be unavailable. The question is whether your operation was designed to handle it.

That’s it for today.

See you all again next week!

Dave