The Senior Engineer Skill Tree Nobody Talks About

TL;DR: There are two skill trees in engineering. Tree A (technical) is well-documented and grindable. Tree B (social, communication, influence) is invisible — but every promotion above Senior depends on it. Most engineers max Tree A and stall, wondering why the level-up isn't happening. This post explains why, and what to do about it.

Howdy. Let me tell you about the most confusing meeting I ever sat in.

I was three years into my SRE career. I'd built monitoring dashboards that made our VP weep with joy. I could debug a Kubernetes networking issue faster than most people could spell "NetworkPolicy." My on-call rotations were clean. My PRs were thorough. My technical skills were, objectively, strong.

And I got passed over for promotion. Again.

The feedback? "Kyle needs to work on his executive presence."

I stared at that phrase like it was written in Klingon. Executive presence? I'm an engineer. I build things that don't fall over at 2am. What does "presence" have to do with any of this?

Why do strong engineers get passed over for promotion?

Because there are two skill trees in engineering, and most people only know about one.

Skill Tree A is the one you know. Languages, frameworks, cloud platforms, system design, algorithms. It's well-documented. There are courses, certifications, LeetCode problems. You can grind it.

Skill Tree B is invisible. It includes things like:

• Reading the room in a meeting and knowing when to push your idea vs. when to let it breathe
• Giving feedback to a teammate that actually lands instead of making them defensive
• Navigating a reorg without panicking or poisoning the well
• Turning a hallway conversation into a career opportunity without being slimy about it

Most engineers pour every skill point into Tree A and then wonder why the level-up isn't happening. The promotion is gated on Tree B. The feedback you get ("communicate more," "show more leadership," "build cross-team relationships") is the manager trying to translate Tree B requirements into something you'll act on.

What does "executive presence" actually mean for engineers?

After that promotion miss, I spent two years figuring out what the feedback really meant. Here's my translation for engineers:

Executive presence = the ability to make other people feel confident in your competence AND your judgment.

Notice both parts. Your teammates already trust your competence — they've seen your code, your incident responses, your designs. What they haven't seen is whether you can:

• Communicate a technical decision to non-technical stakeholders without making them feel stupid
• Disagree with a staff engineer without turning it into a flame war
• Admit you were wrong without it becoming a whole thing
• Champion someone else's idea when it's better than yours

These aren't "soft" skills. There's nothing soft about them. They're the hardest skills you'll ever develop because there's no compiler to tell you when you got it wrong.

How does the technical-vs-social skill ratio change as you level up?

Here's the math that finally clicked for me. At any decent tech company:

The ratio flips between Senior and Staff. And nobody warns you. You just keep grinding Tree A and wondering why the XP bar stopped moving.

This is the cliff most senior engineers hit. They built their identity on being the technical one. The thing that got them to senior actively works against them at the next level — because at staff+, the bottleneck is no longer their code, it's their ability to influence other people's code.

What's the BBQ pit analogy for this?

I grew up in Texas, so let me put it this way.

You can have the best smoker money can buy. You can source prime brisket, use the perfect rub, maintain 225 degrees for 14 hours. The meat can be absolutely flawless.

But if you can't hold a conversation with the people at the table? If you can't make your guests feel welcome? If you grunt and shrug when someone asks about your process?

You're just a person standing alone next to a very expensive smoker.

The brisket is your code. The gathering is your career. Both matter.

What can a senior engineer do this week to start working on Tree B?

I'm not going to pretend I have a quick fix. I spent years on this and made a ton of mistakes. But here are three things you can start doing this week:

1. Listen for the subtext

In your next meeting, don't just track the words. Track the energy. Who's leaning in? Who checked out? When your manager says "that's an interesting approach," do they mean it, or is that code for "I hate this but I'm being polite"?

Engineers are great at parsing log files. Start parsing conversations the same way.

2. Give one piece of genuine feedback

Not in a PR comment. Face to face (or camera to camera). Tell a teammate something specific they did well and why it mattered. Not "great job" — that's noise. Something like: "The way you broke down that migration plan in the design review made it way easier for the PM to prioritize. That saved us a week."

Specific. Genuine. Impactful.

3. Volunteer for the uncomfortable thing

The next time there's a cross-team initiative, a stakeholder presentation, or a mentoring opportunity — raise your hand. These are reps. You don't get better at bench press by reading about bench press.

How do I systematically build Tree B?

The fastest way to start is the free Developer EQ Sprint — a 2-week, 10-exercise workbook that gives you a structured rep-builder for the most common Tree B skills. Each day is ~15 minutes. Day 1 is the skill tree audit (this post is essentially Day 1). Day 9 walks you through writing your own promotion brief.

If you want the full playbook, the book is $20 and uses music production as the framework — EQ, compression, stems, mixing — because those concepts map cleanly to how humans interact.

If you want to keep practicing once the workbook ends, the book takes the same exercises and goes deeper into the why behind them — so when you're in the actual conversation, you've already thought through the framework.

Your technical skills got you here. Your human skills will get you where you're going.

FAQ

Is "executive presence" just a euphemism for "we don't like you"?

Sometimes — but usually not. Most managers genuinely struggle to articulate Tree B requirements. "Executive presence" is the catch-all for the cluster of skills (communication, judgment, composure under pressure, influence) that's hard to name precisely. If you ask "what specifically would you want to see?" most managers will give you a real answer.

Can you actually learn Tree B, or is it innate?

Learnable. Almost entirely. Some people start with more reps (raised in chatty households, did debate in school, had a previous customer-facing job), but the underlying skills are practiced behaviors, not personality traits. Same as code review or system design — you get better with structured practice and feedback.

How long does it take to see promotion impact from Tree B work?

Realistically, 6-12 months. Promotion decisions lag the work by at least one calibration cycle. The good news: even if your current promo cycle has already been decided, the work compounds. The next cycle starts the day after this one ends.

What if my manager doesn't see my Tree B improvements?

You write the promotion brief for them. The single highest-leverage Tree B skill is making it easy for your manager to advocate for you in calibration meetings. The Day 9 exercise in the workbook is exactly this — drafting a one-page brief your manager can copy-paste into your packet.

Should I leave for a different company if I keep getting passed over?

Sometimes. But not before you've genuinely worked on Tree B at your current job — because if Tree B is the gap, switching companies just resets the clock without fixing the underlying issue. Try one full review cycle of focused Tree B work first. If you've done that and still aren't moving, then yes, switch.

This is part of the Developer EQ series on social skills for engineers. Get the free 2-week workbook or the book — $20.