The Quiet Fortnight: Handover Notes That Work When the Office Is Empty
Photo: Jules Verne Times Two, CC BY-SA 4.0, via Wikimedia Commons
There's a particular flavour of mid-December in a UK engineering team. The sprint winds down, the change freeze lands, and somebody suggests one last deploy “while everyone's still around to fix it”. Then the office empties, the on-call rota thins to two names, and the person holding the pager is a backend developer who has never once opened the payments service.
Handover documents are usually written for the person who wrote them, which is a bit like leaving directions to your house in your own handwriting, using landmarks only you notice. The test is different: can a competent colleague, slightly tired, at half eleven at night, with a mug of tea going cold, work out what's wrong without ringing you?
The five-minute rule
If a reader can't get oriented in five minutes, they'll stop reading and start phoning people. So the first job isn't completeness, it's speed. Two sentences on what the thing does for the business, in plain English. Then a line on what actually happens if it stops — and be honest about whether that's a “nobody notices until Monday” problem or a “phone the supplier now” problem.
Everything after that is reference material, and it should be arranged so that the panicking reader can jump straight to the bit they need.
Five things worth writing down
Where to look. Dashboards, log queries, the health endpoint, the queue depth metric nobody remembers the name of. Give each one a link and a person who owns it. Links rot, so date them.
What it depends on. Third-party APIs, message brokers, feature flags, licences, DNS records and — the classic — anything with an expiry date. December has a habit of surfacing the TLS certificate that was renewed in a hurry last January and forgotten about since.
What's already broken. Known landmines deserve a section of their own. The integration test that fails one run in five. The cron job that logs a scary stack trace every night and has done for two years. Writing this down doesn't make you look bad; it stops someone else spending an hour on a problem you already know is a non-problem.
Who to call, in what order. Names, not roles. Times, not “out of hours”. And define what waking someone up actually means — a Slack DM is not an escalation, a phone call is. Include the supplier's support number and your account reference, because that's the one thing people can never find when they need it.
What not to do. This is the most valuable section and the one most often left out. The restart that drops the queue. The cache flush that takes twenty minutes and looks like an outage. The rollback that won't work because a migration has already run. Negative knowledge is expensive to acquire and cheap to share.
Leave things out, on purpose
Don't paste the architecture diagram. Don't link to the wiki page that was last accurate in 2023 — a dead link is worse than no link, because it teaches the reader to distrust the document. Don't write the novella version. A runbook nobody finishes is a runbook nobody reads, and a stale runbook is a trap with good formatting.
Keep the whole thing to a couple of screens. If a detail matters, it can live behind a link in a second document, but the top level has to be scannable at a glance.
Give every page a date and a name
“Last verified: 18 December 2026, by Priya.” One line. It tells the reader how much to trust what's below it, and it quietly shames everyone into keeping the thing current. A runbook with no owner is a rumour.
Test the handover before you log off
Write it, then use it. Ask someone outside the team to answer three questions using only the document: how would you know if this is healthy, how would you find out what changed yesterday, and who would you call first? If they have to ask you a follow-up, that's a gap, and finding it on the 19th is a great deal cheaper than finding it on the 27th.
Then do a short walkthrough of one plausible failure — a queue backing up is usually a good one — with whoever is actually on call. Fifteen minutes. Check the rota is genuinely filled, not “probably filled”. Check the escalation numbers ring through on a mobile, not just a desk phone. Check the dashboard links open on a laptop without VPN, because the first thing that happens in an incident is that someone can't get in.
Kindness is a schedule, not a sentiment
None of this is heroic. The point is precisely to remove the need for heroics. Book the handover session in November, when the calendar still has gaps in it. Freeze changes you don't need. Write the short document instead of the perfect one. Then shut the laptop and go and eat something.
The goal was never a team that can fix anything on Boxing Day. It's a team that doesn't have to.
