The Person-Dependency Audit: When the Knowledge Is in One Head

Ask the question in any leadership meeting: if Dana wins the lottery tomorrow and never comes back, what stops working? Everyone laughs, and then everyone goes quiet, because the answer is specific: the payroll run, the quoting system, the vendor renewals, the thing with the bank. Dana is not an employee; Dana is infrastructure.

Key-person dependency is the most ordinary resilience gap in a small company and the least discussed, because naming it feels like disloyalty. It is the opposite. The person carrying the whole system in their head did not choose that burden, and the company that leaves it there is one bad Tuesday from discovering its price.

The person-dependency audit is the kind fix: find the dependencies, rank them, and lighten them - deliberately, kindly, and before they are tested.

TLDR

• Key-person risk is an infrastructure problem, not a personnel problem.

• Find dependencies by asking 'what stops if they leave,' not 'who is critical.'

• Rank by blast radius: what stops, for how long, and how hard the recovery.

• The fix is rarely documentation alone; it is a second pair of hands that has actually done the task.

• Sharing knowledge is a gift to the person carrying it, not a vote against them.

Finding the Danas

The direct question - who is critical - produces defensiveness. The productive question is mechanical: for each thing the business cannot skip - payroll, invoicing, the production schedule, the customer portal, the bank relationship - ask how many people can actually do it, end to end, without a phone call.

Where the answer is one, you have a dependency. Where the answer is one and that person's documentation is 'it's in my head,' you have a ranked dependency.

The interview matters more than the survey. People underreport their own indispensability out of modesty and overreport it out of pride; the truth comes out walking the task, not describing it.

Ranking by blast radius

Not all dependencies are equal, and the audit's job is the ranking. Two questions sort them: how long can the business survive the task undone - payroll tolerates days, the e-commerce site tolerates minutes - and how hard would reconstruction be for a stranger?

This fictional example shows one company's top of the list. It is an illustration, not a prescription.

Task	Sole holder	Survives	Recovery	Priority
Payroll + bank	Dana	~1 week	Hard - bank verification	1
Quoting system admin	Mike	~1 month	Very hard - custom	2
Vendor renewals calendar	Dana	~3 months	Easy but invisible	3

The last row is the sneaky one: the task nobody sees until the renewal that lapses. Invisible dependencies rank lower in pain and higher in surprise.

Lightening the load, not just writing it down

The instinct is documentation: get it out of Dana's head into a binder. Documentation helps, but a binder that has never been used is a theory. The real fix is a second person who has actually run the task - shadowed it once, done it once with supervision, and been the named backup since.

The rhythm that works: the critical task gets done by the backup twice a year. Payroll's backup runs the February and August payrolls. The knowledge stays warm, the documentation gets corrected by reality, and the primary holder gets something rare: a real vacation.

The service-account version of this problem is its own discipline - the logins nobody owns are person-dependencies wearing a technical costume, and the inventory logic transfers directly.

The conversation that makes it kind

The audit fails socially if it lands as 'we are de-risking you.' It succeeds as the opposite framing: you are carrying too much alone, and the company owes you help. Most Danas know exactly how exposed they are and have been waiting for someone to ask.

Make knowledge-sharing a recognized contribution, not an invisible expectation. The person who trains their backup has made the company more valuable; say so, in the review cycle, in front of the team.

That framing - resilience as care for the people who carry it - is the human half of the same program in building a resilient incident response practice: the systems matter, and the people who run them matter more.

The related discussion of logins nobody owns is worth your time alongside this one. The related discussion of resilient incident response practice is worth your time alongside this one.

Frequently asked questions

How do we start without alarming people?

Start with the tasks, not the people: 'we are mapping what the business cannot skip and making sure every one of them has a backup.' The framing is operational and it is true; the personnel reading is a choice you decline to make.

What if the person refuses to share the knowledge?

Rare, but informative. Refusal usually signals fear - of being replaced or of exposure. The answer is patience and the vacation framing: nobody should be unable to take two weeks off. If the refusal persists, that itself is risk information for leadership.

How deep should the audit go?

Until the list feels complete, which is usually ten to twenty tasks in a small company. The top five by blast radius get the full treatment; the rest get a named backup and a calendar entry.

A Defensible Next Step

This week, ask the lottery question at one leadership meeting and write down the answers without flinching. The list you make is the audit; the kindness is in what you do with it. Book a Decision-Clarity Call if you want the audit run for you.