Scaling
Find the One Thing Actually Limiting Your Business
Every business has one binding constraint at a time. Here's how to find it, why improving anything else changes nothing, and what to do when it moves.
Businesses rarely have twelve problems. They have one binding constraint and eleven things that feel like problems because the constraint is making everything downstream look broken.
The practical consequence: improving anything that isn't the constraint produces no additional output. It makes the queue in front of the constraint longer, which usually feels like progress and isn't.
Find where work waits
The constraint is the step with things piled up in front of it. So look for waiting, not for effort.
- Where does work sit? Proposals awaiting your review. Projects waiting on one person's availability. Invoices waiting to be raised.
- What has a queue? If anything has a backlog that never clears, that's a candidate.
- What do people wait for? Ask directly — "what are you waiting on right now?" The same answer twice is your constraint.
- Where does elapsed time exceed effort? A two-hour task taking three weeks is a queue, not a workload.
That last one is the most reliable signal, and it's why mapping a process with the waits marked is worth doing before you conclude anything.
The usual candidates
Small businesses cycle through a predictable set:
| Constraint | Looks like | |---|---| | Demand | Capacity idle, people underutilised, revenue flat | | Delivery capacity | Turning work away, lead times stretching | | Cash | Profitable on paper, can't fund the next step | | One person (usually the owner) | Everything waits on one approval or one skill | | A specific skill | One type of work always the bottleneck | | Systems | Time lost to rework, chasing, or finding things |
Note that demand and delivery capacity are opposites, and businesses flip between them. Solving one makes the other binding, which is normal and not a sign of failure.
Exploit before you expand
The instinct on finding a constraint is to add more of it — hire, buy capacity, spend.
Do the cheaper thing first: most constraints have significant unused capacity being wasted on the wrong work.
If delivery capacity is the constraint:
- What proportion of delivery time goes on non-delivery work — admin, scheduling, chasing information? Removing that is free capacity.
- Are your best people doing work someone junior could do?
- Is anything being redone because of an upstream failure? Rework is capacity spent twice.
- Are you serving clients whose contribution is negative? Dropping them creates capacity and improves margin simultaneously.
If the owner is the constraint:
- What decisions could be rules instead of questions?
- What work could be delegated with a proper handoff?
- What are you doing because you enjoy it rather than because only you can?
Exploiting is nearly always cheaper and faster than expanding, and it's reversible. Hiring is neither.
Subordinate everything else
The counterintuitive step, and the one that gets skipped.
Once you know the constraint, everything else should run at the constraint's pace — not at maximum.
If delivery is the bottleneck, running sales flat out produces a longer pipeline, worse lead times, and clients waiting. That harms the business rather than helping it. The right move is to slow acquisition or raise prices until delivery catches up.
Running non-constraints at full speed produces work-in-progress, not throughput. It looks busy and creates nothing.
Then expand it
Only once you've exploited and subordinated: add capacity to the constraint specifically.
Hire for the bottleneck, not generally. Buy the tool that removes that specific wait. Fix that one process.
Adding capacity anywhere else is spending money to make the queue longer — which is exactly what "we hired but nothing got faster" describes.
Expect it to move
The moment you relieve a constraint, something else becomes binding. That's not failure — it's the process working.
The failure mode is continuing to optimise the old constraint out of habit. A business that spent two years capacity-bound keeps hiring after demand becomes the real limit, and ends up with idle people and a cash problem.
So make it a recurring question rather than a one-off project. Put "what is currently limiting us, and what did we do about it this week?" in the weekly review as a standing item, and change the metric you track when the answer changes.
When the constraint is you
Common enough to name specifically, and the hardest to see because it doesn't look like a bottleneck. It looks like being busy.
The signals:
- Work regularly waits on your approval, review or availability
- You are the only person who can do a category of work
- Things that should take a day take a fortnight because of when you got to them
- Your calendar is the scheduling constraint for other people's work
No amount of process fixes this until you change what you personally do — which means decision rules for the recurring judgement calls, real delegation for the work, and accepting that some things will be done differently than you would do them.
This is covered properly in when the founder is the ceiling, because it's a large enough problem to have its own answer.
The mistakes
- Improving non-constraints. Feels productive, changes no output.
- Expanding before exploiting. Buys capacity you already had, wasted.
- Running everything flat out. Produces work-in-progress, not throughput.
- Treating it as a one-off project. The constraint moves; the question is permanent.
- Optimising yesterday's constraint. Idle capacity and a cash problem.
- Not naming yourself. The most common constraint in a small business.
What to do next
Ask everyone, including yourself, one question this week: what are you waiting on right now? Write down every answer.
The thing that appears twice is your constraint. Then, before spending anything on it, list what capacity it already has that's being spent on the wrong work.
The Newsletter
WealthLink Weekly
Business. Money. Marketing. Real Estate. Technology. One email.
One email a week. Unsubscribe anytime.