Staying Technical as a Tech Manager: A Practical Guide
What I've learned about staying connected to code when the role keeps pulling me away.
A few months into my first management role, I counted my week. Forty hours, and I’d opened an IDE exactly once. That was to approve a PR I barely had time to read. Nothing dramatic had happened that week. No crisis, no urgent launch. The time had just quietly disappeared into things that were all individually reasonable: 1:1s, content reviews, planning docs, a strategy meeting or two.
That’s the drift. It doesn’t happen in one big shove. It happens one reasonable Thursday at a time.
The standard advice is to block time for code and protect it. In my experience, that doesn’t survive contact with a normal week. Protected time gets colonized. The meeting you couldn’t say no to lands on your blocked afternoon, and the precedent is set. Three weeks later, you’ve written zero code.
Staying technical needs to be built into the structure of the role, not carved out of what’s left over. And the goal isn’t to match your engineers on depth. You won’t, and you shouldn’t try. The goal is to stay grounded enough that when an engineer brings you a hard problem, you can actually engage with it. Without that, your judgment becomes theoretical, and your team will feel it before you do.
Here’s what I’ve found actually works.
Pick two or three technical surfaces and commit
The first mistake most new managers make is trying to hold on to everything they used to do, just at reduced volume. You keep contributing to the main codebase, reviewing every PR, building internal tools, prototyping new things. You just do less of each. This produces the worst of both worlds. You’re not deep on anything, and you’re not delivering on the management side either.
The move is to pick a small number of surfaces and actually commit to them. Drop the rest deliberately, not by accident.
What counts as a good surface? Work that keeps your technical judgment calibrated to reality. If you stop touching code entirely, you’ll still have opinions about architecture, but those opinions will slowly disconnect from how things actually work. You’ll miss details during design reviews because you’re reasoning from a version of the system that existed two years ago. The specific surfaces I’ve held onto are contributions to open source projects, smaller codebases where I can own the whole problem end to end, and product and roadmap conversations where I can push back when something doesn’t feel right.
Let me be concrete about what I’ve dropped. I used to write detailed code samples, the kind that walk through every step and explain every choice. I used to write ebooks on technical topics I was deep in. I used to know our SDKs down to the function signature, which library calls what, which option changes what behavior. None of that is true anymore. I’ve let it go, because holding on to it meant spreading too thin.
The test for whether a surface is the right one: does staying on it force you to engage with how the code actually works today, not how you remember it working? If yes, keep it. If no, it’s not doing the job.
Use AI, but don’t confuse it with staying technical
A lot of what I ship on smaller codebases now gets done with AI. The team maintains some popular open source microsites, and the backlog always grew faster than I could address it. With AI, I can throw work at a couple of them in parallel in the morning. Most of it fails, but when something works, it’s a real improvement shipping that wouldn’t have shipped otherwise. Everything goes through review anyway, so quality doesn’t slip.
It would be easy to conclude that AI is how I stay technical. I want to be careful here, because that’s not quite right.
What AI actually does is keep me connected to the building side of the work. The decisions about what a feature should do, how it fits into the rest of the system, when it’s ready to ship. That’s real work, and AI genuinely helps me do more of it.
But AI also abstracts me further from the coding side. When I use it, I’m reviewing and directing more than I’m writing. The keystroke-level work, actually structuring a function or working out why something’s broken, happens less. AI solves my time problem and creates a depth problem.
The rule I use: AI is the right tool when shipping is the point. Microsites, fixes, content pipelines, anything where the work is delivery rather than learning. But every AI-assisted task is also a signal. If you notice a week has gone by without any code you wrote yourself, that’s a prompt to switch modes on the next thing.
Protect one place where you still code by hand
This is the counter to the AI rule. You need at least one surface, somewhere, where you’re writing code without AI doing the heavy lifting. If you don’t, your coding instincts will slowly hollow out, and you’ll notice too late to reverse it.
At work, for me that’s SDK changes. These are libraries that thousands of developers depend on, and the code needs to be correct at a level of detail I don’t fully trust to AI yet. Review won’t catch everything that implementation judgment would have caught in the writing. So I slow down and write those changes myself. Not for identity reasons. For correctness.
Outside of work, I protect it more carefully. Right now that means an image generator I’m building. I use Claude for a lot, and Claude doesn’t do image generation, so I wanted a UI tailored to how I actually work. Nothing novel. I’m not training models, just wrapping existing ones. But I’m writing it by hand because building for its own sake is part of why I do this.
My honest worry is that my default mode at work keeps shifting toward AI-assisted, and personal projects are becoming the main place where I exercise the by-hand muscle. If that gap widens too far, the skills erode without warning. Being deliberate about the side projects is how I guard against that.
Pick one surface, at work if you can, outside work if you have to. Protect it the same way you’d protect a recurring meeting. Make it visible to yourself so it doesn’t get skipped.
Shift what you read, not whether you read
Reading scales down well to a manager’s schedule in a way coding doesn’t. You can’t meaningfully contribute to a codebase in fifteen minutes. You can get through most of a good newsletter or a chapter of a book in that window.
The trap isn’t stopping reading. It’s continuing to read the material you used to read, because you’re still aspiring to the version of yourself from a few years ago.
When I was learning Rust, I read books about how the language worked, how memory management actually happened, how borrowing and ownership played out in real code. I wanted the depth of someone who was going to be writing Rust the next day. That was the right reading for that version of me.
It’s not the right reading now. These days I’m reading about systems architecture, protocols at a design level, engineering management, and leadership. The technical content is still there, but at the altitude of how systems get built and why, not what happens in memory when you move a value out of scope. The reading I’m doing now matches the questions I’m actually responsible for answering.
Fifteen to thirty minutes most days is plenty, if the material is pointed at your actual altitude. If you’re reading for the job you had three years ago, even an hour a day won’t do much for the job you have now.
Make the technical work structural, not motivational
Willpower doesn’t hold up across a quarter. Blocked time on Friday afternoon works until someone puts a meeting on top of it, and then the precedent is set. Once the block can be overwritten, it will be.
What actually holds is making the technical work visible and expected. When I take on a technical project, it goes in the same planning tools as everything else. It has a ticket. It has a timeline. The team sees it on my plate the same way they see any other project. It’s not a side activity I squeeze in when the calendar happens to be quiet. It’s work, and it’s scheduled like work.
The other half is delegation. Two specific shifts freed up real hours for me.
I still review code and content, but the purpose of the review has changed. It used to be about catching bugs and fixing issues. Now it’s mostly about mentoring, a place where I give feedback that helps the engineer grow rather than gate what ships. That reframing is what lets me do less of it. I’m not reading every line with a critical eye. I’m reading to find the one or two things worth a conversation.
I also delegate more of the visible work I used to volunteer for. Speaking opportunities, writeups, cross-team initiatives. The filter I apply is whether someone on my team could do this and grow from it. Usually yes. They get the growth opportunity and I get the hours back.
Neither change feels dramatic on its own. Together they create the margin where technical work actually happens.
Where this leaves me
None of this is solved, and I want to be honest about that because the parts where I fail are instructive.
The weeks I fail aren’t the weeks with a crisis. Those are easy to see. It’s the quiet weeks that get me. The calendar looks reasonable slot by slot, every meeting is legitimate, every item on the list needs doing. But by Friday I realize coding hasn’t happened, and I can’t point to a single thing that pushed it out. The drift is collective, not individual.
The skill I’m still building is catching that pattern earlier. By Wednesday instead of Friday, while there’s still time to clear something and make space. Some weeks I manage it. Other weeks I don’t, and I try again the next Monday.
If you’re a tech manager who cares about staying technical, the thing to internalize is that it won’t happen as a byproduct of the role. The normal pressures of the job will absorb the time if you let them. You have to choose it, build structure around it, and then protect the structure. And you have to be honest with yourself about when it’s working and when it isn’t.
The specific moves I’ve described, pick your surfaces, use AI deliberately, protect by-hand work, adjust your reading, make it structural, will help. But they work because I keep re-applying them, not because I set them up once and they kept running. That’s the part nobody tells you.