You have 1 article left to read this month before you need to register a free LeadDev.com account.

Estimated reading time: 5 minutes

Key takeaways:

  • Engineering manager roles have shifted from pure coordination to “player-coach,” with 37% of leaders now deeply hands-on.
  • AI tools make it feasible to get back up to technical speed fast.
  • The rule: pick up small unplanned work yourself, investigate complex work, and leave planned work to the team.

The engineering manager role is changing fast. In 2022, my role at an online pharmacy was defined by a predictable cycle: play ‘dependency Tetris’ at the start of the quarter, make sure the team stays unblocked and regularly escalate, and evaluate the leftovers when the next planning cycle begins.

Coding or architecture? Delegate those. That was someone else’s job. Three years later, I joined a new company with the same title but fundamentally different expectations. 

Your inbox, upgraded.

Receive weekly engineering insights to level up your leadership approach.

The engineering manager role many of us started in

The 2022 version of the engineering manager role made sense for its time. Gergely Orosz captured it well in his widely referenced 2021 Pragmatic Engineer diagram.

The engineering manager sat at the intersection of people management and stakeholder management, clearly outside the code circle. It reflected the needs of that period.

During the zero-interest-rate period (ZIRP), companies were scaling fast and teams were growing. In that environment, the coordination layer had genuine value, because someone needed to manage the interfaces between product, engineering, and business. The engineering manager role served that function well.

My first role reflected this model precisely. Roadmap, planning, strategy. The idea of jumping into a codebase was not just unusual. It was actively discouraged.

How the role changed, and why

Moving forward into 2026, there is industry consensus that a deeper change is taking place. LeadDev’s 2026 Engineering Leadership Report shows 37% of leaders are already deeply hands-on. This mirrors the ‘player-coach’ model Gergely Orosz predicted in 2024 and aligns with James Stanier’s recent argument that the non-technical engineering manager is becoming obsolete.

The gravity of the role is shifting. Where the engineering manager once concentrated on people and strategy, the technical dimension is now pulling with equal force.

Source: Ferit Topcu

What is emerging is not the engineering manager role absorbing the tech lead role. It is something closer to a merger. The technical engineering manager is someone who still owns the people and team dimension, but is now expected to operate with the domain depth and architectural literacy that was once the territory of a staff engineer or tech lead only.

How I experienced this shift when joining a new company

When I joined Zenjob in 2025, the expectation was clear from day one to start contributing code, not just managing. My head of engineering made it explicit during my probation check-in. Being hands-on in the codebase was not optional, it was part of the role. A staff engineer on the team said the same thing.

As that year progressed, an internal transition shifted my focus toward an entirely unfamiliar landscape, involving invoicing architectures, B2B technical integrations, and various partner-facing systems. These were domains where I lacked prior experience, requiring a fresh start from the ground up.

So I approached it the way I would expect an engineer to. Instead of keeping distance from technical topics and going straight into roadmap and stakeholder alignments, I started by reading code, tracing bugs, and pairing as often as possible with senior engineers. While doing this, I avoided owning critical features from our roadmap and focused on the unglamorous, unplanned work that showed me what pain points different systems have and how engineers are fixing them.

This is where AI tools helped close the gap. Using Claude Code in plan mode and various MCP servers, I could investigate complex codebases and surface the underlying issues faster than I expected. Over time, I moved toward more autonomous interaction modes.

As an experienced engineer turned manager, the technical muscle does not disappear but it can get rusty. Using various AI tools with genuine curiosity about how engineers approach problems meant I could get back up to speed faster than I expected. In some ways, it meant starting over as a junior.

The critical distinction for me is using AI to genuinely understand a domain, not to generate code I cannot explain.

More like this

When to build, when to step back

The biggest risk in this way of working is obvious. When the engineering manager picks up too much work, engineers lose growth opportunities, and the team risks “ivory tower” behavior or creating “bus factor one” dependencies. The new paradigm of the player-coach role only works if the balance is intentional.

My current decision framework regarding when to code and be hands-on focuses on two dimensions: complexity and planned/unplanned work.

For clear, small unplanned work, like bug fixes or support tickets, I contribute directly, leveraging AI-coding tools for speed. For complex, unclear unplanned work, I resist the urge to “fix” immediately. Instead, I prioritize investigation. I take the time to understand the problem and system, which helps me decide whether to patch the issue, build a formal plan for the team, or park the task entirely.

Source: Ferit Topcu

Planned work belongs to the team. My job there is to protect their capacity, make sure we are progressing towards delivery, and keep our stakeholders constantly in the loop.

This framework is still evolving. New paradigms like Loop Engineering are already shifting things. Clear, small unplanned work that I would have picked up myself can now go straight to an AI agent, no human needed. What counts as “EM takes it” keeps shrinking as the tools get better. For now, the player part of the player-coach role is in using AI and my own judgment to stay useful in the code by tackling the work that falls through the cracks.

The early signal that it was working

A few months into my new domain, I’m still staying curious, handling unplanned work, writing long-term vision documents to improve parts of our system, or proposing features based on the pain points I observed. This approach resulted in two senior individual contributors (ICs) sharing the following feedback, unprompted: “it feels great to have a manager who’s coding and understanding things in detail.”

That comment made me realize something crucial: trust built through proximity to the work is different from trust built through process and communication alone. When an engineering manager understands a system at a meaningful level, trust builds up faster and conversations change. Estimations become more honest. Problems surface earlier.

LeadDev Berlin promo

Berlin • November 9 & 10, 2026

Engineering leadership has never moved this fast.
See how other leaders are keeping pace at LeadDev Berlin.

A different role, and a better one

The engineering manager role demands more, the technical bar is higher, and expectations have expanded without the calendar shrinking. Yet, it is more compelling.

The previous version of the role meant managing the distance between yourself and the work you originally cared about. The new version invites you back into that work – not as an IC, but as a leader operating on both levels.

For engineering managers who became managers because they cared about building good software, that is likely not a burden. It can be the version of the role worth staying for, at least while the industry finds its footing.

The job description has evolved. Now, it’s your turn to do the same.