Empathy and Coaching "Set Exceptional Leaders Apart" in 2026—But We Still Promote Based on Technical Excellence. When Does This Change?

General
1

I’ve been thinking a lot about this lately, especially as we’re about to make senior leadership promotions at our EdTech startup. The research is clear: empathy and coaching are what set exceptional engineering leaders apart in 2026. Yet when I look at our promotion criteria—and honestly, at most companies I’ve worked at—we’re still heavily weighted toward technical excellence.

Here’s what I’m wrestling with:

The Data Says One Thing…

The evidence is pretty compelling. Modern engineering leadership emphasizes that while technical expertise matters, empathy, mentorship, and coaching are the differentiators. These are the skills that drive retention in competitive markets, create psychologically safe environments, and support real career growth.

Studies on motivating engineers in 2026 show we need a balance of technology, empathy, flexibility, and leadership vision. The interpretation of metrics and application to people decisions remains fundamentally human work requiring judgment and empathy.

…But Our Actions Say Another

Yet here’s what actually happens when we sit down to discuss promotions:

  • We spend 60% of the conversation on technical contributions
  • We look for the “best engineer” to promote to team lead
  • Our promotion packets require detailed technical achievements
  • Empathy and coaching are “nice to haves” in the comments section

At my current company (80+ engineers now, up from 25 when I joined), I’ve seen brilliant engineers get promoted to management positions and struggle—not because they can’t code, but because they’ve never had to coach someone through a performance issue or build psychological safety on a team.

Meanwhile, I’ve seen strong people leaders get passed over because their technical contributions aren’t “visible enough,” even though their teams consistently outperform and have the lowest attrition rates in the company.

The Questions I’m Asking

For leaders who’ve made this shift: How did you actually change your promotion criteria? Not just the words on the career ladder document, but the real weightings in promotion discussions?

For ICs considering management: If we’re honest that empathy and coaching matter more than technical depth for leadership roles, how do you build those skills when you’re still an IC? Most companies don’t offer coaching training until after you’re already a manager.

For those who’ve been passed over: Have you experienced being overlooked for promotion because your empathy and coaching skills weren’t “technical enough”? How did you navigate that?

What We’re Trying

I’m piloting a few things with our leadership team:

  • Explicit 50/50 weighting in promotion discussions: technical execution vs. people leadership
  • Required evidence of coaching and mentorship in all senior+ promotion packets
  • Leadership development investment before promotion, not after (we’re running a 6-month leadership training cohort for high-potential ICs)
  • Parallel tracks that let people specialize in technical program management or engineering excellence without requiring team growth

But I’ll be honest—there’s resistance. Some of our best technical contributors don’t want to coach. Some of our executives still default to “promote the best coder.” And our career ladder language is still too technical-skills-heavy.

The Uncomfortable Truth

Here’s what I think is really happening: We promote based on what’s easy to measure, not what actually matters.

Technical excellence is easy to measure—ship this feature, solve that hard problem, get praised in the #tech-wins Slack channel. Empathy and coaching are harder—did they help a struggling IC turn around? Did they create an environment where people felt safe to fail? Did they develop the next generation of leaders?

But “harder to measure” doesn’t mean “less important.” If the research says empathy and coaching set exceptional leaders apart, and we keep promoting based on technical skills, we’re actively selecting for the wrong thing.

What’s your experience? Are you seeing this shift happen at your company? Or are we all still talking about empathy while promoting the same way we did in 2015?

2

This hits close to home. At my company (120 engineers), I recently had to have a hard conversation with our board about exactly this.

The Promotion We Got Wrong

Six months ago, we promoted our best backend architect to Director of Engineering. On paper, it made perfect sense—brilliant technically, shipped critical infrastructure, respected by peers. Three months in, we had our first senior engineer resignation citing “lack of support” and “unclear direction.”

The problem wasn’t that he couldn’t code. The problem was that he’d never had to:

  • Give difficult feedback to someone struggling
  • Navigate team conflict where both sides had valid points
  • Coach someone through imposter syndrome
  • Make the call to let someone go

We promoted based on technical excellence and assumed leadership skills would follow. They didn’t.

What We Changed (Painfully)

After that wake-up call, we completely rewrote our promotion criteria. Not just the career ladder language—the actual rubric we use in calibration sessions:

For Staff+ Engineers (IC track):

  • 60% technical execution and impact
  • 40% mentorship, knowledge sharing, and multiplier effect

For Engineering Managers (people track):

  • 40% technical judgment and architecture input
  • 60% people leadership, coaching, and team outcomes

The resistance was real. Our VP of Eng (who came up in the 2000s) pushed back hard: “We’re an engineering company. We should promote based on engineering skills.”

My response: “Building teams IS an engineering skill. Psychological safety IS a technical competency. If you can’t multiply impact through people, you hit a ceiling at Staff.”

