"I'm leaving in two months," Nadia told the platform team. "And I hope we have an incident every week until then."
Nobody laughed. Léo, who had been on the team longest, put his coffee down. Sam, three months in, looked at the door.
"So that by the last two weeks," she went on, "I'm sure you've got the whole thing in hand. Without me."
The handover everyone does
Most departures follow the same script. The leaving lead spends the final fortnight writing. A wiki space grows to forty pages. There's a two-hour handover call, recorded, with a lot of nodding. Three weeks later the messages start — quick question, sorry to bother you — and none of them ask how something works. They ask whether something is OK.
That's the tell. The handover moved information. What the team actually depended on was the person: her access, her memory, her judgment calls. Nobody designed that dependency. It accumulated, one sensible "let me check with Nadia" at a time.
Nadia had two months, and she didn't want to spend them writing.
The list
The first session wasn't an explanation. It was an inventory, built from both ends.
The team wrote down everything they weren't sure about — every part of the infrastructure and the code they'd hesitate to touch alone, every alarm they'd forward rather than handle. Nadia wrote down everything she was responsible for, which turned out to be a longer list than anyone expected, including her.
Everything on either list was risk. But the two lists didn't match, and what sat on only one of them was riskier still. Some of what Nadia carried, the team didn't know existed: the certificate renewal that ran from her laptop, the Monday cost check she did by habit, the backup restore that only she had ever actually performed. And some of what the team feared wasn't on Nadia's list at all — parts she assumed were common knowledge, which meant, in practice, that nobody owned them.
They merged it into one list of parts, ordered by what would hurt most if it broke on a Friday night with nobody to call.
One part at a time
Then they worked down the list, and every part went through the same loop.
First, Nadia explained the part — how it worked, why it was built that way, what usually went wrong. Not a lecture: a walk through the real thing, with the team asking questions until they stopped having them.
Then they annotated it. For each piece, one question: does this depend on Nadia directly? Her credentials. Her two-factor device. A manual step only she knew to do. A decision everyone deferred to her by default. Each one got marked.
Then they devised tasks to detach every marked item — and this was the part that mattered most. The goal was never to move the dependency from Nadia to Léo. Moving it would only have created the next person everyone had to check with. The goal was to move it off people entirely: the renewal automated, the credentials in the shared vault with proper access, the manual step turned into a runbook or a scheduled job, the judgment call written down as a rule of thumb the team agreed with. Most of the automation ended up in CI — the one colleague that never leaves, never goes on holiday, does the job the same way every time, and does it where everyone can see.
Then they did the work — real tickets, planned into the sprint like any other work, not squeezed into Nadia's evenings.
Then they tested it again, with someone other than Nadia at the keyboard. Sam restored the backup. Léo rotated the credentials. If anyone had to ask her anything along the way, the part went back into the loop.
Only then did they move to the next part.
It was slower than writing a wiki. It was also the first handover Nadia had seen where the list of things that depended on her got shorter every week, and you could see it happen.
Then the incidents came
They did come, as incidents do. Not every week — but enough.
The first one, Nadia was in the channel and said almost nothing. The second, she found out about it in the review. By then, the team wasn't reading from the wiki. They knew what was happening, why the system was behaving that way, and where to intervene — because they had taken each part apart with her, cut the strings attaching it to her, and put it back together themselves.
That's what the line in the first meeting meant. An incident is a handover compressed into an hour: every decision the team will ever have to make alone, all at once, under pressure. If they can run one without looking over their shoulder, the handover has held. And you want to find out while you're still there to catch the fall — not three weeks after you've gone.
The loop, in short
Inventory from both ends — what the team is unsure of, and what the leaving lead actually carries. Both lists are risk; what appears on only one of them is the riskiest of all.
Explain each part on the real system, until the questions stop.
Annotate every direct dependency on the person — access, memory, manual steps, default decisions.
Detach, don't transfer. Automate, share, write down. A dependency moved to a successor is still a dependency.
Do the work as real work, planned and visible.
Test it again without the lead, and send anything that needed them back through the loop.
Don't wait for the leaving drinks
Nadia had two months' notice. That's the luxury version.
Someone will leave. It's never a question of if, only of when — and most departures don't come with two months of warning. A resignation with a fortnight's notice, a long illness, a parental leave that starts early, a recruiter with a better offer. The dependencies Nadia spent two months cutting had been accumulating for years, quietly, every time a script lived on a laptop or a fix was done by hand "just this once".
So the loop works best when it never stops. Foster a culture of automation and tooling that doesn't rely on any specific person: if it runs, it runs in CI; if it's a secret, it's in the shared vault; if it's a decision, it's written down. Treat every "only she knows how" as a bug, and fix it the week you find it — not the month someone hands in their notice.
Done that way, a departure stops being a project. It's just a Tuesday.
The honest tension
This only works if the team is given the time. Two months of detaching work competes with the roadmap, and the roadmap usually wins unless someone with authority protects the space. A leaving lead can ask for that. They can't guarantee it.
And there's a harder limit: you can only detach what you owned. If the real decisions — scope, architecture, timelines — were always made above you, no amount of runbooks will hand them to the team. Sometimes leaving well also means naming that plainly, to the people who hold that authority, before you go.
The measure of a handover isn't how much you wrote down. It's how short the list of things that depend on you has become — and whether the team has already proved it, while you were still in the room.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.