Every program has blockers. Few teams escalate them in time. The blocker isn't usually the problem — the silence about it is.
By the time the blocker gets named in a status meeting, it's been a blocker for ten days. Someone tried to work around it. Someone else assumed the first person had it handled. The team lead suspected something was off but didn't want to "manage upward". By day eleven, the milestone is at risk, and the conversation that should have happened on day two is now happening in front of executives in a recovery review.
Why teams under-escalate
It's almost never that the team is lazy or unaware. The reasons are cultural, and they're identical across companies:
"We'll figure it out" optimism. Engineers, in particular, are wired to solve problems. The escalation conversation feels like admitting they can't. So they spend three days trying — and the three days are usually well-spent — but on the fourth day they're still trying, when escalation should have happened on day one.
Fear of looking incompetent. Especially in cultures where escalation is rare, the act of escalating reads as a signal that you couldn't handle it. Junior engineers feel this more than senior ones; senior ones feel it more than they admit.
Belief that surfacing problems gets you blamed for them. The most common pattern in dysfunctional programs. Someone raised a risk early, got asked "well what are you doing about it", and learned the lesson: don't raise risks unless you've also solved them.
Past trauma. They tried, once, and got punished. Maybe with a comment in a performance review, maybe with a sigh in a meeting, maybe with the implication that they were "negative". Once is enough.
What changes when the culture is right
The goal isn't to make escalation easier — it's to make it normal. In a healthy program, escalating a blocker is a service: the team is giving leadership the information leadership needs to make the right call. It's not a confession. It's not a request for rescue. It's a notification with a recommendation.
That cultural shift takes months and starts with leadership. Specifically: how leadership responds the first time someone escalates. The first response sets the standard for the next year of escalations.
A pragmatic framework
For teams trying to make escalation routine, four moves:
1. Categorize the blocker. Use a small fixed taxonomy. Four categories cover almost everything:
- Scope risk — the work as scoped won't fit the timeline
- Dependency risk — something we need from another team or vendor isn't going to arrive
- External risk — third party (API, regulator, integration partner) has changed something
- Capability risk — the team doesn't have the skills or capacity to ship this without help
The category determines who needs to know.
2. State the cost. Not "this is bad". A specific cost: "if we don't resolve this by Friday, we slip the May 15 milestone by two weeks." Costs in days, dollars, or specific dependencies. Vague costs get treated as vague problems.
3. Propose options, not problems. This is the single biggest predictor of whether an escalation lands well. Three options is the sweet spot:
Option A — extend the deadline by two weeks. Costs: marketing campaign push, contract renegotiation. Option B — cut scope: drop the email integration from v1. Costs: customer ask deferred. Option C — bring in a second engineer for two weeks. Costs: budget hit, slower in another area.
The escalation isn't "help, we're stuck". It's "here are three doors, you tell us which one to open".
4. Bias toward early-and-quiet. A blocker raised in week one, in a 1-on-1, with three options — that's a routine conversation. A blocker raised in week ten, in a status meeting, with no options — that's a crisis. Same blocker. Different professional consequences.
The delivery manager's role
In a well-run program, the delivery manager acts as an escalation proxy. They notice that the team is not escalating something they should be, and they surface it themselves. This relieves the team of the personal risk and turns escalation into an organizational function instead of an individual one.
The delivery manager isn't snitching. They're doing the job. The team's job is to ship. Their job is to make sure leadership has the information needed to keep the program viable.
The takeaway
A program where everyone is comfortable escalating is one that ships on time, with fewer surprises, and with leadership making decisions based on real information. A program where nobody escalates ships its problems instead of its product.
The difference between the two isn't the team. It's the culture leadership built — and the framework they handed the team for what escalation actually looks like.
If your team isn't escalating, the question to ask isn't "what's wrong with the team". It's "what happens to the next person who escalates?"