Succession planning for a system one person understands

Succession planning for a system one person understands means converting single person system knowledge into written runbooks, shared credentials and a rehearsed deputy. The mechanism is simple: inventory what exists, capture the critical steps, have a second person shadow real operations, then prove it works with a game day — before the notice period runs out.

Key Takeaways

• Single person system knowledge is a measurable exposure — the bus factor. One is the most dangerous number in operations.
• Inventory first: every system, server, domain, repository, credential and third-party account, each with a named owner.
• Write runbooks, not manuals — exact commands, expected output, backup locations, dated and kept beside the code.
• Give a deputy real repetitions on live work; reading alone transfers almost nothing.
• Verify with a game day: a supervised drill where the deputy restores, redeploys and decides alone.
• Move account ownership to the organisation before notice ends, and revoke personal access tokens.
• If the system is small and brittle, replacing it can beat documenting it — decide deliberately, not by default.

What does single person system knowledge actually mean?

Single person system knowledge is the detail that lives in one head: deploy commands, server quirks, credential locations, the reasons behind odd rules. Engineers measure the exposure as bus factor — how many people must vanish before work stalls. A bus factor of one means your recovery plan is, in practice, one person answering the phone.

The knowledge splits into two kinds. Explicit knowledge is written down or deducible from the code. Tacit knowledge — which alert to ignore, which job must never run twice, which registrar holds the domain — exists only as memory, and succession planning is the work of moving it into artefacts a stranger could follow.

Why does one-person system knowledge become a production risk?

Knowledge held by one person fails three ways: the person leaves, the person is unreachable during an incident, or their memory drifts from what production actually runs. Drift is the quiet one — systems change weekly, recall does not. The damage shows up as recovery time: a restore an informed team does in half an hour can take days.

The failure mode is rarely dramatic. It looks like a certificate expiring on a Sunday, a payment job that silently stopped in March, or a database only one person knows how to restore. The first hours of those incidents are always archaeology, and archaeology is exactly what a plan removes.

When should you act — and when can it safely wait?

Act now when the system earns revenue, holds customer or personal data, or changes without written steps. A static brochure site on managed hosting can wait; a booking platform one contractor deployed cannot. Rank systems by blast radius — what stops if that person disappears tonight — and by departure risk such as contract end dates.

Blast radius is how far a failure reaches. Define it per system in one sentence: "if this stops, online orders stop." If you cannot name the owner of a system within five minutes, that system is already a risk, whatever it does.

How do you build a succession plan in four weeks?

A workable plan runs in four passes: inventory the estate, capture the critical steps in writing, have a deputy shadow live operations, then verify with a supervised game day. Documentation alone fails, because tacit judgement — which alert matters, which command is safe to repeat — only transfers while someone watches real work happen.

1. Inventory everything. One afternoon, one spreadsheet: systems, servers, domains, repositories, third-party accounts, scheduled jobs — each with an owner and a blast-radius note.
2. Move access to the organisation. Shared password vault, company email for registrations, no production credentials on personal accounts.
3. Write runbooks for the top three risks first. Exact commands, expected output, where backups sit, what never runs twice. Dated, kept beside the code.
4. Describe infrastructure in code where it pays. If a server can be rebuilt from Terraform, OpenTofu or Ansible, a stranger can rebuild it; Terraform's state documentation explains how the code tracks real resources.
5. Give the deputy real repetitions. The next deploy, backup check and certificate renewal: they type, the current owner watches and stays quiet.
6. Run a game day. Restore a recent backup to a scratch machine and let the deputy work alone. Log every hesitation — each is a runbook gap.
7. Repeat quarterly for the next tier down. Succession is a rota, not a document.

What should you capture first?

Capture access and recovery paths before anything else, because they unblock every other task. In order: logins and where they live, backup locations with a tested restore, deploy and restart commands, infrastructure described in code, then the business rules behind odd behaviour. Diagrams come last — a restart command saves more incidents than a tidy picture.

A common mistake we see is starting with architecture diagrams. They age badly and answer questions nobody asks at 2 a.m. The order below is the one we actually use.

How do you prove the handover actually worked?

Prove it with evidence, not assurances. The test: a second person completes a full cycle alone — deploy a small change, restore a recent backup to a scratch machine, renew an expiring certificate — without messaging the original engineer. Time it. Every hesitation or wrong turn marks a missing runbook step; fix the runbook the same day.

