"Escalation failure is not a courage problem. It is a clarity problem — and clarity is something you build into a system before the crisis, not something you demand from people during it."
The Misdiagnosis
Every project retrospective contains some version of the same observation: an issue sat unresolved for too long, the wrong people were making decisions they weren't equipped to make, or a problem that should have reached leadership in week two didn't arrive until week eight — when the cost of correction had compounded beyond what anyone had budgeted for.
The response is almost always the same. Teams are told to speak up earlier. Managers are reminded to create "psychological safety." A new norms agreement is written and filed. The next project begins with the same structural conditions and produces the same pattern.
The diagnosis is wrong. The problem is not that people are reluctant to escalate. The problem is that escalation has no architecture. There are no defined trigger conditions, no mapped pathways, no clarity about what constitutes an escalable issue versus a decision the team should own. In the absence of that structure, people do what any rational actor does when the rules are unclear: they wait, they hedge, they informally absorb the decision rather than risk being seen as someone who couldn't handle it.
The silence that precedes a late escalation is not reluctance. It is the rational response to a system that has given no signal about when or how escalation is appropriate.
This distinction matters more than it sounds. If the problem is people, the solution is behavioral — coaching, culture change, communication training. If the problem is design, the solution is structural — and it can be built, documented, and sustained without depending on any individual's willingness to be bold.
Three Failure Modes
Escalation doesn't break down in one way. Across delivery environments — ERP migrations, public sector infrastructure programs, cross-functional change initiatives — three distinct failure patterns appear with enough regularity that they can be named and designed against.
-
01
Threshold ambiguity There is no defined trigger for when something becomes an escalation. Teams rely on felt sense — "this feels serious enough" — which is inconsistent, anxiety-producing, and almost always leads to late escalation. Without a threshold, the default is to keep trying to solve it internally until it's undeniable.
-
02
Pathway confusion Even when a team member recognizes that something needs to go up, they frequently don't know where "up" actually is. Who receives this? In what format? Through which channel? Does it go to the project sponsor, the steering committee, the functional lead? When the pathway isn't mapped, people either escalate to the wrong level or don't escalate at all.
-
03
Decision packet absence Escalation without context creates a different kind of bottleneck. A senior stakeholder receives a problem without a recommended resolution, without the data needed to decide, and without a clear ask. The issue sits in their inbox while they wait for more information. A well-designed escalation includes the problem, the options, the recommendation, and the decision needed — ready for a yes or no.
Each of these failure modes has a structural root. Threshold ambiguity is a governance design gap. Pathway confusion is an org design gap. Decision packet absence is a delivery discipline gap. None of them are fixed by asking people to be more forthcoming.
What Design Actually Means
Designing an escalation pathway is not the same as drawing a flowchart and calling it a process. The flowchart is the output. The design is the thinking that precedes it — and it requires answering questions that most project governance documents never address.
What qualifies as an escalation?
Not everything is escalable. Decisions the team has authority to make should stay with the team. The design work is defining the categories that cross the threshold — typically: decisions that exceed a defined cost or schedule impact, issues that require authority the team doesn't hold, risks that have moved from watch to active, and conflicts between functions that can't be resolved at the working level.
Who is the right recipient at each level?
Different escalation types belong in different hands. A scope change that affects budget goes to the sponsor. A resource conflict between two department heads goes to their shared executive. A compliance risk goes to governance before it goes anywhere else. The pathway needs to be mapped by issue type — not by hierarchy alone.
A well-designed escalation system is one where any team member can answer, without hesitation: what would trigger an escalation, who it would go to, in what form, and within what timeframe.
What does a complete escalation look like?
The format matters. An escalation that arrives as "we have a problem with the vendor" is not actionable. An escalation that arrives as a structured brief — issue summary, timeline impact, options considered, recommended path, decision needed — can be resolved in a single conversation. The packet is not bureaucracy. It is the condition for fast decision-making at the top.
The Structural Fix
Building a functional escalation system means replacing felt sense with explicit structure at every point where escalation currently depends on individual judgment. The contrast is not subtle.
The right time to build this is before delivery begins — during the governance design phase, when the project charter and RACI are being developed. Escalation pathways should be a standard artifact alongside the risk register and the decision log. They should be reviewed with the steering committee at kickoff so that every stakeholder knows both what to expect and what is expected of them when an issue arrives.
In practice, this rarely happens. Escalation design gets treated as something that can be figured out if and when it's needed. The cost of that assumption is paid in weeks of delay, in decisions that get made at the wrong level, and in the frustration of senior leaders who receive problems they can't act on and teams who feel unsupported.
The Question to Ask Now
If you are currently running a project or managing a program, there is a useful diagnostic you can run today. Ask your team: if a critical risk materialized tomorrow that exceeded your current authority to resolve — what would you do?
If the answer involves hesitation, a description of who they'd probably call, or uncertainty about what information they'd need to bring — the escalation system isn't designed. It's improvised. And improvised systems work only until they're under real pressure.
The investment required to fix this is not large. A two-hour working session to define trigger categories, map pathways, and agree on a packet format is sufficient for most programs. The documentation fits on a single page. The value — in decisions made faster, in issues resolved at the right level, in stakeholder confidence — is disproportionate to the effort.
Escalation failure feels like a people problem because it shows up as human behavior: someone didn't speak up, someone didn't act, someone didn't ask for help in time. But behavior is downstream of structure. When the structure is unclear, the behavior will be inconsistent — regardless of how talented or experienced the people are.
Build the system. The behavior follows.
Escalation is not a soft skill gap. It is a governance design gap — and like all design gaps, it has a structural solution. Define the triggers. Map the pathways. Build the packet format. Do this before delivery begins, review it with your steering committee, and document it alongside your risk register.
When the crisis arrives — and it will — you will not need to ask who should know, how to tell them, or what to bring. The system will already have that answer.