Handoff points in workflows

The place where good work goes to die

The previous lesson asked you to define the inputs and outputs of each step in your workflow with precision — what enters, what exits, and in what form. That was specification at the level of the individual step. Now we zoom out to the seams between steps, because that is where the damage happens.

Every workflow that involves more than one person, more than one tool, or more than one session of your own attention contains handoff points — moments where work-in-progress passes from one context to another. From you to a colleague. From a drafting tool to a review tool. From your Monday self to your Wednesday self. From a spreadsheet to an email. From a conversation to a document. Each of these transitions is a potential failure point, and not a minor one. Research across industries — healthcare, aviation, manufacturing, software engineering — converges on a single finding: handoff points are where the majority of errors originate. Not because the people involved are careless, but because the transition itself destroys information that seemed obvious on one side and became invisible on the other.

If you have ever received a project brief that left out the one piece of context you needed, you have experienced a handoff failure. If you have ever returned to your own work after a week away and spent thirty minutes trying to remember where you left off and why, you have experienced a handoff failure — one you inflicted on yourself. If you have ever watched good work get derailed not by incompetence at any individual step but by miscommunication between steps, you understand the problem this lesson addresses. The work inside the steps is often fine. The work between the steps is where things fall apart.

The Joint Commission finding: communication kills

The most dramatic evidence for the danger of handoffs comes from healthcare. The Joint Commission, which accredits hospitals in the United States, conducted an analysis of sentinel events — the most serious category of medical errors, including wrong-site surgery, patient death from medication errors, and other preventable catastrophes. Their finding was unambiguous: communication failures during handoffs were the leading root cause of sentinel events. Not technical incompetence. Not equipment failure. Not diagnostic errors. Communication failures at the moment when responsibility for a patient transferred from one provider to another.

The pattern repeats with disturbing consistency. A night-shift nurse knows that a patient's blood pressure has been trending downward, but does not mention it during the shift change because it has not yet crossed the threshold for formal escalation. The day-shift nurse, unaware of the trend, does not check until the patient crashes. An emergency physician orders a medication adjustment, communicates it verbally to the admitting team, and the adjustment is lost in the chaos of the handoff because nothing was written down. A surgeon operates on the correct diagnosis with the correct technique, but the post-operative care team does not receive the specific wound-care instructions that the surgeon considered obvious and therefore did not document.

In every case, the failure is not in the clinical judgment. The physicians and nurses are competent. The failure is in the transition — the moment when knowledge that lives in one person's head must be transferred to another person's head, and the transfer is incomplete. The information that was lost was not secret or inaccessible. It was simply not included in the handoff because the sender assumed the receiver already knew it, or would know to ask, or would figure it out from context.

Healthcare's response to this crisis produced one of the most effective handoff protocols ever designed: SBAR.

SBAR: a protocol that saves lives and can save your workflows

SBAR stands for Situation, Background, Assessment, Recommendation. It was developed by the United States Navy for use on nuclear submarines — environments where communication failures have catastrophic consequences and where there is no time for lengthy narrative. Kaiser Permanente adapted it for healthcare in the early 2000s, and it spread rapidly through hospitals worldwide because it worked. Studies published in the BMJ Quality and Safety journal showed that SBAR implementation reduced unexpected deaths, decreased ICU transfers, and improved nurse satisfaction with physician communication.

The protocol is simple. When handing off responsibility for a patient — or, by extension, for any piece of work — you communicate four things in order. Situation: what is happening right now? "Mrs. Garcia in room 412 is reporting increased chest pain, rated 7 out of 10, onset thirty minutes ago." Background: what is the relevant context? "She was admitted yesterday for unstable angina, has a history of two prior MIs, is on heparin and nitroglycerin drip." Assessment: what do you think is going on? "I am concerned this may represent an acute event rather than stable angina." Recommendation: what do you think should happen next? "I recommend an immediate EKG and cardiology consult."

The power of SBAR is not in its content — any competent nurse could communicate this information in a conversation. The power is in its structure. The structure ensures that nothing is omitted. The sender cannot skip the background because they assume the receiver knows it. The sender cannot omit the assessment because it forces them to think critically before handing off. The sender cannot leave the recommendation blank because the protocol demands it. SBAR transforms a handoff from an unstructured narrative — where critical details can hide in the middle of a rambling paragraph or disappear entirely — into a standardized packet of information that can be transmitted, received, and verified.

