When the Right Answer Is to Stay Dependent

A collection about reducing dependence should say where reducing it is the wrong call. At small scale, that is more often than the literature suggests.

The principles in “When the Right Answer Is to Stay Dependent” become easier to maintain when ownership and time spent are visible. Teams evaluating the detailed reference 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 CIPD succession planning guidance; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

Where acceptance is reasonable

The activity is rare and the workaround is tolerable. Something done twice a year that could be deferred a month.

The transfer cost exceeds the exposure. A qualification costing thousands to cover a role whose absence would be inconvenient rather than serious.

The organisation is too small. In a team of four, some single points are arithmetic rather than negligence.

And the dependency is on an owner who is not going anywhere, where the realistic answer is a sale or a wind-down rather than a succession.

What accepting properly means

Naming it, on the map, as accepted rather than outstanding.

Recording why, so the decision can be revisited rather than rediscovered.

Knowing what the fallback is: what actually happens, even if the answer is "we stop doing this for a month".

And reviewing it annually, because the arithmetic changes as the organisation grows.

The difference between accepting and ignoring

Accepting is a decision with a stated reason and a known consequence.

Ignoring is the same situation with nobody having thought about it.

They look identical from outside and behave completely differently in a crisis, because acceptance comes with a fallback and ignorance does not.

The cheap mitigations to do anyway

Even for accepted dependencies: access, contacts, and a short note on where things are.

These cost almost nothing and they convert an accepted dependency from a cliff into a step.

Acceptance should never extend to somebody else being unable to log in.

Reviewing the decision

Annually, and when the organisation changes size or takes on something new.

The thing that made acceptance reasonable — small scale, low consequence — is exactly what changes with growth.

And an accepted dependency from four years ago may now be the largest exposure you have.

The honest framing for owners

An owner-dependent business is a legitimate way to run something.

It limits what can be built, what it is worth, and what happens on illness — and plenty of people make that trade knowingly and are content.

The problem is making it without noticing, which is what happens by default.

What this collection is not arguing

Not that every dependency should be removed.

Not that resilience is free.

Only that dependence should be visible, chosen, and mitigated where the mitigation is cheap — which is most of the practical benefit for a fraction of the effort.

What to check

Which of your dependencies are accepted, and is that written down?

Do the accepted ones have a known fallback?

Have the cheap mitigations been done even for those?

And when was the acceptance last reviewed against the organisation's current size?

The point

Accepting is a decision with a stated reason and a known fallback.

Ignoring is the same situation with nobody having thought about it.

Underlying all of this

Everything in this collection reduces to four habits: know where the dependence sits, do the cheap fixes first, use the absences that already happen as rehearsals, and decide deliberately about what remains. None of it requires a framework, a tool or a consultant, and an organisation that does those four things consistently is substantially harder to damage than one with a succession document nobody has read.

The recurring pattern

The recurring pattern across every section here is the same: dependence forms through sensible individual decisions, becomes invisible because it feels like reliability, and is addressed only after it has cost something. The work that prevents that is small, continuous and unglamorous, which is exactly why it gets deferred.