When a project stalls, the instinct is to look for the person who dropped the ball. I have run enough of these investigations to tell you that you will almost never find one. Trace a stuck project back to its origin and you usually find a moment where work passed from one person to another and something invisible got lost in the gap. The designer finished. The engineer started. But the reason behind a particular choice, the constraint the client mentioned in passing, the half-decision that everyone assumed was settled, none of that made the trip. The work did not fail in the doing. It failed in the handoff.
This is the most underrated problem in project management, and it is underrated precisely because it is nobody's fault in particular. Everyone did their part. The failure lives in the seam between the parts, which means no individual feels responsible for it and no individual can fix it alone. If I could improve only one thing about how a team operates, I would not touch how people do their work. I would fix how they pass it along.
Context is the thing that does not travel
When work moves between people, the artifact moves easily. The file, the ticket, the document, all of it transfers with a click. What does not transfer is the context, and the context is most of the value. Why this approach and not the obvious one. What we already tried and abandoned. Which parts are firm and which are still soft. What the customer actually cares about underneath what they asked for. All of that lives in the head of the person handing off, and unless something forces it out, it stays there.
The cruel part is that the person handing off does not feel the loss. To them the context is so obvious it barely registers as information. They have been steeping in it for days. The person receiving the work inherits a clean artifact with a hollow center, and they do one of two things, both expensive. They either guess, and rebuild a version of the missing context that may be wrong, or they go back and ask, which means the handoff was not really a handoff at all, just the start of a slow conversation that the original person now has to fund out of their own focus.
Either way the team pays. I have come to think of every handoff as a small act of translation, and like any translation, it loses something unless the translator is deliberate. The teams that move fast are not the ones with the most talented individuals. They are the ones who have made handoffs cheap and lossless.
The hidden cost of the casual handoff
Most handoffs are casual, and that is the problem. Work gets passed along in a chat message, a verbal "can you pick this up," a ticket assigned with a one-line title. None of these carry enough to actually continue the work, so each one generates a hidden round of clarification. The receiver asks a question. The sender, now context-switched into something else, answers slowly. The thread drags across days while the work sits idle, marked "in progress" but actually parked.
I once mapped the real timeline of a feature that had taken six weeks to ship and everyone agreed had been "hard." When I laid it out, the actual work added up to maybe nine days. The rest was waiting at handoffs. Waiting for the spec to be clarified. Waiting for the design to be re-explained. Waiting for someone to confirm a decision that had, in fact, already been made but never written down. The feature was not hard. The handoffs were leaky, and the leaks added a month.
The teams that suffer most from this are the cross-functional ones, which is to say all the important ones. Anything valuable crosses boundaries: design to engineering, sales to delivery, support back to product. Every boundary is a handoff, and every handoff is a place where context can fall on the floor. Team collaboration is mostly the art of crossing those boundaries without dropping anything.
Designing a handoff that holds
A handoff that works is not about more documentation. It is about the right shape of information at the moment of transfer. Over time I have come to insist on a few things, and they are simpler than they sound.
The first is that a handoff must include the why, not just the what. The receiving person needs to know the intent behind the work, because intent is what lets them make good decisions about the hundred small questions the artifact does not answer. A handoff that says "build this" without saying "because the customer needs to do X" guarantees a round of clarification.
The second is an explicit statement of what is decided and what is still open. Most handoff failures are not missing information, they are ambiguous information, where the receiver cannot tell whether something is a firm constraint or a placeholder. Naming the open questions directly, "the color is final, the copy is a draft," removes the most expensive kind of guessing.
The third is that the handoff has to be attached to the work, not floating beside it. Context delivered in a chat message is context with a half-life of about a day before it scrolls away. The why, the open questions, the relevant decisions, all of it has to live on the task itself, so that the person doing the work in three days, or the person who inherits it in three weeks, finds it exactly where the work is.
This last point is where workflow and tooling actually matter. In a setup where the conversation, the documents, and the task live in separate systems, a clean handoff is almost impossible, because the context is structurally scattered before anyone even tries to pass it. When the work and everything around it live in one place, the handoff has a chance of being whole. It is one of the reasons we built Atlas so that a task carries its own thread, its own files, and its own decisions. The context cannot fall on the floor if there is no floor between the systems for it to fall through.
The ritual that prevents the silent drop
Tools help, but the deeper fix is a small change in habit, and it costs almost nothing. Before work changes hands, the person handing it off writes a short summary aimed at the specific person receiving it. Not a formal document. A few honest sentences: here is what this is, here is why it matters, here is what is settled, here is what you will have to decide, here is the one thing that will trip you up if I do not warn you about it.
That last clause is the one that earns its keep. Every piece of work has a landmine, the non-obvious thing the originator knows and the receiver does not. Forcing yourself to name it is the single highest-return habit in any operations practice I have seen. It takes two minutes and it routinely saves days.
We also made one cultural rule explicit. The handoff is not complete when the sender lets go. It is complete when the receiver confirms they have what they need. That small reversal changes everything, because it puts the burden of a successful transfer on the person who has the context, where it belongs, rather than on the person who is missing it. A handoff is a promise that the work can continue, and you do not get to call a promise kept just because you stopped holding the thing.
The handoffs you forget to count
Most teams picture a handoff as work moving from one person to another, but two of the most expensive handoffs do not look like that at all. The first is the handoff to your future self. You set a task down on Friday, certain you will remember exactly where you left it, and on Monday you are a stranger to your own work, re-deriving decisions you already made. The cure is the same one we use between people. Before you stop, write the few honest sentences. Future you is a different person with none of today's context, and they deserve the same handoff you would give a colleague.
The second is the handoff across time zones, which remote and distributed teams live with constantly. When the receiver is asleep at the moment of transfer, every gap in the handoff costs a full day, because the clarification round cannot even begin until they wake up. Async work does not tolerate leaky handoffs. It punishes them harder than anything else, which is why the teams that distribute well are almost always the teams that write things down with unusual discipline. They had no choice. The clock made sloppy handoffs unaffordable, and they adapted. The lesson holds even for teams in one room: design the handoff as if the receiver is on the other side of the world and will not be able to ask you a single question. You will be amazed how much that constraint improves the transfer.
Why this is the highest-return fix you have
Improving how individuals work has limits. People are already capable, already trying, and there is only so much faster any one person can go. Improving how work passes between people has almost no ceiling, because the losses there are pure waste. Nobody is getting value from the context that evaporates at a handoff. It is not a tradeoff or a hard problem of skill. It is just a leak, and leaks can be sealed.
I keep coming back to the same picture when I think about a healthy team. It is not a collection of heroes doing brilliant individual work. It is a relay where the baton never touches the ground, where each person receives the work whole, understands not just what to do but why, and passes it on the same way. The brilliance is in the exchange. Get the handoffs right and the rest of your workflow gets dramatically easier, because the work stops dying in the gaps and starts actually moving from one set of hands to the next.