If you have watched a project fail in a way that looked like it came from nowhere and turned out on inspection to have been the handoff, this piece is for you. What failed wasn’t the delivery. It was the moment between the delivery and the receipt, and most organizations have no protocol for that moment at all.
The movement on the rock is not where people die.
This is counterintuitive. From the ground, watching a technical climb, the lead climber moving up and over difficult terrain looks like the dangerous moment. The exposure is visible. The consequence of a fall is obvious. But the experienced climber knows that while leading, the system is at its most coherent. The protection is placed, the rope runs cleanly, the focus is total. The dangerous moment is the transition.
At the belay station, where one climber arrives, gear is exchanged, anchors are transferred, and the lead changes, the system passes through a state of organized complexity that is uniquely vulnerable to failure. Two people are simultaneously clipped and unclipped from different components of the same system. Gear moves from harness to harness. Commands are exchanged under conditions where wind, fatigue, and the cognitive residue of the pitch just completed make miscommunication not just possible but likely. A carabiner dropped here cannot be retrieved. A miscommunication here (“off belay” answered with “belay off” before the new anchor is loaded) breaks the system at the exact moment when the system must be whole.
Every experienced climber I know has a protocol for the belay station. Not a preference. A protocol. A specific, named sequence of actions and verbal confirmations that does not vary regardless of conditions, fatigue, or familiarity with the partner. The protocol is not there because experienced climbers are careless. It is there because the transition is structurally different from the movement, and what keeps you safe on the movement does not keep you safe at the station.
This is the most precisely applicable leadership insight I have carried from technical climbing. The work rarely fails when a team is deep in their own domain. Projects fail in the transitions.
Where the load gets dropped
Organizational handoffs have a structural parallel to the belay station that is almost never examined explicitly, and almost never has a protocol.
Design completes a component and hands it to engineering. Strategy produces a roadmap and hands it to product. Sales closes a deal and hands it to customer success. Research produces a finding and hands it to the team that will act on it. In each of these transitions, two things happen simultaneously. The delivering team disengages from the problem, and the receiving team engages with it. This is the organizational equivalent of one climber unclipping while another clips in. It has exactly the same failure modes.
The assumption that is most commonly dropped in organizational handoffs is not documented in any file and cannot be transferred by handing over a document. It is the tacit knowledge that accumulated in the delivering team during the work. Why a particular decision was made, what was considered and rejected, what the system is sensitive to, where the edges of the specification are fragile. This knowledge lives in the heads of the people who did the work. When those people disengage, the knowledge does not automatically transfer to the document they leave behind.
The receiving team begins from the handoff artifact (the spec, the roadmap, the brief) and assumes it contains what they need. It contains what the delivering team knew how to write down. These are not the same thing. The gap between them is where the project accumulates the technical and strategic debt that surfaces later as a failure that “came from nowhere.”
It didn’t come from nowhere. It came from the belay station.
“Sending the file is unclipping from one anchor. It is not yet clipped to the next one. The system is in the air.”
The protocol question
The specific discipline that belay station practice develops is the habit of treating the transition as a distinct phase requiring distinct attention. Not an afterthought to the pitch, not a preamble to the next one, but a moment that has its own requirements and its own failure modes.
In practice, this means asking explicitly: what does the receiving team need to know that is not in this document? Not “is the document complete?” The document is always complete from the perspective of the person who wrote it. The question is what tacit knowledge lives in the heads of the people who did the work, and how to transfer it before they disengage.
Teams that do this well have developed specific handoff practices that treat tacit knowledge transfer as a primary deliverable, not an optional supplement. A design-to-engineering handoff that includes a walkthrough of the decisions that aren’t visible in the spec. A strategy-to-product handoff that explicitly names the assumptions that would invalidate the roadmap if they turned out to be wrong. A research-to-team handoff that distinguishes between what the data shows and what the researcher inferred from the data, and makes both visible.
These practices are not complicated. They are also almost never done, because the delivering team is already mentally on the next pitch and the receiving team is eager to start moving. The belay station feels like a pause. It is not a pause. It is the moment the system is most vulnerable, and the moment that most repays deliberate attention.
Optimizing the wrong thing
The organizational default is to optimize individual phases of work. Sprint velocity. Design throughput. Research turnaround. Each team measures how fast it can complete its phase and deliver to the next one. The handoff itself is treated as instantaneous, as if the act of sending a file or scheduling a kickoff meeting constitutes the load transfer.
It does not. Sending the file is unclipping from one anchor. It is not yet clipped to the next one. The system is in the air.
High-performing teams have learned that optimizing individual phase velocity while ignoring handoff quality produces a specific failure pattern. Fast work that fails at the transitions, requiring expensive rework that cancels the velocity gains. The project that moves at ten points per sprint and loses thirty points at every handoff is slower than the project that moves at eight points per sprint and loses nothing at the transitions.
The best teams don’t just think about their own work. They think about what the next team needs from them in order to start well. They treat the quality of the handoff as a measure of their own performance. Not just the quality of the deliverable, but the quality of the context transfer that makes the deliverable usable.
This is the difference between leaving the carabiner neatly racked and confirming that the next climber knows which piece goes on which piece of protection and why. The gear is the same. The transfer is completely different.
THE TEAM TEST
Think about the last handoff your team was involved in, either delivering or receiving.
If you were delivering: what did you know about the work that wasn’t in the document? Did you transfer it? If you are honest about the tacit knowledge that stayed in your team’s heads when you handed over, what would the receiving team have needed to know that they didn’t get?
If you were receiving: what did you discover in the first week that you wish you had known before you started? What question, asked at the belay station rather than a week into the pitch, would have saved the rework?
The answer to both versions of that question is your handoff protocol. Not a document. A practice. A specific set of things you do and say and confirm at the transition, every time, regardless of familiarity with the team or confidence in the deliverable.
The carabiner doesn’t know you have done this a hundred times. Neither does the project.
