Shift handovers: making transitions smooth between teams

The handover between two shifts is the most expensive five minutes in a multi-shift operation. Done well, it transmits the day's irregularities — the customer complaint, the broken till, the medication change, the missing delivery — to the people who need to act on them. Done poorly, it produces the kind of slow-motion disaster that compounds across a week: every shift starts behind, finishes tired, and bequeaths a slightly worse handover to the next.

Handovers are not really about communication; they are about compression. The outgoing team has eight hours of context to transmit. The incoming team has, at best, a handful of minutes to absorb it before they have to start their own shift. The skill is deciding what gets compressed in, what gets left out, and how the unsaid things still get captured for tomorrow's reference.

What a handover is actually for

It is worth being explicit about the purpose, because handovers tend to drift into ritual. A useful handover does four things:

1. Transmits anomalies. Anything that is different from a normal shift — equipment, customers, supplies, staff issues.
2. Hands off open commitments. Promises made during the outgoing shift that have not yet been fulfilled.
3. Confirms state. The till count, the inventory level, the patient list — whatever the operation's "current state" is.
4. Marks the boundary. A clear moment when responsibility transfers, so nobody is unsure who owns the next sixty minutes.

Anything in a handover that does not serve one of those four purposes is, in our experience, eventually skipped. The advice below is built around making each of those four work reliably under time pressure.

The standard handover template

Most operations benefit from a written template that the outgoing lead fills in before the incoming lead arrives. The template can live on a clipboard, a shared notebook, a Slack channel, or a dedicated app — the medium matters less than the consistency. A workable starting template:

• Date / shift / outgoing lead / incoming lead — five seconds, removes ambiguity.
• State at handover — till totals, key inventory, patient count, whatever your "state" is.
• Open issues — anything not finished. Include who is owed a response and by when.
• Anomalies / incidents — what was different from a normal shift.
• Heads-up for the next shift — known events, deliveries, callbacks, unusual demand expected.
• Sign-off — outgoing lead signs that the above is accurate; incoming lead signs that they have read it.

Six rows. The discipline is using all six every time, even when the answer to most is "none." The empty rows still serve a purpose: they signal that the handover happened, that the absence of items was confirmed rather than overlooked.

Time on the clock

A handover requires both teams to overlap on shift, which means both teams are paid. Many small operations resist this by ending the outgoing shift and starting the incoming one at the same minute, with the implication that handover happens by osmosis during a hectic crossover. It does not.

Build a deliberate ten- to fifteen-minute paid overlap into the schedule. The cost of those minutes is small compared to the cost of one missed handover producing a misjudged decision an hour later. Treat overlap as part of the shift, not as a luxury.

Verbal versus written

The argument over whether handovers should be verbal or written is mostly a false dichotomy. Both modes do different jobs:

• Written persists. It survives the busy moment when the verbal handover happens too quickly. It is also the only thing that survives when the outgoing person leaves before the incoming person arrives.
• Verbal compresses. A two-minute conversation can convey nuance, tone, and context that a written log struggles with. It also gives the incoming team a chance to ask questions.

The right pattern is both: the outgoing lead writes the template before the end of their shift, and walks the incoming lead through it during the overlap period. The written form catches what the conversation forgets; the conversation catches what the form leaves ambiguous.

Common failure modes

After enough botched handovers, the same patterns keep showing up. Watch for these:

The friendly handover that does not happen

Two leads who like each other often skip the formal handover and chat instead. Twenty minutes of catch-up about life, and a thirty-second "everything fine?" about the shift. The log goes unfilled; the next morning, a missed item triggers a customer complaint. Friendliness is not a substitute for structure.

The single-channel handover

Some operations transmit handover information only on shift change, expecting the incoming team to absorb it in the moment. Two days later, when somebody needs to remember a detail from Tuesday morning, there is nowhere to look it up. A handover that does not produce a durable record cannot be referenced; references are how operations learn.

The phantom owner

"Someone needs to follow up with that supplier about the missing invoice." The outgoing team wrote it down; the incoming team read it; everyone assumes it has been picked up by someone else. Three days later, the supplier rings, annoyed. Every open issue needs a name attached before the shift ends, and the handover format should make a nameless item visibly broken.

The unsignposted change

A new policy or piece of equipment arrives during a shift. The team that experienced the change does not write it up; the team that arrives the next morning never knew it was coming. Big changes get a single point of confusion, while small changes accumulate as background noise. The handover format should have a slot for "new things since last shift" as a routine field.

Handover and skill mix

A subtler point: who is on the incoming shift affects what the outgoing handover should emphasise. If the incoming team includes someone with deep experience, the handover can be terse — they will infer most of what they need. If the incoming team is unusually junior, the handover should be more explicit and the overlap longer.

This sounds obvious, but it is rarely encoded into practice. A simple rule helps: the outgoing lead should glance at who is on the incoming shift and adjust accordingly. If the most senior incoming person is not someone they would normally hand over to, they should slow down and walk through more details. If the most senior person is someone they trust, the handover can be lighter.

The first ten minutes after handover

Handover does not end when the outgoing team walks out. It ends when the incoming team has actually integrated the information into how they are running the shift. The first ten minutes after handover are when the integration happens — open issues get assigned to specific people, anomalies get scanned for anything still active, and the incoming lead sets the tone for the rest of the shift.

Building this short integration phase into the rhythm of the shift — not formally, but as a cultural habit — closes the loop. It is the difference between "the handover happened" and "the team has the context."

Why this connects to scheduling

Handovers do not appear on a roster. They are an invisible tax on every shift change. But they are profoundly affected by the schedule: the length of the overlap, who is paired with whom, how often the same lead-to-lead pairing recurs.

A schedule that pairs two competent leads four nights in a row creates a rhythm where handovers become reliably good. A schedule that randomises the pairings every shift, especially across leads of varying experience, creates a much higher overhead — the leads constantly recalibrate to each other.

It is worth treating "who hands over to whom" as a soft scheduling preference: the algorithm should, all else being equal, favour pairings that have worked before, and flag pairings where two new leads will hand over to each other for the first time. The operational benefit is more than the marginal scheduling cost.

The shortest version

If you have time to absorb only one thing from this article, it is this: handovers fail silently. They do not crash; they degrade. By the time you notice, the cost has already been paid. The cure is mundane — a written template, a paid overlap, an explicit owner on every open issue — but the discipline is non-trivial. Most operations rediscover this every few years, after a quietly avoidable incident. The ones that have learned it stop having the incident.