Handing Back Ownership and Documentation

Handing Back Ownership and Documentation is the part of a rescue that determines whether the work survives the invoice. Ownership is not transferred by a meeting or by a document set. It is demonstrated, by the team, doing the things ownership consists of, while you are still there to watch it go wrong.

Key takeaways

• Handover is a list of demonstrated capabilities with dates and names, not a document pack. Six demonstrations cover most systems, and each one is performed by the team while you stay quiet.
• Start in week two. A handover written in the last week is written for the person leaving, and it shows.
• Write down decisions, not descriptions. An architecture decision record survives refactoring; a document describing how the code works is wrong within a month and nobody updates it.
• Runbooks earn their place only when they are executed from during a real event. An untested runbook is a liability, because it is trusted at the exact moment nobody has capacity to check it.
• Naur's argument sets the ceiling: a theory transfers through contact, not through documents. So the handover is scheduled contact, and the documents are what makes the contact efficient.

Read this beside Chapter 8, which built the relationship this depends on, and Chapter 10, whose release path is the first capability to be demonstrated. Chapter 12 asks what would stop this happening again.

The handover meeting is scheduled for the last Thursday. Someone has produced a document pack: an architecture overview, a deployment guide, a list of known issues, a diagram that was accurate three weeks ago. It runs to a hundred and forty pages. Everyone thanks everyone.

Six weeks later, the first incident arrives at two in the morning. Nobody opens the pack. That is the standard outcome, and it is a design failure rather than a failure of diligence.

Ownership is six demonstrations

Replace the document pack as the definition of done with a list of things the team does, unaided, in front of you, with the date and the name recorded beside each one.

They release to production, using the path from Chapter 10, with the newest person driving. They diagnose an incident end to end, with you present and silent, in a real event rather than a simulated one where possible. They restore from a backup into a scratch environment and confirm the data is intact, which is the check most teams have never run. They change something inside the tested perimeter and ship it, so the net is exercised by its owners rather than by its author. They onboard a new engineer to a first merged change, which is the only real test of the getting-started documentation. They run a postmortem, in the blameless form from Chapter 8, and produce an action with an owner.

Six items, each with a date and a name. That list is the handover artifact. It fits on one page.

What makes it work is that each item fails visibly. A team that cannot restore from backup discovers it in a scratch environment on a Wednesday rather than during a real loss, and the discovery becomes work with two weeks still to spend on it. A document pack cannot fail. That is exactly what is wrong with it.

Start in week two, not in the last week

The handover is a schedule constraint on the whole engagement, not a phase at the end of it.

Anything written in the final week is written by someone whose attention has already moved, for readers who are not yet asking the question. What survives is written during the work: the decision recorded on the day it was made, the runbook written during the incident it describes, the diagram drawn to answer a question someone actually asked.

There is a sequencing rule that makes this concrete. From week two, every repair is performed by a member of the team wherever it is possible, with you pairing rather than delivering. That is slower per repair and it is the only mechanism that transfers anything. Naur is unambiguous on this point: a theory of a program is acquired through working contact with people who hold it, and reconstruction from documentation alone is, in his words, strictly impossible. If the theory you are building during this rescue lives only in your head when you leave, you have recreated the condition you were hired to fix.

The pairing also produces the honest version of the capability list. You will discover in week four that one person is the only one who can do three of the six things, and there is time to change that. Discovering it in the last week produces a note in a document instead.

Write decisions, not descriptions

Documentation effort on a rescue should be spent almost entirely on why, because the what is already in the code and the how changes weekly.

Architecture decision records are the right instrument, and they are cheap. As the ADR community describes them, a record captures a single decision and its rationale, and the lightweight format is credited to Michael Nygard's 2011 post. One file per decision, in the repository, with the context, the decision, the alternatives considered, and the consequences. Ten to twenty of them cover the significant calls made during a rescue, including the five-outcome verdicts from Chapter 4 and the perimeter drawn in Chapter 6.

The reason to prefer them over an architecture document is durability. A description of how the system works is stale within a month and nobody updates it, because updating it produces no visible benefit to anyone. A decision record does not go stale, because it describes a moment. Later decisions supersede earlier ones by reference rather than by editing, which leaves the history intact.

The other document worth the effort is the why column from Chapter 3, converted from a worksheet into something permanent and kept in the repository. Its blank cells are as valuable as its filled ones: they tell the next person which questions remain open, which is information no other artifact carries.

