There is a persistent misunderstanding about what juggling requires.
The misunderstanding is that juggling is about multitasking. Three balls, two hands, one brain - surely you must be tracking everything at once?
You are not. And discovering this - in your hands, not as a concept - is one of the most useful things juggling teaches.
What the juggler is actually tracking
Watch an experienced juggler’s eyes. They are not moving rapidly between the three balls. They are mostly still, focused on a single point at approximately the top of the cascade’s arc.
Each ball passes through this zone in turn. The juggler reads the ball there, where it is briefly slow and easy to track, and the rest of the pattern - the catching at the bottom, the throwing from the hands - happens without direct visual attention.
The CPU core analogy is not wrong
Computer scientists will recognise this structure.
A single CPU core cannot actually execute multiple instructions simultaneously. What it does is time-slice: switching between threads quickly enough that they appear to run in parallel. The apparent multitasking is context-switching at high speed, not genuine concurrency.
Juggling looks like multitasking for the same reason. The balls are in the air simultaneously. But the attention is not. The juggler’s conscious processing is sequential - one ball checked at the apex, then the next, then the next - while the motor system handles the lower-level operations in parallel through learned automation.
The performance limit in juggling is not the number of balls. It is the frequency of the required attention checks. The bottleneck is the single thread of conscious attention, not the volume of work.
What breaks focus and what doesn’t
Juggling also clarifies what kinds of additional load interfere with the pattern and what kinds don’t.
If you ask a juggler a simple question while they are running a steady cascade, they can usually answer. The motor program continues. The apex check continues. The answer emerges from a different system. Mild parallel processing is possible.
If you ask the juggler to do a mental arithmetic problem while juggling, the cascade almost always breaks. Not because the arithmetic is hard but because it competes for the same limited attentional resource that is monitoring the apex.
Designing for the right attention
In technical systems, this translates directly to a design principle: automate everything that does not require genuine attention, so that genuine attention can go where it is irreplaceable.
This is what good alerting design looks like. Not more alerts - most alerts compete for the same attentional thread and produce noise rather than signal. Fewer, more meaningful alerts that appear only when the apex check is genuinely needed. Everything else automated, monitored passively, and surfaced only on exception.
The juggler who has mastered the cascade is not monitoring more. They are monitoring less, more effectively, at exactly the right point in the cycle.
That is the skill. Not expanded attention, but deployed attention - knowing what to watch, and trusting the subroutines to handle the rest.
Read next: Feedback Loops as Infrastructure - how the apex check IS a feedback loop.