Speed Is a System Property.

When delivery is slow, the instinctive fix is to ask individual teams to move faster — but speed is almost never a property of the people doing the work. It's a property of the system they're working inside.

Ask a room full of executives why delivery is slow and the answers cluster fast: the team isn't working hard enough, there's too much scope, we need more engineers. All three point at effort or headcount. Almost none of them point at the system the work is moving through — and that's usually where the real answer is sitting.

The Constraint Sets the Pace, Not the Average

Eliyahu Goldratt's Theory of Constraints starts from an observation that's almost embarrassing once you see it: in any chain of dependent steps, the system can never produce faster than its slowest step. Every other step can be fully staffed, motivated, and executing flawlessly — the system's total output is still capped by the one step that's actually the bottleneck. Goldratt built a discipline, throughput accounting, on top of this: instead of tracking local efficiency at every station, track three numbers — throughput (the rate the system turns work into finished value), inventory (everything invested in work not yet delivered), and operating expense (everything spent converting inventory into throughput). A team running at 100% utilization that isn't the constraint isn't adding throughput. It's adding inventory — unfinished work sitting in a queue, waiting for the one resource that actually paces the system.

That's why "work faster" fails as an instruction more often than it succeeds. If the team you're pushing isn't the constraint, you haven't sped up the system — you've sped up the rate work piles up in front of whatever *is* the constraint. Goldratt's Five Focusing Steps — identify the constraint, exploit it, subordinate everything else to that decision, elevate the constraint, then repeat — exist because most organizations never do step one. They optimize everywhere at once, which guarantees they're optimizing in the wrong place most of the time.

In a product organization, this usually translates into something uncomfortable: the constraint is rarely the team that looks busiest. It might be a single architecture review board, a shared QA environment, a data platform team everyone depends on but nobody funds properly, or one overloaded technical approver. Exploiting the constraint means making sure that resource is never idle, never blocked by upstream noise, and never spending attention on anything that isn't strictly necessary. Elevating it — adding capacity, automating around it, redesigning the process it sits inside — is the expensive step, and Goldratt's ordering matters: elevate before you've exploited and subordinated everything else to it, and you've just paid to build a bigger version of the same bottleneck.

What Elite Delivery Organizations Actually Do Differently

DORA — the research program behind Google Cloud's long-running Accelerate State of DevOps research — has spent close to a decade measuring what separates elite software delivery organizations from everyone else, across tens of thousands of respondents. The gap isn't subtle. Elite performers deploy on demand, multiple times a day, with a lead time for changes of under a day. Low performers can take one to six months to get a single comparable change into production. That's not a 20% difference you'd get from people simply moving with more urgency — it's a difference in kind, and DORA's research consistently traces it to system-level factors: loosely coupled architecture that lets teams ship independently, continuous integration, and fast, effective code review — not to how hard any individual engineer is working.

The part that should really get a CEO's attention is what happens to quality at the same time. If speed and stability were a trade-off — the assumption behind "let's slow down and be careful" — elite performers should be breaking things constantly. Across DORA's reported ranges, they don't: elite performers post change failure rates in the low double digits or better, while low performers post rates running several multiples higher. Speed, in the organizations that have actually redesigned their systems for it, comes bundled with fewer failures, not more.

Why "Try Harder" Is the Weakest Lever You Have

Systems scientist Donella Meadows spent her career cataloguing where you can intervene in a complex system to change its behavior, ranked from weakest to most powerful. Dead last on her list of twelve leverage points: constants and parameters — the numbers you can turn up or down without touching how the system is built. Headcount, hours, quotas, targets. She called interventions at this level "diddling with the details, arranging the deck chairs on the Titanic." Asking a team to work faster is a parameter change. It doesn't touch the structure of stocks and flows that actually governs how work moves through the organization — the buffers, the delays, the rules for who can start what, and when. Meadows ranked structural changes — the rules of the system, who has access to information, the power to redesign structure itself — many levels higher, because they change what the system produces, not just how hard it's pushed.

Put Goldratt and Meadows side by side and two different disciplines arrive at the same message: speed is architecture, not adrenaline. If the constraint hasn't been identified and the flow around it hasn't been redesigned, no amount of individual urgency changes the system's actual output. It just moves the queue.

That has a direct implication for what a leadership team should actually review. A weekly operating rhythm built around team-by-team velocity is measuring parameters — Meadows's weakest leverage point, applied to a status meeting. A rhythm built around the queue in front of the constraint, and whether last week's changes shortened or lengthened it, is measuring the thing that determines whether the organization ships faster next quarter or merely feels busier.