Why I Stayed Hands-On

There's a moment in most engineering management careers where you notice you're the least technically current person in the room, and that it happened without any single decision. The keyboard is never taken away. You just stop being the person who has to make it work, and the gap opens at the speed the field moves, which lately is quickly.

The usual response is one of two bad ones. Some managers keep coding, badly, in the critical path, and become a bottleneck their team routes around. Others let it go entirely, and slowly become someone who can discuss engineering but not evaluate it. I've reported to both. The second is more common and does more damage, because it's invisible for a long time.

What I've tried to hold onto is narrower than either: the specific ability to tell when something is hard. Writing production code is not the point, and neither is staying current for its own sake.

Estimation stops being something you can feel. You lose the felt sense of what two weeks contains, and you replace it with deference: whatever the team says, doubled, because you can't tell the difference between a hard problem and an unfamiliar one. That's a safe policy and it makes you useless in the room where scope gets set, which is where a manager's leverage actually is.

You lose the ability to be told something is impossible. Sometimes it is. Sometimes it means "I don't want to", or "we'd have to touch the module nobody understands", or "that's hard in a way I can't articulate in this meeting". Those are four different situations demanding four different responses, and telling them apart requires having recently been in the third one yourself.

Credibility is not the same as authority. Engineers are generous about managers who don't code and unforgiving about managers who don't understand. The tell is whether you ask a question that shows you know where the difficulty lives. You get about one of those per conversation. You either have it or you don't.

The instinct for what is about to be a problem goes too. The one I'd most hate to lose. Reading a design and feeling that something is wrong before you can say what. The feeling is pattern recognition built from having been burned, and it decays without new burns. It's also, when it works, the highest-value thing a technical leader does all week.

Build something real, on your own time, that can fail. A tutorial will not do it, and neither will a course. It has to have actual stakes, where the failure is yours. The homelab does this: when GPU passthrough doesn't work at midnight, there is nobody to escalate to and no story to point at. That's the value. It reproduces the conditions that build judgment, which is being stuck and responsible for getting unstuck.

Stay close enough to read the work. I read pull requests, because reading code is how you keep a model of the system in your head. Approving them is not the point. The team would catch the bugs anyway. A manager who cannot read the diff is managing a description of the work rather than the work.

Do the unglamorous technical thing occasionally. Take the small ticket nobody wants. Write the runbook. Do the migration dry-run. These are low-risk to the delivery plan and high-signal for you, and they demonstrate something to the team that no all-hands slide does.

Learn the new thing before you have an opinion about it. The specific reason I run local models and agents on my own hardware. I could have opinions about AI coding tools from reading. Those opinions would be worth nothing, and worse, they'd be confidently held. Running the tools daily against my own code, including where they fall apart, is what makes the opinion worth acting on.

Your hands-on work does not belong in the critical path. The moment the team is waiting on my code, I've made myself a dependency with a calendar full of meetings, which is a reliability problem I created and they absorb. Do the work adjacent to delivery, not inside it.

Reading the diff is not reviewing the diff. If I comment on every PR, I've centralized judgment in the person furthest from the code. I read to maintain a model. Someone closer owns the standard, and the difference matters more than it sounds.

Treat your experience as a hypothesis that current facts get to overturn. The thing I got right in 2016 may be exactly wrong now, and a manager with strong technical instincts and stale inputs is more dangerous than one with no instincts at all. Being hands-on is what keeps the inputs fresh; it is not a license to overrule people with better current information.

It impresses no one, and that is fine. If this is about demonstrating you've still got it, it will curdle into competing with your own engineers. The point is being able to help. The tell is whether you're doing it in front of people.

Better decisions under uncertainty, which is most decisions worth making. Build versus buy, whether the estimate is real, whether an architecture will survive its second year, whether the thing being called a two-week task is a two-week task. Every one of those is improved by having recently touched something similar.

Faster escalation triage. When something is on fire I can usually tell within a few minutes whether this is a bad afternoon or a bad quarter, and that changes who I wake up and what I tell the business. Getting that wrong in either direction is costly.

And credibility that compounds. Teams work differently for someone they believe understands the work. Not harder, the thing people wrongly hope for. More honestly. They bring you the real problem earlier, because they don't have to translate it first.

Staying hands-on has a cost, it competes with everything else a leadership job demands, and there are excellent engineering leaders who've let the technical depth go and lead brilliantly on organizational judgment instead. Staying hands-on is a preference with tradeoffs, and I would not press it on anybody as an obligation.

But the thing I'd defend is that the depth has to come from somewhere real. Reading about a technology is not the same as being defeated by it at midnight, and the second one is what produces the judgment worth having. That's what the lab is for. It is the practice that keeps the judgment my job depends on from quietly going stale.