The short version
- Key person dependency is not about titles. It is about who gets asked. Find it by counting questions, not by reading the org chart.
- The cheapest audit takes a week: log every question that only one person could answer, and note how long the asker waited.
- Three fixes, in order of how fast they work: write down the answers that repeat, name a second owner per area, and give people a way to get the answer without the person.
- Cross-training is the slowest of the three and the one most teams start with. Start with the written answers instead.
Every small company has one person everything routes through. Sometimes it is the founder. Sometimes it is the second engineer who built the billing logic in 2021 and is the only one who remembers why it works that way. The company runs fine until that person takes two weeks off, and then it does not.
"We are fine as long as Marta does not get hit by a bus." Everyone laughs. Nobody writes anything down.
The joke is old and the risk is real, but the usual response to it is wrong. Teams treat key person dependency as a documentation problem and start writing a wiki. A year later the wiki is stale and people are still asking Marta.
What key person dependency actually is
A key person dependency exists when work stops because one specific human is unavailable. Not slows. Stops. The test is simple: if this person were unreachable for two weeks, what would sit still, and who would be sitting still with it?
Notice that this has nothing to do with seniority. A support lead who is the only one with the password reset runbook is a dependency. A junior developer who is the only one who has ever deployed the reporting service is a dependency. The finance contractor who knows which of the two supplier accounts is the live one is a dependency.
It also has nothing to do with how much someone is documented. Plenty of teams have thorough documents and a severe dependency, because what people need is not in the documents. What people need is the current state of something, and the reason a choice was made, and both of those live in the person's head and in last month's chat.
Find it by counting questions
Skip the workshop. For one working week, ask everyone to note each time they had to ask a specific named person something, rather than finding it themselves. Four columns, nothing more.
| Column | Example entry |
|---|---|
| Who did you ask | Marta |
| What did you need | Which invoice template the German client is on |
| Could anyone else have answered | No |
| How long did you wait | Four hours |
A week of this on a team of fifteen produces somewhere between eighty and two hundred rows. You do not need statistical rigour. You need the shape, and the shape shows up fast.
How to read the log
Sort by the "who did you ask" column and count. One or two names will carry a share of the total that startles everyone, including the people whose names they are. That is your dependency, measured rather than guessed.
Then read the "what did you need" column for the top name, and sort those entries into three piles.
- Already answered. The same question, asked before, by someone else. This pile is usually the biggest and it is pure waste.
- State of something. Where a piece of work stands right now, what is blocked, what was agreed with a client last Thursday. Not in any document because it changes weekly.
- Genuine judgement. Something only this person can decide, because of what they know or what they are accountable for. This pile is small and it is the only one that should stay.
The waiting column tells you what it costs. Four hours on an invoice question is four hours of someone else stopped, and that person was almost certainly doing something else badly in the meantime. We go through that arithmetic in the coordination tax on distributed teams.
Three ways to spread the load
Take them in this order, because they pay back in this order.
One. Write down what repeats. Every question in the "already answered" pile becomes one short entry somewhere people already look. Not a document nobody opens. Two sentences in the channel where the question gets asked, pinned. This is boring and it removes the largest pile first.
Two. Name a second owner per area. Not a backup who shadows, an actual second name that appears next to the area in whatever list your team uses. The point is not that the second person knows everything. The point is that askers have somewhere else to go, which halves the traffic immediately. The mechanics are in the DRI model in distributed teams.
Three. Cross-train on the genuine judgement pile. This is real work and it is slow, which is why it should be third and why it should only cover the small pile. Sit the second owner in on the decisions for a quarter. There is no shortcut here and there does not need to be, because by now the pile is small.
What does not work: asking the key person to document everything they know. They cannot, because they do not know what they know. The question log tells you what to ask them for, which is why it comes first. More on that failure mode in why nobody reads the docs.
The answers that should not need the person
The second pile, the state of things, is the one that defeats most teams. It is too current for a wiki and too specific for a runbook. It changes every week, so writing it down feels like a losing battle, and so nobody writes it down and everyone asks Marta.
This is the gap StandIn is built for. At the end of the day, the person spends about ninety seconds on a short brief: what moved, what is open, what is blocked, what is next. Most of it is drafted already from the work that happened. When they are away, their StandIn answers questions from that brief, in their words, with a source under every answer. It never guesses. If the answer is not in the brief, it says so and names who to ask.
The effect on the log is direct. The "already answered" pile and most of the "state of something" pile stop reaching the person at all. The genuine judgement pile still waits for them, because it should. Marta can take two weeks off and the company does not stop. See how teams use it for what that looks like in practice.
Common Questions
What is the difference between key person dependency and bus factor?
Bus factor is the number, key person dependency is the condition. A bus factor of one means one person's absence stops the work. The number is useful for talking to a board and useless for fixing anything, because it does not tell you which questions to remove first. The question log does. We cover the measurement in what a bus factor of one really costs.
How do I raise this with the key person without it sounding like a threat?
Lead with the waiting column, not the dependency. The person at the centre is usually the most interrupted person in the company and the most tired. Framing the work as "you get fewer questions" is both kinder and more accurate than framing it as "we are reducing our exposure to you leaving."
We are eight people. Is this worth doing at that size?
It is more worth doing at eight than at eighty, because at eight a single absence is a larger share of the company and there is no slack to absorb it. The audit is also cheaper at eight. One week, one shared sheet.
Does insurance cover this?
Key person insurance covers the financial shock of losing someone permanently. It does nothing about the two weeks in August when that person is on a beach and three deals are waiting on an answer they alone have. The operational version of the problem is the one you feel every quarter.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.