Manager.dev

Engineering managers historically drift from hands-on coding toward full-time coordination, losing touch with the actual work. With AI coding agents transforming software development, this drift is now a critical liability. Managers who don't personally experience coding with LLMs can't make informed decisions about team processes, tooling, or realistic productivity expectations. The author argues there's no longer room for 100% non-coding engineering managers — not due to executive pressure, but because firsthand experience is essential to avoid AI hype-driven mistakes. The recommended approach: start with small bug fixes, then take on a real production feature end-to-end for a couple of weeks, even at the cost of reducing 1:1 cadence temporarily.

The death and revival of the hands-on Engineering Manager

You made an intresting point. Thank you for sharing your experience.

I like the way you laid out your thoughts and I completely agree with it. I feel like these days people are just “talking” and not “doing” enough to back up their claims. Simply experiencing the workflow is more than enough to give them the reality check. Not just from reports but from the actual codebase. Time to get their hands dirty again!

Cutting one-on-ones to make room for coding seems like the quickest way to create a second problem, so the hands-on time needs its own protected slot.

Not unrelated: there’s currently an epidemic of engineering managers who
<ul>
<li>were elevated from code dev to management just due to seniority</li>
<li>completely lack a managerial skill set, and</li>
<li>have now been de-skilled because they haven’t coded anything in years</li>
</ul>
… all resulting in consistently and objectively bad decisions made.

Firsthand use matters because AI changes the review workload as much as the coding workload. A manager who ships one bounded production change can observe prompt iteration, verification time, tool failures, and the gap between generated and accepted code instead of relying on vendor demos. I would avoid measuring success by the amount the manager commits; the useful output is a better team policy for tests, permissions, review, and escalation. The experiment should create organizational learning, not a new shadow contributor.