When to Escalate and When to Absorb

A senior developer on one of my teams told me they were considering leaving. A client escalated a minor bug as a critical blocker. A vendor missed a milestone by a week.

Three problems in the same week. I escalated one, absorbed two. Getting that ratio right is one of the most important skills a PM develops over time, and one of the hardest to teach.

My Decision Framework

Escalate when the problem exceeds your authority to solve. If fixing the issue requires budget approval, contract changes, or organizational decisions, it needs to go up. I escalated the vendor issue because resolving it required renegotiating a delivery timeline that was part of a signed contract.

Absorb when escalating would create more problems than it solves. The client's "critical" bug was a cosmetic issue on a non-production page. Escalating it would have triggered a war room, pulled engineers off sprint work, and created unnecessary anxiety. I acknowledged the client's concern, assigned it to the next sprint, and communicated a timeline. Problem solved without noise.

Absorb retention risks carefully. The developer considering leaving was having a bad week, not making a decision. I had a conversation, understood their concerns, adjusted some workload, and followed up a week later. Escalating a vague attrition risk to leadership would have created a paper trail that helps nobody.

The Cost of Getting It Wrong

Over-escalating erodes trust. Leadership starts seeing you as someone who cannot handle problems. Under-escalating creates surprises. Leadership finds out about a problem too late and wonders why you did not tell them.

The calibration comes from experience. But the principle is simple: escalate when you need authority you do not have, absorb when you have the tools to handle it yourself. When in doubt, ask yourself — will leadership be upset that I did not tell them about this? If the answer is yes, escalate.