Every system has one place that holds everything else

01The principle

A business is a system with something flowing through it: demand becomes sales, sales become commitments, commitments become money. The throughput of the whole system equals the throughput of its narrowest point.

Which leads somewhere uncomfortable. Effort spentanywhere else doesn't produce a smaller result. It produces no result at all.

02Where the method comes from

The foundation is Goldratt's Theory of Constraints. It is forty years old, tested on manufacturing floors worldwide, and there is nothing secret about it.

I added three things it doesn't have, because it was written for factories.

A factory has data by definition — production counts. In a small business half the numbers simply don't exist, and they have to be reconstructed from conversation and indirect evidence. That is separate work, and it takes up most of the diagnostic.

A factory has no owner as a variable. In a small business the owner is half the system — and most often the owner is the constraint.

Third: on a factory floor the bottleneck is physical — a machine, a shift, floor space. In a small business the constraint is more often a rule. An agreement, a habit, a compensation scheme, a decision made seven years ago under different conditions.

03Flow and frame

Two axes. The flow answers where. The frame — everything the flow rests on — answers why.

The flow is a loop, not a line: money returns to demand through repeat purchases and referrals. Treat it as a line and all your work becomes acquisition. Treat it as a loop and it becomes economics.

The frame is built top-down: the owner decides which systems exist, systems decide which processes are possible, processes decide which people last. It is read bottom-up: people can't cope because there is no process, because there is no data, because the owner would rather not see it.

04Symptom

An owner usually sees the symptom where it hurts: not enough sales, thin margin, cash gaps, an overloaded team, constant owner involvement.

That is not yet the constraint. You name a problem from the frame — I look for the place in the flow that produces it.

05Eight blocks

These are the lenses. The first four are the flow, the next four the frame.

All eight are not walked evenly. Eighty per cent of the time goes into one flow block and one frame block — the rest is covered quickly, to rule out alternatives.

06Why one, and not a list

the first thing I say to an owner

I am not saying you have one problem. You have many, and they are all real. I am saying that right now one of them determines the result — and while it stays in place, work on the others won't change anything.

The arithmetic is simpler than the explanation. Say the funnel looks like this:

The first two rows are what most people do. The third is where to start.

And effort outside the constraint doesn't return zero — it returns negative. A hundred sales against a capacity of sixty means forty commitments that cannot be met: either a queue and late delivery, or a refusal after payment. Marketing worked, sales worked, the system got worse.

Why a list fails structurally

The sum of local optima is not a global optimum. The warehouse optimises for never being out of stock — cash freezes. Sales optimise for revenue — margin falls while turnover rises. Production optimises for machine utilisation — the warehouse fills with the wrong items. All three report their targets met, the owner looks at the account and cannot understand why it's empty.

A list of problems reinforces exactly this failure: it hands tasks to departments, and each starts optimising its own.

Where "one" doesn't hold

Three boundaries, better known in advance.

Three independent lines mean three flows and three constraints.The constraint is one per flow, not one per company. So the first job is establishing where the flows begin and end.

Cutting costs also produces an effect — on profit, not on throughput. The difference is that savings have a floor and throughput has no ceiling.

The stage feeding the constraint needs reliability, not speed.Adding capacity there is wasted. Making it predictable, so the constraint never starves, is not. These are different jobs, and they get confused constantly.

07Example

The organisation was producing volume. The income wasn't reaching anyone. A classic signal from the Money block: turnover yes, cash no.

The assumed problem was "we need to sell more". That is an answer from the frame, and it explains nothing — they could sell. There was nobody to sell to.

The constraint turned out to be structural. A rule of the system: the right to author compensation only arises when personal sales exist. And a personal sales channel did not physically exist — six years of effort inside the old channel kept hitting a ceiling, because that channel doesn't create new leads, it only spends existing acquaintances.

The channel was built and the constraint disappeared. The code was a tool. The channel was the solution.

Full case, with numbers and what failed →

08What happens next

A system doesn't get "fixed". It gets stronger, reaches the next wall, and stops there.

When a constraint disappears, the system doesn't become problem-free. It simply hits the next narrow point. I name it in advance — so that three months later it doesn't look like a new breakdown.

The next constraint goes into the document before work begins, with a trigger condition: "the constraint moves to sales once production consistently exceeds a hundred units a month." When that happens, you see the system behaving predictably. That is the test of the method.

Inertia

The half nobody writes about. Rules invented for the old constraint survive after it's gone — and become the new constraint. Almost every rule-based constraint I find is a fossilised step from a previous cycle.

So every rule we put in gets a review date.

09Guarantees

I guarantee the process and the deliverable. Never a financial outcome.

Instead of percentages, two things you can verify. I name the next constraint in advance, with its trigger condition. And if the constraint is removed and the system's result doesn't move, the diagnosis was wrong — and I redo the diagnostic at my own cost.

10Who I don't work with

Better established now than in week three.

• During a cash gap.You need money tomorrow; a diagnostic pays off over months. I'll help in the mini-diagnostic — beyond that, no.
• If you need a list of recommendations rather than one named constraint.That is a different service, and it costs less than I do.
• If it's already settled which conclusions are not allowed.The diagnostic will run straight into them, and you'll have paid for a finding you won't use.
• If the decision is made and you need justification.You need an executor, not a diagnostician. Cheaper and faster.
• If the owner doesn't have two hours a week for this.The plan won't be executed, and that becomes visible in week two.

11Automation

We don't automate what isn't documented and doesn't work manually. Automating chaos gives you fast chaos — now with an invoice attached.

Almost nobody asks the third question, and it saves the most. The fastest CRM on a stage that isn't the bottleneck adds not a single unit of throughput.

How this becomes implementation →