Fast, Cheap, or Good: Why You Can't Have All Three

Someone asks you to deliver a project that is fast, cheap, and excellent. You nod and promise all three. Then reality arrives, and one of them quietly collapses - usually at the worst possible moment.

That collapse is not bad luck. It’s a rule baked into how every system works: push hard on one thing, and you pay for it somewhere else. The skill worth having is learning to see the price in advance and choose it on purpose, instead of being ambushed by it later.

Why this matters

You make trade-offs constantly, whether or not you notice them. Hiring faster usually means hiring worse. Cutting costs usually means cutting the slack that saves you in a crisis. Closing more sales usually means dumping more work on whichever team is already drowning.

When you can’t see the trade-off, the system makes the choice for you - invisibly. Corners get cut, people burn out, debt piles up, and a deadline you thought was safe slips. Learn to spot the price tag and two things change: you stop making promises that physics won’t let you keep, and you start fixing the thing that actually moves the needle instead of the thing that’s easy to measure.

Two ideas run through everything below. The first is the trade-off: getting more of one thing usually means accepting less of another. The second is the local-vs-global trap: making every individual part of a system as good as it can be does not make the whole as good as it can be. Often it makes the whole worse. Once you see these, you can’t un-see them.

There is no free lunch

A trade-off is simply a situation where getting more of one good thing requires giving up some of another. Speed costs quality or money. Cutting costs costs resilience or capacity. Squeezing out short-term profit costs long-term reputation or talent.

This isn’t just folk wisdom. In 1997, researchers David Wolpert and William Macready proved the No Free Lunch theorem: no problem-solving method is best for every kind of problem. Whatever an approach gains on one type of problem, it loses on another. The math formalizes what experience already teaches - you cannot win everywhere at once.

So here’s a rule of thumb that almost never fails. If someone claims they improved one thing with zero cost anywhere, they haven’t beaten the trade-off. They’ve either moved the cost somewhere they aren’t looking, or pushed it into the future where it’ll arrive with interest.

The Iron Triangle: fast, good, cheap - pick two

The clearest everyday version of the trade-off is the project manager’s Iron Triangle: time, scope, and cost. You can optimize any two, but the third has to give.

You want…	You sacrifice…
Fast + Good	Cheap (it gets expensive)
Fast + Cheap	Good (quality drops)
Good + Cheap	Fast (it takes a long time)

The triangle doesn’t vanish when you ignore it. A manager who demands all three doesn’t escape the trade-off - the system absorbs the cost where nobody’s watching: hidden shortcuts, exhausted staff, technical debt, a deadline secretly blown.

Think of it as a seesaw. You can choose where the balance point sits, but you cannot push both ends up at once. Asking for more quality and lower cost and faster delivery is asking all three ends of the seesaw to rise together. Gravity still applies.

When the parts beat the whole

Now the second big idea. In Thinking in Systems (2008), Donella Meadows defines suboptimization as what happens when a part’s goals win out over the whole system’s goals. The part can be a department, a machine, or a person.

The classic version is departmental KPIs - the numbers each team is measured on. Watch the trap unfold in a factory:

1. Sales is measured on deals closed, so Sales closes more deals.
2. Those deals pile onto Engineering, the slowest and smallest team - the bottleneck.
3. Engineering’s backlog grows. Downstream teams, stuck waiting, start more projects to look busy.
4. That sends even more work toward the bottleneck, which jams harder.

Every team’s dashboard glows green. The system’s actual output collapses. Nobody here is stupid - the structure produces the bad result.

The lesson is uncomfortable: green dashboards everywhere can sit right on top of a failing system. Define what success means at the whole-system level first, then design part-level metrics that genuinely serve it. Do it the other way around and you optimize yourself into a hole.

Local optima vs global optima

Let’s name this precisely. A local optimum is a state that’s better than everything nearby but not the best overall. A global optimum is the genuinely best state across all the possibilities. Any system whose parts depend on and feed back into each other almost always has many local optima - lots of little peaks that feel like the top until you look up.

Here’s the trap, as Tiago Forte put it: adding up a series of local optima does not automatically lead to a global optimum - in fact, it can lead to the exact opposite. Optimize each part on its own and you get a pile of local bests that together are often the global worst.

