I keep seeing the same requirement in Engineering Manager job postings: comfortable contributing code regularly or writes and reviews code alongside management responsibilities.
Every time I see it, I wonder whether the company posting the role understands what they’re actually asking for — and what they’re giving up.
Before becoming a consultant, I managed engineering teams for many years at B2B and B2C SaaS companies. During that time I helped teams increase deployment frequency, built stronger engineering cultures, and guided organizations through major technical and organizational change.
I haven’t written production code in years. That isn’t a gap in my skills. It’s a deliberate decision about where I create the most value.
The player/coach model — where an Engineering Manager both manages people and ships code — sounds appealing. In practice, it often creates a trap where neither the management work nor the engineering work receives the attention it deserves, and the team pays the price.
Why the model is appealing
The appeal of coding Engineering Managers is obvious. The logic feels airtight: you get leadership capacity and engineering capacity from a single hire.
In very small organizations this is often a necessary practical compromise. If a startup only has a handful of engineers, dedicating one of them entirely to management may feel impossible, and a player/coach can help the team keep moving.
Yet many organizations continue using this model long after the conditions that justified it have passed. Teams grow from four engineers to eight, then a dozen, then larger still. The responsibilities of management grow with them, but the expectation that the manager will also ship code often remains.
This is where the model breaks down.
Management work expands faster than people expect
Good engineering management requires sustained attention. There are regular one-on-one conversations with engineers, plus coaching and performance feedback. Hiring takes concentrated time. You build and manage cross-functional relationships with Product, Design, and stakeholders. There are production incidents, organizational friction, and the constant work of clearing obstacles for the team.
Much of this work is invisible when it’s done well, but it takes real time and real focus. Software development requires time and focus too, as well as deep, uninterrupted concentration.
Writing and reasoning about code rarely happens well in ten-minute gaps between meetings.
Trying to do both jobs at the same time forces a daily tradeoff. A manager ends up deciding — consciously or not — whether to prioritize the leadership work or the implementation work. When that happens consistently, one of the roles inevitably receives less attention than it should.
In my experience, it’s usually the management work that slips.
A subtle cultural side effect: ownership shifts
There’s another effect that shows up over time when Engineering Managers stay heavily involved in implementation.
A coding manager naturally becomes a technical authority in the team’s day-to-day work. They’re in the code, they have context, and their technical opinions carry additional weight because of a power imbalance: they’re also the manager. Even if that authority is used carefully, it can change team dynamics.
Engineers may defer to the manager’s technical judgment more quickly, and decisions may drift toward the manager by default. Over time, the team can become less comfortable owning difficult technical decisions independently.
This isn’t inevitable, but it’s a pattern I’ve seen often enough to pay attention to.
One of the most powerful things an Engineering Manager can do is help engineers grow into technical ownership — making architectural decisions, defending tradeoffs, and learning from outcomes. That growth is harder when the manager remains deeply embedded in implementation work.
Technical leadership doesn’t require writing production code
Engineering Managers should stay technical. Technical credibility matters, and managers need to understand the systems their teams build, participate meaningfully in technical discussions, and evaluate architectural decisions.
But that doesn’t require being responsible for production code.
Recently I needed to understand how several services in a client’s system mapped APIs to underlying data. I pulled down the repositories, explored the codebase, and used modern tools to trace how the pieces connected.
That kind of engagement — understanding systems, exploring code, evaluating tradeoffs — is exactly the level of technical involvement I believe good Engineering Managers need. What I deliberately avoid is taking ownership of implementation work that the team itself should own.
Technical literacy is essential. Implementation responsibility is optional — and often counterproductive.
Faster development increases leadership demand
Modern development tools are making engineers more productive. Better IDEs, automation, and AI-assisted coding are accelerating how quickly teams can build and ship software.
Some people see this and conclude that Engineering Managers can now return to coding. If AI tools make implementation faster, the thinking goes, a manager should have time to contribute again.
In practice, the opposite tends to happen.
As teams move faster, the organizational challenges tend to grow as well. Systems integrate more quickly, decisions pile up faster, and teams depend on each other more than they used to.
In those environments, leadership attention becomes more valuable, not less. Someone needs to ensure that teams stay aligned, architectural boundaries remain clear, and engineers have the support they need to move quickly without creating long-term instability.
Those are leadership problems, not coding problems.
Why many organizations keep the model anyway
There’s another dynamic that often keeps the player/coach expectation alive.
Many Directors and VPs built their careers as strong engineers who later became managers. During that transition they continued coding for a while — sometimes because they enjoyed it, sometimes because the organization needed it. Over time, that experience becomes part of their mental model of what a “technical manager” looks like.
But it’s worth asking a reflective question: how much management work was postponed or compressed during those years because the manager was still writing code?
Most leaders eventually find that as their responsibilities grow, their time shifts toward leadership work almost by necessity. The transition happens gradually, even if job descriptions and hiring expectations lag behind reality.
When the model can work
The player/coach model can make sense in certain situations: very small teams, early-stage startups, or temporary phases of rapid growth. You just have to understand the tradeoffs.
But it works best as a temporary structure, not a permanent one.
As teams grow, the responsibilities of leadership expand faster than most organizations anticipate. What began as a practical compromise can quietly turn into a constraint.
The challenge for many companies isn’t deciding whether the player/coach model can work. It’s recognizing when the team has outgrown it.
And for an engineering leader who still enjoys coding, fixing the occasional bug or picking up a small task can satisfy that urge — as long as the work stays off the team’s critical path.
The leverage of focused engineering leadership
A strong Engineering Manager doesn’t just add their own technical output to the team. They help the entire team operate more effectively.
They remove organizational friction the engineers can’t address themselves. They build productive relationships across Product and Design. They establish practices that help the team ship software safely and reliably. They coach engineers through technical challenges without taking ownership of the work away from them.
When leadership is done well, the effect is multiplicative rather than additive. The value comes from improving how the whole team operates, not from contributing one more individual stream of code.
Choosing the right model
Organizations designing Engineering Manager roles face a practical choice. They can optimize for short-term implementation capacity by expecting managers to code alongside their teams, or they can invest in leadership capacity that helps the entire team perform better.
Both approaches have their place at different stages of a company’s growth. But as teams scale, leadership becomes the constraint far more often than coding capacity.
The player/coach model can work for a while.
What many organizations discover is that it stops scaling sooner than they expected — often right when the team most needs focused leadership.