The Art of Technical Escalation: When AI Tools Can't Solve the Problem

Escalation Is a Skill, Not a Failure

Early in my career, I viewed escalation as a sign that something went wrong — that I couldn't handle the problem. After years of managing complex programs at Google, I've come to see escalation as one of the most valuable tools in a TPM's toolkit. The question isn't whether to escalate, but when and how.

My Escalation Framework

The 3-Signal Rule

I escalate when three signals align:

1. Timeline impact — the issue will cause a meaningful delay (not just a day, but enough to affect a milestone)
2. Exhausted local options — I've already tried the obvious solutions and involved the immediate team
3. Cross-team dependency — the resolution requires someone outside my org to take action

If only one or two signals are present, I continue working the problem. When all three align, I escalate immediately — not in the next standup, not in the weekly review, but now.

The Escalation Package

A good escalation has five elements:

• The problem — one sentence, no jargon
• The impact — what happens if we don't solve this, in business terms
• What we've tried — demonstrates diligence
• What we need — specific ask, not a vague request for help
• Proposed timeline — when we need the decision by

Related: see Why Every TPM Should Learn to Write Prompts Like Code and From Spreadsheets to AI: The Evolution of Program Management Tools.

Where AI Helps (And Where It Doesn't)

AI tools are getting better at the first two elements — they can synthesize data to clearly articulate a problem and quantify its impact. But the last three elements require judgment that AI can't replicate. Knowing what "we've tried" means understanding the organizational context. Knowing "what we need" means reading the room. And proposing a timeline means understanding the decision-maker's constraints.

Use AI to build the escalation package. Use human judgment to deliver it.