The one engineer who knows the system has resigned. Spend the notice well.

The resignation arrives on a Tuesday. It is polite, it offers four weeks, and it comes from the one engineer who knows how the billing system really runs: which nightly job has to be restarted by hand when it stalls, why one large customer's invoices skip a step, where the payment provider's credentials live. Nobody planned for this, because planning for it always felt like a job for next quarter.

The reflex is to ask them to write everything down. By the afternoon there is a shared document called Handover. By the last Friday it runs to twenty pages, and the first time production misbehaves after they leave, the cause is on none of them. There is a better use of those weeks, and it starts with changing who does the work.

Why the handover document fails

An engineer writing documentation alone has to guess what a stranger will need, and they guess badly for an honest reason. Years of repetition have turned their most valuable know-how into habit, and habits do not come to mind when you sit down to make a list. They will describe the architecture well, because the architecture is what they think about. They will leave out the fact that a deploy only works if the cache is cleared first, because they have done it so often that it no longer registers as a step.

So reverse the direction. Knowledge transfer works when the person receiving it drives: they try to do the real job, get stuck, and ask. Every point where they get stuck is a gap a document would have missed, found while the person who can fill it is still on the payroll. The first decision is therefore not what the leaver should write. It is who receives the system, and whether they can start this week.

What changed: the code can explain itself now

Until recently, most of a handover was a guided tour of the code. What this module does, how a request travels through the system, where the business rules hide. That tour ate most of the notice period, and it was necessary, because reading an unfamiliar codebase cold took weeks.

It no longer has to. AI coding assistants can now read a codebase they have never seen, trace a request from the web endpoint to the database, and draft a plain-language account of what a tangled function does. They get things wrong, and a senior engineer has to check what they produce. But an experienced engineer working with one of these tools can build a working map of a mid-sized system in days, and arrive at the leaver's desk with sharp questions instead of a blank page.

That changes how the notice period should be spent. The leaver's hours are the scarcest thing you have. Spend them only on what the repository cannot tell you, and sort everything else into one of three kinds.

• What the system does. Recoverable from the code, the logs and the commit history. This is the successor's job, with AI assistance. The leaver checks the map; they should not be drawing it.
• Why it is that way. The reason behind the odd retry loop, the customer contract that explains a special case, the migration abandoned halfway through. This exists only in the leaver's head, and it is where most of their remaining time should go.
• What only they hold. Domain and DNS logins, cloud root accounts, signing keys, the vendor contact who actually picks up the phone, two-factor codes on a personal phone. No amount of questioning will reconstruct a password. These have to be transferred one by one, while the person holding them still works for you.

A four-week notice, week by week

Notice periods vary widely by country and contract. The plan below assumes four weeks. With less, compress it; with more, stretch it. Either way, keep the order, because each week depends on the one before. Each week ends with something you can check: a list, a completed run, a passing test, a recording.

• Week one: access and the map. Move every account to a company owner. List the scheduled jobs, the external integrations and everything that can wake someone up at night, and note the real date on which each recurring task next runs. The successor starts mapping the code with AI help and keeps a running log of questions.
• Week two: supervised runs. The successor deploys to production, restores a backup into a scratch environment and rotates a credential, each time with the leaver beside them and hands off the keyboard. Anything that cannot be done without the leaver's hands or login goes on a list. That list is the handover that matters.
• Week three: tests, then a day without them. Write characterisation tests around the parts that scare people most. These are tests that record what the system does today, right or wrong, so that later changes cannot alter behaviour silently. Then take the leaver offline for a full day and let the successor handle whatever comes up.
• Week four: answers, recorded. The leaver works through the question log and records short screen-share walkthroughs of the two or three tasks that are hard to put into words. On the last day, revoke their access the same way you would for anyone else.

Recurring work needs its own treatment, because it runs on the calendar rather than on your plan. If month-end, a quarterly report or a certificate renewal falls inside the notice period, rearrange the weeks so the successor does the real run while the leaver watches, even if supervised runs have to move earlier. If it falls after the last day, rehearse it: a dry run in the scratch environment using last month's inputs, with the leaver comparing the result against what production produced. Annual tasks rarely fit either way. For those, have the leaver walk through the logs of the last run and record the walkthrough.

The day offline feels awkward, because it means deliberately switching off your expert while you still have them. Do it anyway. Whatever goes wrong that day would otherwise go wrong a month after they left, with nobody to ask.

One more thing costs little and is often forgotten: offer the leaver a small paid arrangement for questions after they go, a few hours a month for a quarter. Most people are happy to agree, it is far cheaper than an outage, and it means the first awkward question after their last day still has somewhere to go.

Who should be on the receiving end

The receiver has to be senior. A junior engineer cannot yet tell an important answer from a trivial one, so they collect facts without building understanding, and they do not know which questions to ask. What you want is someone who has inherited unfamiliar systems before and has a feel for where the surprises usually are: the scheduled jobs, the configuration nobody committed, the integration with a partner who changed their API without telling anyone.

Plenty of companies in this position have nobody to spare. The remaining team already carries the roadmap, and the person resigning was often the slack. The honest options are these.

• Promote from inside and backfill. Best for continuity, if you have someone with the seniority and you genuinely take their other work away. A handover squeezed into spare minutes looks fine until the first incident.
• Bring in a senior engineer who stays. An embedded engineer receives the system and becomes its long-term owner. This suits a system that will keep changing, where you want the knowledge to live in someone who attends your stand-ups.
• Bring in a short recovery effort. A small team does the inventory, writes the characterisation tests and runbooks, and hands a tested, documented system to whoever owns it next. This suits a system that mainly needs to keep running, where the risk is the gap rather than the roadmap.

Often the answer is a mix: one person who stays, plus extra hands for the weeks of heavy lifting. Whichever you choose, the receiver's first day should start with the account list from week one, not with the architecture diagram.

If they have already gone

Sometimes the notice was a week, or the departure was unfriendly, or the author left years ago and the system has run untouched since. Recovery still works. It is slower, and it relies on evidence the system leaves behind.

• The cloud bill. Anything that runs gets billed, so the provider's invoice lists what exists whether or not anyone wrote it down. Start with the line items nobody can explain.
• The schedulers. Cron tables, scheduled functions, pipelines on a timer. Tasks that seemed manual are often half automated, with one human step in the middle.
• The commit history. Commit messages and linked tickets often hold the reasons nobody wrote down anywhere else. AI tools are good at summarising years of history for a single troublesome file.
• The shared mailbox and calendar. Through your normal HR and legal process, recurring calendar entries and vendor emails reveal duties and contacts: the certificate renewal, the quarterly reconciliation, the supplier who needs a call.

And ask the person anyway. A polite message offering paid time gets a yes more often than you would expect, even months later.

After the handover

Once the danger passes, the temptation is to get back to the roadmap. Use the momentum instead. A rule that holds up in practice: every system that would hurt if it stopped should have at least two people who have deployed it, restored it and been paged for it within the last quarter. Reading about it does not count.

Most companies find out which systems hang on one person from a resignation letter. The ones that sleep better find out from a drill they scheduled themselves.