There are two ways to have the wrong number of props, and they feel completely different from the inside.
The first: you have four balls, but you can only juggle three. One ball stays in your hand or on the floor between attempts. The fourth prop is not helping. It is dead weight you are carrying for no reason, or it is adding drops you could avoid.
The second: you can juggle five balls, but you only have three. The skill is there. The technique is calibrated for a larger pattern. But you are running a five-ball juggler’s movements on three balls - which means you are either leaving capacity on the table, or more often, you are breaking the pattern because your timing is built for objects that are not there.
Both are planning failures. Neither is a skill failure. And they require opposite solutions.
Having more than you can use
Four balls, three in the air is the classic overprovisioning scenario.
In infrastructure terms: you have provisioned eight servers, but your application is single-threaded and uses one. Seven are idle, costing money, handling zero load. The resources are there. The architecture to distribute work across them is not built.
The same happens with SaaS tier upgrades. An organization moves to an Enterprise plan for the features, then finds that most of those features require workflow changes, training, and configuration that have not happened. The capability is paid for. The pattern to use it has not been designed. The bill grows. The extra props sit on the floor.
Having less than you can use
Can juggle five, have three is the less-discussed mismatch - and it is often harder to recognize because the visible symptom looks like the system is too slow, not that the team is too capable.
A team with the expertise to run a highly distributed system, given budget for three short-memory instances, will be frustrated in ways that look like a technical limitation of the stack. But the stack is limited. The skill is not the constraint. The props are.
The LLM version of this problem is recognizable once you see it: a team building a sophisticated agent architecture, capped at 10,000 tokens per minute by their API tier, watching responses cut off and requests queue up. The technique is sound. The quota is wrong. The answer is not to simplify the architecture. The answer is to upgrade the plan or redesign around the actual constraint - because the skill to use more is already there.
| Juggling | Infrastructure |
|---|---|
| 4 balls, can only juggle 3 - one idle | 8 servers provisioned, single-threaded app uses 1 |
| Enterprise plan, patterns not built to use it | SaaS Enterprise tier paid for, features unused |
| 5-ball skill, 3-ball quota | Expert team capped at wrong API tier |
| Fix: build capability to use all props | Fix: architecture + workflow changes, not more resources |
| Fix: get more props matching the skill | Fix: upgrade the plan or redesign around the real constraint |
Three different props, three different physics
A juggler running three different props - a ball, a club, and a ring - is running three different physics at once. The ball is forgiving - a slight mis-throw self-corrects. The club has weight and rotation requirements - wrong spin and the catch becomes impossible. The ring must stay vertical or it wobbles unpredictably out of the pattern.
Running a club-passing technique with a ring in your hand is not the same as running it with three clubs. The props are not interchangeable without adjusting technique, timing, and catch position. Substituting one for another without making those adjustments produces a pattern that looks like it should work and consistently does not.
The same principle applies to infrastructure substitutions. Replacing a dedicated message queue with a polling loop changes the timing physics of the pattern. Swapping an in-memory cache for a file system changes the latency profile. The architecture cannot be abstracted away from the props it runs on.
Reading the mismatch correctly
Simplifying the system to fit current resources makes the expertise less valuable, not the bottleneck less painful. You lose the capability you already have.
The diagnostic before any fix is: which direction is the mismatch?
If skill exceeds resources, the answer is more resources. Simplifying the system to fit current resources makes the expertise less valuable, not the bottleneck less painful. You lose the capability you already have.
If resources exceed skill, the answer is more capability - better tooling, architectural learning, workflow changes that unlock the tier you are paying for. Adding more resources to a system that cannot use the ones it has just increases the idle inventory.
Getting the count right
A juggler with arms wide, a different prop at each reach, holds a position that cannot be sustained if any one of the three is wrong - wrong weight, wrong timing, wrong technique. The pattern requires that the props match the skill and the skill match the props.
Before scaling in either direction, the question is: which of these two mismatches do I actually have? The answer determines everything that comes next.
Read next: Count Your Props Before You Start - how to avoid the wrong-number problem from the start.