When a Key Person Leaves: A Handover Plan, Not a Farewell

From the field: 30 days without a list

The first thing I did that morning was not planning. It was preparing a counteroffer. I spent four days talking salary ranges with HR. The offer was declined, politely and fairly. The decision had already been made. Those four days were the four days I needed most later.

On day five we sat down and wrote a list: the work they did that nobody else could fully do. It had eleven items. Four of them lived only with them; not one person on the team could say “I can do it if needed”. The most critical was end-of-day reconciliation: a nightly job that compares the file from the clearing side with our order records and reports any difference to the operations team.

In the remaining twenty-six days we held seven paired sessions, wrote four runbooks (step-by-step guides for a task) and handed over 23 access rights and accounts. On the last day we had a nice farewell lunch. I felt ready.

Nineteen days after they left, the reconciliation file did not arrive. The other side’s SFTP server had cut our connection. The reason: once a quarter they send an access confirmation email, and it had gone to the leaver’s closed work address. After five days with no reply, they removed us from their allow list. The file was 2 hours 40 minutes late, and the operations team did that morning’s reconciliation by hand.

That email was not on our list. It came once a quarter, and we had built the list by asking “what do you do every day?”. The mistake was not theirs. It was mine: for six years I never asked that question at all.

Week one: the knowledge map

You do not get the map by asking “what do you do?”. People describe what they do every day and forget what they do once a month, once a quarter, once a year. On the second attempt we used three sources:

• The calendar. The last twelve months, including repeating reminders. The quarterly email was not there, but a yearly certificate renewal reminder was. That told us what to look for in the second round.
• Inbox and channels. Requests in the last year that went only to them and to nobody else. Who asks them, and what do they ask?
• Ownership records. Code owned by a single name, scheduled jobs that run under a personal account, alert routing.

We asked four questions about each task. The table is not there to look nice. It is there to rank things: in thirty days you cannot hand over everything, so you have to choose what will be left incomplete.

TASK                        FREQUENCY  KNOWN BY  WRITTEN?  RISK
------------------------------------------------------------------
End-of-day reconciliation   nightly    1         no        HIGH
Clearing file format change 1-2 / year 1         no        HIGH
SFTP access confirmation    quarterly  1         no        HIGH  <- not on list
Commission table update     monthly    2         partly    MEDIUM
Old reporting service       2 / week   2         yes       LOW
...
TOTAL: 11 tasks, 4 with KNOWN BY = 1  (+ SFTP confirmation: added after the incident)

RULE: KNOWN BY = 1 and rare frequency goes to the top.
      Frequent work is already visible. Rare work is forgotten.

The map has a second benefit: it makes you decide what not to hand over. We did not hand over two of the eleven tasks. We decided to shut down the old reporting service within two months; it was not worth anyone learning. We turned the commission table update into a form that the operations team could use from their own screens. In a 30-day handover, the cheapest knowledge is the knowledge nobody needs.

For the other nine tasks we picked one person each and defined “done”: the new owner has done the task alone once, with the leaver out of the room. A written runbook did not count as done. A completed task did.

Paired work: they watch, you do

We ran the first two sessions the wrong way. The leaver did the work, and the engineer taking over watched and took notes. Both said “got it”. In the third session we switched roles, and the new owner got stuck three times in the first ten minutes: an environment variable, why one table was locked by hand, and which difference amount counted as “normal”. None of it was in the notes.

This is the forced version of the maths in the delegation post. Normally the cost of teaching can be postponed with “it is faster if I do it”. After a resignation it cannot be postponed. It just gets a deadline.

The person who stays writes the runbook

The leaver wrote two of the four runbooks. Both were well written, and both had the same problem: they were written for someone who already knew. “Check the difference”, they said, but not which difference was acceptable, because to the writer that was obvious.

The rule became: the new owner writes the runbook, the leaver reads and corrects it. Under every step there are three lines: what you are doing, how you know it went right, who you call if it goes wrong. The third line matters after the person is gone: “call them” is no longer an option.

Access and ownership: everything that breaks on the last day

Knowledge handover and access handover are different jobs. The first moves what is in a person’s head. The second removes the places where systems depend on that person. We tried to fit the second one into a single afternoon, and that is exactly where we missed the SFTP confirmation.

