Escalation Without Burning Bridges.

Escalate the problem, not the person

Escalation is one of the most misunderstood tools a technical program manager has. Done wrong, it reads as an accusation: you went over someone's head, you made them look bad, you imported a fight. Done right, it is the fastest, cleanest way to unblock a program and protect everyone involved, including the person you escalated past.

I have escalated hundreds of times across programs at different companies, including a critical security incident where decisions had to move in hours, not days. I have watched two failure modes up close. TPMs who are afraid to escalate leave programs stuck for weeks on a problem a single email could have solved. TPMs who escalate carelessly burn trust that takes months to earn back. The whole skill lives in the difference between those two.

When to escalate

Most bad escalations are bad because of timing, too early, before you have earned the right, or too late, after the damage is done. I escalate only when three conditions are all true:

1. The issue is time-sensitive. There is a real clock: a milestone, a dependency, an incident. If it can wait without cost, it can be solved at the working level.

2. I have exhausted my direct influence. I have raised it with the right people, brought the data, tried the alignment, and I am genuinely out of moves at my level.

3. Not escalating would cause more damage than escalating. This is the honest one. Every escalation spends a little social capital. You escalate only when the cost of staying silent, to the program, the timeline, the company, is clearly higher than that.

When all three are true, escalation is not a failure of nerve or a political move. It is your job. Holding the risk quietly would be the failure.

The clock flexes with program tempo. For a quarterly delivery, three days stuck on a dependency is a signal. For an incident, three hours is. The three conditions stay the same; only the deadline changes.

The clean escalation

Once the three conditions are met, how you escalate decides whether you unblock the program or start a feud. I think of it as four moves.

1. Warn before you escalate

The single move that prevents most burned bridges: talk to the person before you go over their head. Before I send anything to their manager, I tell them it is coming.

It sounds like this: "I want to flag that I am planning to loop in your manager on this, because we are now several days past the point where it needed a decision and the milestone is at risk. I wanted to give you a heads-up and one more chance to resolve it first. Can we get to a decision by tomorrow morning?"

This does two things. It gives them a chance to fix it without the escalation, which often resolves the whole thing on its own. And it signals respect even as you hold firm on the program's need. The escalation stops being a surprise attack and becomes something they saw coming.

2. Frame the problem, not the person

The fastest way to turn an escalation into an enemy is to make it about a person. The fastest way to keep it clean is to make it about the program.

Avoid: "She hasn't replied in two weeks." "That team is blocking us." "I can't get traction with him." Each one reads as a complaint about an individual.

Use: "We have a decision that needs authority above the working level." "This dependency is the current critical-path constraint and needs a leadership-level call between the two teams." "We have tried options A, B, and C and reached an impasse that needs a senior decision."

The difference is agency. The second set treats escalation as a normal part of running a program, not as a grievance.

This is also where the message itself matters. A good escalation has four parts: context, ask, options, and recommendation. Context is the situation, what has been tried, and the constraints, in three to five sentences, not the full history. The ask is what you need, specifically, with a deadline; "a decision on the vendor by Thursday" is an ask, "some help here" is not. Options are the viable paths forward, which show you have done the thinking and make the decision easy. The recommendation is what you would do, which signals you still own the problem even while asking for help.

3. Escalate through, not around

There is a real difference between escalating through a chain and around it. Through means looping in the relevant manager with clear framing that you need help at their level. Around means jumping straight to senior leadership and skipping the layer in between.

Through is almost always the right first move. It preserves relationships, gives managers the visibility they actually need, and leaves a clean trail. Around is for genuine emergencies, and it should be rare. When you do go around, say so out loud: "I am coming to you directly because of the timeline, and I have already tried resolving it with the team." The person you skipped will find out either way. Whether they read it as a fair call or a political move depends entirely on how openly you handled it.

4. Close the loop

What you do after the escalation matters as much as the escalation itself.

When it resolves, go back to the person you escalated past: "Thanks for working through this, the decision is in place and we are back on track." That one note tells them the escalation was about the program, not about them. Then close the thread with the leaders you looped in, never leave senior people holding an open question. And watch for patterns: one escalation on a dependency is normal, but repeated escalations on the same team or the same type of issue are a structural problem that needs a different conversation, not just a faster escalation next time.

Escalation is risk management

The most useful way to think about all of this is as risk management. When a blocker sits on the critical path and the fix requires authority you do not have, choosing not to escalate is choosing to hold that risk silently. That is not program management. It is program gambling.

Escalate cleanly, with the three conditions met and the four moves done well, and you are not burning a bridge. You are doing your job in the way that gives everyone, including the person you escalated past, the best chance of succeeding. People on the receiving end of a well-run escalation often walk away with more respect for you, not less. That is the version worth building toward.