Diagnostic Frame
The Constraint Horizon
A team's position on its improvement journey is not a grade. It is the location of the constraint that most limits its flow. The Constraint Horizon names five constraint classes, ordered outward from the team's span of control, and gives a team a warm-up question, four capability tests that find where it stands, and a check for a remaining enterprise constraint.
Working position names the current constraint
The Constraint Horizon defines a team’s position by the class of constraint that binds its flow. There are five classes, ordered outward from nearest the team’s own control to farthest, and each one is a waypoint:
- The team cannot see its work.
- The team cannot finish its work.
- Finished work cannot reach its consumers.
- Delivered work does not change what the team builds next.
- The binding structures belong to the enterprise.
Ask once, test outward, carry one phrase
Using the model takes three steps. Everything else on this page is supporting detail for those steps.
- Ask the warm-up question. If everything your team controls went perfectly for a month, what would still be slow? The answer names what feels slowest. The tests then check whether it is the constraint to work on first.
- Walk the four capability tests in order. A test passes when its condition holds under pressure, not just in a quiet period. The first failure names your waypoint. If all four pass, check whether a binding enterprise constraint remains.
- Carry one phrase: the waypoint, the named constraint, and who controls it. For example: Delivery Edges / release authority (external).
Working position, ceiling, and control
Tests passed earlier in the sequence describe capabilities the team has established. Adopting a practice does not establish the capability; its test still has to pass.
Three facts stay separate in the model:
- Working position is the waypoint named by the first failed boundary test, or Enterprise Structures when all four capability tests pass and a binding enterprise constraint remains.
- The environment ceiling records what the surrounding system prevents the team from changing about its current constraint. This keeps a limit imposed by outside authority separate from a capability the team could build.
- Control is recorded per constraint: team-controlled, jointly controlled, or externally controlled. The model never assumes who owns what.
The five waypoints
All five waypoints at a glance:
| Waypoint | Boundary test |
|---|---|
| Invisible Work | Can the team state, today, what it is working on, what is waiting, and how much is in progress? |
| Own Mechanics | Can the team reliably turn a small batch into finished, verified work its recipients can use, within its own span? |
| Delivery Edges | Does finished work reach the people it is for without an outside wait setting the pace? |
| Learning Edges | Does evidence from delivered work change what the team builds next, within a useful cadence? |
| Enterprise Structures | All four prior tests pass; the binding constraint sits in structures only the enterprise can move. |
Each waypoint in depth:
Invisible Work
The test: can the team state, today, what it is working on, what is waiting, and how much is in progress?
What holds the team back: the team cannot see its own work. Work arrives as assignments to individuals, and queues, interrupts, and work in progress go unmeasured. Integration and acceptance come late, and progress is judged against plan or utilization.
From inside: the team feels busy, unpredictable, and blamed, and nobody can say where the time goes.
You are past it when: work, queues, and intake are visible, the team plans jointly and owns completion, the team keeps an honest work-in-progress count, and at least one short feedback loop actually changes how work is handled.
Own Mechanics
The test: can the team reliably turn a small batch into finished, verified work its recipients can use, within its own span?
What holds the team back: the team cannot finish work at the pace its cadence promises. Quality debt, slow verification, big batches, and internal handoffs set the real pace, no matter what the official rhythm says.
The hazard band: the transition hazards cluster at this waypoint. Debt becomes visible for the first time, morale dips while the team learns to hold itself accountable, and teams regress by taking on too much at once. In the model, this is where adoption stalls most often.
From inside: iterations finish, but each one feels heavier, and the ceremonies keep happening while nothing gets easier.
You are past it when: small batches reliably become finished, verified work within the team’s own span, and internal quality problems no longer set the pace. In software delivery, that means work is tested and releasable, and releasing is a business decision rather than a rescue effort. The condition itself applies in any domain.
Delivery Edges
The test: does finished work reach the people it is for without an outside wait setting the pace? Not every wait fails this test.
What holds the team back: finished work cannot move outward. Completed work queues at the boundary, waiting on integration with other teams, on dependencies, on release or sign-off authority held elsewhere, and on environment and platform gaps. The team itself is no longer the bottleneck, so now the edges are.
From inside: we finish and then we wait, and cycle time is dominated by work that other people own.
You are past it when: finished work reaches its recipients without an outside wait setting the pace. Measuring the wait and escalating it are the exit work, not the exit. While the wait binds, the team stays here, even when only the enterprise can move the constraint.
Learning Edges
The test: does evidence from delivered work change what the team builds next, within a useful cadence?
What holds the team back: the loop between delivering, learning, and deciding. Work flows out but little flows back, or evidence arrives and nobody acts on it: product decisions take too long, the team is far from its customers, and priorities keep churning. The team can deliver. What it lacks is knowing what to deliver, and being allowed to act on what it learns. You can see the difference from Delivery Edges: there, finished work waits to reach its consumers; here, work reaches them and the team waits to learn or decide.
From inside: the team is fast, stable, and possibly building the wrong thing.
You are past it when: operational and customer feedback routinely changes priorities, experiments, or product decisions within a useful cadence.
Enterprise Structures
The test: all four prior tests pass, and the binding constraint sits in structures only the enterprise can move: funding cadence, architecture, governance policy, team topology, culture.
Two substates: Holding means the team sustains its flow, resists regression, and keeps evidence moving upward while the enterprise decides. Moving means the team is working with people upstream who are actively shifting the constraint. As the constraint shifts, the team walks the tests again. They often fail at an earlier waypoint, because new products, a new platform, or new boundaries bring work the old capabilities don’t yet cover.
No final waypoint: the team either repeats the cycle or deliberately stops because where it stands fits its needs.
The locating exercise
The route:
- Ask the warm-up question: if everything your team controls went perfectly for a month, what would still be slow? Keep the answer for step 3.
- Walk the four capability tests in order. The first failure names your waypoint. If all four pass, check for a remaining binding enterprise constraint. If none binds, there is no constraint to name right now: keep the four tests passing, and walk them again when something changes.
- Record the named constraint. When a capability test fails, name the mechanism that makes the test fail, using the best-supported one from your diagnosis. Mark the named constraint provisional if you have not tested that mechanism. Present is not the same as binding. If the warm-up answer points to a constraint outside the team, that outside constraint is the named constraint only if it is the reason the failed test fails. Otherwise, record the outside constraint in the ceiling note. At Enterprise Structures, after all four tests pass, the binding enterprise constraint is the named constraint. Then record the named constraint’s control: team-controlled, jointly controlled, or externally controlled.
Then record two supporting details:
- Ceiling note. Write two lines. Blocker: what prevents the failed condition, or the binding enterprise constraint, from changing, and who holds that authority. Write “none yet” if the team could build the missing capability itself. Also observed: any other outside constraint, including a warm-up answer that is not why the test fails.
- Amplifier check. Before acting on the current constraint, check the four team amplifiers by name: Trust Erosion, Accountability Avoidance, Micromanagement Creep, and Burnout Accumulation. An active amplifier can keep a team from acting on a capability it has built, so write any active one beside the phrase. The Team book checks the amplifiers before the first move, and deals with one first when it is strong enough to keep that move from holding. The amplifiers are defined in Applied End-to-End Flow: Team. They concern team working conditions; the enterprise amplifiers concern the wider transformation environment.
Carry one phrase
The carried output is one phrase: waypoint, named constraint, control class. For example: Delivery Edges / release authority (external). Carry an active amplifier too, written beside the phrase. Everything else in the exercise is supporting detail used along the way. When the constraint moves, the team rebuilds the phrase by walking the tests again from the first.
Example: claims waiting for outside sign-off
An illustrative claims-operations team asks the question and answers: if everything we control went perfectly for a month, clean case decisions would still wait days for another department’s sign-off. Walking the tests: the team can state its queue, so Invisible Work passes. It handles cases reliably within its own span, so Own Mechanics passes. Finished decisions wait days on an outside sign-off, and that wait sets the pace, so Delivery Edges fails. The constraint is sign-off authority, and it is externally controlled. The ceiling note’s blocker line records the sign-off authority and the department that holds it. The carried phrase: Delivery Edges / sign-off authority (external). The constraint concerns how work moves, so the work is on flow. If the team has never measured the wait, its next job is counting the wait and its cost, the evidence an escalation runs on.
A route, not a law
The order is not arbitrary: fixing the constraints inside one class tends to expose the next class outward, so skipping ahead fails. But the order is a route, not a law. Regression is normal, disruption can move the constraint back inward, and a team can hold a stable mixed position for a long time. None of that is a defect.
What the phrase tells you
The carried phrase is built for reuse. What the constraint is about tells the team where to focus next: if it concerns what gets built and why, the work is alignment; if it concerns how work moves, the work is flow. Choosing between generating evidence and fixing what the team controls takes one check first: the state of the evidence that shows the constraint and its cost. If that evidence is missing, the work is generating it. If it exists but the team’s own practices distort it, the work is fixing those practices first. Then the control class suggests the usual next action. A team-controlled constraint means fixing what the team controls. An externally controlled constraint means generating evidence, because an escalation runs on it. A jointly controlled constraint takes both: the team fixes its side of the interface and builds the evidence for negotiating with the counterparty, with escalation as the fallback. The framework deliberately stops there. It names the job, not the method: how a team facilitates, prioritizes, or orders its improvement work is its own choice.
The Horizon locates; it does not grade
Not a maturity model. The output of the locating exercise is a work item, never a level. Waypoints carry names, not numbers. There is no score, no certification, and no cross-team comparison: two teams’ phrases are not comparable and are not meant to be.
A later waypoint is not a better team. Working position is defined by where the constraint lives, not by virtue. A team at Enterprise Structures is not superior to a team at Own Mechanics; its constraint simply lives somewhere else.
Stopping can be the right answer. A team can deliberately hold when further change would not serve its needs. The waypoint names its constraint; it does not dictate an improvement investment.
The amplifiers are inhibitors, not positions. An amplifier threatens an improvement’s ability to hold. It does not add a condition for working position, which the first failed boundary test still sets. So the amplifier check comes last, after the position is found.
The Horizon locates; it does not move you. The model contains no improvement mechanism. What to do about the named constraint belongs to the rest of the framework and to the team’s own judgment.
The two continuums
The pairing with The VSM Adoption Continuum is deliberate, and so is the difference in shape. The two models measure different things. The enterprise continuum measures capability: what the organization can deliver and how it funds work. The Constraint Horizon measures the constraint: what stands in the team’s way and who controls it. An enterprise waypoint says what the organization can do; a team waypoint says what is in the team’s way. The two meet at the ceiling: when a team’s constraint is externally controlled, the team’s work is usually generating evidence for escalation, and that evidence feeds the enterprise-level diagnosis.
Sources and lineage
The Constraint Horizon is an Applied End-to-End Flow concept developed by Curtis Hibbs and Joshua Barnes. Its primary treatment appears in Applied End-to-End Flow: Team, arriving October 2026, which also defines the four team amplifiers named in the locating exercise. The enterprise-altitude sibling, the VSM Adoption Continuum, is treated in Chapter 7 of Applied End-to-End Flow: Enterprise.
Curtis Hibbs and Joshua Barnes are co-creators of Effective Enterprise AI and Applied End-to-End Flow, and co-authors of the Applied End-to-End Flow book series. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.