This is also where new hires benefit. The same runbooks that de-risk a departure are the fastest onboarding material for a new engineer: they learn the system by doing the drills, not by reading a wiki that stopped being true in March.

What goes wrong during a handover — and how do you fix it?

Handovers fail in predictable ways, and each has a cheap fix. The documentation is written once and rots; the deputy never does real work; credentials turn out to be personal; the owner's memory has drifted from production. Debug with evidence: if a runbook step fails during rehearsal, correct the step in the same commit rather than blaming the reader.

• The runbook rots. Fix: runbooks live in the repository and change in the same pull request as the code they describe.
• The deputy only ever reads. Fix: rotate who handles live operations each month, even for small changes.
• Personal accounts surface late. Fix: audit registrars, consoles and app stores during the inventory, not during the exit.
• The owner's memory has drifted. Fix: treat every game-day surprise as a finding about the system, not a failure of the person.

What does succession planning cost in time and effort?

Budget it in engineer-days, not currency: the first pass costs the departing engineer roughly a day per critical system, plus the deputy's shadowing time. Keeping it current costs minutes per change, folded into the change itself. Weigh that against an unplanned rebuild — weeks of contractor archaeology while orders, bookings or reports sit still.

For systems you would rather not document yourself, an arrangement such as managed maintenance with documented runbooks moves the bus factor from a person to a team. For a small business with no second engineer to train, that is often the right answer.

How do you keep credentials and access safe through a handover?

Move credentials into a shared password manager before anyone resigns, and hold account ownership at the organisation level — registrar, cloud consoles, repositories, app stores. GitHub, for instance, lets you transfer a repository between accounts with issues and history intact. Then review who can reach production, revoke personal tokens, and check where backups replicate.

Departure day has its own sequence — revoking sessions, rotating shared secrets, forwarding business email. Our offboarding checklist for system access covers the steps; the short version is that access is easiest to remove the day you remember it exists.

Which mistakes sink most succession attempts?

The commonest mistake is writing a manual nobody reads instead of runbooks people can follow. Close behind: documenting how the system was built rather than how it is operated; capturing everything during notice and nothing after; and declaring the handover done when the PDF ships. If rehearsal is not scheduled, the plan is not real.

Two smaller traps: runbooks with no expected output, so the reader cannot tell success from failure; and credentials shared verbally "to save time", which undoes the vault work in one message. A useful rule: if a step cannot be rehearsed, it is not documented yet.

Your contractor resigns on a Friday: a realistic scenario

Picture the version we meet most often: a two-person business, a booking system one contractor built and ran for three years, and a resignation email on a Friday. Without a plan, the next weeks become archaeology — which server, which registrar, which database password. With a plan, day one is a checklist and the contractor documents while serving notice.

A realistic composite: in week one the inventory finds the domain parked in a personal registrar account and the only backup syncing to a laptop. Both get fixed cheaply, because the plan surfaced them. By week four a barely-known deputy passes the game day — restore, redeploy, renew — alone, and the leaver leaves with nothing unique in their head. That pattern, inventory first and drama later, sits behind most takeover work in our portfolio.

Document it or replace it? Comparing your options

Choose documentation when the system works, fits the business and would stall operations for months if rebuilt. Choose replacement when the system is small, poorly understood and cheap to recreate — a one-week rebuild beats months of archaeology. Most real cases are hybrid: capture the critical paths now, then plan a staged replacement without deadline panic.

In short: single person system knowledge is a scheduling problem, not a personality problem. Inventory the estate, write runbooks beside the code, give a deputy real repetitions, verify with a game day, and move ownership to the organisation. Done in advance it costs days; done after the farewell email it costs months.

People also search for

• How do you write a user manual for an internal system?
• What happens to a web system when a key person leaves?
• When should a legacy system be replaced rather than documented?
• How does a parallel run make a system handover safer?
• How do you train staff on a system they did not build?
• Is custom software harder to hand over than off-the-shelf tools?

If the notice letter has already arrived, our team can help: we take over undocumented systems, write the runbooks, move accounts into your name, then run it or hand back something your own team can operate. Our software team handles custom systems end to end — contact us for a review, and you keep the written plan whether or not you hire us.