The Juggling Co.

Ideas · Tech · 3 min read · Updated 30 April 2026

Juggling and Technology — From Cascade to Cloud

Three balls in the air, n services in production, k decisions in flight. The pattern is the same — and once you've felt it physically, you read it differently in code.

Tech

Most of the time I spend at AWS re:Invent ends up with someone asking why the stage is closer to a circus than a keynote. The honest answer is that they’re the same stage. A juggler holds a small system together at the edge of capacity. A platform engineer does the same thing on a slower clock with bigger props.

The cascade is a control loop

A juggling cascade is a control loop disguised as a trick. Eyes track, brain predicts, hands execute, the next throw corrects the last drop. The loop doesn’t pause for novelty — when you add a new prop or change the rhythm, you negotiate the change while the loop keeps spinning.

Every cloud system worth shipping is the same shape. Health checks predict. Auto-scaling executes. Deploys correct. Rollbacks recover. The clock is slower — but if the loop ever stops, the system stops.

Mapping it out

Juggling Cloud & systems
Three-ball cascade — alternating throws on a fixed beat Round-robin load balancing — even distribution across n healthy targets
The apex — the moment between throw and catch where you can plan The deploy window — the gap between traffic spikes where you can ship
Adding a fourth ball collapses the cascade into a fountain Adding a region collapses your single-cluster mental model into multi-master
A drop costs you one beat — if you don't panic and chase it A failed pod costs you one window — if you let the orchestrator do its job
Different-weight props — same pattern, different hand-feel Different runtimes (Lambda, ECS, EKS) — same shape, different tuning
Pass to a partner — you trust their timing or you both drop Cross-team contracts — you trust the SLA or the integration breaks
The pattern transfers in both directions. Engineers who learn to juggle make better operators. Jugglers who learn AWS make stranger keynote speakers.

AI changes the prop, not the pattern

The current wave — agents, MCP, Q-style assistants — adds a new prop to the cascade. The prop is unfamiliar. The pattern isn’t. You still:

  1. Predict what each tool will do under load.
  2. Throw the right call to the right service at the right time.
  3. Catch the result. Validate it. Don’t trust the catch you didn’t see.
  4. Recover when the model returns something the next step can’t use.

The teams shipping the best agentic systems aren’t the ones with the deepest theory. They’re the ones who’ve shipped enough cloud to know what the loop feels like — and have therefore developed the muscle to add a ball without dropping the rest.

Why this is the through-line

The Brain essay is about the substrate. The Change essay is about the people. This one is about the medium I actually work in — AWS, AI, and the cloud platforms that show up in every conference talk I give. If you came here from the AWS Hero profile, this is the page that explains why my conference badge says both “Community Builder” and “Performer” — and why those words are doing the same job.

Related videos