When a colleague leaves, they leave more than code behind. There are unresolved questions, reasons for earlier decisions and small operating procedures that never reached the documentation. A handover makes this context accessible to the person taking over.
Start with a map of responsibilities
List the departing specialist’s areas of responsibility and assign new owners. Distinguish routine work, operational interventions and changes in progress. A repository link is insufficient if nobody knows who approves a release or talks to the dependent team.
Record why things work this way
Alongside instructions, capture important constraints and open decisions. What is a temporary solution? Which option did the team reject, and why? Separate the verified current state from personal recommendations. The successor can then reconsider a decision without reconstructing the whole story.
Let the new owner try the process
Choose a representative activity, such as starting the development environment or preparing a change on a test branch. The person taking over performs it while the previous owner observes and adds missing context. Every point that needs a spoken hint reveals something to document. Check operational actions only in an appropriate, approved environment.
Finish with a specific agreement
Summarise what has been transferred, what remains open and who owns it. Review access changes with the responsible administrator; passwords do not belong in the handover document. Agree any follow-up support in advance, including its scope and availability. A good handover does not rely on a former colleague answering questions indefinitely in their own time.