Most sequences have one real constraint — and it is often not the most visible one
When progress has stalled across multiple areas simultaneously, the instinct is to look for multiple causes. In most cases there is one. A single unresolved decision, an unclear dependency, a missing resource, or an ownership gap is holding up everything that follows it — and the apparent complexity is a symptom of that one constraint rather than a collection of separate problems.
The difficulty is that the real blocker is not always the most visible one. Work that is generating the most noise — the tasks that keep being raised, the requests that keep arriving, the people who keep chasing — is often not the constraint. The actual blocker tends to be quieter, because it is the thing nobody has been able to progress rather than the thing everybody is talking about.
Pairwise comparison helps isolate the real constraint by examining what is actually blocking progress against what is generating urgency — so attention goes to the right place rather than the loudest one.
Identifying what is actually blocking progress versus what is generating noise
A blocker and a bottleneck are different things — and they respond to different interventions
Treating a bottleneck as a blocker adds effort without clearing the constraint. Identifying which one this is determines what the right response looks like.
A blocker is something that prevents progress entirely until it is resolved. Nothing downstream can move until the blocker is cleared. The right response is to address it directly and as quickly as possible.
A bottleneck is something that slows progress without stopping it entirely. Work continues but at reduced speed or quality. The right response may be to increase capacity at the bottleneck, reduce the load going through it, or restructure the sequence to route around it.
Many apparent blockers are actually bottlenecks in disguise — things that feel like hard stops but would yield to a restructured approach. And some apparent bottlenecks are actually blockers — things that look like they can be worked around but are in fact the constraint that everything else depends on. Identifying which is which is where the comparison starts.
Whether this is the real constraint and whether addressing it is within reach
The real constraint is the one whose removal produces the most downstream progress — not the one that feels most urgent
Confirming that this is genuinely the constraint — rather than a symptom of a different one — is worth doing before committing resources to resolving it.
The test for whether something is the real constraint is straightforward: if this were resolved tomorrow, how much would move? If the answer is a significant amount across multiple areas, it is the constraint. If the answer is that one specific thing would move but everything else would remain stuck, there is likely a different constraint upstream.
The second question is whether addressing it is within direct control. A blocker that can be resolved by a decision or an action is different from one that depends on another person, a different team, or an external factor. The response to each is different — direct action in the first case, escalation or restructuring in the second.
Comparing the characteristics of the blocker directly makes both of those questions easier to answer with confidence rather than assumption.
When the cost of resolving and the cost of working around are both significant
The right response to a blocker depends on whether resolving it is more efficient than restructuring around it
Resolving a blocker directly is the right call when the effort required is proportionate to the progress it releases, when it is within direct control, and when the workaround is creating more work than the fix would require. In those conditions, clearing the constraint is the most efficient use of available resource.
Restructuring around it is the right call when resolving it directly would take longer than the sequence can afford, when it depends on a party that is not moving, or when the restructured sequence is genuinely viable rather than just a way of deferring the problem.
Establishing which of those applies — and being honest about whether the workaround is a real solution or just a way of not dealing with the constraint — is what the priority comparison at this stage is for.
The three realistic responses to an identified blocker
Each of these is a genuine resolution — the right one depends on what the blocker actually is and where control sits
Addressing the blocker directly and clearing it before anything else means it is within control, the effort is proportionate, and the downstream release justifies prioritising it above everything else currently active. This is the right outcome when the blocker is genuine, resolvable, and the main obstacle to progress across multiple areas.
Reducing its impact by restructuring what depends on it means the blocker cannot be cleared quickly enough — but the sequence can be reorganised to reduce how much it is holding. This works when the dependency structure has flexibility and when a restructured sequence is genuinely viable rather than just a way of avoiding the constraint.
Escalating or reassigning it means the blocker is outside direct control and the dependency is not moving. Escalation surfaces the constraint to someone with authority to resolve it. Reassignment transfers ownership to someone with the access or relationship to move it. Both require an honest acknowledgement that the blocker cannot be resolved from the current position — which is information worth having clearly rather than implicitly.