When a process lives in one person's head (and why that's a risk)
If one person is the only reason a process runs, you don't have a process — you have a dependency. Here's how to spot key-person risk and a practical way to get the work out of someone's head without a giant documentation project.
September 15, 2026
Every business has at least one: the process that only really works because a specific person is there. They know which client is an exception, which number never reconciles cleanly, which step you can skip and which you absolutely can’t. It runs smoothly — right up until they take a vacation, have a bad week, or leave.
That’s not a functioning process. It’s a dependency wearing a process costume. And it’s one of the most common, least-noticed risks in a small business, precisely because everything looks fine while the person is still there.
How to tell you have this problem
Some honest warning signs:
- When someone asks “how does this work?”, the answer is “ask [name].”
- The person who runs it can’t fully take a week off without things piling up or breaking.
- Training a replacement feels impossible because so much of it is “you just kind of learn it.”
- When that person is out, questions wait for them instead of getting answered.
- The real instructions aren’t written anywhere — they’re in an inbox, a personal spreadsheet, or a head.
If two or more of those are true, the work is carried by a person, not a system. The task might be simple; the risk isn’t.
Why “just write an SOP” usually fails
The standard advice is to document it — write a step-by-step SOP and the risk goes away. It rarely works, and it’s worth understanding why, because the reason points to the real fix.
Most documentation captures the steps: do this, then this, then this. But the reason the process depends on one person is almost never the steps. It’s the judgment — the exceptions, the “if it looks like this, do that,” the small decisions made dozens of times without anyone noticing they’re decisions. A step list captures what the person does on a normal day and misses everything that makes them hard to replace.
The value locked in someone’s head is rarely the steps. It’s knowing what to do when the steps don’t fit.
So the document ends up technically complete and practically useless. The moment reality deviates from the happy path — which is constantly — the new person is stuck, and everyone concludes the process “can’t really be handed off.” It can. The documentation was just aimed at the wrong thing.
A better way to get it out of their head
If you want to de-risk a process, capture judgment, not just sequence. A practical approach:
1. Follow, don’t interview. Sit with the person while they do the real work, or have them narrate it as they go. Don’t ask “what are the steps?” — you’ll get the sanitized version. Watch what actually happens.
2. Hunt for the decisions. Every time they pause, choose, or say “it depends,” stop and capture it. What made you do that? How did you know? What would have changed your answer? These moments are the actual process.
3. Write down the exceptions, not just the rule. For each step, ask: “When does this not apply? What’s the weird case?” The exceptions are where key-person knowledge hides.
4. Define the triggers. What starts the process, what tells you it’s done, and what signals that something’s wrong? A process someone else can run needs clear entry and exit points, not just a middle.
5. Build a fallback before you need it. Decide, in advance, who covers this when the primary person is unavailable — and make sure they’ve actually done it once, not just read about it. A backup who has never run the process is not a backup.
The goal isn’t a document — it’s independence
You’ll know you’ve succeeded not when you have a nice binder, but when the honest answer to “what happens if this person is out next week?” is “it keeps running.” That’s the real test, and it’s a higher bar than documentation.
Getting there takes someone willing to do the un-fun work of extracting judgment, writing down the messy exceptions, and standing up real coverage. Sometimes that’s an internal effort. Sometimes the cleaner move is to hand the whole process to a team whose job is to absorb it — learn how it actually runs, document the judgment, and build the coverage in from the start — so it never depends on any single person again, including the one who used to carry it.
Either way, the principle holds: a process you can’t hand to anyone else isn’t finished. It’s a risk you haven’t dealt with yet.