Every team that optimizes for itself makes the organization worse.

The trap

It’s natural to improve what’s in front of you. Make your service faster. Reduce your team’s cycle time. Clear your backlog. Each of these feels productive in isolation, and each one can actively harm the system it belongs to.

A faster service that pushes load onto a downstream dependency didn’t speed anything up — it moved the bottleneck. A team that clears its backlog by shipping half-finished work didn’t deliver value — it created inventory. Optimizing the part while ignoring the whole is the most common way to make things worse while feeling like you’re making them better.

The theory

This comes from systems thinking and the Theory of Constraints. Goldratt’s insight was that a system’s throughput is determined by its constraint — the single slowest point. Improving anything that isn’t the constraint doesn’t improve the system. It just creates excess capacity that piles up as work-in-progress.

The implication is counterintuitive: most of the system should be deliberately underutilized. If every part is running at 100%, the system is fragile, overloaded, and slow. Slack isn’t waste — it’s what allows the whole to absorb variation without breaking.

In practice

This shows up everywhere:

  • Microservices that are individually fast but produce cascading failures because nobody optimized the interaction patterns between them.
  • CI pipelines where each stage is tuned but the end-to-end time is terrible because of queue waits and handoffs.
  • Organizations where every team hits their OKRs but the product still ships late because the goals weren’t aligned to the same constraint.

The fix is always the same: stop looking at the parts. Trace the value stream end to end. Find where work actually stalls. Improve that one thing. Ignore everything else until the constraint moves.

The discipline

Optimizing for the whole requires resisting the urge to fix what’s obviously improvable but locally irrelevant. It means tolerating inefficiency in one area because the system needs slack there. It means measuring outcomes at the boundary of the system, not the boundary of the team.

It’s harder than local optimization because it requires understanding the whole. And the whole is usually nobody’s job.