Optimising the part vs the whole

Optimising a part of a business does not necessarily improve the business, and quite often makes it worse. A system's output is limited by its constraint, so improvement anywhere except the constraint adds cost, inventory, or noise without adding throughput. The question to ask before any improvement project is not "does this make the department better?" but "does this move the number the whole system exists to produce?"

Why doesn't improving every part improve the whole?

Because a business is a chain of dependent steps, and a chain's strength is set by its weakest link. Goldratt built The Goal around exactly this: a plant where every machine ran at maximum local efficiency while the plant as a whole missed every shipment. Efficiency at a non-constraint does not create output; it creates a queue in front of the constraint.

The same structure sits inside a service firm. When marketing doubles lead flow while sales capacity is fixed, then response times stretch, lead quality handling degrades, and conversion falls — you paid to make the system worse. Local and global optima diverging like this is one of the recurring patterns catalogued in A Systems-Thinking Guide for Founders, and it is probably the one that wastes the most money.

What does local optimisation look like in a 5–50 person firm?

It rarely announces itself. It looks like diligence:

• Sales "optimises" by chasing only the hottest inbound leads, while the outbound pipeline that feeds next quarter goes unworked.
• Delivery polishes projects to 95% when 85% was the brief, starving the pipeline of capacity for new revenue.
• Finance tightens spend approvals, saving hundreds while sales waits days for tools that unlock thousands.
• A founder A/B tests subject lines for a week on a list of 400 people — a sample where the winner is statistical noise.

Each actor is genuinely improving their patch. The whole slows down. Nobody did anything wrong by their own scoreboard, which is precisely the problem: departmental scoreboards manufacture local optimisation.

How do you optimise for the whole instead?

The mechanism comes straight from constraint theory, adapted for a service business:

1. Name the system's output. For most firms this is signed revenue, or gross profit delivered per month.
2. Find the constraint. When you trace a deal from first touch to cash and ask where work queues up, then the longest queue marks the constraint. It is usually one of: lead flow, sales capacity, or delivery capacity — and in owner-led firms it is frequently the owner's calendar.
3. Exploit the constraint before adding anything. When the constraint is sales time, then strip non-selling work from salespeople before hiring another one.
4. Subordinate everything else. Non-constraint areas should run at the pace the constraint can absorb, even if that means they look "inefficient" on their own metrics.
5. Elevate the constraint — invest to expand it — and then go back to step 2, because the constraint moves.

Run this loop twice a year and you will spend improvement money where it changes the output. Skip it and improvement budgets scatter across whoever argued best.

Where does this bite hardest in growth spend?

Sales and marketing, because that is where local metrics are most seductive. Open rates, click rates, and connection requests are all local optima; the global number is qualified conversations produced per month at acceptable cost. It is why comparing a hire against a system on the global number is so clarifying — the analysis in what a BDR costs vs what an outbound system costs only makes sense once you stop asking "who works harder?" and start asking "what does a qualified conversation cost end to end?" A £35k+/year BDR optimising their own activity stats and a £4,000–£6,500 system feeding a fixed sales calendar are answers to different questions; only one of them is the global question.

The trap runs the other way too. Fixing deliverability, list quality, or copy in isolation while follow-up is broken just delivers more leads to the point of failure — the whole chain view matters more than any single link, which is the connective tissue between this piece and compounding systems: you compound the loop that feeds the constraint, not the loop that is easiest to feed.

Doesn't this mean tolerating waste?

Yes — deliberate, bounded waste at non-constraints. Idle capacity away from the bottleneck is not a problem; it is the price of flow, and hunting it down usually re-creates the queue somewhere worse. There is a longer argument about why removing all slack makes systems fragile, but the short version is that a system tuned to 100% local utilisation everywhere has optimised away its ability to absorb variation. And because the constraint moves after you elevate it, the target of optimisation moves too — expect the diagnosis to be wrong within a year, on a delay you will not see coming (this month's revenue was decided in March).

What does this change on Monday?

List your current improvement projects — tools, hires, training, tests. Against each, write the system-level number it is supposed to move and the constraint it addresses. Anything that cannot name either is local optimisation; park it. Most firms I audit have two or three of these running at any time, absorbing exactly the attention the actual constraint is starved of.

---

Keep the thinking coming: The Format — a fortnightly letter on business and personal systems. Subscribe by email.