Escalation Protocols

Overview

Escalation is the act of moving a problem, decision, or blocker to a higher level of authority because the current level cannot resolve it within the required time. Done well, escalation is a professional signal that the team has exhausted its options at the working level and needs support. Done poorly — too late, without context, or without a proposed resolution — escalation creates a crisis where there could have been an early intervention.

For the decisions that frequently require escalation, see Decision Turnaround Time. For communicating status during an escalation, see Stakeholder Communication Frameworks.

Why It Matters

Late escalation is the most expensive kind. A blocker that is escalated on the day it becomes critical leaves no time for the escalation recipient to act. The same blocker escalated a week earlier — when it was Amber — can often be resolved without disruption.

Not escalating is a choice, and it has consequences. Managers who absorb escalatable problems rather than escalating them are making a decision to handle the risk themselves. Sometimes that is the right call. Often it results in a surprise that is larger than the original problem.

Clear escalation paths reduce friction. Teams that do not know who to escalate to, or how, tend to either not escalate (and absorb the blocker) or escalate to the wrong person (and create confusion). Clear paths reduce the friction that prevents timely escalation.

Escalation with a proposed resolution is more effective than escalation with a problem. A manager who escalates "the payment provider is taking three days to respond to our integration query and this blocks our sprint" is creating a problem for their director. A manager who escalates "the payment provider is unresponsive; I propose we switch to the backup provider we evaluated in Q2 — I need your approval to do so" is asking for a decision. The second version gets resolved faster.

De-escalation requires as much attention as escalation. An escalation that is resolved but never closed leaves a trail of senior stakeholders who do not know the problem is solved. Close every escalation explicitly.

Standards & Best Practices

When to escalate

Escalate when:

• A decision required for delivery has not been made within the agreed SLA
• A dependency from another team is blocked and the teams cannot resolve it bilaterally
• A risk that was Amber has materialised into a delivery impact (now Red)
• A scope or resource change is needed that is above the manager's authority to approve
• A conflict between teams cannot be resolved at the team lead level
• A stakeholder is making requests that contradict agreed project scope or commitments

Do not escalate when:

• The problem can be resolved at the working level with one more attempt
• The SLA has not been missed yet (escalating before a deadline creates noise)
• You do not yet have a proposed resolution or a clear ask

Escalation levels

Define escalation levels before they are needed:

Most escalations should resolve at L2 or L3. An escalation that reaches L4 regularly is a signal that L2 and L3 are not functioning effectively.

The escalation package

When escalating, provide a structured summary:

1. What the issue is — one sentence, factual
2. How long it has been unresolved — timeline of attempts to resolve
3. What impact it is having or will have — specific delivery or timeline impact
4. What you have already tried — prevents the escalation recipient from suggesting already-attempted solutions
5. What you need — a specific ask: a decision, a resource, an intervention
6. By when — the deadline for the decision or intervention

An escalation package that answers all six points enables the escalation recipient to act without scheduling a follow-up meeting to gather context.

Escalation vs venting

There is a meaningful difference between raising a problem (escalation) and describing frustration (venting). Escalation packages should be factual, specific, and action-oriented. They should not include editorial commentary about other teams or stakeholders, assessments of blame, or expressions of frustration.

The escalation recipient should be able to act on the package without needing to first untangle the emotion from the facts.

How to Implement

Decision tree: should I escalate?

Is the issue blocking delivery or creating significant risk?
├── No → Monitor; log as Amber in RAID; set a review date
└── Yes
    Has the issue been raised at the working level?
    ├── No → Raise it at L1 first; give it the agreed SLA to resolve
    └── Yes
        Has the SLA for resolution been missed?
        ├── No → Wait; re-confirm the deadline; prepare the escalation package
        └── Yes
            → Escalate to the next level with the escalation package

Escalation communication format

Send this to the escalation recipient:

## Escalation — [Brief topic]

**From:** [Your name]
**To:** [Escalation recipient]
**Date:** [Date]
**Urgency:** [High / Critical]

### Issue

[One sentence: what is the problem?]

### Timeline

- [Date]: Issue first identified / raised
- [Date]: First attempt to resolve at working level
- [Date]: Second attempt / SLA missed
- Today: Escalating

### Impact

[Specific delivery impact: what story, sprint, or milestone is affected? By how much?]

### What we have tried

- [Attempt 1]
- [Attempt 2]

### What I need from you

[Specific ask: a decision, an intervention, a resource]

### By when

[Date and time this needs to be resolved to avoid delivery impact]

Escalation tracking

Log all active escalations:

## Escalation Log — [Project name]

| Date opened | Issue   | Level | Escalated to | Ask   | Deadline | Status   | Date closed |
| ----------- | ------- | ----- | ------------ | ----- | -------- | -------- | ----------- |
| [date]      | [issue] | L3    | [name]       | [ask] | [date]   | Open     | —           |
| [date]      | [issue] | L2    | [name]       | [ask] | [date]   | Resolved | [date]      |

Review the escalation log in weekly stakeholder updates. Escalations that are open and approaching their deadline should be flagged explicitly.

Closing an escalation

When an escalation is resolved:

1. Notify all parties who were involved in the escalation
2. Record the resolution in the escalation log
3. Update the RAID log (the underlying risk or issue may still need monitoring)
4. Conduct a brief post-mortem: could this escalation have been prevented? What would have needed to be different?

Tools & Templates

Escalation package (short form)

For quick escalations via email or Slack:

**Escalation — [Topic]**

Issue: [One sentence]
Impact: [Delivery impact]
Tried: [What has been attempted]
Need: [Specific ask]
By: [Deadline]

Escalation path map

Create this at the start of a significant project:

## Escalation Paths — [Project name]

| Issue type                    | L1 (working level)  | L2 (team leads)                     | L3 (management)                      |
| ----------------------------- | ------------------- | ----------------------------------- | ------------------------------------ |
| Cross-team dependency blocked | PM + counterpart PM | Team lead + counterpart             | Manager + counterpart manager        |
| Decision not made in time     | PM → decision owner | PM manager → decision owner manager | Director                             |
| Scope conflict                | PM + EM             | PM manager + EM manager             | VP Product + VP Engineering          |
| Vendor / partner unresponsive | PM → vendor contact | PM manager → vendor account manager | Director → vendor escalation contact |

Common Pitfalls

Escalating too late. The most common escalation failure. A problem that was Amber for two weeks and Red for one day is escalated on the day of impact. The escalation recipient has no time to act. Escalate at Amber, not at Red.

Escalating without an ask. Escalations that describe a problem without requesting a specific action create work for the escalation recipient. They have to interpret the problem, determine what help is needed, and get back to the requestor. Specific asks get resolved faster.

Bypassing levels. Going directly to senior leadership for an issue that should have been resolved at the team lead level creates noise and erodes trust in the escalation process. Work through levels in order; escalate to the next level only when the current level has been given a fair opportunity to resolve.

Not de-escalating. An escalation that resolves but is never formally closed leaves the escalation recipient in the dark about whether their intervention worked. Close every escalation explicitly, with a note on resolution.

Escalating with blame. "The platform team is not co-operating and has been obstructionist" puts the escalation recipient in the position of managing a conflict rather than solving a problem. Factual escalations — "the dependency has not been delivered; the impact is [X]; I need [Y]" — are easier to act on than blame-laden ones.

Treating escalation as failure. Managers who are reluctant to escalate because it signals that they cannot handle the situation tend to absorb problems until they become crises. Timely escalation is a professional act, not an admission of defeat. The point of an escalation path is to use it.