Handover craft · 5 min read
The 2am test: building a handover that works without you
The real measure of a good handover is not whether your manager is impressed. It is whether someone who has never met you, at an hour they would rather be asleep, can keep things moving without a frantic call. Here is how to build one that passes.
A good handover is not a trophy document you present at an exit interview. It is a tool that works in your absence. The simplest quality bar is the 2am test: would someone half-asleep, a little stressed, and completely new to your work be able to keep things moving without calling you?
If the answer is yes, you have done the real job. If the answer is "well, with a few questions," you have written a rough draft of a handover. Here is how to close that gap.
What is the 2am test?
The 2am test is borrowed from the world of on-call engineering, where runbooks are measured by whether they help a tired responder fix a problem at an unreasonable hour. Applied to handover, the test asks a slightly different question: can someone step into your role cold and make the next few decisions?
Notice the scope. A handover does not need to teach someone your entire job. It needs to give them the minimum viable context to keep things moving for the next week or two — until they have had enough time to build their own understanding. The 2am test keeps you honest about what "minimum viable" actually means.
The three questions someone at 2am needs answered
Strip a handover down to its bones and it only needs to answer three questions:
1. What is on fire right now? — What is due this week? What is blocked? What is waiting on a response that will not arrive unless someone chases it? What is fragile and likely to break next? This is the most urgent section and the one most handovers skip because people do not want to admit things are shaky. Admit it. The alternative is that the next person discovers it at 2am with no warning.
2. Where are the levers? — What systems, logins, dashboards, folders, and contacts does someone need to actually do the work? Not a list of every tool the company owns — just the ones your work depends on. For each one, include enough detail that someone can find it and use it: the URL, the account they need access to, the person who can grant that access. A single link with a note is worth more than three paragraphs of description.
3. Who knows what? — You carry a web of relationships in your head: the person in legal who reviews contracts, the ops person who knows why that one server acts up, the stakeholder who prefers a Slack message over email. That web is invisible to the next person and it is the thing they will miss most. List the five to ten people someone needs to know, and next to each name write one sentence about why. Not their job title — what they actually help with.
If your handover answers these three questions clearly, it already passes the 2am test for the first two weeks. Everything else is bonus.
Too much detail vs too little
The most common handover mistake is not too little information — it is too much of the wrong kind. A twenty-page document explaining the history of every decision, the architecture of every system, and the philosophy behind the team's approach is not a handover. It is a memoir, and nobody reads memoirs at 2am.
Too little detail looks like bullet points that assume knowledge: "Deploy the pipeline." To whom? From where? With what command? Is there a consequence if it goes wrong?
The sweet spot is one step more detail than you think you need, for the things you think are obvious. The architecture diagram can be a link. The deploy command should be pasted in full, with the directory you run it from and a note about what to check afterward.
A useful rule of thumb: write commands and steps as if you are leaving a note for yourself six months from now, when you have forgotten everything. That is roughly the mental state of the person receiving your handover.
The "runbook + context" pattern
The most reliable handover format pairs two layers:
- A runbook section — short, step-by-step procedures for the tasks that will come up in the first month. Deploys, approvals, reporting, the weekly thing that nobody else knows how to run. Numbered steps, pasted commands, explicit checkpoints. This is the layer someone reads at 2am when something needs to happen right now.
- A context section — the broader picture that helps the next person make good decisions. What is the team's current priority? What is the one project everyone is worried about? What decisions are pending and whose input is needed? This is the layer someone reads on a Tuesday morning when they are trying to understand what matters.
The two layers serve different moments. Keep them separate. A runbook with three paragraphs of context between every step is unreadable under pressure. A context document with commands buried in prose is useless for quick reference.
Testing your handover
The most reliable way to know if your handover passes the 2am test is to test it. Hand it to someone on your team — ideally someone who is not already familiar with your work — and ask them to find the answer to three specific questions, without asking you for help. Watch where they go. Watch where they pause. Every pause is a gap in your handover.
If you cannot test with a real person, test with a time gap. Finish your handover, close it, and do not look at it for three days. Then come back and try to answer your own three questions. The parts that confuse you are the parts that will confuse the next person.
The 2am test is not about perfection. It is about giving the next person a genuine running start. A handover that passes it is a quiet act of care — and it is one of the most useful things you will ever write for your team.
The skeleton that helps you write handover docs that pass the 2am test the first time.
Keep reading
Disclaimer: The Handover Folder is a documentation tool, not a secrets manager. Never paste credentials, tokens, or private keys into a runbook — reference them from your real secrets store.