Dependence accumulates invisibly and feels like reliability

The problem, stated plainly

Somebody in your organisation knows how things work. They handle the difficult client, they know why the system is configured oddly, they are the approval, and half of the passwords are effectively theirs.

The principles in “Dependence accumulates invisibly and feels like reliability” become easier to maintain when ownership and time spent are visible. Teams evaluating the feature summary can use it to coordinate recurring work, identify tasks concentrated on one person and plan realistic backup capacity, while treating the data as a prompt for knowledge transfer rather than as a substitute for speaking with the people who do the work.

For an independent benchmark, compare the local approach with Ready.gov business preparedness guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

This is normal and it is not a planning failure. It accumulates through ordinary decisions: give the task to whoever does it best, let the person who knows the client keep the client. Each step is sensible. The outcome is an organisation that stops if one person does not appear on Monday.

Why nothing gets done about it

Because it feels like reliability. Dependence has no symptoms while the person is present — it produces speed rather than friction. Decisions are quick because one person can make them; problems are solved fast because somebody knows.

The cost is entirely deferred, and it arrives all at once. A resignation, an illness, a family emergency, a holiday that was supposed to be two weeks. Then a dozen small dependencies surface together, each individually manageable and collectively overwhelming. Organisations in that position describe it the same way afterwards: we did not realise how much was in his head.

Raising it is also awkward. Telling somebody the organisation depends on them too heavily sounds like criticism or like a prelude to reducing their role. It is neither, and the framing that works is different: dependence traps the person as much as it exposes the organisation. No holiday without the phone on. No illness without guilt. No promotion, because nobody can replace them in their current role. Most people in that position recognise the description immediately.

Why the standard advice does not apply

Succession planning as it is usually written assumes a bench: internal candidates, development programmes, nine-box grids, a pipeline of people ready to step up.

In an organisation of twelve there is no bench. The person who would cover is already doing their own job at full capacity. Which means the answer is different in kind rather than in size, and most of the available material does not apply — it was written for organisations with slack, and a small organisation has none.

What is available instead is smaller and more practical: know where the dependence sits, do the cheap fixes, use the absences that already happen as rehearsals, and decide deliberately about what remains.

Start with access, not knowledge

Knowledge takes months to spread. Access takes an afternoon, and it is frequently what actually stops work when somebody is unavailable.

Accounts registered to a personal email rather than a company one. Systems where one person has the only login. Two-factor codes on one phone. Recovery addresses pointing at an individual. And the one that ends businesses: a domain registered to a former employee's personal account, or to a developer who has disappeared.

Check today who owns your domain, who the registrant contact is, and whether the renewal card belongs to somebody still with you. Fifteen minutes, and it is the single highest-return task in this collection.

The map, in thirty minutes

Down the left: the things that would hurt if they stopped for a week. Not tasks — obligations. Payroll goes out, the report reaches the client, the machine gets serviced, the regulator gets its return.

Then four columns: who does it now, who else could today, who could with a day's briefing, and — the one people leave out — where the knowledge lives if neither of those is anybody. "In Sarah's head" is a different answer from "in the shared folder", and both are different from "nobody knows".

Do it alone from memory first, then with one or two colleagues. The corrections are the valuable part: people consistently believe tasks are more widely understood than they are.

Use the absences you already have

Everything here is theoretical until somebody is actually away. A planned holiday is the only realistic rehearsal you will get, and most organisations waste it — the person answers messages from the beach, everything difficult waits for their return, and nothing is recorded.

Used deliberately it costs nothing extra. Agree no contact and mean it. Name who covers what. Ask the coverers to write down everything they could not answer, rather than saving questions up. Then spend half an hour afterwards going through that list, sorting each item into a knowledge gap, an access gap or an authority gap — because each has a different fix.

The holidays are happening anyway. Over two years this produces more improvement than any deliberate programme.

The knowledge that never gets written

Every organisation documents something. The trouble is that the documented part is rarely the part that matters when somebody leaves.

What gets written: steps that are stable, repeated and easy to describe — which is the part a competent person could work out anyway. What does not: why something is done that way, the exceptions, the judgement about when to escalate, and who at the client actually decides.

That knowledge stays unwritten because it is invisible to the person who holds it. Knowing which supplier needs chasing on a Thursday does not feel like knowledge; it feels like ordinary competence. Which is why asking somebody to write down what they know produces procedures and not much else.

The habit that works is smaller: if you explain something twice, write it down the second time. Three minutes, at the moment the explanation is already fresh. Over a year that accumulates into documentation shaped by what people actually ask, which is a different and more useful artefact than anything a project produces.

Why documentation projects fail

Somebody nearly left, everybody got a fright, and a project was announced. The sequence from there is consistent: enthusiasm for two weeks, a template too detailed to complete, three people writing and one of them thoroughly, then a busy month. Eighteen months later the folder is out of date enough to be misleading.

And that last state is worse than nothing. Documentation that exists and is wrong is dangerous, because somebody follows it, the error is attributed to them rather than to the document, and after that nobody trusts the folder — including the parts that are still correct.

Bounded works where comprehensive does not: one process, one client account, one system, with a date. And before a known departure, where the scope is simply what this person knows about these four things.

When somebody resigns

The notice period is the only structured handover you will ever get, and most organisations spend it finishing projects, which is the least valuable available use.

Within a day, agree what the period is for and ask them directly: what do you know that nobody else does? People are usually candid at that point — they have nothing to lose and most want to leave things in order. That single conversation produces a better dependence map than any exercise you could have run while they were staying.

Then name a receiver, even if they are not the permanent successor. Transfer to nobody in particular does not happen: the documents get written and nobody reads them. And move access in the first days rather than the last.

If there is only an hour, four questions in this order: what is in flight and what is promised, what only you can get into, who to ring at the three most important clients and suppliers, and what would you warn me about. That last one reliably produces something useful and nothing else asks for it.

What this collection will not tell you

That every dependency should be removed. At small scale some are arithmetic rather than negligence, and some are not worth the transfer cost.

That resilience is free. Spreading knowledge costs the expert's time, the learner's time, and errors during the learning period. Pretending otherwise is why this advice is usually ignored.

Or that it will stop people leaving. Nothing here is a retention measure. It changes what a departure costs you, which is a smaller and more achievable claim.

Where to start

You have never looked at this: what key-person dependence actually looks like, then the map.

Somebody is about to go on holiday: planned absence as a test.

Somebody has resigned: notice periods, then handover conversations.

Somebody is unexpectedly absent: what to do in the first week.

You are the dependency: the owner who cannot take a holiday.

You want the cheapest wins: access and passwords, then supplier knowledge.