The Engineering Manager’s Dilemma: Career Path, Compensation, and Why the Best Engineers Don’t Always Make the Best Managers

The Fork in the Road That Defines Tech Careers

At some point between the third and seventh year of a software engineering career, a question arrives that shapes everything that follows: should I move into management? It appears innocent — a promotion, a new challenge, a recognition of leadership potential. In practice, it is the most consequential career decision in the technology industry, and it is one that the majority of engineers navigate with inadequate information.

The numbers reveal the stakes. According to Levels.fyi compensation data, a Staff Engineer (L6) at Google earns a median total compensation of approximately $568,000, while an Engineering Manager at the equivalent level earns approximately $591,000. At that level, the two tracks are roughly comparable. But the pattern shifts at senior levels and varies by company. At Amazon, a Principal SDE can earn a median of $568,000, while a Senior Software Development Manager averages $625,000 — but industry-wide analysis shows that Staff+ individual contributors often command a 15-25% premium over management-track peers at equivalent seniority. At Meta, an E6-level engineer earns a median of approximately $754,000 in total compensation. The takeaway: at the highest technical levels, the IC track frequently matches or exceeds management compensation, overturning the traditional assumption that management is the path to higher pay.

This compensation reality upends the traditional corporate assumption that management is a “promotion” from engineering. In most technology companies today, management is a lateral move to a different discipline, not a step up in a hierarchy. Understanding this distinction — and its implications for daily work, career trajectory, skill development, and personal fulfillment — is essential for making an informed choice.

---

The Dual-Track Ladder: How Modern Tech Companies Structure Careers

The dual-track career ladder has become standard at virtually every major technology company, though the specifics vary. The IC track typically progresses through Senior Engineer, Staff Engineer, Senior Staff Engineer, and Principal Engineer (or Distinguished Engineer at the top). The management track runs from Engineering Manager to Senior Engineering Manager, Director of Engineering, Vice President of Engineering, and CTO. Both tracks, in theory, offer equivalent compensation, scope, and organizational influence at corresponding levels.

At Google, the tracks diverge at L5 (Senior Software Engineer). An L5 can become an L6 Staff Engineer or an L6 Engineering Manager. Both carry similar compensation bands, but the day-to-day reality diverges dramatically. The Staff Engineer spends 70-80% of their time on technical work — architecture, code review, technical strategy, and cross-team technical leadership. The Engineering Manager spends 70-80% of their time on people work — one-on-ones, hiring, performance management, team dynamics, and project coordination.

Spotify’s approach became famously influential across the industry. The company’s “Squad” model, introduced around 2012, emphasized that Engineering Managers (through “Chapter Leads”) focused on people and career development while “Tech Leads” handled technical direction — explicitly separate responsibilities. However, Spotify’s own engineering leaders later acknowledged that the model was aspirational rather than fully implemented, and the company has since evolved toward more traditional management structures. The model’s influence persists across the industry even as Spotify itself moved on. Stripe takes a different approach, with a “Player-Coach” model where Engineering Managers are expected to remain technically hands-on, reviewing pull requests, writing and reviewing design documents, and investigating incidents alongside their teams. This hybrid approach has gained popularity but carries its own risks: the demands of both roles can lead to doing neither well. The model works best in small teams (4-6 engineers) and becomes increasingly unsustainable as team size grows beyond 8.

---

The Skills That Transfer and Those That Don’t

The belief that great engineers naturally become great managers is one of the most persistent and damaging myths in the technology industry. The skills that make someone an outstanding individual contributor — deep technical expertise, the ability to focus for extended periods, comfort with ambiguity in code, and a drive for personal mastery — have limited overlap with the skills required for effective management.

Engineering management demands proficiency in an entirely different domain: active listening, conflict resolution, giving and receiving feedback, hiring and interviewing, performance evaluation, organizational politics, cross-functional communication, and the ability to derive satisfaction from others’ accomplishments rather than one’s own. Google’s Project Oxygen research, which analyzed over 10,000 data points about managers from performance reviews and feedback surveys, found that the top predictors of management effectiveness were coaching ability, empowerment of team members, and communication. Technical expertise ranked last among the original eight key management behaviors identified. Google later expanded the framework to ten behaviors in 2018, adding collaboration and decision-making, but the core finding held: soft skills matter far more than technical depth for management effectiveness.

The transition shock is real and well-documented. The Jellyfish 2024 State of Engineering Management Report, which surveyed over 600 engineering professionals, found that only 37% of engineering managers reported finding their work rewarding — compared to 75% of individual contributor engineers. The same study found that 65% of all respondents had experienced burnout in the past year, with the figure rising to 85% among managers at large organizations. The concept of “the maker’s schedule vs. the manager’s schedule,” articulated by Paul Graham in his influential 2009 essay, captures the core tension: engineers thrive on long, uninterrupted blocks of focused work, while managers operate in a world of fragmented 30-minute increments. For many new managers, this shift from maker to manager feels like a loss rather than a gain.

---

The Regret Factor and the Path Back

Dissatisfaction among engineers who transition to management is widespread. Community discussions on Blind, the anonymous professional network popular in tech, consistently surface regret from engineering managers who miss the IC track. The reasons cluster into familiar categories: loss of technical skills, lower compensation compared to senior IC peers at some companies, burnout from people management demands, and the feeling of being “stuck” — too far from code to return to IC easily, but not senior enough in management to have real organizational influence. The Jellyfish data reinforces this: the gap between IC satisfaction (75% finding work rewarding) and manager satisfaction (37%) is one of the starkest findings in recent engineering workforce research.

Returning to the IC track is possible but comes with costs. Technical skills atrophy quickly — two years away from hands-on coding can create a significant gap, especially in fast-moving areas like AI/ML, cloud infrastructure, or frontend frameworks. Companies like Google and Meta have formal “manager-to-IC” conversion processes, but they typically require demonstrating current technical capability, which means a period of ramp-up. Some companies have experimented with rotation frameworks where engineers can try management for a defined period with a clearer path back to IC if it is not the right fit — though these remain informal at most organizations rather than guaranteed programs.

The emerging “player-coach” or “tech lead manager” hybrid role attempts to address the regret problem by allowing managers to maintain technical engagement. Companies like Stripe and Vercel have built their engineering organizations around this model, arguing that managers who write code make better technical decisions and retain more credibility with their teams. Charity Majors, CTO of Honeycomb, has championed a related concept — the “engineer/manager pendulum” — arguing that the best engineering leaders oscillate between IC and management roles throughout their careers rather than committing permanently to one track. The evidence on the player-coach model is mixed: while it can work brilliantly in small organizations, it scales poorly. A manager of 10 engineers who also writes code is, in practice, a manager who writes very little code and an engineer who manages poorly. The math of time simply does not work beyond a certain team size.

---

---

Sources & Further Reading

• Levels.fyi – Tech Compensation Data
• Jellyfish 2024 State of Engineering Management Report
• Google re:Work – Project Oxygen: What Makes a Great Manager
• Paul Graham – Maker’s Schedule, Manager’s Schedule (2009)
• Charity Majors – The Engineer/Manager Pendulum
• The New Stack – Engineering Managers in 2024: Burnout and More Duties
• Will Larson – Staff Engineer: Leadership Beyond the Management Track
• Gergely Orosz – The Pragmatic Engineer