The framework
Every engineering delivery failure can be traced to one or more of three inputs going wrong:
- Scope clarity — Is everyone building the same thing?
- Dependency resolution — Are the blockers known, owned, and being removed?
- Execution capacity — Is there enough focused time for the actual work?
These three form the delivery triangle. When all three are solid, teams deliver predictably. When any one is weak, the others compensate for a while — and then fail together.
The triangle is useful because it names the actual source of the problem, which is almost never “the engineers are slow” or “the estimates were wrong.”
Scope clarity
Scope clarity does not mean detailed requirements. It means everyone involved in a piece of work has the same mental model of what done looks like.
This is harder than it sounds because scope conversations often feel complete when they are not. The PM describes the feature, the engineers nod, the Jira tickets get created. What everyone discovers three weeks later is that the PM’s mental model of done was significantly different from the engineer’s mental model — and neither party thought they were being unclear.
The test for scope clarity is this: can the engineer describe the done state in concrete terms that the PM would immediately recognize? If not, there is a gap somewhere in the model.
The most common scope gaps I have seen:
- Undefined edge cases that neither party mentioned because they seemed obvious to one side
- Implicit integrations that the engineer was not told about or the PM did not know existed
- Unstated quality expectations — the PM expected production-quality; the engineer built something they considered a draft
None of these are failures of intelligence. They are failures of the conversation that happened before work started.
Dependency resolution
Dependencies are blockers that the team does not control. Waiting for a decision. Waiting for API access. Waiting for a design. Waiting for another team to finish something.
The failure mode around dependencies is almost always: someone identifies a dependency, mentions it once in a standup, and then waits. When the dependency has not resolved in two weeks, the conversation happens again, and it turns out nobody was actively removing it.
Dependencies are not passive. They do not resolve themselves. Every unresolved dependency needs an owner who is actively working the resolution — making the request, following up, escalating when needed.
The engineering lead’s job in this model is not to personally resolve every dependency. It is to ensure every dependency has an owner and to escalate when owners are blocked.
A simple tracker works. The format does not matter. What matters is that every blocked item has a name, a resolution action, and a next check-in date.
Execution capacity
Execution capacity is the variable that organizations consistently underestimate.
The naive model is: an engineer is either working or not. The realistic model is: an engineer is working at approximately 30-60% capacity on any given day, and high-throughput work (the kind that moves complex features forward) requires sustained blocks of several hours.
Execution capacity is not headcount. It is focused hours.
A team of ten engineers in a meeting-heavy culture may have less execution capacity than a team of six in a meeting-light culture with clear decision authority. The headcount model will predict the former outperforms. Reality often disagrees.
The way to improve execution capacity:
- Protect large time blocks. Meetings in the morning or late afternoon leave the core of the day intact. Meetings scattered through the day fragment it.
- Reduce synchronous overhead. Not every question needs a meeting. Not every update needs a standup. Some teams are in more coordination than the coordination is worth.
- Reduce decision friction. When engineers have clear authority to make decisions in their domain, they stop waiting. When authority is ambiguous, waiting is rational behavior.
How to use the triangle
When a team misses an estimate or is running behind, ask which vertex is the problem:
- If everyone is not sure what done looks like → scope clarity problem
- If people are waiting for things that are not moving → dependency resolution problem
- If the actual work time is too low even when other things are clear → execution capacity problem
The root cause determines the fix. Adding engineers is rarely the fix for any of the three, and almost never the fix if you have not yet diagnosed which vertex is the issue.