The manager who is the process

Ask a business to describe how a particular process works and sometimes the honest answer is "ask Sarah." Not because Sarah wrote the process — because Sarah is the process. The steps live in her head, adjusted on the fly for whatever situation comes up, and nobody else could run it the same way even with the best intentions.

How this happens without anyone deciding it should

Nobody sets out to build a process this fragile. It accumulates gradually: Sarah handled this task well early on, kept handling it as the business grew, made hundreds of small judgement calls along the way that were never written down because there was never a natural moment to write them down, and eventually the process and Sarah became functionally the same thing.

This is common precisely because it's efficient in the short term. Sarah is fast, she's good at it, and asking her to slow down and document every judgement call would cost time now for a benefit that only materialises if she ever leaves. Most days, that trade looks like a bad use of her time — right up until the day it isn't.

Why this is a bigger risk than it feels like day to day

The risk is invisible under normal operating conditions, which is exactly what makes it dangerous. The business runs fine, the numbers look fine, and there's no signal anywhere in the system that a single point of failure exists — because the system only records that the process happened, not that it happened to depend entirely on one specific person's memory to happen correctly.

It only becomes visible at the worst possible moment: when Sarah is unexpectedly unavailable, whether through resignation, illness, or simply being on leave when something unusual comes up that only she knows how to handle.

How to spot this before it becomes urgent

A useful test: for any given process, ask what would happen if the person running it took a sudden two-week leave with no warning. If the honest answer involves things slowing to a crawl, mistakes appearing that wouldn't normally happen, or someone saying "we'll just wait until they're back," that process is a person, not a process — see what leaves with an employee that the ERP never had.

The test is deliberately uncomfortable, because most businesses have at least one process that fails it, and identifying which ones is the entire value of asking.

Why "just write an SOP" undersells the problem

An SOP captures the steps of the standard case. What actually makes Sarah valuable is her handling of everything that isn't the standard case — the judgement calls, the exceptions, the situations where the SOP doesn't quite apply and she knows what to do anyway. Writing down the standard process is necessary and nowhere near sufficient, because the standard process was never the hard part.

Reducing the dependency without disrupting the person

Shadow the process, don't just document it. Have someone else sit with Sarah through a normal week and specifically watch for the moments she deviates from the obvious steps — those deviations are where the real knowledge lives, not in the steps themselves.

Ask "what would you tell your replacement" as a direct, low-stakes question, separate from any conversation about her actually leaving. Framed as a hypothetical rather than a threat, it often surfaces genuinely useful detail that a formal documentation request wouldn't.

Build redundancy gradually, on real cases, not through a one-off training session. Have a second person handle the process under Sarah's supervision for a period, learning through the actual exceptions as they arise rather than through a simulated version of them.

The point isn't to make anyone replaceable out of distrust

This isn't about undervaluing the person who built the process. It's the opposite — recognising that the judgement they've built is genuinely valuable enough that the business shouldn't be one absence away from losing access to it. Protecting that knowledge protects the business and, often, makes the person's actual expertise more visible and more valued, not less.

Common questions

How do you know if a process depends too heavily on one person?

Ask what would happen if that person took a sudden, unplanned two-week leave. If the process would stall, mistakes would appear, or the business would simply wait for them to return, the process is functionally a dependency on that individual rather than a documented, repeatable system.

Why isn't writing an SOP enough to fix this?

Because an SOP captures the standard steps, and what usually makes the person valuable is their handling of exceptions and judgement calls that fall outside the standard steps. The SOP documents the easy part; the hard part was never written down because it doesn't fit neatly into a step-by-step format.

What's a better approach than asking someone to document everything they know?

Shadowing the process in real time and specifically watching for moments where the person deviates from the obvious steps, since those deviations reveal the actual judgement being applied. Building redundancy gradually, by having a second person handle real cases under supervision, transfers more than a one-off documentation exercise.

Does identifying this problem imply distrust of the employee?

No — it's a recognition that their accumulated judgement is valuable enough that the business shouldn't depend entirely on their continuous availability to access it. Done well, this kind of review often makes an experienced employee's expertise more visible and more valued, not less.

Related: what leaves with an employee that the erp never had · key-person risk in finance · rehiring the same knowledge twice