What you'll learn
- Define the work your backup is expected and authorised to cover.
- Observe an ordinary task and an exception, including every prompt or correction.
- Record what is covered, what remains unproven and who handles the fallback.
Start with the work behind key person dependency
Key person dependency leaves essential work unable to continue reliably when its usual owner is unavailable. Start with a recurring task you already know depends on one specialist and a short absence you can prepare for. Choose one item that needs attention during that window. Ask the expert what a usable result looks like, which errors matter and which decisions require someone else. Use an accepted example, alongside the checks that make it acceptable.
Agree what can wait and tell the people affected. The backup does not need to reproduce every part of the expert’s role. They need a clear covered task, a feasible deadline and a route for anything outside it. Keep the expert responsible for the wider role while agreeing what the backup will cover during the absence.
If key person dependency centres on you as the founder, use the founder bottleneck audit. This guide starts once you have identified a specific task: which part can this backup safely cover?
Give the backup time, authority and approved access
Confirm the arrangement with both people. Name the commitment that moves off the backup’s workload, who takes it or agrees its delay, and when it returns. If nobody has capacity or the required competence, reduce the covered scope, arrange suitable qualified help or record an agreed delay with its owner. More instructions cannot create missing time.
A 2026 qualitative study of smaller voluntary sport organisations describes time and capacity constraints on redistributing work concentrated in key people. It examined three community-managed sport facilities in England using interviews from 2018 to 2020. This is context from a different setting, not evidence that this rehearsal works for commercial teams. It supports taking the preparation burden seriously.
Check access before practising. Use the backup’s own approved account and permissions through the authorised owner. NCSC guidance on shared access favours delegated privileges because shared accounts make it harder to trace actions to individuals. Do not put credentials in the coverage record or bypass a required approval to finish the exercise.
If cover repeatedly lands on someone who is already full, use the team overload guide to decide what moves. Calling someone a backup should not quietly give them a second full job.
Observe an ordinary case and a representative exception
Choose an ordinary case and an exception the expert recognises as relevant: a missing input, an unfamiliar request or a discrepancy that needs a decision. Agree the scope, output checks, time available, stop point and available decision owner before starting. Use synthetic or approved practice inputs when live consequences cannot be contained. Keep practice outputs separate from anything customers receive.
- 01
Prepare the work without concealing the rules
Give the backup the current instructions, accepted example and authorised references. Teaching and questions come first. Do not create a surprise absence, withhold access or plant an undisclosed failure to test loyalty.
- 02
Observe the attempt and keep a help record
Note what the backup produced, elapsed time, each prompt or correction, missing access and the decision route they used. Be explicit that this is preparation for cover, not a hidden performance assessment.
- 03
Compare the actual output with the agreed checks
Ask the relevant reviewer to inspect the work. A finished file can still contain a consequential error. If help was needed, repair that specific dependency and repeat the affected case using another suitable input.
Official UK local-responder exercise guidance distinguishes training from exercising a plan and advises controlled practice, correction and another exercise after serious weaknesses. It is historical guidance for a different operational setting, not a small-company compliance standard. The ordinary-plus-exception approach here is a practical recommendation, not a validated test.
Follow a hypothetical customer report through a failed attempt
Asha prepares a weekly customer status report and will be away for one week. Dan is the designated backup. Their manager agrees that Dan will prepare the usual report for the account lead by Thursday noon; sending it and deciding changes to customer commitments remain with the account lead. The report must match the approved input snapshot, identify missing information and avoid presenting an unverified status as fact.
The manager moves Dan’s weekly pipeline-cleanup task to another colleague with that colleague’s agreement, and confirms the change with its requester. Dan has an hour reserved for report preparation during the absence. Asha and Dan also get scheduled preparation time before she leaves. They rehearse with synthetic customer data and save drafts in a practice area.
On the first ordinary case, Dan cannot open the saved input snapshot. Asha opens it from her account so he can continue. That assistance goes in the record: the report may be correct, but Dan has not demonstrated that he can start it alone. In the exception case, one item has no status. Dan marks it complete until Asha asks what confirms that conclusion. He corrects it to unresolved. That prompt and correction are recorded too.
The manager asks the authorised system owner to give Dan approved read-only access to the input snapshots. Asha adds the missing-input instruction and shows where the account lead can resolve an uncertainty. During cover, Dan may mark the item unresolved and request clarification; he may not invent a status or amend the customer commitment. The account lead confirms they will be available for that route, rather than leaving Asha as the routine fallback while away.
Dan then repeats an ordinary case and a missing-status exception with new synthetic inputs. In this hypothetical repeat, the two take 28 and 12 minutes. He opens the inputs himself, produces drafts that meet the agreed checks and routes the missing status to the account lead without an expert prompt. These illustrative times fit the reserved hour; they are not a benchmark for another team.
The coverage record now says: “For Asha’s one-week absence, Dan can prepare the usual report from approved inputs, flag missing status and request clarification from the account lead. Read-only access worked; repeated drafts passed the checks without Asha’s help. Customer circulation remains with the account lead. New report formats and changes to customer commitments are outside cover.” The narrower conclusion is useful even though Dan has not learned Asha’s whole role.
Accept only the scope demonstrated and name the fallback
| Decision | Evidence to keep | Arrangement before the absence |
|---|---|---|
| Covered within the stated scope | The output met the checks within available time, using approved access and the agreed decision route, without an expert prompt or correction. | Name the covered dates, allowed decisions, required reviews and available fallback for a new exception. |
| Needs another supported practice | Record the exact help, correction, missing access or timing problem. A result completed with help is not an independent pass. | Repair that dependency and repeat the affected case. Until then, use an agreed qualified alternative or delay, with an owner. |
| Outside scope or unsafe to attempt | The work requires authority, competence, capacity or controls the backup does not have; or a rehearsal cannot be safely contained. | Keep it with an authorised qualified owner, obtain suitable help or agree a safe delay. Do not count it as covered. |
For the hypothetical report, new formats stay unproven and changes to commitments stay outside Dan’s authority. If an unfamiliar input appears during the absence, Dan pauses the affected part and contacts the account lead. If that person is unavailable, the manager follows up on the agreed delay and informs the customer through the authorised route. “Ask Asha on leave” is not the routine plan.
Keep the work item, acceptable output, covered window, workload trade-off, practice inputs, actual result, time and help record together. Add the accepted scope, allowed decisions, stop point, fallback owner and response expectation. Give the expert, backup and affected reviewer the same current version. Store only the work information they need, with appropriate access; leave credentials and sensitive customer material in their approved systems.
One successful rehearsal is evidence for the stated task under those conditions. It does not prove resilience across the whole role, predict every exception or establish that the expert’s judgement is replaceable. If the repeat still needs support and no workable fallback exists, tell the affected people what cannot be covered and who will resolve it before the absence starts.
Close the temporary arrangement after the expert returns
Ask whether the accepted scope held in real work, what reached the fallback owner and whether the expert was contacted despite the agreed route. Inspect relevant outputs with both people. An interruption may reveal a missing instruction or an unavailable decision owner; it does not by itself show that the expert withheld knowledge or the backup failed.
Confirm who owns the next report, when the displaced work returns and which instruction is now current. Ask the authorised system owner to review any temporary access. NCSC’s guidance for small organisations recommends reviewing access as roles change and removing access no longer needed. If you want a permanent role transfer, make that a separate decision; the manager-to-individual-contributor handover guide deals with a different transition.
When key person dependency keeps showing up in recurring handoffs, Cooperly’s Fundamentals can support a conversation about expectations and ownership alongside working profiles and team context. Keep the actual coverage evidence in the appropriate work record. Cooperly does not certify the backup’s competence, grant system access or replace the manager’s acceptance decision.