Two open hands. A silver club spinning between them. Neither is holding it.
The club is mid-flight - past the first hand, not yet in the second. The throw has been made. The catch has not been confirmed. In this gap between release and reception, the entire logic of collaborative systems lives.
The club pass is not a delivery. It is a contract.
What has to happen before the throw
In a solo juggling cascade, the juggler makes all the decisions. Where the ball goes, when it leaves, how high - every parameter is under their control. The catch is made by the same person who made the throw, with full knowledge of both.
In a club pass, this changes completely.
Before the club leaves the first juggler’s hand, both parties have to have agreed on: the timing of the throw within their shared rhythm, the height of the arc, the number of spins in the rotation, and the exact position where the receiving juggler needs to be standing. None of this is confirmed at the moment of catch. All of it is agreed before the moment of throw.
If the agreement is wrong - if either party has a different mental model of the throw - the club arrives at the wrong angle, the wrong height, the wrong spin count. The catch fails. Not because of anything that happened in the air, but because of something that was not aligned before departure.
The API contract
A REST API is a club pass made formal.
The producer and consumer agree, before any request is sent, on: the endpoint structure, the expected payload shape, the authentication method, the response codes, and the error format. This agreement - the API contract - is documented before either party sends or receives anything. The contract is the pre-flight alignment that makes the in-flight message catchable.
When a contract is violated - when the producer changes a field name without updating the documentation, when the consumer sends a payload shape the producer was not expecting - the club arrives at the wrong angle. The catch fails. The error in the response is not the problem. The failure of alignment before the throw is the problem.
The same contract in team handoffs
The club pass is not only a technical metaphor. It describes every handoff between people - in organisations, in projects, in any collaborative work where one party’s output becomes another party’s input.
The sales team passes to implementation. The design team passes to engineering. The on-call engineer passes to the morning team. Each of these is a club in the air between two parties. Each of them requires a pre-flight alignment: what is the shape of the handoff? What is the expected state of the work? What needs to have been done before the pass, and what will be done after?
| Juggling | The club pass in practice |
|---|---|
| Club pass: both parties agree on spin count, height, and timing before the throw | API design: producer and consumer agree on schema, auth, and error format before the first call |
| Wrong spin count: club arrives at uncatchable angle - nothing in the air is wrong, everything before the throw was | Breaking API change: field renamed without contract update - request arrives in a format the consumer was not expecting |
| Shared rhythm: both jugglers synchronise their timing before the first pass begins | Service-level agreement: producer and consumer agree on latency, availability, and retry behaviour before integration |
| Sprint review handoff: what the last sprint produced, what the next one will start from | Team handoff: what is the state of the work, what decisions have been made, what remains open |
| Club in the air: neither party controls it - both parties responsible for the contract that sent it correctly | Message in transit: neither producer nor consumer can change it once sent - the contract that governed the send is what matters |
The most common failure in collaborative systems is not in the execution. It is in the pre-flight agreement that was never made explicit. The club arrives uncatchable not because the throw was bad, but because nobody told both jugglers how many times it should spin.
The shape of a clean pass
Two open hands, both extended, neither gripping. The club is between them - spinning, committed, in flight.
Neither hand is closed. The catcher’s hand is open because the catch has not happened yet. But the catcher’s position is already established - the feet are planted, the arm is at the right height, the hand is open at the right angle. The catcher has already made the decision to receive before confirmation that the throw was catchable.
This is the operating state of any effective collaborative system. Both parties have committed to the handoff before it completes. The trust in the shared contract precedes the delivery of the object.
Building the contract before the first throw
In club passing, two jugglers do not attempt a pass without establishing the shared rhythm first. They count together. They synchronise their base pattern. They agree on the timing before the first club goes across. This is not bureaucracy - it is what makes the throw catchable.
In collaborative technical work, the same preparation produces the same result. An API designed collaboratively - with producer and consumer both at the table before any code is written - is more likely to be catchable than one designed unilaterally and documented after. A sprint handoff with an explicit definition of done is more catchable than one that assumes both parties share the same implicit understanding.
The contract is not overhead. It is the alignment that makes the throw catchable. Without it, everything that happens in the air is gamble.
Further reading
- Richardson, M.J., Marsh, K.L., and Schmidt, R.C. (2005). “Effects of visual and verbal interaction on unintentional interpersonal coordination.” Journal of Experimental Psychology: Human Perception and Performance, 31(1), 62-79. Establishes that two people engaged in a shared rhythmic task develop perceptual-motor coupling without explicit coordination - the mechanism behind passing partners who develop shared timing automatically through practice.
- Lewbel, A. (1995). “The Science of Juggling.” Scientific American, 273(5), 92-97. Covers the mathematical and physical constraints of passing patterns, including the pre-flight agreement requirements encoded in siteswap timing.
- Beek, P.J. (1989). Juggling Dynamics. PhD thesis, Free University Amsterdam. The foundational analysis of timing coordination in juggling - includes the inter-juggler timing requirements and failure modes when shared timing breaks down.
Read next: The Devil Stick Runs While You Work - the pattern of autonomous systems that need occasional correction but not constant contact. The Mathematics of Passing - the formal mathematical structure of what makes a passing pattern valid. The Mandala of Group Juggling - what the pre-flight agreement produces at the scale of six jugglers.