The Senior Engineer Skill Tree Nobody Talks About

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?

The Skill Tree You Can't See

Here's what nobody tells you when you start in tech: there are two skill trees.

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 BBQ Pit Analogy

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 "Executive Presence" Actually Means

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.

The Uncomfortable Math

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

Junior to Mid: Almost entirely technical. Ship code, learn the stack, don't break prod too often.
Mid to Senior: Mostly technical, but you need to start mentoring, writing docs, and communicating clearly in design reviews.
Senior to Staff: Maybe 40% technical, 60% influence, communication, cross-team collaboration.
Staff to Principal: 20% technical, 80% organizational leadership.

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

So What Do You Actually Do?

I'm not going to pretend I have a quick fix. I don't. I spent years on this, made a ton of mistakes, and eventually wrote a whole book about it (using music production as the framework, because that's how my brain works).

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.

The Session Starts Now

I wrote Developer EQ because I wish someone had handed me this playbook a decade ago. It uses music production as a metaphor — EQ, compression, stems, mixing — because those concepts map perfectly to how humans interact.

If you're a developer who's technical enough but stuck on the "other stuff," the book is $20 and it'll save you years of figuring this out through painful trial and error.

And if you want to go deeper, the live cohort is where we actually practice this stuff together. Four weeks. Small group. Real exercises, not theory. Because reading about social skills without practicing them is like reading about guitar without ever picking one up.

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

This is part of the Developer EQ series on social skills for engineers.