The image is a diptych.
On the left: a single pair of hands, three silver balls in motion, the cascade arc visible as a blur of light between them. Everything that happens in this image happens inside the boundary of one person. The left hand and the right hand are in conversation with each other. The coordination is internal.
On the right: two pairs of hands, four clubs crossing in the space between them. The clubs are mid-pass - in transit from one juggler to the other. What happens in this image happens in the space between people. The throw is not complete until the other person catches.
These are not two levels of the same skill. They are two different architectures.
What changes when you add a partner
The cascade and the club pass are not separated by difficulty. They are separated by architecture.
In the cascade, when the timing drifts, you feel it in your own hands. The ball arrives at the wrong moment and you adjust your next throw before you consciously decide to adjust it. The feedback loop runs entirely within one nervous system. You drop, you retrieve, you restart. The cause of the drop and the correction to the next throw are both accessible to you from inside the pattern.
In the club pass, when the timing drifts, you may feel it as the club arriving at the wrong angle or the wrong moment - but the source of the drift may be in the other person’s previous throw. You cannot fix it from your side alone. The adjustment requires the other person to change something on their side, and for both of you to find the new shared timing together. Debugging requires conversation. The repair has to be negotiated, not just executed.
This is also why club passing is more fragile during learning and more resilient in execution. The learning phase exposes every timing misalignment in the shared structure, because both people are calibrating simultaneously. But once the shared timing is established - once the mutual pattern is stabilised across two nervous systems - the two-person pattern holds itself together in ways that neither person could maintain alone. The constraint becomes the structure.
What organisations get wrong about handoffs
Most change programs are designed like cascades - structured as internal coordination problems within a team, a department, a function. The governance model assumes that if each team does its part, the transitions between them will work.
But many change programs are structurally club passes. The integration between a technology implementation and a change management workstream cannot be debugged from either side alone. The clubs cross in the space between the two teams, and both teams need to have their hands open at the right moment.
The failure of these integrations almost always looks like a handoff problem from the inside. “IT didn’t communicate what was changing.” “Change management didn’t understand the technical constraints.” “The release happened without the training being ready.”
These are not communications failures. They are timing structure failures. The two teams were running internal timing - each optimising their own arc - without establishing a shared clock that both programs could coordinate against.
The cascade you debug alone. The club pass you debug together. Both require that you actually pick up what dropped.
The diagnosis: which kind of pattern are you running?
The diagnostic question for any multi-team change is not “do we have good governance?” It is “is this a cascade or a club pass?”
If the answer is cascade - if the coordination problem is genuinely solvable within each team’s own boundary - then strong individual team capability is enough, and cross-team governance is mainly coordination overhead.
If the answer is club pass - if there are clubs moving between teams in real time, and both teams’ timing affects whether those clubs can be caught - then individual team capability is necessary but not sufficient. The shared timing structure has to be explicitly established. Both teams have to know what the shared clock is, and both teams have to be in a position to catch what is being thrown.
| Juggling | Cascade vs. club pass in organisational change |
|---|---|
| Cascade: one person, internal timing, self-correcting feedback loop | Single-team change: one department redesigning its own process, with feedback from within the team and correction within the team's hands |
| Club pass: two people, shared timing, externally-correcting feedback - each person's throw affects the other's catch | Cross-functional change: technology and operations both need to move at the same moment, and neither can succeed if the other is on a different timing |
| The cascade can be practiced alone - you can work on your timing without a partner | A single team can prototype its own process change in isolation, getting the internal timing right before bringing it to the boundary |
| The club pass cannot be practiced solo - the pattern requires both people by definition | Cross-functional integration cannot be 'prepared' by each team independently and then combined. The shared timing has to be built together, through the actual exchange |
| Club pass errors look like one person's bad throw - but the source is often the other person's previous catch, which was off because of the one before that | Integration failures look like one team's missed deadline - but the root cause is usually a shared timing assumption that neither team ever made explicit |
Read next: The Club Pass Is a Contract - how the throw to another person creates an obligation that runs in both directions. The Mathematics of Passing - the formal mathematical structure that governs the shared timing described here. The Mandala of Group Juggling - what the club pass architecture looks like when scaled to six people.