Empathy and Coaching Set Great Engineering Leaders Apart in 2026—Yet We Keep Promoting the Wrong People

vp_eng_keisha · April 5, 2026, 7:59am

Last quarter I promoted two engineering managers.

Manager A was our strongest technical contributor—built internal tools that 3x’d team velocity, mentored juniors on architecture patterns, and consistently delivered complex features ahead of schedule.

Manager B had good technical skills but wasn’t the sharpest architect in the room. What set them apart: they developed three engineers who are now ready for senior roles, ran 1:1s that people actually looked forward to, and built the kind of team culture where people don’t leave.

Guess which one our promotion committee initially ranked higher?

The Research Caught Up to What We Already Know

I’ve been thinking about this a lot since reading the 2026 engineering leadership research. The data is clear:

McKinsey found companies investing in leadership development are 2.4x more likely to hit performance targets
High-empathy organizations achieve 56% higher revenue growth than peers
Teams led with empathy are 8.5x more engaged than average
92% of hiring managers now consider soft skills equally or more important than technical skills

Engineering leaders are re-evaluating what makes teams effective: mentorship, curiosity, emotional intelligence, and empathy are rising in importance. Technical depth is becoming table stakes, not the differentiator.

As one study put it: “Companies are emphasizing adaptability and cross-functional thinking above pure coding prowess—empathy for making complex decisions involving human workers and AI agents is now the key factor that drives engineering success.”

The Promotion Paradox

Here’s what keeps me up at night: our IC track still rewards engineers who scale via tools and automation. Build a script that saves 100 hours? Promotion-worthy. Ship a feature with AI-assisted velocity? Promotion-worthy.

But our management track requires completely different capabilities that we barely measure—coaching effectiveness, team retention, cross-functional collaboration, developing future leaders.

The brutal truth? At my EdTech company, we almost promoted someone who optimized for their own productivity over building team capability. They automated themselves into efficiency. But they hadn’t developed a single engineer ready for the next level.

Meanwhile, the manager who spent hours coaching, who ran retrospectives that actually changed how we worked, who created psychological safety so people could fail fast and learn—that person doesn’t have a portfolio of “I built X tool that saved Y hours.”

Their impact is in other people’s growth. And we almost missed it.

What Are We Actually Measuring?

I pushed back on our promotion committee. Here’s what I asked them to consider:

For IC → Manager transitions: Are we promoting people because they built tools that scale, or because they demonstrate the ability to develop others?
For Manager → Senior Manager/Director: Are we evaluating based on their team’s velocity, or based on how many future leaders they’ve developed?
For leadership roles: Do we value leaders who “stay technical” and contribute code, or leaders who create environments where their teams do their best work?

The committee’s first instinct was to weight technical contributions heavily. Because that’s what we can measure. Story points, deploy frequency, code quality metrics, tool adoption.

But retention? Team engagement? Cross-functional collaboration? Number of direct reports ready for promotion? Those are harder to quantify—so we ignore them.

The AI Shift Makes This Urgent

Here’s why this matters now and not five years ago: AI is handling more of the coding. The value of “being the best coder in the room” is declining. The value of “building teams that navigate ambiguity, collaborate across functions, and develop the next generation of leaders” is skyrocketing.

If we keep promoting people based on 2020 criteria—technical depth, tool building, individual velocity—we’re going to build leadership teams optimized for a world that no longer exists.

So Here’s My Question

Look at your last three engineering promotions—especially IC to Manager, or Manager to Senior Manager.

What did your promotion rubric actually reward?

Technical contributions and tools built?
Number of features shipped or velocity improvements?
Team outcomes: retention, engagement, reports ready for promotion?
Coaching effectiveness and leadership demonstrated?

I’m not saying technical skills don’t matter. They absolutely do. But if someone can’t coach, can’t build psychological safety, can’t develop others—are we really setting them up to succeed as leaders?

And if your best people-developer doesn’t have a stack of “I automated X process” examples, are they getting overlooked?

Because based on the research, we’re leaving a 2.4x performance multiplier and 56% revenue growth on the table if we keep promoting the wrong people into leadership.

