Covering a notice period

A senior engineer resigns. There is a notice period, which feels like enough time, and then it is the last week and nothing has been handed over because there was always something more urgent.

The risk is not the vacancy. Vacancies are manageable. The risk is that a body of undocumented knowledge walks out, and the systems it covered become opaque.

The first week matters most

The instinct after a resignation is to focus on hiring. That is the wrong first priority, because a replacement will take months to arrive and the knowledge is leaving on a fixed date.

Establish what only they know. Sit down with them and work through it honestly. The systems they are the only person for. The processes that run because they run them. The vendor relationships where they are the contact. The passwords and access nobody else has. The recurring tasks nobody else has ever done.

Ask directly: "If you were unavailable from tomorrow, what would break, and how long before anyone noticed?" People who are leaving tend to answer this candidly, and the answer is usually longer than the manager expected.

Rank it by consequence. Not everything can be handed over properly, and attempting to transfer everything evenly means nothing is transferred well. Concentrate on what would hurt.

Capture in the order that matters

First, access and credentials. Anything only they can log into. Administrative accounts, vendor portals, registrar and certificate accounts, licence portals, out-of-band management. These are quick to transfer and catastrophic to lose. Do them in week one.

Second, the things that would break silently. Scheduled jobs, scripts on their machine, manual monthly processes, monitoring that only alerts to them. Anything that runs without anyone thinking about it is invisible until it stops.

Third, the undocumented operational knowledge. The order services must start in. The system that cannot be restarted before a particular job completes. The application whose vendor support requires a specific patch level. Why that firewall rule exists.

This third category is where most of the value is and it is the hardest to extract, because the person does not think of it as knowledge. It is just how things are.

Fourth, relationships. Introduce their successor, or an interim contact, to the vendors and internal stakeholders they dealt with. A warm handover is worth considerably more than a contact list.

Get it out of their head efficiently

Asking someone to "write documentation" during a notice period produces either nothing or a document nobody can use. Better methods:

Walk through real work with someone recording. Have them do a routine task while a colleague watches and writes it down. The colleague asks the questions the person leaving would not think to answer, because they are the ones who do not know.

Have someone else do it while they watch. More effective still. The remaining engineer performs the task, the leaver corrects them. What gets corrected is exactly the undocumented knowledge.

Ask about the exceptions, specifically. "What is unusual here?" "What would surprise someone new?" "What have you had to explain more than once?" These questions surface more than any request for documentation.

Record short videos for anything visual. A five-minute screen recording of a process is faster to produce than a written procedure and often more useful.

Cover the gap while it lasts

Continuous work needs a real answer immediately. On-call rotas, monitoring, and out-of-hours coverage do not pause. Redistributing them across a team that is already stretched creates a second resignation risk, and that is a common way one departure becomes two.

Options, roughly in order of speed:

• Temporary external cover for the operational load. Fastest to arrange, and it protects the remaining team.
• Redistribute deliberately, with something removed. If work is shared out, something else must stop. Adding it on top is what causes the next departure.
• Promote or move someone internally, with support. Often overlooked, and internal candidates already know the estate, which is the slower half of the learning.

Project work should be paused or reassigned explicitly, not left to drift. A project quietly stalled for three months is a decision made by default.

Use the notice period to reduce single-person dependency

A departure is the clearest evidence you will get about where the concentration risk sits. It is worth acting on beyond the immediate handover.

For each system the person was sole owner of, name a new owner and a deputy. Two people, not one, or you have recreated the problem with a different name.

Where the answer is that no one else can own it, that is a finding worth escalating. It usually means the system is either more complex than it needs to be, or genuinely warrants a second person being trained.

The last day

• Every credential rotated, not just their personal account. Anything they knew, including shared and service account passwords.
• Access removed everywhere, checked against a coverage list rather than memory. Include third-party portals, which are the most commonly missed.
• Equipment returned and accounted for.
• Personal machine checked for anything work-related that lives only there: scripts, notes, keys.
• Forwarding and delegation reviewed, including any mail rules they set.

Afterwards

Keep a channel open if the relationship is good. Many people leaving on reasonable terms will answer a question a month later. That is not a substitute for handover, and it has saved a great many organisations from a problem they could not otherwise solve.

And note what was missing. The things you discovered only they knew, after they had gone, are the list of what to document before the next person leaves.