The Myth of the Coding Manager

“The bottleneck is always at the top of the bottle.” —Andy Grove

A while back, I saw a senior engineering manager posting from a top tech company. The first requirement? “Must pass our senior engineer technical assessment.” Leadership and team development ranked last, after code.

This isn’t just one company’s issue; it’s an industry trend that conflates technical and management skills, forcing managers to split focus between leading teams and writing code. This often leads to lower satisfaction, higher turnover, and a management discipline that’s quietly hollowing out.

Jellyfish’s 2025 State of Engineering Management reports that 65% of engineering managers experience burnout, rising to 85% in large organizations. These are self-reported figures with the limitations inherent in this type of data, but the directional signal is consistent across independent sources.

How Management Became a Side Job

Today’s hybrid expectations are eroding a discipline that took decades to develop. Historically, managers moved from senior technical roles into people-leadership positions. Their technical expertise provided context, but their primary impact came from fostering collaboration, driving execution, and enabling teams to scale. Management, like coding, is a skill that must be developed intentionally.

The Cost of Splitting Focus

The pattern shows up the same way in practice. A senior engineer gets promoted, inherits a team of eight, and spends the next six months trying to stay hands-on while one-on-ones slip, hiring drags, and two strong engineers quietly start looking elsewhere. The code gets reviewed. The team doesn’t.

Stack Overflow’s 2025 Developer Survey found that teams whose managers code more than 30% of the time see 25% lower satisfaction and 20% higher turnover. Correlation isn’t causation, and self-reported surveys have limits. But the pattern holds across multiple independent data sources: beyond a modest threshold, IC work crowds out the leadership activities that drive team outcomes.

Why It Breaks Down

• Career Growth Stalls: When managers are buried in code reviews and sprint tasks, one-on-ones and mentorship are neglected.
• Technical Decisions Get Rushed: Coding while leading leaves little room for deep architectural thinking, and frequent context switching compounds the damage.
• Culture Deteriorates: When managers aren’t present enough to model norms, resolve friction, or recognize good work, trust erodes quietly—long before it shows up in attrition data.
• Leadership Becomes Unsustainable: As teams grow, the balancing act breaks down. A manager of five might still code. At ten or more, a coding manager is just an overworked IC with extra meetings.

When Management Is Treated as Overhead

If the downsides are clear, why does this hybrid model persist? Hiring freezes and budget pressure drive role consolidation. The push for faster delivery perpetuates the myth that coding managers are more efficient. Sometimes hybrid roles are necessary—in the earliest stages, with five engineers and everyone shipping, it’s survival, not compromise. Once management becomes a full-time job rather than an outgrowth of seniority, the broader argument applies.

Leading Beyond the Code

Great engineering managers don’t need to write the most code. Their primary impact comes from fostering alignment, enabling effective execution, and creating conditions for their teams to thrive.

• Strategic Communication: Translating technical complexity into business impact. Keeping leadership aligned before misalignment becomes a project risk.
• Organizational Effectiveness: Mapping cross-functional dependencies before they become blockers. Making decisions that hold up past the next sprint.
• Team Development: Hiring well, mentoring deliberately, and building the next layer of technical leadership before you need it.

The relevant metrics aren’t pull requests—they’re cycle time, deployment frequency, change failure rate, and team health indicators like eNPS and voluntary attrition. These reveal whether a manager builds capacity or just stays busy.

Two Tracks, Defined

Organizations that retain technical talent build two distinct paths:

• Individual Contributor Track: For technical experts specializing in coding, system design, or deep domain leadership. No people management.
• Engineering Management Track: For those focused on team development and organizational effectiveness.

The Long Game

There’s an honest emotional dimension to this transition that doesn’t get enough attention. Coding delivers immediate feedback: the build passes, the test goes green, the feature ships. Management is about delayed gratification. Your best work may not be visible for quarters—sometimes longer. Acknowledging this makes the transition sustainable.

A related fear is technical atrophy: stepping away from feature work puts an expiration date on your judgment. The strongest version of this concern isn’t about managers writing features with their team. It’s about credibility. Can you recognize a bad architectural trade-off before it ships, or earn the trust of engineers skeptical of decisions made from a distance?

That concern isn’t unfounded. But the answer isn’t staying on the critical path. It’s staying close to systems: incident reviews, architecture discussions, and proof-of-concept spikes before your team invests a sprint. The goal isn’t to remain a senior engineer, but to stay sharp enough that your senior engineers can’t hand-wave past you.

The Shift Worth Making

That job posting—senior engineer assessment first, leadership last—tells you exactly what the organization values. The teams that outlast the market corrections are built by managers who inverted that priority list.

The question isn’t whether your managers can pass a senior engineer assessment. It’s whether they’re building teams that don’t need them to.

[Published on 2/1/2025 at https://adams.io/blog/the-myth-of-the-coding-manager]