Constraint

Origin & evolution

Eliyahu Goldratt put constraints at the centre of management thinking in his 1984 business novel The Goal), which introduced the Theory of Constraints. His claim was deceptively simple: every system has one constraint that limits its throughput, in the way a chain is only as strong as its weakest link. Improving anything other than that constraint produces no gain in the output that matters. The famous illustration is a hiking troop whose pace is set by its slowest walker; speeding up the others only stretches the line.

Goldratt turned this into the five focusing steps: identify the constraint, exploit it (wring maximum value from it as-is), subordinate everything else to it, elevate it (add capacity), and then repeat, because relieving one constraint exposes the next. The discipline was to resist optimising the non-constraints, which feels productive and changes nothing.

The idea spread from factory floors to software through Lean and DevOps, where the constraint is usually a stage in the delivery flow such as code review or a single deployment📤DeploymentEngineeringA deployment eventView reference → pipeline. The current debate is about scope. Goldratt described physical, single-bottleneck systems; knowledge work often has policy constraints (an approval rule, a risk🎲RiskComplianceA risk to the product or businessView reference →-averse habit) that are self-imposed and movable, which makes "identify the constraint" partly an act of organisational honesty.

How it works in practice

A team's checkout conversion is flat. They want to redesign the payment screen, add wallets, and rebuild the cart, all at once. Applying the constraint lens, they instrument the funnel⬇️FunnelGrowthA conversion funnel tracking user progressionView reference → and find one stage where 38% of users drop: a forced account-creation step before payment. That step is the constraint. Exploiting it costs nothing structural; they add guest checkout and conversion rises 11 points in two weeks. The wallet work and cart rebuild, had they shipped first, would have moved nothing, because users never reached those screens. Only after the account-creation constraint is relieved does the next bottleneck (slow address validation) become worth touching.

Constraint vs. its neighbours

• Assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → is something the team believes is true but has not verified. A constraint is a boundary that genuinely holds, whether the team likes it or not. Many supposed constraints are assumptions in disguise ("legal will never allow it"), and testing them is how false constraints dissolve.
• Dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → is a relationship: your work cannot proceed until another team or system delivers something. A constraint is a property of the system itself, a fixed limit rather than a waiting relationship. A dependency can become your binding constraint, but not every constraint is a dependency.
• Risk is a possible future event with some probability of harming the work. A constraint is a present condition that already shapes what is buildable. A risk might never happen; a constraint is in force today and belongs in the design inputs, not the worry list.

In the graph

In the Unified Product Graph, a constraint lives in the strategy region and acts as a boundary other entities are pinned to. A product carries its outer limits through product_bounded_by_constraintProductbounded byConstrainthierarchy, while constraint_constrains_featureConstraintconstrainsFeaturecross-domain, constraint_constrains_initiativeConstraintconstrainsInitiativesemantic, and constraint_constrains_metricConstraintconstrainsMetricsemantic connect a single boundary to everything it actually shapes, from a feature⭐FeatureProduct SpecificationA product capability or featureView reference →'s scope to a target it caps. Ownership is explicit through constraint_owned_by_teamConstraintowned byTeamcross-domain, which answers the question Goldratt's method forces: who can move this, and is it real. Modelling constraints as connected nodes, where a brief would bury them in prose, means a team can query which boundary touches the most work and focus there first. That is Goldratt's discipline made structural: find the one limit that governs throughput before improving anything else.