Picture a basketball coach who benches the best ball-handler so every player gets more shots. Each player’s individual shooting numbers go up. But passing collapses, ball movement dies, and the team loses. The local metric improved; the global outcome got worse.

Find the constraint, ignore the rest

Eliyahu Goldratt’s novel The Goal (1984) gives us the single most useful tool here. His central claim: the throughput of any system equals the throughput of its single binding constraint. Throughput is the rate at which the system produces what it’s actually for. A constraint (or bottleneck) is the one resource or step that limits everything else.

The consequence is sharp. Making a non-constraint more efficient doesn’t just fail to help - it actively hurts, because it produces work that piles up and jams the real constraint.

Goldratt illustrates this with the “Herbie hike.” A scout troop has to reach camp together. The slowest boy, Herbie, carries 40-plus pounds of gear and lags behind. The fast scouts racing ahead don’t help at all - they just widen the gap. The fix isn’t to push the fast hikers; it’s to put Herbie at the front to set the pace and redistribute his load.

LOCAL OPTIMUM (each scout as fast as possible):
fast --> fast ----> Herbie(slow) ... gap ... goal
   the group fractures, nobody arrives together

GLOBAL OPTIMUM (everyone subordinate to the constraint):
Herbie(lightened) -> rest match pace -> ALL reach the goal

Drum-Buffer-Rope: the case for deliberate idleness

Goldratt’s scheduling method makes this concrete. Drum-Buffer-Rope forces every non-constraint to obey the bottleneck’s pace:

• Drum - the constraint sets the rhythm for the whole system.
• Buffer - a small protective stock of work kept just before the constraint, so it never sits idle waiting. This looks like inefficiency. It’s insurance.
• Rope - a signal that stops upstream steps from releasing more work than the constraint can handle.

The counter-intuitive payoff: deliberately letting your non-bottleneck resources sit idle increases total output.

One warning that catches almost everyone. Don’t plan capacity from average speeds. A line of five stations each averaging 100 units an hour does not produce 100 units an hour - variation and waiting accumulate, so it produces less. A chain performs at its weakest link, not its average link.

When local rationality creates global chaos

In The Fifth Discipline (1990), Peter Senge describes the Beer Distribution Game. A supply chain runs retailer to wholesaler to distributor to brewery. Each player orders sensibly to keep their own inventory near target. But nobody can see the whole chain, and orders take time to arrive.

A tiny bump in retail demand gets amplified at each stage into wild swings - the bullwhip effect. A retailer selling four cases a week can leave a wholesaler buried under 220 truckloads it can’t move. Every single decision was locally reasonable. The system dynamic produced the disaster anyway.

Efficiency vs resilience: a trade you should make on purpose

Resilience is a system’s ability to absorb shocks and keep working. It’s built from redundancy - spare capacity, backup suppliers, safety stock, reserve systems. To a pure efficiency mindset, redundancy looks like pure waste, so lean, just-in-time systems strip it out. The bill comes due only when disruption hits.

COVID-19 exposed this worldwide in 2020 and 2021. Decades of lean, single-source, zero-safety-stock supply chains were brilliant under normal conditions. When shipping and manufacturing broke at the same time, car plants halted for missing chips and PPE ran short in wealthy nations. NHS England, after a decade of efficiency cuts, was running bed occupancy above 85% - the exact threshold it had itself named as the safety risk line - and had to cancel hundreds of thousands of admissions to free up beds.

The traffic analogy is worth keeping in your head. A highway flows smoothly at 85% capacity. Past 95%, one driver tapping the brakes triggers a stop-and-go wave that travels backward for miles. The last 10 to 15% of “utilization” is bought at a steep, nonlinear cost in stability.

Nassim Taleb (Antifragile, 2012) sharpens the vocabulary:

• Fragile - breaks under stress.
• Robust - survives unchanged.
• Antifragile - actually improves under stress, like muscles or evolution.

His point: slack and redundancy aren’t waste, they’re armour. Over-optimized, tightly connected systems are fragile by construction.

