The Art of the Escalation

Junior PMs avoid escalation because it feels like admitting failure. Senior PMs escalate early because they know the cost of delay. It took me years to learn the difference.

When to escalate

When you've exhausted your authority. If I've talked to the API team lead twice and the dependency is still unresolved, I'm not going to have a third conversation that produces a different result. That's when I bring in their engineering director.

When the risk exceeds your level. A one-day slip? Handle it yourself. A potential two-week delay on a committed delivery? Your leadership needs to know today, not next week.

When cross-team politics are blocking progress. Some blockers aren't technical — they're organizational. Teams protecting their roadmap, competing priorities, resource conflicts. These require someone with broader authority to resolve.

How to escalate well

Bring solutions, not just problems. "We have a dependency issue" is a complaint. "We have a dependency issue; here are three options with trade-offs, and I recommend option B" is an escalation.

Be specific about what you need. "I need the VP to tell Team X to prioritize our API changes this sprint" is actionable. "I need help with the API situation" is not.

Document the timeline. Show what you've already tried and when. This demonstrates diligence and helps the escalation target understand the full picture without re-investigating.

Escalate to the right level. Going too high too fast burns political capital. Going too low wastes time. Match the escalation level to the decision authority needed.

The cultural component

I work to build a team culture where escalation is expected, not feared. When an engineer escalates a technical risk to me early, I thank them publicly. When they sit on it for a week hoping it resolves itself, we have a private conversation about why that's more dangerous than escalating.

Escalation is a tool. Use it precisely, not reluctantly.