# Everything tied to a person moves to the team BEFORE the last day
[ ] Code ownership     : CODEOWNERS lines with a single name (3 services for us)
[ ] Scheduled jobs     : cron jobs running under a personal account
[ ] Alert routing      : alerts that go straight to them
[ ] Secrets / keys     : anything in a personal vault -> team vault
[ ] Vendor contact     : are they the "contact person" on the other side?
[ ] Recurring invites  : external meetings, confirmation emails
[ ] Account ownership  : domain, certificate, cloud account - whose email?

# The line we missed: "Vendor contact".
# The other side knew the old address, not the new one.

The lesson from the missed line is simple: the outside world does not know your org chart. Whoever is named in the other side’s records is who the system depends on. In the last week, an email should have gone to every vendor: “your contact is changing, the new address is the team address”. It did not.

What I told the team (and what I did not)

I told the team four days later, when the counteroffer was settled. In those four days of silence, three different stories went around: the company was shrinking, the team was being broken up, more people were leaving. None of them was true, but all of them came from my silence.

In the next conversation I said three things, in this order:

1. What is happening. They are leaving, the last day is this date, it is their decision and a good one.
2. What the plan is. The knowledge map, who takes over what, the schedule of paired sessions.
3. What I need from you. You have 26 days to ask them anything. Do not say “I will ask later”.

What I did not say: “There is nothing to worry about.” There was. The reconciliation job was going to be fragile for a while, and everyone knew it. Promising confidence you do not have is less convincing than showing a plan you do have.

My conversations with the leaver were separate. They wanted their remaining weeks to mean something; they did not want to feel like a “knowledge dump machine”. We talked about this openly in a one-on-one and gave their last two weeks a small but real piece of work. It helped the handover too: their head was still in the team.

The real lesson: make the list before anyone resigns

Bus factor is a rough measure: how many people have to leave before a piece of work stops? For our reconciliation job the answer was one, for six years. I knew it. Every year someone raised it in a retrospective, and I said “you are right, let us look at it sometime”. That person never took leave, never got sick and solved everything, so the risk was invisible. They were exactly the hero I described in the burnout post, and I was the manager celebrating them.

What I do now is not complicated. We build the knowledge map once a quarter, as if someone had resigned, from the same three sources. For every task known by only one person, a second person does it at least twice in the next quarter — one watches, the other does. The access list is reviewed on the same day.

We added one more test: the two-week leave test. Once a year, every person on the map is truly unreachable for two weeks. Every task that gets stuck in those two weeks goes onto the map as a risk line. It is a small rehearsal of a resignation, but in this rehearsal nobody leaves.

Two tasks still sit with one person. One is very rare; the other is that person’s special interest. We recorded both but did not bring them to zero. Zero is not an honest target. The target is to know which risk you are carrying on purpose. As the team grows, the map grows too — going from 5 people to 15, this was the thing that created the most work.

What to track

What did not work for me

• The counteroffer. I spent four days and nothing changed. Offering money to someone who has already decided usually just shortens the handover. Now I start the handover plan first; if there is something to discuss, it runs in parallel.
• “Write down everything.” In the first week I asked them to put everything they knew into one document. It was 14 pages, nobody read it, and the useful part was two paragraphs. Writing does not carry knowledge. The new owner doing the work does.
• Access handover squeezed into the last week. We left the list for the last two days. The forgotten line was forgotten right there. Access handover is week-one work.
• Telling the leaver “we will call you later”. It was a kind offer, and we called once. They were busy in their new job, and fairly so. A plan cannot depend on the leaver being reachable afterwards.

Checklist

Conclusion

That Monday meeting lasted 15 minutes. In the six years before it, I never found 15 minutes to talk about the same risk. Knowing the bus factor was not enough. I needed to act on it, and I did not, because the system worked — thanks to one person.

The 30-day handover plan worked; today three people can run the reconciliation job. But the plan was trying to pay six years of debt in one month, and it missed one line. The 2 hours 40 minutes of delay was the price of that missing line.

The test: if someone on your team said tomorrow morning “my last day is the 30th”, could you write down today what you would do in the first week? If not, your plan is just a farewell lunch.