For most of the last decade, the standard advice for new engineering managers was consistent:

Get out of the code.

Your job is people and priorities now, not pull requests.

Every hour spent reviewing a diff is an hour not spent on the work only a manager can do.

I gave that advice myself, more than once, and believed it. Lately, I’m watching it reverse.

More Hours in the Trenches

LeadDev’s Engineering Leadership Report 2026 (May 2026), based on 600 engineering leader responses, found that 37% are doing more hands-on technical work than they were a year ago. One in three managers surveyed are considering leaving management to go back to being an individual contributor. Neither number is describing burnout in the abstract. Engineering leaders are being asked to do more, technically, strategically, and managerially, as organizations flatten and AI reshapes how code gets written, reviewed, and shipped.

Forty-five percent of leaders in the same survey say they’re working more hours than they were a year ago. The survey doesn’t isolate which part of the job is eating those extra hours, but put those three numbers together and my read isn’t “management got harder” in some general sense. The technical half of the job looks like a meaningful part of what’s pulling managers back in, even if how much varies by org and by manager.

Where’d the Skill Go?

Most teams shipping AI-authored code at volume need someone who can look at a pull request and quickly answer whether the decision fits how the system is actually supposed to work, not just whether it compiles and passes tests. That’s not a reviewing-for-typos skill. It’s the kind of judgment that senior engineers and architects have from years of writing and living with a codebase, and organizations spent the last decade deliberately moving their most senior people away from the place where that judgment gets built and exercised.

Augment Code’s 2026 survey (May 2026), a vendor-run poll of 219 engineering leaders, found 55% concerned or very concerned about their teams losing shared understanding of how their own codebase evolves, one of the largest single concerns the survey surfaced. The same report found only 19 of 219 organizations had actually updated role definitions to match a job that’s already changed underneath them. The concern is there, but the org chart (and likely, the comp) hasn’t caught up to it yet.

I’ve felt this pull in my own work. A few months ago, a team I was working with was doing deep-level network driver and packet work. The check isn’t just whether a change compiles but whether it risks the wrong kind of write that could catastrophically break hardware. While my initial goal with the group was to help them right some of their operating practices, I found myself rapidly needing to upskill in the domain. For me, as someone who loves the spot between engineering and product, I didn’t mind, but it was a heavy ask and a lot of research that not all people leaders might want to take on.

The point is that most engineering managers and people leaders are having to stay close enough to the coding layer to have an informed opinion and be able to quickly judge whether a suggestion or architectural decision is sound.

What This Isn’t

This builds on the same pressures behind why teams are struggling to understand their own codebases, why code review turned into a bottleneck, and why metrics and shipping have diverged. Each is a different coupling breaking: code losing its connection to comprehension, a dashboard losing its connection to what actually shipped. Today we’re looking at the next layer: who’s positioned to adjudicate when any of those couplings break. Increasingly that’s whoever, whether manager, tech lead, or staff engineer, hasn’t let their technical judgment atrophy.

It’s also not an argument that every manager should reopen their IDE and start writing production code again. Plenty of the work that pulled managers back in this year looks more like informed review and technical arbitration than authorship, settling a disagreement about approach or catching a design decision that looks fine locally and wrong at the system level. That’s a different skill than shipping features and it decays on its own. It needs enough recent hands-on time to stay sharp, not necessarily a return to full-time coding.

I don’t know how much “technical time” is enough, but it likely varies based on team, technology, and scale. What I’ve settled on is treating it as a floor rather than a schedule. Enough regular contact with real code that a judgment call draws on something current instead of a version of the codebase, or the craft, that stopped updating five years ago. For those of us who like both sides, the people work and the systems work, that’s not a burden. It’s an opening.