The resignation you fear is the one from the person who understands the part of the system nobody else does. In India that arrives with a notice period — often thirty days, sometimes sixty or ninety — which is genuinely generous compared with many markets and is still less time than it feels like once you subtract handover of current work, leave they will take, and the disengagement that follows any resignation.
The instinct is to ask for a handover document, and it is a weak instrument. What gets written is a description of the systems, which is the part that can be reconstructed by reading code. What leaves with the person is different: why things are the way they are, which parts are fragile, what was tried and abandoned, which customer has the unusual configuration, and what happens at three in the morning when a particular alert fires. Documents rarely capture that because the author no longer notices it is unusual.
Pairing works better than writing. Have someone shadow them through real work for the notice period — not a walkthrough, but the actual tasks: a deployment, an incident, a support escalation, a monthly job. The knowledge that matters surfaces as a running commentary on things going slightly wrong, and it transfers to a person rather than to a file. If you get one thing from a notice period, make it this.
Prioritise by risk rather than by breadth. In the first days, establish and remove the single points of failure: credentials held personally, accounts registered to their name or personal email, a domain or certificate only they can renew, a payment method that is their card, a system where they are the only administrator. That work is unglamorous, takes hours rather than days, and is the part that turns a difficult departure into an emergency if it is skipped.
Then write the runbooks together, for the things that will actually be needed — deploy, roll back, restore, run the monthly process, handle the top three alerts — and test each one by having the remaining person execute it while the leaver watches without helping. Every place they have to intervene is a gap in the runbook, and that is the only reliable way to find them. A runbook written and never executed is a document that will fail on its first real use.
The broader lesson is that the moment to prevent this is not when someone resigns. Rotating who handles incidents, requiring more than one person on production access, and treating any system with a single knowledgeable owner as a risk on the register — these cost a little continuously and remove the crisis entirely. The team that handles a key departure calmly is not the one that ran a good handover; it is the one that never had a single point of failure to hand over.
