The question I hear most from engineers thinking about management is some version of "will I lose my technical skills?" The honest answer is: some of them, yes. You won't be the fastest person on the team at shipping a feature any more, and you shouldn't try to be. But there's a big difference between not writing much code and not understanding the system. The first is the job. The second makes you a worse manager every month it goes on.
After many years of leading teams, here's how I think about staying technical, and the habits that have actually lasted.
Why it matters
A manager who has lost touch with the technology makes worse decisions in ways that are easy to miss. You can't tell a reasonable estimate from a wild guess. You can't spot when a "small refactor" is really a rewrite in disguise. You can't tell the difference between an engineer who's struggling and one who's been handed an impossible problem. And your team stops bringing you technical questions, because they've learned you can't help.
Staying technical isn't about proving you still can. It's about keeping the judgement your team and your stakeholders rely on.
The goal is not to be the best engineer on the team. It's to stay close enough to the work that your judgement is still worth something.
What I let go of
Letting go is the first part, and the part new managers resist hardest.
- Critical-path work. If a feature depends on my code, my meeting-heavy calendar becomes the team's bottleneck. I don't take anything with a deadline that others depend on.
- Being the expert on everything. There will be parts of the system I don't know well. Someone on the team should know each part better than I do, and that's a sign things are working.
- Winning technical arguments. My opinion carries extra weight because of my role, whether I want it to or not. I give it, I explain it, and then I let the people doing the work decide more often than not.
- Keeping up with every framework. I follow the shifts that matter to our systems and our hiring. I don't need to try every new library.
What I keep
Design reviews
This is the highest-leverage technical work a manager can do. I read every significant design doc on my team and the important ones from teams we depend on. I don't review to approve; I review to ask the questions that might not have been asked. What happens when this dependency is down? How do we roll it back? Who gets paged? How will we know it's working? A few good questions at design time are worth more than any amount of code I could write.
Reading code, regularly
I read pull requests most days, though I rarely leave comments on them. Reading code keeps me honest about what the system actually looks like, as opposed to what the architecture diagram says. It also tells me a lot about the team: where the tests are thin, which areas everyone avoids, who explains their changes well. When I do comment, it's on direction and risk, not style.
Being on the incident path
I join the major incident reviews, and occasionally I still sit in on the incident itself. Nothing teaches you how a system really behaves like watching it fail. Incident reviews are also where you find out which parts of the system the team is quietly afraid of, which is exactly the information a manager needs when planning.
Small, off-critical-path code
I still write code, just not the code the team is waiting for. Internal tools. Scripts that pull together metrics for planning. A prototype to test whether an idea is worth putting on the roadmap. Fixing a flaky test that's been annoying everyone. It keeps my hands familiar with the build, the tooling and the codebase, and it never blocks anyone.
Learning in public with the team
When something new is worth understanding, I learn it alongside the team rather than separately. A lunchtime session where someone walks through a new tool. A shared reading list. Pairing for an hour with an engineer on something they're excited about. It's more fun, it's better for the team, and I learn faster when someone more expert is explaining it.
How I find the time
None of this happens unless it's protected. A manager's calendar fills itself; technical time has to be put in deliberately.
- Block it. I keep two short blocks a week for technical work: reading designs and code, or a small piece of building. They're treated like meetings, not like free time.
- Batch the reading. I review pull requests and design docs in one sitting rather than letting them interrupt the day.
- Cut meetings that don't need me. Every quarter I look at my recurring meetings and drop the ones where I'm a passive attendee. That's usually a few hours a week right there.
- Use the commute or the quiet hour. Long-form technical reading, articles, conference talks and books, goes where I have attention but no meetings.
A warning about the other extreme
There's a failure mode on the other side, too: the manager who stays so technical that they never really become a manager. They still take the hardest tickets, rewrite designs they don't like, and spend their one-on-ones talking about code instead of people. It feels productive. It leaves the team without a leader and without room to grow.
If you're spending more than about a fifth of your week on hands-on technical work as a manager of a full team, ask honestly whether that's what the team needs or what you enjoy.
The long view
The engineers who move into management and stay sharp tend to share one habit: they stay curious about how things work and they ask good questions. Code was always a means to that end. You can keep the curiosity and the judgement for a whole career, even when your commits become rare.
Written by Parvez
Engineering Manager at Innova Solutions and a software architect with 25+ years in the industry. I write about leadership, architecture, Java and the books that shaped how I work.
More about me