For your own workflows, SBAR translates directly, even when the stakes are not life and death. Any time you hand work to another person — a colleague, a client, a collaborator — you can structure the handoff as: Situation (here is what exists right now — the deliverable in its current state, the decision that has been made, the problem that has been identified), Background (here is the context you need — the client's constraints, the previous decisions that shaped this state, the dependencies), Assessment (here is my read on where things stand — what is working, what is not, what I am uncertain about), and Recommendation (here is what I think should happen next — and here is where I stopped, so you know exactly where to pick up).

The cost of this protocol is sixty seconds of structured thinking before you hand something off. The return is the elimination of the thirty-minute clarification conversation, the two-day rework cycle, or the silent error that propagates downstream because nobody caught it at the transition.

The 20% rule: what evaporates at every transition

Gerald Weinberg, in his book Quality Software Management, offered a rule of thumb that has been validated by decades of project management experience: every handoff between people loses approximately 20% of the relevant information. The number is not precise — some handoffs lose more, some less — but the direction is consistent and the magnitude is significant.

Think about what 20% loss means across a workflow with multiple transitions. If your project passes through four handoffs and each loses 20% of the context, the person at the end of the chain is working with roughly 41% of the original information. More than half the context has evaporated. Not because anyone was negligent. Not because anyone chose to withhold information. Simply because each transition involved a compression — the sender decided what was "important" to communicate, transmitted that subset, and left behind everything they considered obvious, tangential, or too detailed to mention.

The tragedy is that the 20% lost at each transition is rarely random. It tends to be the implicit knowledge — the assumptions, the constraints, the reasons behind decisions, the history that explains why things are the way they are. Explicit facts survive handoffs reasonably well. "The deadline is March 15" gets transmitted. "The client moved the deadline from April 1 to March 15 because their board meeting was rescheduled, which means they will be more flexible on scope than on timing" does not get transmitted, because it is a story rather than a data point. But that story is precisely the context the next person needs to make good decisions.

Weinberg's observation explains a phenomenon that anyone who has worked on a multi-person project has experienced: the further downstream you are from the original decision, the less you understand why the decision was made. By the third or fourth handoff, people are executing instructions they do not understand, following specifications whose rationale has been lost, and making local optimizations that conflict with the original intent because the intent was never communicated — only the output of the intent.

Lean manufacturing: the seven wastes at the seam

Taiichi Ohno's Toyota Production System identified seven forms of waste — muda — in manufacturing processes, and three of them cluster heavily at handoff points. Waiting: work sits idle because the receiving party is not ready, does not know the work is available, or needs information that was not included in the handoff. Transportation: work is physically or digitally moved between locations, tools, or formats, and each move introduces delay and the possibility of damage or loss. Defects: errors introduced not by the processing step itself but by miscommunication about what the processing step should produce.

In knowledge work, these wastes translate with uncomfortable precision. Waiting manifests as the email that sits in someone's inbox for three days because the sender did not indicate urgency, or the document that arrives without the information the receiver needs to act, triggering a round of clarifying questions that adds a week to the timeline. Transportation manifests as the information that must be copied from one tool to another — from a project management system to an email, from a document to a spreadsheet, from meeting notes to a task list — and each copy is an opportunity for transcription errors, formatting loss, or simple omission. Defects manifest as the deliverable that meets the stated specification but not the unstated expectation, because the specification transmitted at the handoff was incomplete.

Ohno's insight was that these wastes are not inevitable costs of production. They are symptoms of poor flow design. The Toyota Production System reduced handoff waste not by asking workers to be more careful but by redesigning the system so that handoffs carried less risk: standardized work-in-progress containers, kanban signals that communicated status without requiring conversation, visual management systems that made the state of work visible to everyone without requiring a verbal update. The waste did not disappear because people tried harder. It disappeared because the system made failure more difficult than success.

The hot potato problem: ownership during transition

There is a particularly dangerous variant of the handoff failure that deserves its own name: the hot potato problem. It occurs when work is in transition and no one clearly owns it. The sender considers the handoff complete — they have thrown the ball. The receiver has not yet acknowledged receipt — they have not caught the ball. During the gap, the work belongs to no one. It floats. And floating work drops.

The hot potato problem is especially acute in asynchronous communication. You send a Slack message with a file attached and a request for review. The recipient sees it, intends to review it later, and continues with their current task. Three days pass. You assume they are reviewing it. They have forgotten it exists. The work has been in limbo for three days, owned by neither party, progressing not at all.

The solution is an acknowledgment loop — a protocol where the receiver confirms receipt and, critically, confirms when they will act on it. "Got it, will review by Thursday" is not administrative overhead. It is the mechanism that prevents work from entering the ownership void. Without the acknowledgment, the sender must either follow up (adding friction and social cost) or wait and hope (adding delay and uncertainty). With the acknowledgment, both parties share a clear expectation, and the work has an owner at every point in its lifecycle.

In software engineering, this principle is formalized in API contract design. When one system sends data to another, the receiving system sends back an acknowledgment — an HTTP 200 response, a receipt confirmation, a status code. The sending system does not consider the handoff complete until the acknowledgment arrives. If the acknowledgment does not arrive within a defined timeout, the sending system retries or escalates. No data floats in limbo. No request disappears into a void. The protocol ensures that every handoff is either confirmed or flagged as failed.

You can implement the same principle in human workflows. The handoff is not complete when you send the message. The handoff is complete when the receiver acknowledges it. Until that acknowledgment arrives, the work remains your responsibility. This is not micromanagement. It is ownership hygiene. It is the difference between a system where work drops silently and a system where dropped work is immediately visible.

The handoff you make to yourself

Not all handoffs involve other people. Some of the most consequential handoffs you make are to yourself — specifically, to your future self, who will have a different cognitive context than your present self.

You stop working on a project at 5 PM on Friday. You resume on Monday morning. The person who sits down on Monday has access to the same files, the same tools, and the same email threads. But they do not have access to the mental model you held at 5 PM on Friday — the decision you were weighing, the problem you had just identified, the approach you were about to try, the specific reason you stopped where you stopped. That mental model existed in working memory, and working memory does not survive the weekend.

If you left no notes — no breadcrumb trail for your Monday self — you will spend the first thirty minutes of Monday reconstructing context. You will reread documents you already read. You will re-derive conclusions you already reached. You will wonder why you made certain decisions that seemed obvious on Friday but are now opaque. This is a handoff failure, and it happens so regularly that most people do not even recognize it as one. They experience it as "Monday morning sluggishness" or "getting back into the groove." It is neither. It is information loss at a handoff point, identical in structure to the information loss that occurs when you hand work to a colleague without sufficient context.

The protocol is simple: before you stop working, write three sentences. Where am I? What was I thinking? What should I do next? This is SBAR compressed for self-handoff: situation (where I stopped), assessment (what I was thinking about the state of the work), recommendation (what my next action should be). The cost is two minutes. The return is the elimination of the thirty-minute context reconstruction that otherwise begins every work session.

This practice extends beyond daily transitions. Any time you context-switch — from one project to another, from one tool to another, from deep work to a meeting and back — you are performing a handoff to a slightly different version of yourself. The version of you that returns from the meeting does not have the same cognitive state as the version that left for the meeting. A one-sentence note before the meeting ("I was debugging the authentication flow, specifically the token refresh logic, and I think the issue is in the expiry calculation") costs five seconds and saves fifteen minutes.

Acceptance criteria: the handoff specification

The most robust defense against handoff failures is borrowed from software engineering: acceptance criteria. In agile development, a user story is not considered complete until it meets a set of predefined conditions that were agreed upon before work began. These conditions are the acceptance criteria, and they serve as a contract between the person doing the work and the person receiving the work. The criteria are specific, testable, and unambiguous. "The login page should look nice" is not an acceptance criterion. "The login page loads in under two seconds, displays the company logo at 200x80 pixels, and shows an error message within the password field when credentials are invalid" is a set of acceptance criteria.

In personal and team workflows, acceptance criteria at handoff points serve the same function. Before you hand a draft to your editor, both of you should know what "done" looks like for this handoff. Does the draft need to include citations? Should it be formatted in a specific template? Is it expected to be polished prose or rough notes that the editor will reshape? These questions, answered before the handoff, eliminate the rework that comes from mismatched expectations.

The pattern generalizes to any handoff. Before you hand a deliverable to a client, agree on the acceptance criteria. Before you hand a research brief to a colleague who will write from it, specify what the brief should contain and in what format. Before you hand a task to your future self, define the starting conditions for the next session — what should be in place so that you can begin work immediately rather than spending time on setup.

Acceptance criteria transform handoffs from trust-based to contract-based. Trust says "I am sure they will know what I mean." Contracts say "here is exactly what I mean, and here is how we will both know if the handoff was successful." Trust is a fine quality in relationships. It is a terrible quality in workflow design, because it relies on telepathy, and telepathy does not scale.

The Third Brain as handoff mediator

AI introduces a genuinely new capability at handoff points: the ability to translate between contexts without the information loss that normally accompanies human-to-human transitions.

Consider the most common handoff failure — the sender communicates what they consider important, and the receiver needs information the sender did not think to include. An AI, given the full context of the sender's work and the known needs of the receiver, can identify the gap. "Your handoff to the design team includes the content and the layout preference but does not specify the target audience, the brand guidelines version, or the file format for final delivery. Based on the design team's standard intake requirements, you should add these three items." The AI is not performing creative work. It is performing gap analysis — comparing what the sender has prepared against what the receiver will need. This is precisely the kind of pattern-matching task that AI handles well and that humans handle poorly, because the sender's curse of knowledge makes their own blind spots invisible.

AI can also serve as a persistent context bridge for self-handoffs. Rather than relying on your own two-minute note at the end of a work session, you can ask an AI to summarize the session: what was discussed, what decisions were made, what questions remain open, and what the recommended next steps are. The AI's summary is not subject to the same cognitive fatigue that affects your end-of-day note-taking. It does not forget the important detail you mentioned at 2 PM because it is now 5 PM and you are tired.

There is a deeper application as well. In workflows that involve multiple handoffs across multiple people, an AI can serve as the institutional memory that no individual person maintains. It can hold the full history of a project — every decision, every rationale, every context shift — and surface the relevant portions at each handoff point. The new team member who joins a project midstream does not need to read six months of email threads. They need the current state, the key decisions and their rationales, the open questions, and the immediate next steps. An AI that has been tracking the project can generate that briefing in seconds, providing a handoff that is more complete and more accurate than any human-to-human summary.

The sovereignty check applies here as it does with all AI applications: the AI mediates the handoff, but you verify its mediation. The AI's gap analysis might miss a nuance that matters. The AI's session summary might emphasize the wrong priorities. Use it as a first draft of the handoff protocol, not as the final word. The goal is AI-assisted handoffs that lose less than the 20% that Weinberg observed in purely human transitions — not AI-controlled handoffs where you abdicate responsibility for ensuring the receiver has what they need.

From handoffs to measurement

You now understand why handoff points are the most dangerous locations in any workflow, and you have a toolkit for making them safer: structured protocols like SBAR, acknowledgment loops that prevent the hot potato problem, acceptance criteria that define what "done" looks like at each transition, self-handoff notes that preserve context across sessions, and AI-assisted gap analysis that catches what you miss.

But there is a question this lesson has raised without answering: how do you know if your handoff protocols are working? How do you measure whether the rework decreased, whether the cycle time shortened, whether the error rate dropped? You cannot manage what you cannot measure, and you cannot measure what you have not defined.

That is the subject of the next lesson. Workflow measurement addresses workflow measurement — the practice of tracking time, quality, and throughput across your workflows. The handoff protocols you designed in this lesson create the clean boundaries that make measurement possible. Without defined handoff points, your workflow is a continuous blur of activity with no clear stages. With defined handoff points, your workflow becomes a series of discrete stages connected by explicit transitions — and each stage, each transition, can be measured, evaluated, and improved.

---

Sources:

1. The Joint Commission. (2017). Sentinel Event Alert 58: Inadequate hand-off communication. The Joint Commission.
2. Haig, K. M., Sutton, S., & Whittington, J. (2006). SBAR: A shared mental model for improving communication between clinicians. Joint Commission Journal on Quality and Patient Safety, 32(3), 167-175.
3. Weinberg, G. M. (1992). Quality Software Management, Vol. 1: Systems Thinking. Dorset House Publishing.
4. Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.
5. Patterson, E. S., Roth, E. M., Woods, D. D., Chow, R., & Gomes, J. O. (2004). Handoff strategies in settings with high consequences for failure. International Journal for Quality in Health Care, 16(2), 125-132.
6. Starmer, A. J., et al. (2014). Changes in medical errors after implementation of a handoff program. New England Journal of Medicine, 371(19), 1803-1812.
7. Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill.