Staying technical, deliberately

Engineering management pulls you away from the engineering work it is supposed to judge. The promotion adds people to manage and takes away hours at the keyboard, the calendar fills with one-on-ones, planning, hiring loops, and escalations, and meanwhile the field keeps moving: new frameworks, new deploy patterns, new ways of working with AI agents, whole categories of tool that did not exist last quarter. Some people will tell you the answer is a balance between coding and managing, and others will tell you to stop coding altogether. I do not think either camp is right.

Going hands off does not free you from the technical part of the job, because the decisions that need a technical eye keep arriving whether or not you can still make them. It just quietly removes the hands-on practice that built the eye in the first place.

Don't fold to the stop-coding camp

The case against managers coding sounds reasonable, and some of it is true around the edges: switching between code and meetings is expensive, and nobody is paying you to ship features anymore.

I reject it anyway, because the engineering work itself is changing too fast. What an engineer does week to week is moving, and so is how code gets from an idea to production. A manager who has not touched the work cannot make calls about those changes, and is left reacting after the team has already picked a direction, by which point the choice is locked in.

AI is one of these shifts, and there will be others. The argument applies to whatever shift comes next, because the work keeps changing and a manager who is not in the work cannot keep up with it. Treat "managers should not code" as a hard rule and you grow managers who mistake their own seniority for the field's stability, an easy mistake to make when the career keeps advancing while the field underneath it keeps starting over.

The four payoffs you lose hands off

Staying technical pays back four ways that get lumped together as one, and each fails in its own way when you stop.

Smell test. You read a design and something looks off before you can say what. You read a code change and it reads plausible, and because you know the system, the plausibility itself is what warns you. You cannot always explain the signal, but you can point to where the team should look next. That kind of pattern recognition comes from hours spent in real code, and reading about the code from the sidelines does not build it.

Noise filter. Most new tools and frameworks do not deserve the team's attention, so saying no is the default answer, but a no only carries weight when you have tried enough of these tools yourself to see how they fail. Without that, the team chases whatever happens to be loud that quarter.

Adoption velocity. For the few tools that do deserve attention, how fast the team adopts them is decided by you before it is decided by the engineers. If you have used the tool yourself, the team picks it up in weeks. If you have to be briefed first, the team waits with you, for the briefing to land and for your confidence to catch up, and the waiting adds up, paid by the team rather than by you.

Sustainment. Most of a manager's day is abstract, decisions and conversations, and the small reward of writing a piece of code and watching it run is gone. For an engineer turned manager that absence is a slow drain, the kind you may not notice until the quarter goes badly. Building something yourself, even on a weekend, keeps you able to keep doing this work. Most public writing about engineering management skips this point because it sounds soft. It is soft, and it is also the one holding the other three up: without that small reward, the whole practice dies quietly in the third month of a hard quarter.

Each failure has its own shape:

• Without the smell test, bad designs ship before you catch them.
• Without the noise filter, the team's attention gets eaten by hype.
• Without adoption velocity, the team waits for you to catch up.
• Without sustainment, you stop doing any of this at all.

Stay up to date, on the margins

The cheap half runs on small bits of weekday time, through four channels, in rough order of payoff:

• A small list of writers. Maybe five people whose taste you trust. Read what they write themselves, because the aggregators paraphrasing them are noise.
• A few trend summaries. One or two newsletters that filter for you. Skim them and move on.
• An hour with each new tool. No more than an hour, because most tools will not survive it, and the hour exists to find that out cheaply.
• Conversations with people doing the work. One real conversation with someone using the tool beats three articles about it.

The filter matters more than the volume: read a hundred things where all hundred are noise and you have only learned how to feel busy. Keep the list small and the signal high. The same filtering runs your team's roadmap, and this practice is rehearsal for it.

Reading gives you opinions. Building gives you taste, and the cheap half only buys the first.

Try hands on, on the calendar

The expensive half is building something: a side project, a ticket the team would not otherwise pick up, a small prototype, a weekend repo. The form matters less than how often it happens, and if it is not on the calendar, it is not happening.

I do mine on weekends, one evening or one Saturday morning a week, small things, almost always throwaway. By any team metric those hours are unproductive, and by the metric this essay is about they are the most productive hours of the week.

Building without reading rots in the other direction, leaving you stuck on last year's tools while the eye narrows. The two halves run in parallel, and skipping either one costs you something the other cannot give back.

The AI venue, where the eye now lands

The form of hands-on work has changed underneath all of this. Your team is shipping with AI tools now, copilots that suggest code inside the editor and agents that take a task and come back with a patch, and the work that exercises your eye is judging what the AI produced and redirecting it when it goes wrong. That is the same skill taste was always built on, because the typing was only ever a proxy for the judgment it trained. The shift makes staying technical more important, and the test now is whether you use the tools yourself or watch your team use them.

A manager who skips this is voluntarily out of the loop on the part of the work that is moving fastest. The smell test applied to generated code is the same smell test, pointed at newer surface area.

When this is wrong

This has two honest edges. At very large scale the hands-on hours have to compress: a director with sixty engineers will not match a manager with five, and that is fine, because the goal was never lines of code. The job needs the technical eye, the ability to read a design and notice when something is wrong with it, and the minimum is however much hands-on time keeps that eye working. For most managers that number is higher than what they are doing now.

Second, the practice needs calendar protection, and it needs it because it is the one block on your calendar with nobody else attached to defend it: treat it as optional and it disappears the first time the quarter gets hard. Block time for it the way you would block time for planning. Nothing hurts in the week you skip it. The damage shows up later, in adoption velocity and in the bad design you could not catch in time.