2026-10-15
October 15, 2026
Most escalations fail because they hand a senior person a problem instead of a choice.
Every senior TPM has sent the message: "Team A and Team B disagree on the API contract, and we're blocked. Can we get on a call?" It feels responsible. It is neither. You have surfaced a conflict, which is a feeling, and asked a busy executive to reverse-engineer the decision hiding inside it. The reply is usually a meeting, then a second meeting, then a vague "work it out," and you have lost a week and some of your standing.
Escalation is a decision tool. It applies when the current owner lacks the authority, context, resources, or cross-functional leverage to resolve something. If no decision or help is needed, the message is an update and should be labeled one. Antoine Buteau, in his May 2026 executive communication series, puts it sharply: "Escalation is not panic with a senior audience." Senior leaders are not afraid of bad news. They are allergic to unframed news.
The fix is a discipline, not a template: name the decision, bound it, bring options with costs, make a recommendation, and say what would change your mind. The rest of this issue is about why that is harder than it sounds, why it is the core of managing up and sideways at staff level and above, and how to close the loop afterward with a method Jeff Bezos made famous.
Treat the escalation as something you ship to a user with limited time and a specific job to do. The user is a director or VP who has about ninety seconds, no context on your program, and one lever: a decision. Product thinking applies directly. What is the job to be done? Make a call they are qualified to make, without re-deriving the situation. Every sentence that does not serve that job is friction.
Why people escalate badly. A November 2025 CIO.com piece by Priyank Desai and Snahil Singh lists the reasons people avoid escalating at all: fear that it signals failure, worry about accountability, damage to relationships, and the label "difficult to work with." The result is the pattern Buteau describes, escalations that are either too noisy (everything is urgent) or too late (the good options are gone). Both come from the same root. The sender has not decided what they are asking for, so they either shout or wait.
The anatomy of a decision-ready escalation. Buteau's list of what a strong note answers is a good spec: what is happening, why it matters, why now, what decision is needed, what the options are, what inaction costs, who owns the work, and what should not happen while the decision is pending. Collapse that into a one-pager and you have the structure Desai and Singh recommend: problem context, business impact, options with pros and cons, a clear summary of the disagreement, and the specific guidance you need. Notice what is absent: a narrative of who said what in which meeting. The history is an appendix, not the lead.
Bound the decision. The most underrated move is the decision boundary. "Should we adopt the new contract?" invites the executive to wander into the whole architecture. "Between Option 1 (ship v1 contract in Q4, migrate later) and Option 2 (delay two sprints, ship v2), which do we pick by Friday?" lets them stay on one narrow question. Bounding also protects the executive, which is a form of respect that gets remembered.
Managing sideways is the same craft. Desai and Singh recommend that when the two parties report to different managers, you use a joint escalation with managers at the same level, which reduces in-group bias. As a TPM you often hold neither reporting line, so you are the one who can draft the one-pager both sides sign off on as an accurate statement of the disagreement. Getting your peers to agree on the description of the disagreement, even when they cannot agree on the answer, is the highest-leverage thing you can do. It also turns you into the neutral author, which is the real source of influence without authority. Meg Adams of the New York Times makes a related point in LeadDev (July 2026): share a written point of view before the live discussion, make the ask easy to answer, and set a date for the decision.
The leader's side. If you are the director receiving these, the same sources point to practices that make your org better at it: insist on data, publish tenets so teams escalate only when a tenet is broken, and watch escalation patterns as a health signal. Repeated escalations on the same topic usually mean a missing decision right, not a difficult team.
Time-box before you send. Desai and Singh also advise time-boxing the analysis. A useful rule: if two good-faith attempts at resolution at your level have not produced an answer, the third attempt is an escalation. Waiting longer burns the very options you will later ask the executive to choose among.
Try this week. Take the one issue currently stuck between two teams and write it as a half-page: a one-sentence bounded decision, two or three options each with cost and what it forecloses, your recommendation, "what would change my mind," and the date you need an answer. Send it first to the two peers in conflict with one question: "Is this an accurate description of our disagreement?" Only escalate once both say yes.
What it is. A decision-closing norm: when a team lacks consensus, someone with conviction asks the others to commit anyway, with disagreement voiced but not re-litigated. Bezos described it in his 2016 letter to shareholders, alongside the idea that most decisions should be made with around 70% of the information you wish you had.
When to use it. After an escalation returns a decision that one party dislikes, or any time a stalled decision costs more per week than a mediocre answer would. Best for two-way-door decisions, where you can reverse course if you are wrong.
How to run it:
When NOT to use it. For one-way-door decisions (security, legal, irreversible data migrations) or when the dissent is about missing facts rather than differing judgment; get the facts first.
Example: two directors disagree on a migration cutover date. The VP picks the earlier date, both dissents are recorded with their tripwires (error budget burn, rollback time), and both say "I'm in" before the meeting ends.
The Engineering Leadership Report 2026 (LeadDev) — A survey of 600 engineering leaders finds 37% doing more hands-on technical work, 45% working more hours than a year ago, and one in three managers considering a return to IC work. For a TPM, that is a reminder that your leaders have less slack for unframed problems than they did a year ago.
Where Is Technical Program Management Heading in 2026? — Aadil Maan (Dec 2025) predicts flatter TPM teams, a return of the generalist IC TPM, and AI fluency as a baseline. He frames these as observations, not forecasts; useful as a self-audit checklist.
Escalation management: Tips for making faster, better decisions — Priyank Desai and Snahil Singh (CIO.com, Nov 2025) give a practical recipe for both senders and receivers; the "joint escalation at the same management level" advice is the one to steal.
"Most decisions should probably be made with somewhere around 70% of the information you wish you had."
— Jeff Bezos, 2016 letter to Amazon shareholders
Don't miss what's next. Subscribe to Critical Path: