A Knowledge Transfer Plan

A short plan for the weeks before an engineer leaves: the systems only they can explain, the work still open, and who reviews that path next.

A knowledge transfer plan is the list you write when someone is leaving and the overlap is already short. The generic version asks for a handover document, a password export, and a meeting. The person who has to review the billing job next month needs something narrower: the systems only this person could explain, and a named person who will review them next.

Write it with them, before the farewell. Two weeks is enough if you spend it on those gaps. A month of overlap spent on status updates is not.

The plan

knowledge-transfer.md

# Knowledge transfer: Name, last day YYYY-MM-DD

## Systems only they can explain
- System. The one constraint. Who takes review.

## Still open
- Pull requests and incidents, and who picks them up.

## One change someone else will ship
The path, the person, and the date.
This is the test that the transfer happened.

## Where the notes live
Link the decision, the postmortem, or the runbook.
Do not paste a second copy here.

A filled-in example

knowledge-transfer-priya.md

# Knowledge transfer: Priya, last day 2026-04-10

## Systems only they can explain
- Nightly billing. The job must not run on two servers. The lock
  is held by the database connection. Sam takes review on app/Jobs/.

## Still open
- Alert if the job skips. Not started. Sam decides if it is needed.
- Refunds stay with the billing team. Support already knows.

## One change someone else will ship
Sam adds the skip alert, or closes the ticket, by 3 April.
Priya reviews it.

## Where the notes live
postmortems/2026-03-02-double-billing.md
docs/adr/0007-advisory-lock-on-billing.md

What to leave out

An inventory of every repository they have touched is a catalogue, and catalogues do not get opened during a review. Passwords belong in the access tool. A recorded walkthrough helps only if someone can find the minute that mentions the lock. If the recording is the only copy of the constraint, write the constraint down as well. The recording will not show up on the next pull request.

Leave the constraint on the system

Prodigent keeps the note on the system, so the person who takes over is not depending on a handover doc they have to remember to open.

Try Prodigent free