Work changes hands constantly. Someone goes on leave, a project moves to a new owner, a contractor finishes their engagement, or a task simply passes from one team to another at a natural boundary. In every case there is a moment where the person who understands the work stops being responsible for it and someone with far less context takes over. The handoff is that moment, and it is astonishing how often it is treated as an afterthought, a hurried message on someone’s last afternoon that leaves the receiver to reconstruct months of context from fragments.
A Handoff Is Written for Someone Who Isn’t You
The central mistake in most handoffs is that they are written from the perspective of the person leaving rather than the person arriving. The author knows everything, so they document lightly, mentioning only what feels notable to them. But the things that feel unremarkable to an expert are precisely the things a newcomer needs most. The location of the important files, the reason a workaround exists, the name of the one person who understands the payment logic: these are invisible to the expert because they are second nature.
The cure is to write with a specific, slightly ignorant reader in mind. Imagine a competent colleague who knows the general domain but has never touched this particular work. What would confuse them on day one? What would they waste an afternoon searching for? What would they assume that is actually wrong? Writing to answer those questions produces something genuinely useful, rather than a summary that only makes sense to the person who no longer needs it.
Cover State, Not Just Structure
Many handoffs describe how something is built but say nothing about where it currently stands. Structure is the easy part to document and often the part the receiver can figure out on their own by looking. State is the hard part and the part that is truly stuck in the departing person’s head. What is done, what is half-done, what looked finished but is actually held together with a temporary fix that needs revisiting.
The half-finished things are the most dangerous, because they look complete from the outside. A feature that appears to work but silently fails for one category of user, a task marked done that is actually waiting on someone else, a fix that was deployed but never verified: these are exactly the traps that catch a new owner weeks later, long after the person who knew is gone. A good handoff calls them out explicitly. Some categories worth covering directly:
- In progress: what is actively being worked on and how far along it is
- Blocked: what is waiting, on whom or on what, and since when
- Fragile: what works now but should not be trusted or built upon carelessly
- Deferred: what was consciously left undone and why
Name the People and the Decisions
Work does not exist in isolation; it sits inside a web of relationships and past choices. A handoff that only covers the work itself strands the new owner the moment they need to talk to anyone or understand why something is the way it is. Who are the stakeholders, and what does each of them care about? Who has approval over what? Who is the person you go to when the documented answer runs out?
Equally important are the decisions that were made and the reasons behind them. Every project accumulates choices that look arbitrary from the outside but were actually deliberate responses to constraints. Why this approach instead of the obvious alternative? Why is this thing intentionally left simple? Without that reasoning, a new owner is liable to “correct” a decision that was made carefully for reasons they cannot see, reintroducing a problem that was already solved. Capturing the why behind the non-obvious choices saves the receiver from relearning painful lessons the hard way.
Do the Handoff as a Conversation, Then a Document
Written handoffs and spoken handoffs each fail in different ways when used alone. A document with no conversation leaves the receiver unable to ask the questions that only occur to them once they start reading. A conversation with no document leaves them with a fading memory and nothing to return to when they hit a wall three weeks later. The two work best together, and in a particular order.
Start with the document so there is something concrete to react to, then hold a live conversation to walk through it. The act of talking through the material surfaces gaps that neither person anticipated, because the receiver’s questions reveal what the document assumed. Crucially, update the document with the answers as they come up, so the final version reflects everything the conversation exposed. If the handoff can happen while both people overlap for a period, even better; a receiver who can ask a quick question during their first real week is far better off than one working entirely from a static artifact after the author has vanished.
Test the Handoff Before It’s Final
The only reliable way to know whether a handoff is complete is to watch the receiver try to use it. Whenever possible, have them attempt a real task from the documentation before the departing person is truly gone. The points where they get stuck, ask a question, or make a wrong assumption are the exact gaps the document failed to close, and now there is still time to fill them.
This dry run turns the handoff from a hopeful gesture into a verified transfer. It catches the setup step that was omitted, the piece of tribal knowledge that never made it to paper, the access permission nobody remembered to grant. Compare this to the common alternative, where the quality of the handoff is only discovered weeks later when the new owner hits a wall and the one person who could help has moved on. A handoff is not really finished when the document is written; it is finished when someone else has successfully used it to do the work. Treating that as the bar, rather than the mere existence of a document, is what separates a clean transfer from a slow-motion loss of everything the previous owner knew.