A succession plan for the person everyone depends on

Start with the leave calendar. If one person's absence causes everyone to postpone changes, worry about recovery or keep their phone number close, the organisation has a dependency worth addressing.

That person may be generous with their knowledge and still be difficult to replace. The problem can come from years of urgent work, undocumented decisions or a lack of protected time for anyone else to learn.

I would approach succession as service continuity and professional development, not an exercise in proving that somebody is dispensable. The person holding the knowledge needs to be part of the plan, with enough time and support to make it work.

Map what cannot happen without them

Ask about tasks, decisions and access separately. Knowing the steps is not enough if another person lacks permission to perform them. Having administrator access is not enough if nobody understands when a step is safe.

List the critical activities and the consequence of waiting. Include infrequent work such as a certificate renewal, restoration, annual process or supplier escalation. Routine ticket records may miss these because they happen rarely.

Identify informal knowledge too. The specialist may know which supplier contact can resolve a difficult issue or which apparently harmless change affects another system. Capture the operational significance without putting private contact details into widely accessible documents.

Rank dependencies by consequence and urgency. Do not start by documenting every task the person performs. Start with the work that would cause the greatest difficulty during an unplanned absence, then expand as capacity allows.

Choose a real backup arrangement

A named backup needs the necessary skills, available time and authority. Assigning the role to someone already overloaded may satisfy a register without improving continuity.

For each critical activity, decide whether cover comes from another internal person, a supplier or a change that removes the specialised task. Some dependencies are better retired than taught to a second person.

In a fictional team, one engineer maintains a custom nightly transfer. A colleague can learn the restart procedure, but the longer-term answer may be replacing the transfer with a supported service. The succession plan should distinguish immediate cover from that later technical decision.

Avoid making the backup arrangement depend on shared credentials. Provide appropriate individual access and emergency procedures through the organisation's approved controls. Verify that the substitute can obtain access when needed rather than assuming the permission request will be approved during an incident.

An external backup also needs usable documentation and a commercial arrangement that covers the task. A supplier's general willingness to help is not the same as confirmed service coverage.

Pair the work, then change who leads

Begin with the experienced person performing the task while explaining the judgement involved. Ask the second person to write or improve the operating notes as they learn. That helps expose assumptions the expert no longer notices.

Then reverse the roles. The learner performs the task and explains their reasoning while the specialist observes. Record the points where they needed help and improve the notes or training.

Use safe environments and appropriately controlled exercises. Do not create a production incident merely to test the plan. For consequential operations, agree the scope, safeguards and recovery arrangements before starting.

Teach the conditions for stopping and asking for help. A useful procedure describes expected results, warning signs and escalation, not only a sequence of commands. A substitute who recognises that the system is behaving differently may be safer than one who follows every step regardless.

Protect time for the pair. If knowledge transfer is always the first activity cancelled, the organisation has chosen to retain the dependency. Make that trade-off visible through the capacity plan.

Test whether the service can cope

The test is whether another authorised person can complete the critical activity using the available materials, not whether a document exists.

Choose representative tasks and observe them. Can the substitute find the notes, understand the prerequisites, obtain access and confirm the result? Can they contact the correct escalation point if the expected outcome does not appear?

Record gaps without turning the exercise into a judgement of the learner. The point is to improve the system of support. A missing permission or outdated screenshot is a useful finding before an actual absence.

For tasks too risky to rehearse fully, use a tabletop exercise or a non-production test and state the limitation. Do not claim independent operational cover if only a discussion has occurred.

Review the evidence with the service owner. Risk ownership includes deciding whether remaining gaps are acceptable and how soon they need attention.

Keep the plan current without making it another burden

Succession work can become stale when the system changes or the backup moves roles. Add a knowledge and cover check to significant changes. The operating notes and access arrangements should change with the service.

Rotate occasional tasks where sensible so the substitute retains familiarity. Review coverage before planned leave, while keeping expectations respectful: leave should not become a period of unofficial on-call work because preparation was incomplete.

Give the specialist recognition for teaching and improving the service. If performance expectations reward only personal output, knowledge transfer will always look like time away from the real job.

The immediate goal is practical. Another person should be able to perform the most consequential tasks safely, and everyone should know which gaps remain. That makes leave easier to plan and gives the specialist room to develop beyond the work only they currently know how to do.