What makes a handover fail

Somebody leaves a role. Somebody else takes it on. There is a period of overlap, a document, perhaps a meeting, and then the first person is gone.

Three months later something goes wrong that would not have gone wrong before, and the explanation is always the same shape: he knew how to handle that.

Why handover documents miss the important things#

Because the important things do not feel like knowledge to the person who has them.

Anybody doing a job for a few years has absorbed a large body of situational knowledge that they no longer experience as knowledge. Which supplier's delivery notes are always short by a bag. Which approval genuinely needs chasing and which arrives on its own. Which of two similarly named items in the system is the one actually used. That the report on Tuesday is wrong unless you run the other one first.

None of this appears in a handover document, because a handover document is written by asking somebody what they do, and people answer that question by describing their formal responsibilities.

This is the same mechanism that hides ordinary defects from the people living with them. A problem that survives longer than a month or two stops being experienced as a problem and gets absorbed into the description of the job. We wrote about that at length in the gap you stopped noticing. Handover surfaces the same blindness under time pressure.

The three categories, and only one of them transfers well#

Documented process. Transfers fine. It is written down, it can be read. This is what handover documents contain, and it is the least valuable third.

Undocumented routine. The daily and monthly things nobody wrote down because they are too obvious to mention. Partly transferable, if the overlap period is long enough for the successor to watch a full cycle. A month is not a full cycle for anything with a quarterly component.

Judgement and relationships. Which vendor will actually turn up on a Sunday. Which colleague to ask before formally raising something. What the unwritten tolerance is on a particular measurement. Barely transferable at all in a handover, and it is often the majority of what made the person good.

Knowing which of the three you are losing tells you what to do. The first needs nothing. The second needs a longer overlap covering a real cycle. The third needs relationships to be introduced deliberately, one at a time, rather than listed.

Ask about workarounds, not about duties#

The single most productive handover question is not "what do you do".

It is: what do you work around?

Ask it out loud and wait through the pause. The answers do not come as complaints. They come as instructions, delivered helpfully, in the tone of somebody explaining how a door has to be lifted before it will close. Oh, you have to enter it twice, the first one never saves. Don't use that report, use this one. Ring him rather than emailing, he doesn't check.

Every one of those is a piece of load-bearing knowledge that no document would have captured, because from the inside it is not knowledge — it is just how the job is done.

It is also, incidentally, a free audit of your own systems. Each workaround is a defect somebody has been quietly staffing. We found an entire class of these in our own software — features that had been built and had never been given a button, so a workaround was doing the job instead and nobody had ever filed a request. The story is written, and never wired.

The things that actually break#

In practice, handover failures cluster in a small number of places.

Access. Accounts, keys, permissions, and the one system nobody remembered because it is used twice a year. The successor discovers the gap at the moment they need it, which is the worst moment.

Recurring obligations with long periods. Anything annual. A renewal, a return, a certificate, an inspection. The predecessor did it eleven months ago and will not think of it; the successor has never seen it happen.

Relationships that were personal. A supplier who gave good service because of a person, not because of a contract. This degrades quietly over months and is usually attributed to the supplier.

In-flight decisions. Anything half-negotiated. The state of a discussion lives in somebody's head and in a set of messages nobody else can read, which is the same reason a snag list that actually closes gives every item an identifier and a named owner rather than a wording.

Undocumented commitments. Something promised verbally that the records do not show. These surface as accusations of bad faith.

What a handover should actually produce#

Not a document. A set of artefacts that outlive the meeting.

• A calendar with the annual and quarterly obligations on it, each with the name of whoever must be told and roughly what is involved. This is worth more than everything else combined.
• A list of access held, including the awkward ones — shared logins, a physical key, an account in somebody's personal name.
• A written list of in-flight items with their current state and who the other party is.
• Introductions made in person to the five or six relationships that matter, with the predecessor present and saying so.
• The workaround list, from the question above, in their own words.

Notice that four of the five are lists of specific facts rather than descriptions of a role. Roles do not transfer. Facts do.

The same test decides what goes into the document set handed over at the end of a project — what belongs in a handover file.

Overlap is not the same as availability#

"Ring me if you need anything" is offered sincerely and used twice.

The successor will not ring, for ordinary human reasons: they do not want to look incapable, they do not know what they do not know, and after a fortnight it feels like an imposition. Availability is not a handover mechanism, and planning around it is how organisations end up depending on the goodwill of somebody who no longer works there.

If knowledge has not moved during the overlap, it has not moved.

The short version#

Handovers fail on the knowledge the departing person does not know they have.

Ask what they work around rather than what they do. Cover a full cycle, not a convenient window. Produce lists of specific facts — obligations, access, in-flight items, relationships — rather than a description of the role.

And treat every workaround you uncover as a defect report, because that is exactly what it is. The related failure, where work stops in the gap between two people who both think it is with the other, is covered in why tasks stall between people.