Third quarter in a row, and Priya is standing in front of the same steering committee explaining the same slip. The word she reaches for is "resourcing." Heads nod around the table. Someone proposes adding two contractors to the team. The meeting ends on time. Nothing about next quarter will be different, and everyone in the room already half knows it.
If you have spent any real time as a project or program leader, you have sat in some version of this meeting yourself. Different company, different quarter, different word standing in for "resourcing." Prioritization. Communication. Team maturity. Scope creep. The label changes. The pattern underneath does not.
The problem is not lack of awareness
Most program and delivery leaders I coach can define a constraint the moment I ask them to. They know the difference between a blocker and something structural. That is not where the breakdown happens. The breakdown happens thirty seconds into a real meeting, under real pressure, when a constraint shows up wearing a costume, and the costume looks exactly like something the leader already has a fluent, comfortable vocabulary for.
A constraint rarely announces itself. It arrives disguised as a resourcing gap, a communication breakdown, or a team that is simply moving too slowly. Those labels are not wrong exactly. They are just the surface the constraint is producing, and surfaces are what get escalated, staffed, and coached. The structure underneath keeps doing what it was built to do.
Symptom vocabulary versus constraint vocabulary
Every organization has a rich, fluent vocabulary for symptoms. Blocker. Resourcing gap. Communication issue. Prioritization conflict. These words get used in every steering committee in the world, and they all point at something that feels fixable by Monday.
Almost no organization has an equally fluent vocabulary for constraints. Team ownership gaps, which are a structural constraint. Misaligned incentives, which are an incentive constraint. A long approval process, which is a governance constraint. A locked annual budget, which is a funding constraint. These point at something in the design of the system, and they carry an uncomfortable implication: the fix might not belong to the team that is visibly struggling. It might belong to whoever built the funding model, the reporting line, or the scorecard. That is a harder sentence to say out loud in a steering committee, so the easier vocabulary wins by default. I have written before about why this vocabulary gap exists and why it is the most underplayed dimension of software delivery. Here I want to show what it looks like in the room.
Four constraints, wearing four disguises
Structural, disguised as a communication problem. A platform team and a product team both claim ownership of the same shared service. When something breaks at the seam, the retro concludes the two teams need to talk more. The hidden assumption is that better standups close the gap. The insight is that nobody owns the seam itself, and no amount of talking assigns ownership that was never designed in.
Incentive, disguised as a prioritization disagreement. Product is measured on roadmap throughput. Engineering is measured on system stability. They share a sprint, and every planning session becomes a negotiation between two reasonable people who cannot both win. The hidden assumption is that sharper prioritization skills would resolve it. The insight is that both people are being rational inside two scorecards that were never designed to agree with each other.
Governance, disguised as team slowness. A change that takes four hours to build and two minutes to roll back still waits two weeks for approval. Leadership starts asking why the team cannot move faster. The hidden assumption is that the team is the bottleneck. The insight is that the team is moving at precisely the speed the approval process allows, and no individual effort changes that ceiling.
Funding, disguised as scope creep. Budget is locked twelve months before the evidence needed to validate that scope even exists. When the market shifts and priorities need to move, it gets recorded as poor upfront planning. The hidden assumption is that better estimation would have prevented it. The insight is that the funding cycle set the commitment window before anyone could have known enough to commit responsibly.
The most important question when you identify a constraint is not how do you fix it. It is what kind of constraint it is.
One quarterly review, four constraints, one word
Put all four in the same room and they tend to collapse into a single word: friction. The steering committee hears "resourcing," "prioritization," "slowness," and "scope creep," and treats each as its own isolated fire. What they are actually looking at are four different constraint types, each requiring a different kind of authority to address, each following a different path toward resolution.
That is the value of naming precisely, not generally. A structural gap and a funding cycle are never going to respond to the same conversation.
The better model: name it, then sort it
Once a constraint is named accurately, the next question is not how to fix it. It is what category it belongs to, because the category determines who needs to be in the room. Entrowise's constraint framework sorts every constraint into one of three categories: eliminable, where the right authority and will can remove it; mitigable, where the impact can be significantly reduced even though the constraint itself persists; and manageable, where the constraint defines the operating environment and the goal shifts to working confidently within it rather than fighting it.
A structural ownership gap is usually eliminable. A funding cycle is usually mitigable. A regulatory requirement is almost always manageable. Treating all three the same way, usually by assigning an action item and a due date, is how the same problem survives four consecutive retrospectives wearing four different names.
A short checklist for the next time the familiar label shows up
Before reaching for "resourcing" or "communication" in the next steering committee, three questions are worth asking. Is this in the way of one piece of work, or is it shaping every piece of work like it. Would actually resolving this require someone to admit a past decision was wrong, or does it just require patience and a workaround. And if nothing changes about the structure, incentive, governance, or funding underneath, will this exact conversation happen again next quarter.
If the honest answer to that last question is yes, the word on the table is not a symptom. It is a constraint, and it has been waiting to be named correctly.
Program and delivery leaders do not get better at their jobs by getting better at labeling problems. They get better by getting more accurate about what they are labeling.
If naming your constraints accurately sounds harder than it should be, that conversation is exactly where Just-in-Time Coaching starts.
Discussion questions:
- What is the constraint in your organization that keeps getting escalated under a different name every quarter?
- When you last named a constraint honestly, what category did it turn out to be, eliminable, mitigable, or manageable, and did that change who you brought into the room?