DevOps Professional · Module 7: Incident leadership and handover
Handover Packages Someone Else Can Use
A handover succeeds when a stranger can operate the system next week. The package holds everything that currently lives in heads; the audit proves it by running from the package alone, and the gaps found are fixed before they matter.
10 min reading
Objectives
- Explain what a handover package holds: runbooks, maps, issues, contacts
- Audit a package by operating from it solo while the author watches
- Score gaps as gifts: every failure of the package is a fix before departure
- Keep the package alive with ownership and rehearsal dates
Why this matters
A senior engineer departs after a documentation sprint, and the successor discovers the runbooks describe last year's architecture, the contact list names departed people, and the known-issues page ends eighteen months ago. The package existed; it was archaeology, not operations. Handover quality is measured one way: someone else runs the system from the package while the author stays silent. The L69 lab audits exactly this; this lesson defines what passes.
Concepts
The package has five parts. Runbooks for the common incidents with symptoms, commands, mitigations and verifications, each rehearsed with a date. Ownership map: every component with its named human, no orphans. Known issues with workarounds that actually work, tried recently. Pending work with context, so the successor inherits direction as well as state. Contact paths: who to call for what, current, tested. Anything the author would ask in the first month belongs here; the test is whether they would need to ask at all.
The audit is a solo drill. The successor operates from the package while the author watches silently: triage a staged symptom with the runbook, find an owner from the map, follow a contact path. Every stall is a package defect, recorded without blame and fixed with priority. Passing means boring success; the drill finds nothing the package lacked. Schedule audits before departures force them, and after every major redesign, which obsoletes packages silently.
Currency is structural. Each part carries an owner and a review date; stale parts fail the audit automatically. Handover debt is tracked like tech debt: known gaps with owners and dates, visible on the team board. A package that passed last year and changed never since is a suspect, not an asset; systems move, and packages move with them or die.
Worked example
A fixture system ships a handover package to a peer operator. The audit drill stages two symptoms: the runbook resolves the first cleanly, the second stalls on a missing contact, and the gap is fixed same-day with the contact verified live. The package passes on re-audit with both resolutions quoted; the fixed gap is logged as the drill's value.
Common wrong move
Handing over access instead of understanding. Credentials and dashboards without runbooks, maps and rehearsal leave the successor equipped and helpless. Access is the smallest part; operability is the package.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
Audit a fixture handover package by operating from it solo, log every stall as a package defect, fix them, and pass re-audit with both resolutions quoted.
Pass criteria
The record shows the solo audit with stalls logged, the fixes with verification, and the passing re-audit quoted.