Short answer
#The principle
A leaving developer has a finite and shrinking amount of attention for you, and it is competing with a new job, a handover to their replacement, and the natural human tendency to disengage from something that is ending. Plan for one good hour rather than forty.
So the only question that matters is: what can nobody else supply?
| What | Recoverable without them? | Ask for it? |
|---|---|---|
| Structure — components, dependencies, interfaces | Yes, from the system | No |
| Behaviour — what happens when a payment fails | Mostly, with effort | Only the parts an analysis flags as unknown |
| Reasoning — why it was built this way | No | Yes, first |
| Operational habit — what they check, what they ignore | No | Yes, second |
| Account ownership and access | Discoverable, slowly and painfully | Yes, and verify it yourself |
#Reasoning — the irrecoverable half
Ask these in writing. Written answers survive; a conversation both of you half-remember does not.
Six questions, in priority order
- Which part of this system would you be nervous about somebody changing, and why? The single highest-yield question available. It reliably surfaces the thing nobody would have found for six months.
- What did you try that did not work, and why did you go this way instead?
- What is here because of a constraint that no longer exists? Prevents a new team spending a quarter removing something that was load-bearing, or keeping something that is not.
- Which decisions would you make differently now?
- What did you want to do and never get approved?
- If you had one more month, what would you have fixed?
Why written
A recorded walkthrough is better than nothing and much worse than written answers. Nobody rewatches a two-hour recording, nobody can search it, and the person who most needs it has not been hired yet. Six written paragraphs get read.
#Operational habit — the 3am knowledge
This is the category people forget entirely, and it is the one that hurts on the first bad night after they have gone.
Six more
- What do you check after a deploy?
- Which alerts do you ignore, and which ones actually mean something? Without this, a new team either ignores everything or investigates everything. Both are bad.
- What breaks regularly, and what do you do about it?
- What has to be done by hand, and when? Monthly and quarterly manual steps are the ones discovered in month three.
- What is the thing you always have to explain to new people?
- What would you check first if the site went down right now?
#Facts that are faster to ask than to derive
A small number of factual questions are worth asking even though they could theoretically be established another way, because asking takes a minute and establishing takes a week.
- Is there anything running that is not in this repository? Scheduled tasks on a server, a cloud function created in a console, a script on their machine, a report they send manually.
- Who outside the company depends on this system? Partners, integrators, a customer with an API key. Nobody else knows this.
- Which outside services does it use, and whose account is each in? The second half is the part that is not in the code.
- Who else has ever had access to any of this? Former contractors, a friend who helped once, an agency from three years ago.
- Is there anything you would want a new person to be told on day one? An open-ended catch-all that is worth its place.
#Access, in the right order
The instinct is to revoke everything immediately. That instinct locks people out of their own systems.
-
Establish ownership first
For each account: is the owning identity a company address you control, or a personal one? Anything in the second category is a transfer, not a revocation.
-
Transfer what needs transferring
Domain, cloud organisation, registrar, app stores, payment provider. Several have multi-day processes and at least one will surprise you.
-
Create your own route in
Company-owned admin accounts on everything, with recovery going to a company mailbox. Verify each one works before the next step.
-
Then revoke and rotate
Personal accounts, personal tokens, SSH keys, anything on their machine. Treat every credential they could have seen as exposed — hygiene, not an accusation.
#What not to ask for
Do not ask them to write documentation. Three practical reasons:
- It takes days of their remaining time and produces what they remember rather than what is there.
- It is written under time pressure, by somebody who is leaving, for a reader who does not exist yet.
- Almost all of it is derivable from the system, at a cost of one instruction, by somebody who is not them.
The better move: derive the structural picture first, then send them the gaps as questions. Twelve specific questions get answered in a leaving week. "Please write documentation" produces a document nobody trusts and everybody feels bad about.
#What goes wrong
Waiting until the last week to start.
Instead Start the day notice is given. Attention is highest on day one and lowest on day thirty.
Asking open-ended questions in a meeting.
Instead Send a numbered list and ask for written answers with a date. Specific questions get specific answers.
Treating it as an audit.
Instead Frame it as continuity. Most people leaving want the thing they built to keep working, and will help if the request is not adversarial.
Forgetting recovery addresses on accounts.
Instead Check them on every account you cannot afford to lose. A company account whose recovery email is personal is not a company account.
Not asking what runs outside the repository.
Instead Ask it in exactly those words. People remember immediately when asked directly and never think to mention it otherwise.
#What this does not cover
What this does not do
- Employment terms, notice periods and anything contractual. Ask somebody qualified.
- What to do if they refuse to engage. Then everything that is a property of the system is still recoverable and everything that is a property of them is not — prioritise accordingly.
- Their replacement. This is about extracting what is leaving, not about onboarding what arrives.
- Code quality. A leaving developer is not the person to ask whether their own code is good.