Everything else gets a hard test before it is written. If nobody will read this during an incident or during an onboarding, it is not documentation, it is a deliverable.

Runbooks are only real if they have been executed from

A runbook is a procedure someone follows under stress, which makes an untested one worse than none. It is trusted at the exact moment nobody has the capacity to verify it.

So write them from real events rather than from imagination. During an incident, somebody who is not driving writes down what the driver actually does, including the dead ends. Afterwards, that becomes the runbook, and the postmortem action is to have someone else execute it from during the next occurrence. Google's postmortem practice supplies the surrounding discipline, which is that the output of a review is an owned action rather than a description.

Keep the set small and current. Five runbooks that are exercised beat forty that are not, and every runbook needs a last-executed date visible at the top. A procedure last run eight months ago should be read as a hypothesis about the system rather than as instructions.

The natural set on a rescued system is short: how to release, how to roll back, how to restore data, how to rotate the credentials you found in the wrong place, and how to respond to the failure mode that produced the most incidents during the engagement.

Hand back the numbers, not just the system

The team is inheriting a set of measurements as well as a codebase, and those need an owner as explicitly as the code does.

Deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate, in DORA's current definitions, have been the instrumentation of this whole rescue. Name the person who publishes them weekly after you leave, and put the publication in a place with an audience, because a metric with no reader stops being produced within a month.

Hand over the error budget arrangement from Chapter 5 the same way, including the objective and who may spend it. That arrangement is what stops the next delivery pressure from silently reintroducing the trade that caused this, and it only survives if a named person has both the number and the standing to hold the line.

One caution about targets. The moment these numbers become an individual performance measure, they stop being diagnostics and start being managed, which is a slower and more expensive way of losing the instrumentation than simply forgetting to publish it. Say that out loud to whoever inherits them.

When the team cannot take it back

Sometimes the six demonstrations do not pass. Not through unwillingness. The team is two people, both new, and the system needs four to run safely.

Say so early and say so in writing. A handover into a team that cannot carry the system is not a handover. It is a delay with a ceremony attached, and the next incident becomes an emergency because the capability was recorded as present when it was not.

There are three honest responses, and the choice belongs to the owner rather than to you. Extend, with a reducing commitment and named capability targets, so the gap closes on a schedule. Hire, accepting that new capacity is unproductive for weeks and that Chapter 7's argument about where people are added still applies. Or reduce what has to be operated, by returning to Chapter 4's archive verdicts and executing the ones that were deferred, because a smaller system needs a smaller team.

What you must not do is write the pack and leave. It is the version that looks complete and fails first.

The last thing to remove is yourself

The final weeks have a specific shape, and it is a reduction rather than a completion.

Stop taking work. Move from doing to reviewing, then from reviewing to being available, then to being absent for a stated period while still contactable. A week where nobody needs you is the strongest evidence available. It is worth more than any document you could have written in that week.

Leave a written statement of what is unfinished. The repairs deferred and why, the components marked for archiving that were not archived, the perimeter gaps, the decisions the owner still has to make. Being explicit about that list is what distinguishes a handover from an exit, and it is the part a future rescue, if there is one, will start from.

Chapter summary

A handover is a set of demonstrated capabilities rather than a document pack, and the artifact is a single page listing six of them with a date and a name beside each: released unaided, diagnosed an incident, restored from backup, changed something inside the tested perimeter, onboarded an engineer to a merged change, and ran a blameless postmortem that produced an owned action. Each demonstration can fail visibly and early, which is the property a document pack lacks. Start in week two, pair rather than deliver, and accept the slower pace, because Naur's argument sets the ceiling on what documents can carry and a theory transfers through contact. Spend the writing effort on decisions rather than descriptions: architecture decision records in the repository, one per significant call, superseded by reference rather than edited, plus the why column from Chapter 3 kept with its blanks intact because the blanks name the open questions. Treat runbooks as real only once they have been executed from during an event, keep the set to five or so with a last-executed date at the top, and derive each from an actual incident rather than from imagination. Hand back the measurements with a named publisher and a real audience, along with the error budget arrangement and the standing to hold it, while warning plainly against turning those numbers into individual performance targets. Then reduce yourself out of the system in stages, and leave a written statement of what remains unfinished.

The delivery is running, the team owns it, and the engagement is ending. That leaves one question, and it is the one the business will ask first at the next planning cycle. Chapter 12 is Preventing the Next One: the early signals that were visible long before anyone called this a rescue, the controls that catch them, and why most prevention fails as a matter of incentives rather than of knowledge.