Most companies have one: the person everyone asks. They know where the document is, when the contract renews, and what was promised to which customer. Nobody planned it, and it works perfectly until they are out for two weeks. This page is about seeing that dependency early, while it is still cheap to fix.
What is key person risk?
Key person risk is when a company's normal operation depends on what one person knows, holds or remembers, so their absence stops or damages the work. It is not limited to founders and executives. Often the key person is an office manager, a senior engineer, or the one account manager a large customer trusts.
How do you know you have it?
Answer these about any role you are worried about. Two or three yeses are enough to take it seriously.
- Has this person ever postponed a holiday because nobody could cover?
- When they are away, do colleagues phone them anyway?
- Is "ask them" the usual answer, instead of a document or a system?
- Is there a customer or supplier who will only deal with them?
- Would a contract renewal or filing deadline be missed if they were out for a month?
- Are they the only one with a login, a signing right, or an approval?
- Do they maintain a spreadsheet nobody else understands?
- Have promises been made that exist only in their memory or mailbox?
- Would you struggle to write their job description from memory?
How does it happen?
Usually by accident, and usually to your most reliable people. Someone good becomes the default for every question, each small favor adds to what only they know, and writing it down is never the urgent thing that day. Deliberate hoarding exists, but it is the exception. Treat it as a gap in how the company runs, not as a fault in the person.
Why doesn't "just document it" work?
Because the person doesn't know what they know. Asked to write it down, they will describe the formal steps. The customer's unwritten discount, the supplier who answers on Saturdays and the report they quietly correct don't feel like knowledge to them; that is simply the day's work. They are also the person with the least spare time, and a document written once starts going stale the next morning.
What are the options?
These work best in combination.
| Option | What it solves | Where it falls short |
|---|---|---|
| Shared access and split approvals | Removes the hard single points fast: sole logins, sole signers | Access is not knowledge |
| A substitution matrix (who covers whom) | Makes cover explicit, and shows where there is none | Naming a stand-in does not give them what they need to know |
| Process documentation | Formal, repeatable steps | Covers only what the person thinks to write; goes stale |
| Cross-training and shadowing | Hands-on skill, seen in action | Ties up two people for weeks; covers only what happens to come up |
| A role record (Understudy) | Shows what the role actually carries, rebuilt from its email, calendar and systems | Only sees what left a written trace; needs the role-holder's consent, by design |
What can you do this week?
None of this needs any software.
- List the logins, signing rights and approvals only one person holds, starting with the bank, tax portals and your domain.
- Put every contract, licence and renewal date into a shared calendar.
- Name a stand-in for each critical role, and tell them.
- Answer the twelve quick-path questions from the 100 handover questions.
- Then send the person on a real holiday and write down what breaks. It is the cheapest test there is.
How can you see the dependency without asking them to write it down?
Start from the trace the work already leaves. Email, calendar and systems of record show the workstreams a role runs, the people it works with inside and outside the organization, the commitments it has made, and the systems it owns. The person then corrects what is wrong, which takes far less of their time than writing from a blank page.
One role on one page, drawn directly from its record. Fictional data from the live demo.
It has limits: phone calls and hallway decisions leave no trace, which is why the method treats the record as the start of a conversation, not a replacement for one. When someone does go on leave or move on, the same record produces the handover document.
Should the key person be worried?
They shouldn't be, and how you introduce this decides whether they are. Being indispensable has a cost for them too: no real holidays and calls on sick days. The record belongs to the person whose role it is, and they decide what is shared. It maps the work, not the worker. If the real aim is to find out who can be let go, this is the wrong tool, and the homepage says so plainly. How the data is handled is on the security page.
How the record behind all of this is built: knowledge transfer from the work itself.