The Investment That Actually Worked

Here’s what made the difference—and this is the part most companies skip:

6-month “Leadership Track” program before promotion decisions:

  • Monthly 1:1 executive coaching ($500/session, company-paid)
  • Quarterly 360 reviews focused on leadership behaviors
  • Required “shadow management” project (lead a cross-functional initiative)
  • Book club on leadership (we did “Radical Candor,” “The Manager’s Path,” “Resilient Management”)

Cost per person: ~$8K. Cost of a bad promotion that leads to senior engineer attrition: $180K+ in recruiting, ramp time, and lost productivity.

The ROI is obvious when you frame it that way.

The Uncomfortable Question

But here’s what I’m still wrestling with: What do you do when your best technical contributors don’t want to develop empathy and coaching skills?

We have a Principal Engineer who’s phenomenal technically but has explicitly said “I don’t want to mentor people. I want to build systems.” And that’s… fine? We need people who go deep on hard technical problems.

But the industry keeps saying “empathy is essential for leadership,” and we keep promoting technical experts who don’t have it. Are we creating two separate career tracks—one for “empathy leaders” and one for “technical experts”—and calling only one “leadership”?

I don’t have a clean answer yet. What I do know is that our attrition rate for engineers reporting to managers who went through the Leadership Track program is 8%, compared to 23% for those who didn’t.

That’s not “nice to have.” That’s business-critical.

Question for @vp_eng_keisha: The 50/50 weighting you mentioned—how do you actually measure the “people leadership” half? We’re struggling with making it objective enough that it doesn’t feel like favoritism.

3

This resonates deeply. At my company (Fortune 500 financial services, 40+ engineers on my teams), I’ve lived both sides of this—as someone who was promoted primarily for technical skills, and now as a leader trying to change the system.

The Personal Story

I got promoted to Engineering Manager in 2019 because I was the best architect on the team. Full transparency: I was a terrible manager for the first 18 months.

I knew how to design distributed systems. I had no idea how to:

  • Create psychological safety for a junior engineer afraid to ask questions
  • Navigate the politics when my team’s roadmap conflicted with another director’s
  • Give feedback that actually helped someone improve vs. just making them defensive
  • Support a team member going through a mental health crisis

The technical skills that got me promoted were maybe 20% of what I actually needed to succeed. The other 80%—empathy, coaching, conflict resolution, emotional intelligence—I had to learn on the job while leading a team. That’s not fair to the team.

Where We’re Stuck (And Why)

Here’s the uncomfortable reality at a large company: our promotion criteria are designed to be defensible in a lawsuit, not to identify good leaders.

When we promote to Director or above, Legal reviews the documentation. They want to see:

  • Quantifiable technical achievements
  • Delivered projects with business impact
  • Performance ratings over time
  • Peer feedback

“Shows exceptional empathy” or “creates psychologically safe teams” is hard to defend if someone sues for discrimination. “Shipped 5 critical infrastructure projects on time” is much cleaner legally.

So even though we know empathy matters, our promotion packets end up 80% technical achievements because that’s what Legal approves.

What’s Actually Working

Despite those constraints, we’ve made progress through specific behavioral evidence:

For “empathy and coaching,” we require:

  • At least 2 direct reports who were promoted under your leadership (shows development)
  • Measurable improvement in team engagement scores (we use quarterly surveys)
  • 360 feedback specifically asking about coaching effectiveness
  • Evidence of “crucial conversations” handled well (conflicts resolved, difficult feedback given)

For “psychological safety,” we look for:

  • Team experiment failure rate (we WANT teams to try things that don’t work—means they feel safe)
  • Blameless postmortem participation and quality
  • Incident response where team members admitted mistakes early
  • Anonymous feedback about whether people feel safe to disagree

It’s not perfect, but it makes “soft skills” concrete enough that Legal approves them as promotion criteria.

The Cultural Shift That’s Harder

But here’s what we’re struggling with: changing what the executives value.

Our C-suite came up in the 2000s-2010s when “10x engineer” culture was dominant. They still light up when someone mentions a clever algorithm optimization. They glaze over when I talk about how I helped a struggling manager develop their team.

Just last quarter, I had a promotion blocked for one of my best managers. Her team has 94% engagement scores, 0% attrition in 18 months, and consistently delivers on roadmap. But she’s not “technical enough” for Director level according to the VP.

Meanwhile, a peer got promoted to Director based on a successful system redesign—even though his team has 30% annual attrition and his direct reports consistently mention “lack of support” in feedback.

We’re rewarding the outcomes we say we don’t want.

The Question I Keep Coming Back To

For those of you who have changed this successfully: How do you shift executive mindset when the executives themselves were promoted under the old criteria?

