In short
Key person risk exists when a process, relationship or system depends on one individual whose absence would stop or seriously degrade it. Measure it by counting, for each critical process, how many people could perform it to standard without assistance — the answer is your bus factor. Reduce it by transferring the three transferable things (access, documented method, and relationship context) rather than by trying to clone the person. Most exposure can be removed in a quarter; what remains is genuine expertise and should be managed, not eliminated.
Key takeaways
- Key person risk is a structural condition, not a comment on anyone's performance or character.
- Bus factor of one on any revenue-critical process is an emergency dressed up as a strength.
- Three things are transferable: system access, documented method, and relationship context. Judgement mostly is not.
- The dependent person is usually the most trapped person in the business, not the most powerful.
- Holidays are the cheapest live test you will ever run. Use them deliberately.
What key person risk actually looks like
It rarely announces itself. It looks like a business running well, because it is running well — right up until the week it does not.
The recognisable symptoms:
- One person's holiday requires planning by three other people
- Certain clients ask for a specific individual by name and will not accept a substitute
- A system exists that only one person has full access to, and nobody is entirely sure what else it touches
- Questions in the group chat are addressed to a person rather than to a channel
- Someone routinely says “I'll just do it, it's quicker than explaining”
- An entire category of work quietly waits when one person is in meetings
- Bus factor
- The number of people who would need to become unavailable before a process stops working. A bus factor of one means a single absence — illness, resignation, a family emergency — halts that process entirely.
The uncomfortable part is that key person risk is usually created by generosity. The person absorbing everything is doing it because they care, because it is faster, and because saying no would let someone down. Nobody set out to build a dependency. It accumulated one helpful act at a time.
Measuring the exposure without drama
This has to be measured on processes, not on people. The moment it becomes a conversation about individuals, it becomes political and stops being useful.
The inventory
List every process the business would notice stopping within two weeks. For each, record three numbers:
| Column | Question | Watch for |
|---|---|---|
| Performers | How many people have performed this in the last 90 days? | Anything at 1 |
| Capable | How many could perform it to standard without asking anyone? | The honest answer is usually lower than the first column |
| Access | How many have the credentials, permissions and approvals to do it? | Capability without access is not capability |
The third column catches a failure mode people miss constantly. Two colleagues may both know how to issue a refund, but if only one has the payment gateway permission, your bus factor is still one. Capability and authorisation have to be counted separately.
Weight by consequence
Not every bus factor of one is urgent. Multiply by what breaks:
- Revenue stops — invoicing, order fulfilment, the client-facing delivery step. Fix within weeks.
- Compliance or safety exposure — payroll, regulatory filing, data access controls. Fix within weeks, and document the control.
- Delivery degrades — quality review, escalation handling. Fix within a quarter.
- Inconvenience — the office plant order. Note it and move on.
The minimum bus factor for anything that touches revenue or compliance. Not three, not five — two, genuinely and demonstrably. Perfect redundancy is not the goal; surviving one absence is.
The three things you can actually transfer
Attempts to reduce key person risk usually fail because they aim at the wrong target. You cannot transfer twelve years of judgement in a training session, and trying makes everyone feel the exercise is futile. But judgement is only one of four components, and the other three transfer readily.
1. Access
The easiest and most often neglected. Every credential, permission and approval right held by one person is a hard dependency regardless of how well documented the process is. This is a weekend of work, not a quarter:
- Inventory accounts and permissions per system
- Move anything on a personal account or personal email onto a shared, role-based account
- Ensure at least two people hold every permission that gates revenue or payroll
- Put credentials in a password manager with defined recovery, not in someone's browser
2. Documented method
The steps, the decision rules, the failure modes. This is straightforward capture work — the method is covered in detail in documenting processes when nothing is written down. The key discipline is that the document must be written by someone else and tested by a third person, or you have simply written down what the expert already knew.
3. Relationship context
Most underrated of the three. When a client insists on one person, it is rarely irrational loyalty. It is usually that the person holds context nobody wrote down: what went wrong in 2024, which of the client's stakeholders actually decides, what they hate. Capture it as a short client dossier — history, preferences, sensitivities, decision-makers — and introduce a second named contact before you need one.
4. Judgement, which mostly does not transfer
Accept this rather than fighting it. What you can do is narrow where judgement is required: convert the recurring judgement calls that have become predictable into explicit decision rules, and leave the genuinely novel ones with the expert. Most “you need experience for this” work turns out to be 80% pattern and 20% actual judgement once someone writes the patterns down.
A ninety-day reduction plan
Concrete, sequenced, and designed not to disrupt delivery.
Weeks 1–2: inventory and access. Complete the process inventory above. Fix every access dependency, because it is cheap and it removes the most catastrophic failure mode — being unable to act at all.
Weeks 3–6: capture the top three. Take the three highest-consequence bus-factor-one processes and run live capture on each as they naturally occur. One page each. No more.
Weeks 7–10: shadow and swap. The second person performs the process from the document while the original owner watches without intervening unless something is about to break. Then swap the observation: the original owner performs it, the second person notes anything the document missed. Two rounds is usually enough.
Weeks 11–12: test with absence. The original owner takes a week away from that process entirely — not away from work, just genuinely uninvolved in that one thing, with no questions routed to them. What breaks is your remaining gap, and it will be smaller and more specific than anyone expected.
The holiday test
Once you are past the first cycle, holidays become your standing test. Before someone takes leave, ask which processes will be uncovered and confirm the cover works — then, crucially, do not route questions to them while they are away. A holiday where the key person answers six messages is a holiday where you learned nothing.
Handling the conversation with the person themselves
This is where most efforts stall, so it is worth being direct about it.
The person at the centre of a dependency often hears the initiative as a threat: you are making me replaceable. Sometimes that fear is explicit, more often it shows up as passive resistance — the documentation session that keeps getting rescheduled, the handover that is always “too complicated to explain right now.”
The framing that works is true, which is why it works: concentration of knowledge is what is trapping them. They cannot be promoted, because nobody can take over what they do. They cannot take real leave. They cannot work on anything more interesting, because their week is consumed by being the only person who can answer. Reducing the dependency is the precondition for their next step, not a preparation for their exit.
Nobody gets promoted out of a role that only they can do. Being irreplaceable is a ceiling, not a moat.
Two practical moves make it credible:
- Make them the owner of the transfer, not the subject of it. They decide what gets captured first and they sign off the documents. Authority over the process, rather than exclusivity of it.
- Attach it to something they want. If the reduction unlocks a project, a title, or genuinely uninterrupted leave, say so specifically and then honour it. One broken promise here poisons the whole programme.
Living with the risk that remains
You will not get every bus factor to two, and chasing that is its own form of waste. Genuine deep expertise is a competitive asset and duplicating it is expensive. What matters is knowing precisely where the remaining exposure sits and having decided about it deliberately.
Keep a short register — five lines is plenty — recording for each remaining single point of failure:
- What breaks, and how quickly
- The interim workaround if that person is unavailable for two weeks
- What the business would do if it were permanent
- Who reviews this and when
That last line prevents the register becoming a museum. Review it when the business changes shape: a new client tier, a new system, a departure, a growth step. Each of those either introduces new concentration or reveals old concentration that had been masked.
The end state is not a business where everyone can do everything. It is a business where nothing important depends on one person being available, where absence is a scheduling question, and where your best operators are free to do their most valuable work rather than their most repeated work. That is also, not coincidentally, a business that survives its own growth.
The Mayim Ops assessment scores ownership, documentation and resilience together, and reports where knowledge concentration is creating exposure — with the evidence traced back to specific answers rather than delivered as general advice.
Frequently asked questions
What is key person risk in a small business?
Key person risk is the exposure created when a process, client relationship or system depends on one individual, so that their absence stops or seriously degrades it. It is measured as a bus factor: the number of people who would need to become unavailable before the process fails. A bus factor of one on anything revenue-critical is a material business risk.
How do you calculate bus factor?
For each critical process, count how many people could perform it to standard without asking anyone for help, and separately count how many hold the credentials, permissions and approvals required. The lower of those two numbers is your real bus factor, because capability without access is not capability.
How do you reduce dependency on one employee?
Transfer the three transferable components rather than trying to replicate the person. Move system access onto shared, role-based accounts so at least two people hold every critical permission. Capture the method as a tested one-page checklist. Write down relationship context as a client dossier and introduce a second named contact before you need one.
How do I raise key person risk without insulting my best employee?
Frame it accurately: concentration of knowledge is what prevents that person being promoted, taking real leave, or working on anything more interesting. Make them the owner of the transfer rather than its subject, give them sign-off on the documents produced, and attach the outcome to something they actually want.
What is an acceptable bus factor?
Two, genuinely demonstrated, for anything touching revenue, payroll or compliance. Higher redundancy is rarely worth the cost for a small business. For deep specialist expertise, full duplication may be uneconomic, in which case the right answer is to record the exposure deliberately in a short risk register with a stated interim workaround.