I haven't written production code in years, and I don't intend to start. This is about the thing that goes when you stop building anything at all, which is different, happens quietly, and is much harder to get back.
9 February 2026·6 min read
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. Nobody takes the keyboard 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. Not writing production code, and not staying current for its own sake. Keeping the specific ability to tell when something is hard.
Because what erodes isn't syntax. Syntax is trivially reacquirable and nobody's effectiveness depends on it. Four other things go, and they go quietly.
The first to go and the most expensive. 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.
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.
Engineers are generous about managers who don't code and unforgiving about managers who don't understand. The tell isn't whether you can write the code. It's whether you ask a question that shows you know where the difficulty lives. You get about one of those per conversation, and you either have it or you don't.
The one I'd most hate to lose. Reading a design and feeling that something is wrong before you can say what. That 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.
So what does hands-on mean when you aren't shipping features? Concretely, for me, four things.
Not a tutorial, not a course. Something with 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 whole value. It reproduces the conditions that build judgment, which is being stuck and responsible for getting unstuck.
I read pull requests. Not to approve them and not to catch bugs the team would catch anyway, but because reading code is how you keep a model of the system in your head. A manager who cannot read the diff is managing a description of the work rather than the work.
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.
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.
And the honest counterweight, because the failure mode of this argument is a manager who thinks staying technical means staying in the code.
The single hard rule. 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.
If I comment on every PR, I've centralised 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.
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 licence to overrule people with better current information.
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.
What it actually buys, in the terms a business would recognise.
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.
I want to be careful not to overclaim this. 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 organisational judgment instead. This is a preference with tradeoffs, not a moral position.
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 isn't a hobby that happens to be adjacent to my job. It's the practice that keeps the judgment my job depends on from quietly going stale.