Most small businesses have at least one process that works because of a specific person, not because of a well-designed system. A monthly report that only Sarah knows how to produce. A client onboarding sequence that lives in James’s head. A data process that involves steps no one else has ever been asked to explain out loud.
This isn’t a sign of bad management. It’s how processes develop in fast-moving small teams — someone figures something out, it works, and the business keeps moving. Documentation feels like overhead when everyone’s already too busy.
The problem surfaces when that person isn’t there.
What it actually looks like
Key-person dependency rarely announces itself as a risk until it becomes a crisis. The most common scenarios:
Holiday. Someone takes two weeks off and a monthly process either gets rushed before they leave, gets delayed until they’re back, or gets attempted by someone else who discovers mid-way that they don’t have all the context they thought they did.
Illness. Less predictable than holiday and harder to plan around. The process stalls. Work-arounds get improvised. Things that should have taken an hour take a day, because whoever is covering is figuring it out as they go.
Departure. The highest-stakes version. When the person who owns a process leaves — whether planned or not — the knowledge that lived in their head leaves with them. The handover notes, if they exist at all, rarely capture the judgement calls and edge cases that made the process actually work.
Scaling. Less dramatic but just as real: the business grows, the process needs to run more often or for more clients, and suddenly the single person who owns it becomes a bottleneck. There’s no crisis, just a steady accumulation of pressure and the growing sense that things are more fragile than they should be.
The hidden cost before anyone leaves
The risk doesn’t only materialise when someone is gone. It’s running all the time.
When a process depends on one person, that person carries it everywhere. They can’t take a proper holiday without either rushing through the work before they leave or staying half-available while they’re away. Their capacity becomes the process’s capacity — if the client base grows, they absorb it; if they’re stretched, things slow down; if they’re distracted, quality slips. The business can’t scale that function without scaling the person, and people aren’t infinitely scalable.
There’s also the problem of what happens when something goes wrong. If a report goes out with an error and only one person understands the process well enough to diagnose where it came from, you need that person’s full attention at exactly the moment the problem is most urgent. That’s a difficult position to be in — and one that’s entirely avoidable.
Why documentation alone doesn’t fix it
The instinctive response to this problem is documentation. Write it all down, create a runbook, make sure there’s a record of how things work.
Documentation is better than nothing. But it has a ceiling as a solution, for a few reasons.
First, the parts of a process that are hardest to document are usually the most important ones — the judgement calls, the exceptions, the “you’ll know it when you see it” moments that an experienced person navigates automatically. These don’t translate cleanly into a written procedure.
Second, documentation goes out of date. The process evolves, shortcuts get added, the underlying tools change slightly, and the documentation quietly stops matching reality. Nobody updates it in real time because nobody has time.
Third, documentation still requires a human to execute the process correctly every time. It reduces the risk of things going wrong, but it doesn’t remove the manual effort or the opportunity for error.
What actually makes a process robust
The more durable fix is to move the knowledge out of people’s heads and into the system itself — so that the process works correctly because of how it’s built, not because of who’s running it.
In practice, this means a few things:
The logic is explicit, not implicit. Instead of a process that relies on someone knowing to check column D against column G and flag anything over a certain threshold — a tool that does that check automatically and surfaces the result. The judgement call gets encoded once, correctly, and applied consistently every time.
The steps are enforced, not remembered. Instead of a checklist that someone has to follow and tick off — a workflow where the steps happen in sequence by design, and where skipping one isn’t possible without it being obvious.
The output is consistent regardless of who runs it. The right person and a new person get the same result, because the process doesn’t require familiarity to execute correctly.
None of this requires complexity. The kinds of processes that translate well into tools tend to be the ones that already follow consistent rules — they just need someone to build those rules in properly rather than leaving them in someone’s head.
A useful test
A simple way to assess any process in your business: could someone who’d never done it before produce the correct output on their first attempt, without asking for help?
If the answer is no — if it would require a briefing, a walkthrough, or access to knowledge that only exists in someone’s head — the process has a dependency problem.
The question isn’t whether you currently have the right person doing it. It’s whether the business would be fine if you didn’t.