Theory of Constraints Foundations

11 canonical Theory of Constraints primitives for diagnosing and exploiting system constraints. Primitives are domain-agnostic: the same Five Focusing Steps that fix a production line apply to a software delivery pipeline, a product roadmap, or a consulting engagement. Each primitive solves a specific class of throughput-limiting problem.

When to Apply

Apply theory-of-constraints when:

• One bottleneck demonstrably gates total system throughput (the system has a constraint, not many)
• Roadmap or capacity-allocation under a hard limited resource (eng-weeks, GPU-hours, account-managers)
• Funnel debug where a single step blocks downstream conversion
• Policy constraint suspected (a rule, not a physical limit, is what's holding throughput)
• Subordination question — "should other steps slow down to match the bottleneck?"
• Post-AI adoption reassessment — when AI coding tools improve individual velocity but DORA metrics (lead time, deployment frequency, MTTR) stay flat, re-run 5FS; the constraint has likely shifted downstream to code review, QA, or integration (documented pattern 2024–2026; see IT Revolution "Revenge of QA" 2026, Logilica 2025, Faros AI 2025)
• LLM / agent-pipeline optimization — when end-to-end latency or task throughput of a multi-step AI pipeline is not meeting targets despite adding models or workers; the constraint is frequently the decode stage of a Planner/Arbiter LLM component or a downstream guardrail/eval stage, not raw capacity (2026 pattern; profile before scaling)