In short
A handoff fails when it transfers the task but not the context. Fix it by defining, for each handoff, what must be true before work may be passed on (a definition of ready), what the receiving team needs in order to start without asking, and who is accountable during the transfer itself. Handoffs should be structured — a required set of fields, not a message — and the receiving team, not the sending team, should define what it needs.
Key takeaways
- Work does not fail inside teams. It fails in the gaps, which nobody owns.
- The receiving team should define the handoff requirements, because only they know what they need.
- A definition of ready prevents the most expensive failure: work accepted, started, then blocked.
- Accountability must not lapse during a transfer. Name who owns the item mid-flight.
- Structure beats goodwill. A required set of fields survives staff turnover; a good relationship does not.
The gap nobody owns
Trace a delayed piece of work backwards and you will usually find that every team touched it promptly. Sales closed on Tuesday. Delivery started on the 19th. Between those two dates: nothing visible, and nobody responsible for the nothing.
This is structurally different from a performance problem, and it resists all the usual performance remedies. You can add a status meeting, which reports the delay without shortening it. You can ask people to communicate better, which works for about six weeks. You can escalate individual cases, which fixes those cases.
Every team is measured on what happens inside its boundary. The delay happens outside every boundary, which means it appears in nobody's numbers and belongs to nobody's improvement plan.
What is actually being lost
Three things go missing in a bad handoff, in ascending order of cost:
| Lost | Symptom | Cost |
|---|---|---|
| Time | The receiving team does not know it has arrived, or does not know it is theirs to start | Days of pure waiting |
| Information | Receiver must reconstruct the brief from emails, calls and guesswork | Hours per item, plus errors |
| Context | The commitments, sensitivities and constraints behind the work never transfer at all | Rework, and occasionally a lost client |
The third is the one that causes real damage. A delivery team can rebuild a specification. It cannot know that the client was promised a particular sequence, or that they reacted badly to something similar last year, unless someone tells it.
Why good people produce bad handoffs
Nobody withholds context deliberately. Four mechanisms produce the loss anyway.
The curse of knowledge. The sender cannot easily see which parts of what they know are non-obvious, because to them nothing is non-obvious. They pass on what feels like the complete picture, and it is complete only from inside their own head.
The sender defines the handoff. In most businesses, the format of a handoff was designed by the team doing the sending — which means it contains what is convenient to provide rather than what is necessary to receive. This single inversion explains a large share of handoff failures.
Accountability lapses in transit. Sales considers it delivered. Delivery has not accepted it. For some period, sometimes days, the item is owned by no one, and items owned by no one do not move.
The relationship substitutes for the process. In small teams, handoffs work because Amara knows Ben and just tells him. This is genuinely effective and completely non-transferable. It fails at the exact moment the business grows — when Ben is replaced, or when there are now four Bens and it is unclear which one.
That last point deserves emphasis, because it is why handoff quality tends to degrade during growth even as everything else improves. The informal mechanism that worked at eight people cannot scale, and nothing was built to replace it.
Define ready before you define the format
The highest-leverage intervention is also the least technical: agree what must be true before work is allowed to cross the boundary.
- Definition of ready
- A short, explicit list of conditions that must be satisfied before work may be handed to the next team. Work that does not meet it is not passed on — it stays with the sender until it does.
This prevents the single most expensive handoff failure: work that is accepted, started, and then blocked. That failure costs more than a delay, because the receiving team has already allocated capacity, begun work, and must now unwind and reschedule — and the item usually loses its place in the queue entirely.
A definition of ready should be short enough to check in under a minute. For a sales-to-delivery handoff it might be:
- Signed agreement is attached, not described
- Scope is written down, including what is explicitly excluded
- Client's named day-to-day contact is recorded, with time zone
- Any commitments made verbally during the sale are written down
- Payment terms confirmed and first invoice raised or scheduled
- Known risks or sensitivities noted, even briefly
Six lines. Checkable. And note that most of them are things the sender already knows — the definition of ready does not create work so much as it prevents that knowledge from evaporating.
The receiver writes it
This is the rule that makes the whole thing work. The team receiving the work defines what it needs to start without asking questions. The sending team may negotiate on feasibility, but they do not get to decide what counts as sufficient, because they are not the ones who will be blocked.
Structure the handoff, do not just improve the message
A handoff should be a set of required fields, not a well-written message. The distinction matters for a specific reason: a message depends on the diligence of whoever wrote it, and a structure does not.
Practical implementation, in increasing order of robustness:
| Mechanism | Works when | Weakness |
|---|---|---|
| A template people copy | Small team, high goodwill | Erodes under pressure; sections silently dropped |
| A form that produces the record | Most businesses, most handoffs | Needs someone to maintain it as needs change |
| Required fields in the workflow tool | Where work already lives in a shared system | Can become box-ticking if fields are not genuinely used |
| Automated transition on completion | High-volume, stable handoffs | Requires the earlier steps to be working first |
Most businesses should aim at the second or third row. The fourth is a legitimate target once the handoff is stable — see what to automate first for how to sequence it.
Include the four things a receiver always needs
Whatever the format, these four are non-negotiable, and their absence is the cause of nearly every follow-up conversation:
- What was promised, including anything agreed verbally
- What was explicitly ruled out, which is invisible in every artefact unless written down deliberately
- Who to ask, named, on both sides
- What is unresolved, because unstated open questions become discovered problems at the worst moment
Never let ownership lapse in transit
The transfer itself needs an owner. Two rules cover it.
Rule one: the sender owns the item until the receiver accepts it. Not until they send it — until acceptance. This means the sender has a live interest in the handoff being complete, because incomplete handoffs bounce back to them rather than becoming somebody else's problem.
Rule two: acceptance is an explicit act with a deadline. The receiving team confirms within an agreed window — often one working day — either accepting or rejecting with a specific reason. A rejection is not a failure of the relationship; it is the mechanism working. What must not exist is a third state where the item has been sent, not accepted, and not rejected.
One working day is a reasonable default acceptance window for most internal handoffs. The specific number matters far less than the fact that a number exists and that something happens automatically when it passes — the same decision clock and default principle applied to transfers.
Rejections are data
Track rejected handoffs and the reason. Within a month you will have a ranked list of exactly what is missing most often, which tells you what to fix in the sending process. A rejection rate that starts high and falls is a healthy signal. A rejection rate of zero usually means people are accepting incomplete work and absorbing the cost silently, which returns you to the original problem with an extra step.
Designing a handoff in ninety minutes
Take your worst handoff — usually sales to delivery, or delivery to support — and put both sides in a room.
First 20 minutes. The receiving team lists every question they have had to ask in the last month about work they received. Just the questions. No solutions, no defensiveness. This list is the specification.
Next 20 minutes. The sending team marks which of those they already knew at the point of handoff. Almost all of them, usually. This is the moment the conversation changes character, because it becomes clear the problem is transfer rather than knowledge.
Next 20 minutes. Draft the definition of ready from the marked items. Anything the sender did not know is a separate problem, to be solved earlier in the flow rather than at the handoff.
Next 20 minutes. Decide the mechanism, the acceptance window and what happens on rejection. Keep it simple enough to start next week.
Final 10 minutes. Agree how you will know it worked. Two measures are enough: time from handoff to accepted start, and number of clarification questions per item.
Review after a month with both teams. Expect the definition of ready to grow slightly and then stabilise. If it keeps growing, the handoff is being used to compensate for a problem further upstream, and that is where to look next.
The Mayim Ops assessment scores communication and handoffs as one of ten operational dimensions, and identifies which specific transitions in your business are losing the most time and context.
Frequently asked questions
Why does work stall between teams?
Because the space between teams belongs to no one. Each team completes its own work promptly and is measured on what happens inside its boundary, so the delay in the gap appears in nobody's numbers. Fixing it requires assigning accountability to the transfer itself, not asking teams to work faster.
What is a definition of ready?
A short, explicit list of conditions that must be true before work may be passed to the next team. It prevents the most expensive handoff failure, where work is accepted, started and then blocked, forcing the receiving team to unwind allocated capacity and reschedule.
Who should define what a handoff contains?
The receiving team, because only they know what they need in order to start without asking questions. When the sending team designs the handoff, it tends to contain what is convenient to provide rather than what is necessary to receive, which is a common root cause of handoff failure.
How do you stop context being lost between departments?
Make the handoff structured rather than conversational, and require four things every time: what was promised including verbal commitments, what was explicitly ruled out, who to ask on both sides, and what remains unresolved. Structure survives staff turnover and time pressure in a way that a good working relationship does not.
Should teams be able to reject a handoff?
Yes, within an agreed window such as one working day, with a specific reason recorded. Rejections are the mechanism working rather than a relationship failure, and tracking the reasons produces a ranked list of what is missing most often. A rejection rate of zero usually means incomplete work is being accepted and the cost absorbed silently.