Why Senior Engineers Make Terrible Managers

The best debugger I'd ever worked with sat across from me, visibly deflated. Six months earlier, they'd been promoted to engineering manager after years of stellar technical performance. They could trace through the most complex codebases like reading a novel, solved production issues that left others stumped, and mentored junior developers with patience and clarity.

Now they were asking to step back to an individual contributor role.

"I'm good at fixing code," they said. "I'm terrible at fixing people."

This wasn't an isolated incident—it's become an industry epidemic. We promote our best engineers into management roles and wonder why teams implode, productivity plummets, and talented people leave. The problem isn't with the people we're promoting; it's with our fundamental assumption that technical excellence naturally leads to management capability.

The Linear Promotion Myth

The Traditional Career Ladder

Most tech companies operate on a simple principle: good engineers become senior engineers, senior engineers become tech leads, tech leads become engineering managers. It's tidy, logical, and completely wrong.

This linear thinking reflects what Laurence Peter identified in "The Peter Principle"—people rise to their level of incompetence. In engineering, we've created a system where the only path to career advancement and higher compensation is through people management, regardless of aptitude or interest.

The result? We lose excellent engineers and gain mediocre managers.

The Skills Mismatch

I've watched brilliant technical minds struggle with basic management tasks: giving difficult feedback, navigating office politics, translating business requirements into technical strategy. These aren't skills you pick up from years of writing elegant code or architecting scalable systems. They're entirely different competencies that require different thinking patterns, emotional intelligence, and interpersonal skills.

Consider the typical senior engineer's daily reality: they solve logical problems with definitive solutions, work independently or in small technical teams, and receive clear feedback through code reviews and system performance. Management, by contrast, involves navigating ambiguous people problems, facilitating cross-functional collaboration, and measuring success through team productivity and individual growth—metrics that are far less concrete than whether the build passes.

Why Technical Skills Don't Transfer

Different Problem-Solving Worlds

Marshall Goldsmith's "What Got You Here Won't Get You There" explains how the behaviours that create success at one level can sabotage performance at the next. This principle is particularly pronounced in the engineering-to-management transition.

Problem-solving approaches differ fundamentally. Engineers debug systematically: isolate the issue, identify root cause, implement fix, verify solution. People problems don't work this way. When a team member is underperforming, there's rarely a single root cause or clear fix. It might be personal issues, unclear expectations, team dynamics, or a dozen other factors. The systematic debugging approach often makes things worse.

Communication and Measurement Challenges

Communication patterns clash. Engineers communicate with precision and technical accuracy. Management requires emotional intelligence and the ability to navigate difficult conversations with empathy. Kim Scott's "Radical Candor" framework—caring personally while challenging directly—feels foreign to many engineers who've built careers on being right rather than being supportive.

Success metrics become abstract. Code either works or it doesn't. Systems either scale or they don't. But how do you measure whether someone's growing professionally? Whether team morale is improving? Whether your technical strategy aligns with business goals? These fuzzy metrics frustrate engineers accustomed to clear binary outcomes.

Common Failure Patterns

I've seen these patterns play out repeatedly. The micromanaging ex-engineer who can't resist diving into every technical detail. The conflict-avoidant technical leader who lets team dysfunction fester rather than address interpersonal issues. The "just figure it out" manager who expects their team to solve people problems with the same systematic approach they'd use for technical challenges.

The Better Alternative: Technical Leadership Tracks

Rethinking Career Advancement

Here's what the industry gets wrong: we assume that career advancement requires people management. Will Larson's "Staff Engineer" brilliantly articulates an alternative path—technical leadership without people management responsibilities.

Staff engineers, principal engineers, and distinguished engineers wield enormous influence through their technical expertise, architectural decisions, and cross-team collaboration. They solve complex technical problems, mentor other engineers, and shape technical strategy. Their impact often exceeds that of many engineering managers, yet they don't need to conduct performance reviews or navigate budget discussions.

Creating Genuine Dual Tracks

Creating genuine dual-track advancement means more than just fancy titles. It requires compensation parity, clear progression criteria, and organisational recognition that technical leadership is leadership. Some companies have cracked this code: Amazon's principal engineer track, Google's staff engineer progression, and various startups that explicitly separate technical leadership from people management.

When Management Transitions Actually Work

When management transitions do work, it's usually because the engineer has demonstrated genuine interest in people development, shown strong communication skills in technical contexts, and actively sought out opportunities to mentor and guide others. They've recognised that management isn't a promotion—it's a career change requiring completely different skills.

The Hidden Costs of Getting It Wrong

Team and Individual Impact

The failure to distinguish between technical excellence and management capability creates cascading problems throughout organisations.

Teams suffer when technically-minded managers struggle with people development, conflict resolution, and strategic thinking. I've seen entire engineering teams lose momentum because their manager couldn't navigate organisational politics or translate business requirements into actionable technical work.

The promoted engineer often experiences personal misery. They lose the joy of hands-on technical work, struggle with unfamiliar responsibilities, and face imposter syndrome in areas where their technical expertise provides no advantage. Many eventually leave their companies rather than admit the transition isn't working.

Organisational and Cultural Consequences

Organisations lose twice: they gain an ineffective manager and lose an excellent individual contributor. The ripple effects include decreased team productivity, increased turnover, and cultural erosion as other engineers watch talented peers struggle in management roles.

From a diversity and inclusion perspective, the linear promotion path often perpetuates homogeneous leadership. If the path to advancement requires management skills that weren't emphasized during someone's technical development, we inadvertently filter out people who might excel at technical leadership but haven't had equal access to management skill development.

Making Better Decisions

Assessing Interest and Aptitude

Smart promotion decisions start with honest assessment of both interest and aptitude. Does the candidate actively seek out mentoring opportunities? Do they facilitate technical discussions effectively? Have they shown curiosity about business strategy and team dynamics?

Michael Watkins' "The First 90 Days" provides excellent frameworks for leadership transitions, but most organisations skip the foundational question: should this transition happen at all?

Gradual Transitions and Support Systems

Trial periods and gradual transitions work better than sudden role changes. Technical lead positions, project management responsibilities, and cross-team collaboration opportunities let potential managers test their interest and aptitude before committing fully.

For those who do transition successfully, comprehensive support systems are essential. Management training, mentorship from experienced engineering leaders, and clear expectations help bridge the skills gap. Will Larson's "An Elegant Puzzle" offers systems thinking approaches that help technically-minded people understand organisational dynamics.

Progress, Not Promotion

Career advancement doesn't require abandoning what you're good at for something you might hate. Technical expertise is valuable throughout your career, and technical leadership represents a legitimate alternative to people management.

If you're a senior engineer considering management, ask yourself honestly: are you excited about developing people, or do you just want career progression? Do you enjoy facilitating collaboration and resolving conflicts, or would you rather solve complex technical problems?

If you're making promotion decisions, consider whether your best engineers would serve the organisation better by remaining in technical roles with appropriate recognition and compensation. Create advancement paths that don't force people to choose between career growth and professional satisfaction.

The debugger from my opening story eventually became a staff engineer. They now influence technical architecture across multiple teams, mentor other engineers, and shape the company's technical strategy. They never need to conduct another performance review, and they've never been happier or more effective.

Sometimes the best career move is staying exactly where you belong.