The short answer
The dip after someone leaves is proportional to how much only they knew. Reduce that continuously by pairing, reviewing and documenting, and the roll-off becomes an administrative event rather than a setback.
Handover in the last two weeks helps, but it cannot transfer six months of accumulated context. The work has to happen along the way.
The rule worth holding
No part of the system should be understood by exactly one person. Not the augmented developer, and not your own senior engineer either.
- Pair on anything new or complex, even briefly
- Rotate who works on which area rather than letting ownership harden
- Require a second reviewer on anything only one person understands
- Write decisions down where the reasoning lives, not only in chat
This is good practice regardless. Augmentation just gives you a known date by which it matters.
Documentation that survives
| Write down | Because |
|---|---|
| Why a decision went that way | The code shows what, not why |
| Anything outside the repository | Scheduled jobs and services get orphaned |
| Known fragile areas | Saves the next person weeks |
| How to run and deploy it | Assumed knowledge until it is not |
| What was deliberately not done | Turns unknown debt into a backlog item |
Documentation written as part of the work is accurate. Documentation written in the last week is a summary of what someone remembers.
The last two weeks
- Stop starting new work, finish or hand over what is in flight.
- Have your developer make a real change while the leaver only answers questions.
- Walk through the deployment and any operational procedure, with your person driving.
- Transfer anything in their name: accounts, keys, certificates, services.
- Capture the list of things they would have done next.
Step two is the test. Everything else is preparation for it, and if it goes badly you still have two weeks to fix the gap.
Plan the overlap
If someone is replacing them, overlap the two for a week or more. It costs one week of double rate and saves considerably more in ramp-up.
Where that is not possible, front-load the documentation and accept that the replacement will be slower for longer. Either way, decide deliberately rather than discovering it.
After they have gone
Expect a period where things take longer, and resist the urge to treat that as a failure of the handover. Some knowledge only transfers by encountering a problem.
Keep a note of what people had to work out afterwards. That list is the gap in your handover process, and it makes the next one better.