How is your company thinking about this?

eng_director_luis · April 5, 2026, 8:00am

This hits close to home, Keisha. I’m dealing with exactly this paradox at our financial services company.

Six months ago, I promoted one of our strongest technical architects to engineering manager. On paper, it was the obvious choice—this person designed our entire microservices migration, mentored juniors on distributed systems patterns, and was the go-to expert for complex technical problems.

Three months in, their team was struggling. Retention dropped, people weren’t developing, and the person who had been our architecture MVP was drowning in 1:1s they didn’t know how to run effectively.

The False Choice

Here’s what I learned: We don’t actually have to choose between technical skills and people skills—but our promotion criteria create a false binary.

In financial services, we need both. Regulatory requirements mean our leaders have to understand technical depth (data security, compliance frameworks, audit trails). But they also need to build teams that can navigate constant regulatory changes, work across compliance/legal/engineering boundaries, and develop the next generation.

The issue isn’t that technical skills don’t matter. The issue is that we weight them 80/20 when the actual job requires 40/60 in favor of people leadership.

What Actually Fixed It

I paired that struggling new manager with our head of engineering ops for six months of intensive coaching. They learned:

How to run effective 1:1s (not just status updates, but actual development conversations)
How to delegate with context instead of just throwing work over the fence
How to create psychological safety so people could surface compliance risks without fear

It worked. But it took six months of remedial people leadership training because we promoted someone based on criteria that didn’t match the actual job.

My Current Approach: Dual-Track with Clear Expectations

We now have explicit promotion criteria for both tracks:

IC Track (Staff/Principal/Distinguished):

Technical depth and systems thinking
Influence through architecture and tooling
Mentorship at a technical level (code reviews, design reviews)
Cross-team impact through technical contributions

Management Track (Manager/Senior Manager/Director):

Team outcomes: retention, engagement, promotion readiness
Coaching effectiveness (we actually measure this through skip-level feedback)
Cross-functional collaboration (how well do product, design, and eng work together?)
Leadership pipeline development (how many people are you preparing for the next level?)

The key difference: for management promotions, technical contributions are table stakes but not the primary evaluation criteria.

The Question That Changed My Calibrations

When we’re evaluating manager promotions now, I ask the committee: “If this person left tomorrow, would their team struggle because they lose technical expertise, or because they lose a leader who developed them?”

If the answer is “technical expertise,” they might be a great Principal Engineer. If the answer is “developed them,” they might be a great Director.

Both are valuable. But they’re different jobs.

Your point about the AI shift is critical. As AI handles more implementation, the value of “I can architect and code the solution” decreases. The value of “I can build a team that navigates ambiguity and delivers business outcomes” increases exponentially.

Are we adjusting our promotion criteria as fast as the market is shifting? Based on my experience: absolutely not.

cto_michelle · April 5, 2026, 8:00am

Luis, your dual-track framework is exactly right. But I want to push this conversation further.

At CTO Level, Technical Depth Becomes Less Valuable

I’m going to say something controversial: If you’re an engineering manager and you’re still the best coder on your team, you’re either hiring wrong or leading wrong.

At my company, I track retention data by manager. The pattern is stark:

Managers with high technical skills but low EQ: 22% annual attrition
Managers with moderate technical skills and high EQ: 9% annual attrition

That’s a 2.4x difference in retention. When you factor in recruiting costs, ramp time, and knowledge loss—high-EQ managers are delivering exponentially more business value, even if they’re not writing the most elegant code.

The AI Shift Isn’t Future Tense—It’s Present Tense

Here’s what changed in the last 12 months at my company:

Our senior engineers now ship features 2-3x faster with AI coding assistants
Our technical architects spend 40% less time on implementation, more on design
Our biggest bottleneck shifted from “can we build this?” to “should we build this? for whom? why?”

The leaders who thrive in this environment aren’t the ones who can still out-code the AI. They’re the ones who can:

