Theory of Constraints
The principle that a system's throughput is set by a single binding constraint, so improvement anywhere else produces nothing.
At any moment one thing limits the whole. Effort spent elsewhere yields no improvement, which is the most commonly ignored fact in both performance engineering and delivery improvement.
The cycle: identify the constraint; exploit it, ensuring it is never idle or doing work something else could do; subordinate everything else to it; elevate it by adding capacity; then repeat, because the constraint has now moved.
Applied to a technical system, the constraint is a resource — a database, a connection pool, a thread pool, a network path. The signature is queueing: work waiting for that resource while others idle.
Applied to delivery, the constraint is usually not engineering capacity. Flow efficiency in most organisations is 5–15%, meaning work spends most of its life waiting — for review, for an environment, for a dependency, for a release window. Adding engineers to a system constrained by approval queues achieves nothing, and it is done constantly.
The step most often skipped is subordinate. Once the constraint is known, everything else should be arranged to keep it fed — which frequently means deliberately running non-constraint resources below capacity, an idea that feels wrong and is correct.