Key-person risk: the list nobody wrote down

Consider a team where Claire is absent. A report waits, customer replies slow down and colleagues hesitate because she normally knows which data to trust. This shows a continuity dependency.

The sick note exposes a structural problem.

Build a register of the people whose absence would stop a critical activity. Its length depends on the operation; five to twelve names is not a universal rule.

Distinguish rare expertise from a single point of failure

There is a difference between being hard to replace and being a single point of failure. Hard to replace means it would take four months and a good recruiter to find someone capable. A single point of failure means something the company relies on stops working the moment one person is not there to keep it going.

Most key-person conversations confuse the two. They talk about hiring pipelines and succession plans and retention bonuses. Those address the first problem. They do not address the second.

The second problem is narrower and more specific. It is about a piece of operational knowledge that was never transferred, never documented, and never tested. The process works because one person runs it. The person runs it because it has always been their job. Nobody has ever asked what would happen if the person could not do it for two weeks.

The answer is usually discovered during the two weeks. It is expensive.

There is a type of CEO who knows the list by name. She can rattle off four of them right now. The finance director who is the only one who understands how the bank reconciliation actually works, not the way the SOP describes it. The operations lead who has been routing supplier exceptions through a personal system since 2021. The sales engineer who alone knows which legacy client needs a phone call before an email. The admin person who has been maintaining a spreadsheet that is the real system of record for half the company.

She knows the names because she has lived the consequences. She has had the Tuesday where someone was out and something broke. She has seen the scramble. She has done the scrambling herself.

What she has never done is write the list down as a structural fact. Not as a worry. As a fact. The company does not have a key-person register. It has a mental list the CEO carries around, updated by anxiety rather than by design.

The list has a shape you can map if you are willing to look.

For each name, there is a question. What does this person do that nobody else in the company could do tomorrow, without training, without a manual, without calling them on their day off? The answer is never the job description. The job description is what HR filed. The real answer is the undocumented layer. The way this particular supplier actually pays, which is not how the contract says. The reason this client always gets an extra review, which is not in the CRM. The three-step workaround that keeps the reporting pipeline alive, which exists only in a script one person wrote and has never shared.

The list is not about seniority. Some of the names are directors. Some of them are people who have been doing the same job for eleven years and whose title has not changed once. Seniority does not create the risk. Undocumented operational knowledge does.

Ask the people on the register to explain the critical work in enough detail for another operator to attempt it safely.

There are reasons. The most common one is that the person doing the work is busy doing the work. Pulling them out for two days to document a process feels like a cost with no visible return. The process works. It has always worked. Why fix it?

You can already see the answer in the sick week, the vacation that overlaps with a supplier crisis, the unexpected resignation, or the parent who goes on leave. The company discovers the fragility of its knowledge structure through an event instead of a plan.

The cost is not the person's salary. The cost is the gap between the moment they stop doing the work and the moment someone else can start doing it. That gap has no budget line and no owner. It just appears, as delays, as errors, as clients who notice something changed and are not sure what.

The reason this matters more now than it did five years ago is that for the first time the company has an alternative to carrying every piece of operational knowledge in human heads. The work that lives in one person can be made explicit. The rules that one person follows by instinct can be written down and applied by a system. The process that depends on a phone call to Claire can be rebuilt so that Claire's knowledge is embedded in the workflow, not in Claire's availability.

This begins with mapping, before AI enters the picture. Before any system can carry what Claire knows, someone has to sit with Claire and understand what she actually does and why: the real work behind the job description, the exceptions, the judgment calls, and the three checks she runs that she has never been asked to explain because everyone trusts her.

Documentation is the start of transfer. A second operator must perform representative tasks, handle known exceptions and find the recovery path without calling the original expert. A system also needs enforced controls and tested recovery.

The test is not whether you have key people. Every company does. The test is whether you know which ones, what they hold, and what the company would lose if any of them stopped showing up next Monday.

Most CEOs cannot answer that question precisely. They have a feeling. They know certain names make them uncomfortable. They know certain processes would stall. They have never mapped it far enough to see the structure underneath.

For each critical activity, record the knowledgeable person, the consequence of a two-week absence, available documentation, access rights, backup operator and the last successful transfer test. Assign a next action and an owner to every gap.

An afternoon can start the inventory. It cannot establish that knowledge transfer works across every critical process. Schedule the representative tests and record what the replacement could actually complete.

Maintain the register after role changes, incidents and process updates. It should show an operating dependency and its evidence, without turning a valued colleague into the problem.

Bring one dependency to a 30-minute Strategy Session. We will recommend the next evidence or transfer test, without promising a complete register in that conversation.