They got to C-level by being technically brilliant. They survived (and thrived) in environments that didn’t prioritize empathy. Telling them “that’s not enough anymore” feels like telling them their success wasn’t legitimate.

But the data is clear: the leadership that worked in 2015 doesn’t work in 2026. Especially as we try to retain diverse talent who have options and won’t tolerate environments that don’t value them as whole people.

I love what both @vp_eng_keisha and @cto_michelle are doing with structured leadership programs. The ROI math Michelle shared ($8K investment vs. $180K attrition cost) is exactly the kind of framing that might work with my CFO.

Anyone have talking points for convincing a technically-minded C-suite that empathy is a business metric, not a “nice to have”?

4

Coming at this from the product side, and I have to say—this exact mismatch is why product and engineering struggle to collaborate effectively.

The Pattern I Keep Seeing

At my current company (Series B SaaS, ~65 engineers), I work with 4 Engineering Managers. Three of them were promoted because they were great engineers. One was promoted because she was a great leader who happened to be a good engineer.

Guess which one I can actually partner with to deliver product outcomes?

The three “great engineers”:

  • Want to discuss technical architecture for 45 minutes before we talk about customer problems
  • Struggle to translate technical constraints into product trade-offs I can take to customers
  • Default to “we need 3 more engineers” when scope is tight instead of helping prioritize ruthlessly
  • Rarely proactively bring up team capacity or morale issues until someone quits

The “great leader”:

  • Starts conversations with “what problem are we solving for whom?”
  • Translates technical complexity into language I can use with customers and sales
  • Proactively flags when her team is underwater and works with me to cut scope
  • Tells me when someone on her team is struggling BEFORE it becomes a performance issue

The difference isn’t technical competence—they’re all technically strong. The difference is empathy for the customer AND empathy for the team.

The leader who gets both can hold two truths at once:

  1. “This is technically the right thing to build”
  2. “But my team is burned out and our customers need something simpler”

The technically-focused managers optimize for technical correctness and assume product outcomes will follow. They don’t.

Why This Matters for Product Delivery

Here’s the uncomfortable part: when engineering leaders lack empathy, product velocity suffers.

Leadership in engineering research shows that engineering managers who balance technical excellence with people skills create environments where teams can actually deliver. But when managers are promoted purely on technical merit, I see:

  • Longer cycle times because people are afraid to ask for help or admit they’re stuck
  • More rework because juniors don’t feel safe questioning approaches
  • Scope creep because the manager can’t have hard conversations about what’s feasible
  • Attrition which destroys institutional knowledge and velocity

The best product-engineering partnerships I’ve seen happen when the engineering leader cares as much about their team’s growth and the customer’s problem as they do about technical elegance.

The Question Product Needs to Ask Engineering

To @vp_eng_keisha and other engineering leaders: When you evaluate empathy and coaching skills, do you include cross-functional empathy?

I’ve seen engineering managers who are great coaches to their team but can’t empathize with product or design constraints. They’re patient with junior engineers learning to code, but dismissive when I explain why customers need feature X before the “technically correct” feature Y.

Should “ability to collaborate with non-engineering functions” be part of empathy evaluation? Or is that a separate skill?

What We’re Trying (From the Product Side)

At my company, I’ve started including “cross-functional collaboration” feedback in engineering promotion packets. It’s been… mixed.

When we promoted Sarah to Engineering Manager, I provided detailed feedback about:

  • How she translated technical constraints into customer value trade-offs
  • How she proactively surfaced team capacity issues before they became crises
  • How she helped her team understand customer context, not just requirements

The VP of Engineering thanked me for the feedback, then told me it was “nice to have” but not part of the promotion criteria.

Meanwhile, when we promoted James (brilliant technically, terrible collaborator), I flagged that his team consistently missed product deadlines because he wouldn’t have honest conversations about scope. That feedback was “noted” but didn’t block the promotion.

The result? Sarah’s teams consistently deliver on product roadmap. James’s teams are always “delayed due to technical complexity” that nobody surfaced until sprint 3.

Real talk: If empathy and coaching matter for engineering leadership, product leaders need a seat at the table for engineering promotions. Not veto power, but voice.

Because from where I sit, the engineering leaders who have empathy—for their teams AND for the business—are the ones who actually help us ship products customers love.

Are any of your companies involving cross-functional partners in engineering leadership evaluations? How’s that going?

5

The tension between platform adoption and developer autonomy is something we’ve been wrestling with too.

What’s worked for us is treating the platform as a recommendation system rather than a mandate:

  • Default path: Fully managed platform (90% of use cases)
  • Exception path: Custom setup with approval (takes 2 days, not 2 weeks)
  • Escape hatch: For truly unique needs, documented and supported

Adoption went from 40% to 82% once we stopped treating exceptions as failures.