Almost every small team has one person everyone turns to. They know which client prefers calls, which supplier needs a reminder, and which spreadsheet column must never be sorted. That person is valuable. They are also a single point of failure, and most of the time nobody notices until they are ill, on leave or gone.
How to tell if you have this problem
The signs are rarely dramatic. Work simply slows down whenever one person is unavailable. Questions pile up in their inbox while they are away. New hires take months to become useful because the real rules are not written anywhere. And that one person is quietly exhausted, because they are interrupted all day.
A quick check: list your ten most important recurring tasks. Next to each one, write the names of people who could complete it correctly tomorrow without asking anyone. Any task with one name, or none, is a risk worth fixing.
- Work stalls when a particular person takes a day off.
- The same questions are asked to the same person every week.
- Nobody else can explain why a step is done a certain way.
- Onboarding depends on shadowing rather than written material.
Why asking them to 'write it all down' fails
The usual response is to ask the expert to document everything. It almost never works. They are already the busiest person on the team, and writing documentation for a task they can do in their sleep feels pointless to them. The result is either nothing, or a long document that skips the parts that matter most because those parts feel obvious to the person writing.
Experts are often the worst people to write the first draft, precisely because they no longer notice the decisions they make. Knowledge has to be pulled out, not pushed out.
A better method: interview, watch, then write
Pair the expert with someone who does not know the task. The learner does the writing; the expert only talks and does. This splits the effort so it fits around normal work.
Pick one task at a time, ideally the one with the highest risk from your list. Then follow three short sessions.
- Interview (15 minutes): the learner asks what starts the task, what 'done' looks like, who receives the result and what usually goes wrong.
- Watch (one real run): the expert does the task normally while the learner notes every step, every system opened and every decision made. The learner asks 'why?' at each decision.
- Write and test (30 minutes): the learner drafts the steps, then completes the next real run themselves while the expert watches silently and only steps in to prevent a mistake.
Capture the decisions, not just the clicks
Steps like 'open the sheet' and 'send the email' are easy to capture. The valuable knowledge is in the judgement calls: when to escalate, which client gets special handling, what counts as urgent. Ask the expert to finish this sentence as many times as they can: 'If this happens, then I…'.
Each answer becomes a rule in the document. Where the answer is genuinely 'it depends', write down what it depends on and who decides. That is honest, and it shows exactly where human judgement must stay.
Make it a habit, not a project
Do one task every week or two. Ten tasks over a quarter will change how resilient your team feels, without anyone having to stop normal work for a documentation sprint.
Then rotate. Once a task is documented, let a second person run it for real at least once a month. Knowledge that is written but never used fades quickly; knowledge that two people practise stays alive. The expert gets fewer interruptions, the team gets cover, and you finally get to take a holiday without checking your phone every hour.
What to say to the expert
How you frame this matters. If the expert hears 'we need to document your job', they may worry that they are being replaced. Explain the real reason: the team depends on them too much, they deserve a proper holiday, and their knowledge is too valuable to live in one place. Most experts are relieved once they understand that the goal is fewer interruptions for them, not less importance.
Give them credit visibly. Name them as the source in the document, and thank them in front of the team. People share knowledge more willingly when it is recognised rather than quietly extracted.
An illustrative example
Imagine a small training company where one coordinator handles all batch scheduling. A learner sits with them for one scheduling run and writes down the steps, then asks 'if this happens, then I…' questions. Seven hidden rules appear, such as never scheduling a batch on the same day as a trainer's other client. The next month, the learner schedules the batch alone using the notes. The coordinator now has backup, and the rules are visible to everyone.
Key takeaways
- List your key tasks and the names of people who can do each one. Single names are risks.
- Let a learner write while the expert talks and does. Knowledge has to be pulled out.
- Capture 'if this, then I…' decisions, and rotate who runs the task so it stays alive.
