Questions we answerCapacity and workload

Too much depends on one person. What are my options?

Reduce the fragility before it becomes a crisis: write the work down, develop a second person, move adjacent work off them, or decide it is acceptable for now with a date to look again.

Start from this question

Free · a few minutes · starts from “Something in the team isn't working

The short answer

This is a real risk and it is almost never solved by hiring someone similar. Key-person dependency comes from knowledge that was never written down and decisions that never got delegated, and a second person inherits both problems. The cheap moves come first: write down what only they know, hand over the decisions that do not need them, and see what is left. A hire becomes the right answer when the remaining work is genuinely a full role rather than the residue of one person's undocumented habits.

A single-person dependency works right up to the day it doesn't — leave, illness, a resignation. The risk is not that the person is doing a bad job; it is that nobody else can.

The options are mostly cheap. The diagnostic helps you see which one fits, and which would only move the dependency somewhere else.

Is it really this?

Worth checking before you spend anything. These are the signals that tend to tell the two apart.

Signs it is

  • Their holiday is a planning exercise for everyone else.
  • Nobody else can answer a routine question about the work.
  • You would struggle to write a handover if they resigned tomorrow.

Signs it's something else

  • Others could do the work but do not, because it has never been shared out.
  • The dependency is on a decision you have not delegated rather than on their knowledge.
  • It is one system nobody else has access to, which is an access problem with a quick fix.

What's usually behind it

  • Work that grew around one capable person and was never written down.
  • A team too small for anyone else to have picked it up.
  • A skill that genuinely sits with one person and needs to be developed in another.

What people usually get wrong

  • Asking the busiest person to document everything at once, so nothing gets documented.
  • Recruiting a second specialist without changing how the work is shared, and getting two silos.
  • Calling the risk acceptable without ever putting a date on reviewing it.

The options, and when each one fits

In no particular order. Which of these fits depends on your situation, not on the question you typed.

  • Write down the critical parts

    The knowledge is the dependency, and a few pages would remove most of the risk.

  • Pair someone alongside them

    There is someone who could learn it if they were given the work and the time.

  • Move adjacent work off them

    They are the only person who can do the hard part and are also doing everything around it.

  • Recruit a second person

    The skill is genuinely scarce and the exposure is too large to carry.

When doing nothing is the right call

Sometimes the honest answer is that the risk is real, removing it costs more than the exposure, and you will carry it. That is defensible as long as it is written down, said out loud to the person concerned, and given a date when it will be looked at again.

What the diagnostic asks

  • How long it has been like this and who owns the work.
  • How many people could actually do it, and how much is written down.
  • Whether someone in the team could realistically grow into it.

“I don't know” is always an answer. Nothing is assumed on your behalf.

The routes it weighs

Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.

  • Develop

    Build the capability in someone already in the team, with time and support.

  • Process improvement

    Change how the work flows — remove steps, name an owner, fix the hand-offs.

  • Redistribute

    Move ownership of the work to where it fits, and make that explicit.

  • Recruit

    Recruit a new person for a durable, sizeable need that is central to the team.

  • Do nothing yet

    Record the issue, set a revisit date, and decide what would change your mind.

What changes the answer

  • Someone internally who could grow into it makes development the natural first move.
  • Nothing written down makes documentation the first step whatever else follows.

Get your own read

A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.

Related questions