The Handoff: Why Work Gets Lost Between People
A handoff is the transfer of accountability for a piece of work from one participant to another. Not the transmission of a file, not a notification, not a mention in a channel — the moment responsibility actually moves. Work that has been sent but not accepted has left one owner without reaching another, and in that interval it belongs to nobody.
That interval is where most work in multi-step paths is lost. Not lost as in deleted — lost as in sitting, unowned and unnoticed, while both people involved believe the situation is handled. The sender's view is that it's done and gone. The receiver's view is that nothing in particular is urgent. Both are reasonable. Neither is wrong about their own position. And the work ages.
Why Handoffs Are the Weak Point
Every other part of a workflow has someone paying attention to it. Work being performed has a performer. Work waiting in a defined queue has a queue owner. The handoff is structurally different: it's the one moment in the path where the work is between two people's attention rather than inside either.
Three properties make this worse than it sounds.
Nobody experiences the delay. The sender has moved on to something else — from their perspective the item concluded cleanly. The receiver hasn't started counting, because as far as they know this item just appeared. The only person experiencing the gap is the requester, who is outside the workflow and can't see where their item is.
No individual is at fault, so no individual corrects it. Handoff gaps aren't caused by negligence. They're caused by the absence of a mechanism, and the absence of a mechanism is nobody's immediate problem. This is why handoff delays persist for years in otherwise well-run teams.
They're invisible to most measurement. If your stages are drawn around activities rather than ownership transitions, the handoff happens inside a stage, where no timestamp records it. A workflow can show healthy per-stage times and long overall cycle times with no apparent explanation — the time is disappearing into gaps the structure doesn't represent.
The Four Ways Handoffs Fail
1. Send without transfer. The sender completes their part and pushes the work onward — an email, a status change, a mention — without any confirmation that someone received it. This is the default handoff in most organizations and the source of most gaps. The work is in transit indefinitely.
2. Transfer to a group. The work goes to a team, a shared queue, a channel. Available to everyone, urgent for no one. Items that are easy or interesting get claimed; ambiguous ones age. Nobody has refused anything, which is exactly why nobody corrects it.
3. Transfer without context. The receiver gets the work but not what they need to act on it — the constraint discussed three weeks ago, the reason for the unusual approach, what the sender was uncertain about. So the receiver's first action is to ask, which means the real handoff happens a day or two later, after a round-trip that shouldn't have been necessary.
4. Transfer without criteria. The receiver gets the work and can't tell whether it's ready. Is this draft complete or a rough pass? Was this approved or just reviewed? Unclear readiness produces one of two failures: the receiver proceeds on something that wasn't ready, or waits to check, converting a handoff into a negotiation.
What a Complete Handoff Includes
Four elements. Any handoff missing one of them is a candidate gap.
A named recipient. A person, not a department, not a queue with no owner. If the handoff's destination can't be stated as a name — or a role that resolves to one today — the work is going somewhere it may not be received.
An acceptance event. Something that marks the receiver taking ownership, distinct from the sender releasing it. This is the element almost always missing, and it's the one that closes the gap: until acceptance, the sender still owns the work. That single rule removes the state where an item belongs to nobody, and it does so without any new tooling — it's a convention, not a feature.
The context required to act. What the receiver needs and wouldn't otherwise have. The practical way to determine this is to ask them what they most often have to come back and request.
A readiness signal. What must be true for the work to cross — stated once per boundary, not negotiated per item. "Draft complete, sources checked, formatted" takes one sentence to write and eliminates an entire category of back-and-forth.
Making Handoffs Visible
You can't fix what you can't see, and handoff time is specifically the thing most workflows don't record. Three ways to surface it, in ascending order of effort.
Check whether your stages match your transfers. If two people work an item sequentially within one stage, the interval between them is invisible. Splitting that stage at the transfer point makes the wait measurable — which is usually the first time anyone sees how large it is.
Measure sent-to-started intervals. For a sample of completed items, compare when the sending side marked their part done to when the receiving side first touched it. The distribution is usually more alarming than the average, because the tail is where the damage is.
Count the follow-up messages. Every "just checking on this" marks a handoff that failed to transfer ownership. They cluster around your worst handoffs with considerable precision, and counting them requires no instrumentation at all.
Fixing the Gap
In rough order of yield:
Make acceptance the transfer point. The sender owns the work until the receiver takes it. Stated as a norm and applied consistently, this is the highest-leverage change available, because it eliminates the ownerless interval by definition rather than by diligence.
Automate notification with context attached. If transfers depend on someone remembering to notify, make it automatic. This is a rule, not a restructuring, and it targets the largest single wait in most multi-stage paths.
Replace group destinations with named ones. Rotation schedules, round-robin assignment, or a named triager — any of them beats a shared queue. The requirement is that at any given moment, the answer to "whose is this?" is a person.
Write the readiness criterion for each boundary. One sentence per handoff. This is an hour of work for an entire workflow and prevents most rework.
Add aging escalation at handoff points. A rule that flags items sitting unaccepted past a threshold, routed to a named person. This converts the silent failure into an event — not preventing gaps, but ensuring they end.
The Broader Point
Handoffs are where workflow structure earns its existence. A single person working alone needs no workflow management — they need a task list. The entire discipline exists because work passes between people, and passing is the part that goes wrong.
This has a useful implication when you're deciding where to spend effort on a workflow. The stages are usually fine; the people in them are usually competent and busy. The interesting question is almost always what happens in the moments between them, which is also the part nobody is assigned to watch. Improvements aimed at the gaps tend to outperform improvements aimed at the stages, and they're generally cheaper, because they're conventions rather than redesigns.
FAQ
What is a handoff in a workflow? The transfer of accountability from one participant to another — not merely sending a file or a notification. Until the receiving side has taken ownership, the work is between owners, which is where most lost work in multi-step paths sits.
Why does work get lost between people? Because the interval between sending and accepting belongs to nobody. The sender has moved on, the receiver hasn't begun counting, and the only person experiencing the delay is the requester, who can't see where their item is. No individual is at fault, which is why the problem persists rather than getting corrected.
How do you fix handoff problems in a workflow? Make acceptance — not sending — the point where ownership transfers, so the sender still owns work until someone takes it. Then automate handoff notification with context attached, replace group destinations with named recipients, and write one readiness criterion per boundary. These are conventions and rules rather than structural redesigns.
How do you measure handoff delays? Compare when the sending side marked their part done to when the receiving side first touched the item, across a sample of completed work, and look at the distribution rather than the average. If your stages don't split at transfer points, the handoff is happening inside a stage and isn't recorded at all — splitting that stage is what makes the wait visible.
Why don't handoff delays show up in workflow metrics? Because stages are often drawn around activities rather than ownership transitions, which puts the handoff inside a stage where no timestamp captures it. The result is a workflow with reasonable-looking per-stage times and an unexplained gap between them and overall cycle time.
