Key-person risk is the risk that work stops, slows or goes wrong when one particular person is unavailable. It comes from knowledge, access or relationships concentrated in a single head, and it is invisible right up until the day it is expensive.
Every team has some. The problem is rarely that it exists — it is that nobody has written down where.
What does key-person risk actually look like?
Three kinds, and only one of them is usually on anybody’s list.
Access risk is the easiest to see and the easiest to fix. One administrator on a system, one signatory, one person with the credentials. IT and finance already look for this.
Relationship risk is the account that renews because a particular person makes the call each year, or the supplier who answers because they know one name. It transfers slowly and only by introduction.
Knowledge risk is the large one. Someone knows the sequence, the thresholds, the traps and the reasons — tribal knowledge that no document holds. It cannot be granted like access or introduced like a relationship. It has to be asked for, and that takes time nobody schedules until a resignation forces it.
How do you find it?
Watch what happens when people are away. The risk announces itself.
You do not need an audit to start. Five signals surface most of it, and every one is observable this week.
- Holiday interruptions. Who gets messaged while off? That is a live dependency, not a keenness problem.
- Approvals that wait. Which decisions sit until one specific person returns.
- Always-the-same-name tasks. Work that is never assigned to anyone else, usually because reassigning it would be slower than doing it.
- One-name runbooks. Procedures whose escalation step is a person rather than a role.
- Questions new joiners ask twice. Whatever they cannot find and have to ask about is knowledge that lives in someone rather than somewhere.
Write the list before you rank it. Teams routinely find the concentration is not where they assumed. The critical process usually has three people who understand it, precisely because it is critical.
How do you judge which instances matter?
Two questions, in this order. Neither needs a scoring model.
How fast does the business notice? Some work stops being done and nobody sees it for a quarter. Other work is visible within a day.
How many people can do it today? Not “could learn it” — can do it, unsupervised, this week.
Anything noticed within a week and known by one person is your real list, and it is usually short. Everything else is a second pass. Beware the instinct to start with the most important work: that tends to be the work several people already share, because its importance made someone insist on cover.
What actually reduces it?
Four options, and picking the wrong one wastes the effort.
- Capture the knowledge. Ask the person, write it down, keep it where the team reads. The only option that works when they are already leaving.
- Spread the work. Rotate it so a second person practises rather than reads. Slower, and far more durable.
- Remove the dependency. Automate it, simplify it, or stop doing it. The best outcome where it is available, and it rarely is.
- Accept it deliberately. Some concentration is rational. A specialist skill needed twice a year may be cheaper to insure or contract than to duplicate.
The fourth is a legitimate answer and almost never written down as one. A risk you have decided to carry is managed. A risk nobody decided about is just exposure with a story attached.
Why do documentation projects fail here?
Because they capture the sequence and lose the judgment.
The instruction “please document your processes” produces the tidy version of the work. The thresholds, the exceptions and the traps feel too obvious to the person writing to mention. They are also the whole reason that person is hard to replace. Meanwhile the people holding the most concentrated knowledge are, by definition, the busiest.
Asking questions works better than assigning documentation, and asking two people beats asking one. A disagreement between two experienced colleagues is itself a finding about how the work really runs. That is the method behind a knowledge transfer plan, and the handover questions are a usable starting set whether or not anybody is leaving.
Where should you start?
With the one that is leaving, or the one that would hurt tomorrow.
If somebody has resigned, the list is written for you. If nobody has, pick the single instance where work stops within a week and one person holds it, and run the questions on that. One properly captured dependency beats a spreadsheet of thirty you never got to.
Then check it landed: have the second person do the work unaided while the expert is available but not intervening. Whatever they have to ask about is the part that has not transferred yet — and you still have time to fix it.