A real meltdown: Southwest Airlines, December 2022

Southwest’s point-to-point network squeezed maximum use out of its aircraft in normal weather. But it had no hub-based way to recover. When winter storm Elliott hit, one cancelled leg stranded entire crews with no recovery path, and the airline’s legacy crew-scheduling software couldn’t re-plan in real time - staff fell back to spreadsheets and phone calls.

In ten days: 16,700 flights cancelled (about 70% of the schedule), two million passengers stranded, and a $140 million federal fine. The pilots’ union had warned a month earlier that the airline was “one IT router failure away from a complete meltdown.” The efficiency that kept Southwest profitable for 50 years had quietly removed the slack it needed to survive a rare, severe shock.

Common misconceptions

“If every part shows a good number, the whole must be healthy.” Green dashboards can sit on top of a failing system. Success has to be defined at the system level first.

“We’ve run lean for ten years and been fine, so we’re safe.” Fragility is invisible until the shock arrives. Taleb’s turkey is fed every day for 1,000 days - each day confirming “the farmer is friendly” - right up to the day before Thanksgiving. The absence of catastrophe is not proof of resilience.

“Cutting price is a sure win - more customers, more revenue.” It’s a local optimization of “units sold” that ignores four system effects: you instantly lose margin on customers who’d have paid full price; a 5% price cut needs roughly a 17.5% volume jump just to break even on operating profit; frequent discounts train shoppers to wait for sales; and extra volume can saturate your hidden capacity constraint. This is why Hermès and Rolex refuse to discount - they protect margin, scarcity, and brand value, not just today’s unit count.

“Pareto efficient means fair or good.” The Pareto frontier is the set of solutions where any gain in one goal forces a loss in another, and Pareto efficiency means no change can help someone without hurting someone else. But one person holding everything while everyone else has nothing can be Pareto efficient. Efficiency describes the trade-off structure; it says nothing about whether the outcome is just.

How to use this

1. Name the trade-off out loud before you commit. For any goal, ask: “If I push this, what gives?” If the honest answer is “nothing,” you haven’t found the cost yet - keep looking.
2. Define success at the whole-system level first. Decide what good looks like for the whole before you set a single team or part-level metric. Then make sure each metric genuinely serves that whole.
3. Find the one constraint. Don’t spread improvement evenly. Locate the single slowest step that limits everything, and improve that. Speeding up anything else just floods the bottleneck.
4. Subordinate everything to the constraint. Let non-bottleneck resources sit idle when they need to. Keep a small buffer in front of the bottleneck so it never starves.
5. Optimize in order: correct, then measure, then tune. Make it work and stay maintainable first. Then measure to find the real bottleneck. Only then optimize the small part that actually matters. Donald Knuth’s warning still holds - premature optimization is the root of much wasted effort. A developer who spends two days hand-tuning a module before profiling often discovers later that 94% of the slowness was a single database query missing an index, fixable in minutes.
6. Buy resilience on purpose. Treat slack, redundancy, and safety stock as insurance with a known premium - not as waste to be cut. Decide how big a shock you want to survive, and pay for it deliberately.
7. Check the boundary before you call anything “optimal.” Almost every local-vs-global failure is secretly a boundary problem: whoever optimizes draws the line to include the benefits they capture and exclude the costs that land on others. A 2024 U.S. Senate investigation found Amazon warehouse workers injured at nearly twice the rate of comparable warehouses. Within the boundary of “items per hour,” the system looked optimal. Widen the boundary to include injuries, turnover, and regulatory and reputational cost, and it isn’t. The costs left out of your metric are usually exactly where the real damage hides.

Conclusion

If you remember one thing, make it this: every optimization is a trade, and the sum of local bests is rarely the global best. The job isn’t to make every part shine. It’s to find the one constraint that limits the whole, fix that, and let the rest be “good enough.”

There’s a deeper question hiding underneath all of this, though. We keep saying “improve the whole system” - but a system only has a single right answer once you’ve decided where its edges are, and who counts as inside. Move that boundary, and yesterday’s optimal decision becomes today’s disaster. That question of where to draw the line - and who gets to draw it - is where systems thinking gets genuinely interesting.