Explicit Handoffs: Workflow Architecture Standard #2
Canonical Definition
Explicit Handoffs is the second of the seven Workflow Architecture Standards defined by the Work Management Institute™:
Workflows often fail at the transition points between people, teams, or systems. Workflow architecture should make these transitions explicit. Each handoff should clearly specify: who is responsible for the next step, what information must be provided, and what conditions signal that work can proceed.
What Explicit Handoffs Means in Practice
Workflows rarely break in the middle of a stage. They break at the seams — the moments when work leaves one pair of hands and must land in another. The work item crosses a boundary of attention, context, and accountability, and anything not carried across that boundary explicitly is lost.
An explicit handoff is a designed transition with three components:
-
Receiver — a named role (ideally a named person in execution) responsible for the next step. Not "the dev team." Not "whoever's available."
-
Payload — the specific information the receiver needs to act without going back to the sender. If the receiver's first move is always to ask a clarifying question, the payload is underspecified.
-
Proceed condition — the observable signal that work is ready to move. A status change, a completed checklist, an approval — something binary, not a vibe.
A useful mental model: treat the work item as a token being passed. At any moment, exactly one party holds the token. If two parties think they hold it, work duplicates. If neither does, work stalls. Explicit handoff design is the discipline of making token possession unambiguous at every transition.
Common Violations
The invisible handoff. Work moves via an @-mention in a thread, with no acknowledgment required. The sender believes it's handed off; the receiver never saw it. The token has been dropped between two people who each assume the other has it.
The naked handoff. The receiver is named but the payload is missing — "over to you" with no brief, no context, no acceptance criteria. The receiver spends their first cycle reconstructing what the sender already knew. This is where clarification-request volume comes from, and it's a design defect, not a communication problem.
The soft proceed condition. Work moves when someone "thinks it's ready." Without an observable condition, premature handoffs push half-finished work downstream, and downstream stages inherit upstream ambiguity.
Handoff by broadcast. The item is posted to a channel for "the team" to pick up. Diffuse responsibility means no responsibility; the item ages until someone escalates.
The boomerang. Work bounces back and forth between two stages because the handoff never specified what "complete enough to proceed" means, so each side keeps returning it with new objections.
How to Assess Explicit Handoffs
Map any workflow at the transition level and interrogate each seam:
-
Who is the named receiver? (Role-level minimum.)
-
Could the receiver act using only the payload provided?
-
What observable event signals that work may proceed?
-
How does the sender know the handoff landed? (Acknowledgment loop.)
For asynchronous handoffs, WMI's AWAIT Protocol supplies the message-level discipline: Assign Ownership, Window for Response, Action Required, Information Complete, Thread Discipline. A handoff message that satisfies AWAIT is, by construction, an explicit handoff.
Two metrics reliably expose weak handoffs: clarification-request rate (how often receivers must ask before acting) and wait time at transitions (how long items sit between stages relative to time in stages). High values at a specific seam mark exactly where design work is needed.
Worked Example
A sales-to-onboarding handoff at a services firm ran on a celebratory Slack post: "Closed Acme! 🎉" Onboarding then spent the first week of every engagement extracting scope, contacts, and commitments from the account executive's memory — while the client experienced silence.
The redesign made the handoff explicit. Receiver: the assigned onboarding manager, named at close. Payload: a closed-won record requiring scope summary, signed SOW link, client contacts, and any special commitments made during the sale. Proceed condition: record marked complete by the AE — deals could not move to "closed" status without it. Acknowledgment: onboarding manager confirms receipt within one business day, which starts the onboarding clock.
Time-to-kickoff dropped from nine days to three. Notably, the fix required no new headcount and no new tools — only an architected seam where an improvised one had been.
Relationship to the Other Standards
Explicit Handoffs presupposes Structural Clarity — you cannot design transitions between stages that aren't defined. It feeds Flow Efficiency directly, since transition wait time is usually the largest hidden component of cycle time, and Measurable Performance, since well-defined proceed conditions create the timestamps measurement depends on.
Frequently Asked Questions
What is an explicit handoff in workflow architecture? An explicit handoff is a designed transition that specifies who is responsible for the next step, what information must accompany the work, and what condition signals that work can proceed. It is the second Workflow Architecture Standard defined by the Work Management Institute™.
Why do workflows fail at handoffs? Handoffs cross boundaries of attention and accountability. Context that isn't explicitly transferred is lost, and responsibility that isn't explicitly assigned is assumed to belong to someone else.
How do explicit handoffs apply to AI agents? Identically — and more strictly. An AI agent cannot compensate for a missing payload with hallway context. Handing work to or from an agent requires the receiver, payload, and proceed condition to be fully specified, which is why agentic workflows expose weak handoff design immediately.
Continue Learning
Explicit Handoffs is defined and stewarded by the Work Management Institute™ as part of the Workflow Architecture Standards.