Engineering managers are writing more code again. What does that actually mean for the role, and is it something to celebrate or worry about?
Several posts and articles published lately approach the same shift from very different angles.
LeadDev's Engineering Leadership Report 2026 reports that hands-on coding among engineering managers rose from 20% to 35% in a year. Its framing is a comeback for the player-coach model, one that Gergely Orosz anticipated in 2024.
Gregor Ojstersek sees a risk: the instincts that make someone a good manager - delegation, prioritization, and enabling others - can be undermined when they take on too much of the work themselves. James Stanier argues that the question may be shifting altogether: people management is necessary, but technical literacy is increasingly part of the job.
Jellyfish's 2026 State of Engineering Management report focuses on another part of the same change. As organizations adopt AI, the challenge is no longer simply encouraging usage; it is demonstrating that the investment delivers value. Measuring the ROI on AI investment is one of the top discussions I see over and over in engineering managers groups.
These perspectives do not necessarily contradict one another. They highlight different questions: What does hands-on work enable? What does it displace? And what technical understanding does a manager need, whether or not they write code?
The real question isn't "should?" - it's "what works?"
Coding can help a manager stay close to the system, explore an unfamiliar area, test an idea, or have a more grounded technical conversation. AI tools can make these activities easier to fit into a busy week.
But the same activity can also become a way to avoid the less immediate work of management: coaching, delegating, aligning priorities, and creating the conditions for a team to succeed. A manager's commits may be visible; the opportunities lost when they take on the work themselves are harder to see.
That is the tension behind the player-coach model. Hands-on contribution can be valuable when it strengthens the team's work. It becomes a problem when the manager turns into a dependency - or when individual output quietly replaces the work only the manager can do.
The answer will vary by person and context. Some managers think more clearly when they can inspect and experiment with the code. Others create more value by focusing on people, strategy, and the roadmap. Many move between those modes depending on the team's needs.
The important question is not whether coding is inherently good or bad for managers. It is whether the time spent in the codebase improves the team's outcomes enough to justify what it takes away from the rest of the role. This tension exists even before AI but it is surfaced and amplified now since AI tooling reduced barriers even to technical managers who used to be ICs.
Coding and technical judgment aren't the same
There is a distinction worth making: writing code and being able to evaluate solutions and code are different capabilities.
A manager may not need to implement features personally. But they still need enough technical understanding to discuss architecture and trade-offs, recognize meaningful risks, and know when to bring in deeper expertise.
This is where Stanier's argument about the changing expectations of engineering management becomes relevant. His point is not simply that managers should spend more hours coding; it is that technical engagement may be becoming a baseline expectation as organizations flatten and AI changes how software is produced.
Itamar Gilad's essay on Artificial Competence adds a related caution. AI can help people produce work in domains they cannot adequately judge. In software, that means a plausible-looking implementation is not necessarily a sound one. Delegation remains essential, but it does not remove the need to ensure that competent technical judgment is present.
That judgment does not have to live entirely in the manager. It can be distributed across a team and supported by review, testing, and clear ownership. The manager's responsibility is to make sure the right expertise is involved and that important risks are not mistaken for details someone else will catch.
The accountability question
The discussion about managers returning to the codebase is happening alongside a broader shift in how organizations think about AI.
Jellyfish's report emphasizes the growing pressure to demonstrate that AI adoption is improving engineering outcomes. That raises a useful question for managers: are we measuring activity because it is easy to count, or are we measuring whether the work makes the team more effective?
Coding hours and commit counts can tell us that activity happened. They cannot, on their own, tell us whether the manager made the right trade-off. Nor can a broad productivity metric explain whether a manager's technical contribution helped the team learn, reduced risk, or created a new bottleneck. The challenge, as it was in the past, is to connect individual activity to outcomes.
Finding our own balance
Rather than adopting a universal rule, it may be more useful to ask yourself three questions:
- Does coding make you better at the rest of your job - or substitute for it? Look at a typical week. Does time in the codebase lead to sharper technical conversations, better decisions, or a clearer understanding of the system? Or does it mean that coaching, delegation, and planning keep slipping?
- What does your organization actually reward? Are you evaluated on personal technical contributions, team outcomes, or some combination? If visible coding is treated as proof of credibility, is that expectation aligned with what the team needs from you?
- Can you evaluate the work you are accountable for? Could you discuss your system's architecture and trade-offs, recognize when a proposal needs deeper review, and question output that looks polished but may be wrong? If not, what expertise or review practices would close that gap?
These questions point to different decisions. One manager may benefit from regular hands-on exploration; another may need to protect more time for the team. Both may need to strengthen their technical judgment, even if they do so in different ways.
Coding may be optional. Technical judgment may not be.
The question isn't simply whether engineering managers should code more.
It's whether coding helps them lead more effectively, whether their organization rewards the right outcomes, and whether they can ensure that the technical work they are accountable for is sound.
Writing code may be a choice. Understanding the system, recognizing risks, and knowing when to trust or challenge AI-generated work may be becoming part of the job regardless.
The challenge for engineering managers is to find the right balance between hands-on contribution and enabling their teams to do their best work.