Staying technical, deliberately

Engineering management pulls you away from the engineering work it is supposed to judge. Getting promoted adds people for you to manage and takes away hours at the keyboard. Your calendar fills with one-on-ones, planning, hiring loops, escalations. 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 balance between coding and managing. Others will tell you to stop coding altogether. Neither is right.

Going hands off does not free you from the technical part of the job. It quietly removes the hands-on practice that builds the technical eye the job depends on.

Don't fold to the stop-coding camp

The case against managers coding sounds reasonable. Switching between code and meetings is expensive. You are not paid to ship features anymore. Some of this is true around the edges.

The reason to reject it anyway is that the engineering work itself is changing too fast. What an engineer actually does week-to-week is moving. How code gets from an idea to production is moving. A manager who has not touched the work cannot make calls about those changes. They can only react after the team has already picked a direction, by which point the choice is locked in.

AI is one of these shifts. There will be others. The argument applies to whatever shift comes next: the work keeps changing, and a manager who is not in the work cannot keep up with those changes. Treat "managers should not code" as a hard rule and you grow managers who mistake their own seniority for the field's stability. The career advances. The field starts over.

The four payoffs you lose hands off

Staying technical pays back four ways, often treated as one. Each one fails differently 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, but because you know the system, the plausibility itself is the warning. You cannot always explain the signal, but you can point to where the team should look next. This kind of pattern recognition comes from hours spent in real code. Reading about it from the sidelines does not get you there.

Noise filter. Most new tools and frameworks do not deserve the team's attention. Saying no is the default answer. But you can only say no with confidence if 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, for your confidence to catch up. The lag adds up.

Sustainment. Most of a manager's day is abstract. Decisions and conversations. 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. You may not notice it until the quarter goes badly. Building something yourself, even on a weekend, is what keeps you able to keep doing this work. Most public writing about engineering management skips this point because it sounds soft. The softness is the disguise. Without that small reward, the practice dies quietly in the third month of a hard quarter.

Each one fails differently if you let it lapse:

• Without the smell test, you cannot catch bad designs before they ship.
• 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. Built on small bits of weekday time. Four channels, in rough order of payoff:

• A small list of writers. Maybe five people whose taste you trust. Read what they write themselves. The aggregators paraphrasing them are noise.
• A few trend summaries. One or two newsletters that filter for you. Skim them, do not archive them.
• An hour with each new tool. No more than that. Most will not survive the hour. That is the point of the hour.
• 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. If you read a hundred things and all hundred are noise, you have only learned how to feel busy. Keep the list small. Keep the signal high. The same filter applies to your team's roadmap; this practice rehearses it.

Reading gives you opinions. Building gives you taste. The cheap half is necessary but not enough.

Try hands on, on the calendar

The expensive half. Actually build 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 you do it. If it is not on the calendar, it is not happening.

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

Building without reading rots in the other direction. You stay stuck on last year's tools and the eye narrows. The two halves run in parallel. Each one fails differently if you skip it.

The AI venue, where the eye now lands

Today, the form of hands-on work has changed. Your team is shipping with AI tools: copilots that suggest code inside the editor, agents that take a task and come back with a patch. The work that exercises your eye now is judging what the AI produced and redirecting it when it goes wrong. That is the same skill taste was always built on. Typing was the proxy; judgment was the thing it produced. The AI shift makes staying technical more important; 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 moving fastest. The smell test applied to generated code uses the same skill, on newer surface area.

When this is wrong

Two honest edges. At very large scale, hands-on hours have to compress. A director with sixty engineers will not match a manager with five. That is fine. The goal was never lines of code written. The goal is the technical eye: being able to read a design and notice when something is wrong with it. The minimum is however much hands-on time keeps that eye working. For most managers, the right number is higher than what they do now.

Second, this practice needs calendar protection. If you treat it as optional, it disappears the first time the quarter gets hard. Block time for it the way you would block time for planning. The cost of letting it lapse shows up later, in adoption velocity and in the bad design you could not catch in time.