How To Escalate Effectively To Senior Manager

Escalating Isn’t Throwing the Problem Upstairs

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Escalating Isn’t Throwing the Problem Upstairs

Escalating technical issues is one of the most misunderstood responsibilities in software engineering leadership. When done right, it builds trust. When done wrong, it erodes confidence fast. I want to share the simple, high-trust way to escalate problems.

You see, too many engineering leaders misunderstand what escalation really is.

They think it means alerting their boss. Ringing the alarm. Forwarding the pain.

“Hey, this broke—someone above me needs to care about this now.”

I’ve seen it happen countless times: a manager or tech lead kicks the problem up the chain with little context, no recommendation, and zero accountability.

That’s not escalation. That’s abdication. And it undermines your credibility.

True escalation is a leadership skill. It’s about helping people above you make a better, faster decision with less cognitive load. Done well, escalation is a signal that you are in control, even when things are going wrong.

Done poorly, it’s a signal that you’re over your head.

So what does effective escalation look like?

Here’s the simple framework I teach every engineering manager on my teams:

1. What was the good state?

Start by establishing the baseline.

What was working? What did we expect?

Example: “We normally make data available within 5 minutes of a complete simulation run, well below the 15 minute SLA.”

This grounds your audience in reality before things went wrong.

2. What changed?

Describe the deviation from that baseline.

What broke? What’s different now?

Example: “As of this week, the new data analysis is taking 14 minutes.”

Now they understand what went off the rails.

3. What’s the impact?

This is where you give them a reason to care.

Who is affected? What are the consequences if this continues?

Example: “As a result of the longer data analysis, the total time to make the data available is 17 minutes and we’re now breaching the SLA. There are financial penalties tied to this breach.”

Make it concrete. Emotional if necessary. Don’t bury this.

4. What do I recommend and what do I need from you?

This is where most escalations fail. You don’t just show the problem, you own the next step.

Offer a path forward and make a clear ask of the person you’re escalating to.

Example: “We recommend temporarily disabling the new analysis and rolling back to the old one. I need your help getting alignment with the Data team as we’ll delay their project and impact their customers.”

If you want to be seen as a strategic, dependable leader in engineering, learn to escalate like a peer, not a passenger. Show them what changed, what matters, what you’ll do about it, and how they can help. You’ll gain more trust and influence with this one habit than with a hundred status updates.

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.