What do you do when important knowledge walks out of your company? Maybe someone retires or makes an unexpected job change. If the time comes to hand off the care of an important system to someone new, are you ready for that kind of transition?
One person knows how your software really works.
You do not need to document every line of code. But you do need a clear, tested route for another capable person to understand the system, gain the right access, perform routine work, and know when to ask for help.
Start with the work, not the technology
A server diagram can be useful, but it does not explain why the system matters.
(Who actually looks at those things anyway?)
Begin with the work people depend on. Perhaps the application registers families for a program, calculates membership fees, schedules volunteers, or produces information staff need every morning. Write down the handful of workflows that would cause real difficulty if they stopped.
For each one, record:
- who uses it
- what outcome they need
- when it is time-sensitive
- what other services it depends on
- what people do if it is temporarily unavailable
This gives a future developer the context needed to make responsible decisions. It also helps leaders see that continuity is not merely an IT concern. If a failed import prevents staff from serving people, the organization owns that problem even when a vendor maintains the code.
NIST's contingency-planning guidance begins from a similar premise: understand the systems and processes that support essential functions, then set recovery priorities. A small organization can apply that principle without having to create a whole disaster-recovery department.
Name the owners
Custom software usually needs more than one kind of ownership.
The service owner decides what the system should accomplish, weighs competing needs, and accepts or escalates operational risk.
The technical owner understands how the system is maintained and can coordinate changes, incidents, and technical suppliers. Other people may own data, privacy, finance, or a particular business process.
This is particularly relevant in larger organizations, such as higher education or health institutions where a significant number of departments may all have processes they rely upon.
Or in the case of a small team, one person may fill several roles. What matters is that the responsibilities are named and that each owner has enough authority to act.
AWS's operational guidance recommends assigning owners to procedures, keeping those procedures in a central location, and updating them as the environment changes. It specifically identifies knowledge held by only a few people and instructions scattered across individual machines as warning signs.
The point is not bureaucracy, but to make responsibility transferable.
Record a primary and backup person for each important responsibility. Include outside suppliers, but do not let “the agency handles it” be the entire plan. Someone inside the organization should know what the supplier is responsible for, how to reach them, and who can approve urgent work.
Create one stewardship file
You may already have fragments of the information you need in contracts, password managers, repositories, ticket systems, and old email threads. Do not begin by moving everything. Create a short stewardship file that tells an authorized person where to look.
It should answer six questions.
1. What does this system do?
Describe its purpose, important users, critical workflows, and expected hours of operation in plain language. Link to deeper requirements or diagrams if they exist.
2. Who is responsible?
List the service owner, technical owner, backup contacts, support provider, and the person authorized to approve spending or emergency changes. Include how to reach them through organizational channels.
3. What does it depend on?
Identify hosting, domain names, source-code repositories, databases, email or payment services, scheduled jobs, and important integrations. Note which organization owns each account and when contracts or certificates renew.
(The number of times I've needed to go on a digital safari to find who actually owns the domain the business needs... The pain is real.)
4. How is access managed?
Do not paste passwords or recovery codes into the file. Record which approved password manager or access system holds them, who can grant access, where multi-factor authentication recovery is controlled, and what happens when someone leaves.
This is also a good moment to notice accounts registered to a former employee's personal email address. Finding that during a calm review is much nicer than finding it during an outage.
Where possible, this is a great opportunity to transition email addresses to "positional" addresses instead of personal-name addresses. A lot of transition grief can be avoided if the important emails still get to "donors@yourorg.com" even after a key employee moves on.
5. How is routine work performed?
Link to short instructions for recurring work: deploying a release, checking a failed process, restoring a backup, renewing a certificate, or responding to a common support problem.
A useful runbook states the expected result, required permissions and tools, the steps to follow, common failure points, and where to escalate. That is the practical minimum recommended by AWS's runbook guidance.
6. What remains uncertain?
Record known risks, unsupported components, incomplete documentation, and decisions the team has deferred. A candid gap is more useful than a polished document that implies everything is under control.
Keep this file in a shared location that the relevant people can find without asking the usual expert. Give one person responsibility for reviewing it after important changes and at a modest recurring interval.
Test the handoff before you need it
Documentation can look complete while depending on assumptions that exist only in the writer's head.
Choose one routine, low-risk task and ask the backup person to perform it using the written instructions. The usual expert may observe, but should resist quietly supplying every missing step. Note where the reader hesitates, lacks access, or cannot tell whether the result is correct.
This is especially necessary in the age of AI. AI-written materials give the appearance of completeness until you actually try to follow its instructions. Only then do you discover just how much generated content is in that document.
AWS recommends validating procedures by having someone other than the author perform them. This small rehearsal tests more than prose. It reveals missing permissions, unclear ownership, unavailable tools, and steps that have quietly changed.
You can also rehearse a decision rather than a technical procedure. If an integration stopped sending records tomorrow, who would assess the effect on users? Who could authorize an investigation? Who would speak with the vendor? Who would tell staff about the workaround?
The answers expose whether your organization has a genuine continuity plan or merely a knowledgeable person.
Keep the scope humane
The phrase “we need documentation” can produce a project so broad that nobody begins it. Aim first at the paths that matter most.
Document the system's purpose, the people and access required to care for it, and the procedures whose absence would stop or seriously burden the organization. Add depth when a real task, incident, or handoff shows that it is needed.
This work also makes outside help more effective. A new developer still needs time to understand an unfamiliar codebase, but they can begin with the right priorities, contacts, environments, and known risks. They spend less time reconstructing the organization from clues.
For your next operational meeting, choose one custom system and ask: If our usual expert were unavailable for two weeks, what would we be unable to do?
Write the answers in a single stewardship file. Then choose one safe procedure and let the backup person try it. The gaps you discover will give you a practical documentation plan, and one that is grounded in the work your people actually need to continue.
This is basically a freakout-prevention plan. By gradually filling out your runbook over time, it might be mostly defined by the time you actually need it.
Future You will thank you.