Navigate ambiguous business requirements with product and customers
Build teams that collaborate across engineering, product, design, data
Develop engineers who ask strategic questions, not just implement features
Create psychological safety so teams can experiment, fail fast, and learn

None of those capabilities correlate with “stayed technical and contributed code.”

The Question We Should Be Asking

Keisha, you asked what promotion rubrics actually reward. I want to flip that question:

When was the last time you sat in a board meeting or exec team discussion where the CEO asked: “How many lines of code did our VP Engineering write this quarter?”

Never. Because that’s not the job.

But here’s what the CEO does ask me:

“Why is engineering taking 6 months to ship features that our competitor ships in 6 weeks?”
“Why did we lose our three best senior engineers in the same quarter?”
“Can your team scale to support our international expansion?”
“How are we developing the next generation of technical leaders?”

Those questions are answered by leaders who build high-performing, resilient teams. Not by leaders who “stay technical.”

When Do We Stop Rewarding the Wrong Thing?

I’m not anti-technical leaders. I’m anti-measuring the wrong things.

If a VP Engineering candidate tells me “I still write code every week to stay sharp,” I hear: “I’m not spending enough time on the actual job—which is building organizational capability, not individual contributions.”

The market has shifted. AI handles implementation. The value is in:

Strategic thinking: what problems should we solve?
Team building: who do we need, how do we develop them?
Cross-functional alignment: how do we translate business needs into technical roadmaps?
Leadership pipeline: how many people on my team are ready for the next level?

If your promotion criteria don’t measure those things, you’re optimizing for 2020 while competing in 2026.

How many companies are brave enough to actually change their rubrics?

maya_builds · April 5, 2026, 8:01am

Coming at this from a design perspective, and Michelle’s point about cross-functional collaboration is exactly where this gets real.

Empathy Isn’t a Soft Skill—It’s Essential for Multi-Disciplinary Work

I’ve worked with two types of engineering managers:

Type 1: High technical skill, low empathy

Optimized for velocity and story points
Treated design feedback as “scope creep” or “nice to have”
Shipped features fast, but they solved the wrong problems
Design-eng collaboration felt adversarial

Type 2: Moderate technical skill, high empathy

Asked “what user problem are we solving?” before “what’s the implementation?”
Created space for design to collaborate early, not just hand off specs
Shipped slower initially, but built better products that users actually wanted
Design-eng collaboration felt like partnership

The business impact? Type 2 shipped products that had 40% higher user engagement and 30% lower support tickets. Because empathy meant they understood why design decisions mattered, not just that they added implementation complexity.

The Metrics Blindness Problem

Keisha, you nailed it when you said we measure story points and deploy frequency but not team health or cross-functional outcomes.

Here’s what we don’t measure but absolutely should:

How often does product/design/eng align on the problem before jumping to solutions?
How much rework happens because we didn’t collaborate early enough?
How many features ship fast but miss user needs because we optimized for velocity over discovery?
How often do designers feel heard vs steamrolled by “engineering constraints”?

The engineering manager I work with now isn’t the strongest technical contributor on the team. But they create space for designers to bring user research into sprint planning. They ask clarifying questions about user needs. They challenge us when our designs aren’t technically feasible—but with empathy and curiosity, not dismissiveness.

That manager unlocks better products. The previous manager who “stayed technical” and optimized for speed? They unlocked faster deployments of features nobody wanted.

Design-Eng Collaboration Requires Empathy, Not Just Technical Depth

I’ve seen brilliant technical architects who couldn’t collaborate across disciplines because they lacked empathy for non-engineering perspectives. They viewed design as “make it pretty” and product as “tell me what to build.”

Meanwhile, managers with strong EQ but less technical depth understood: design brings user empathy, product brings market strategy, engineering brings feasibility. The job isn’t to be the best coder—it’s to synthesize those perspectives into solutions that work for users and the business.

If your promotion rubric rewards individual technical contributions over cross-functional collaboration, you’re incentivizing exactly the wrong behavior for modern product development.

How many of your best engineers would make terrible managers because they can’t empathize with non-engineering stakeholders? And how many are we promoting anyway because they built impressive tools?