When I moved into my first management role, a more senior leader told me: “You’ll stop writing code within six months.” He said it like it was inevitable, a law of nature. I took it as a challenge. Twenty-five years later, I still write code. Not as much as I used to, and not the same kind, but I’ve never fully let go. And I think that’s been one of the most important decisions of my career.

But staying technical as you move up is harder than it sounds, and doing it badly can be worse than not doing it at all.

Why It Matters

There’s a pragmatic argument and a credibility argument, and both are real.

The pragmatic argument is that you make better decisions when you understand the technology your team is working with. Not at the level of knowing every line of code, but at the level of understanding the trade-offs, the constraints, and the pain points. Will Larson recommends that new engineering executives build and deploy a trivial change, do an on-call rotation, and attend incident reviews, not because they need to prove anything, but because these activities give you ground truth that no dashboard can provide.

The credibility argument is simpler: engineers trust leaders who understand their world. Google’s Project Oxygen research found that having key technical skills to advise the team was one of the ten behaviours of high-performing managers. You don’t need to be the best engineer in the room, but you need to be technical enough that your team respects your input and trusts your judgement on technical matters.

Fournier puts it well, at the level of managing multiple teams, you stay technically relevant by overseeing technical investment, asking informed questions, analysing trade-offs, and trusting your gut checks. The gut checks only work if you’ve kept your technical instincts sharp.

What Staying Technical Actually Looks Like

The mistake I see most often is leaders who try to stay technical by staying in the critical path, reviewing every PR, approving every design, being the final decision-maker on every technical choice. That’s not staying technical. That’s being a bottleneck.

Ben Edmunds, writing in 97 Things Every Engineering Manager Should Know, suggests a priority order that I’ve found useful: management duties first, then code reviews, then architecting, then fixing bugs, then internal tools. The key insight is that code reviews and architecture discussions keep you technically engaged without putting you on the critical path for delivery.

Here’s what works for me in practice:

Code reviews. This is the single best way to stay close to the codebase without blocking anyone. You see what’s being built, you understand the patterns being used, and you can provide guidance without being a gatekeeper. Fournier recommends this at every level of management, and I agree, it’s the activity with the best ratio of technical engagement to time invested.

Attending incident reviews. When something breaks in production, the post-incident review is a goldmine of technical context. You learn about the systems, the failure modes, the gaps in monitoring, and the trade-offs the team is living with. Larson specifically recommends this for new executives, but I think it’s valuable at every level.

Writing small things. I still pick up small features or bug fixes when I can. Not the critical-path work, that belongs to the team, but the internal tooling, the developer experience improvements, the small quality-of-life fixes that nobody else has time for. It keeps my hands in the code and often surfaces pain points that I wouldn’t discover any other way.

Building and deploying. Larson’s advice to build and deploy a trivial change is about more than the code itself. It’s about experiencing the development workflow firsthand, the build times, the test suite, the deployment pipeline, the monitoring. If your team tells you the CI pipeline is slow, you’ll understand viscerally what that means if you’ve recently waited for it yourself.

The Line Between Engagement and Interference

This is where it gets tricky. Larson makes an important point: knowing what a team is doing and questioning the thinking behind their decisions is not micromanagement. It’s doing your job. But there’s a difference between informed engagement and interference.

Two questions help me check myself:

First, am I carefully considering the feedback of those closest to the work before making decisions? If I’m overriding my team’s technical judgement based on my own preferences rather than genuine concerns, that’s interference.

Second, am I adding friction to a team that would have gotten to a similar quality decision without my involvement? If the team would have made the same call without me, my involvement is overhead, not value.

The goal is to be technically informed enough to ask good questions and spot potential problems, without being so involved that the team can’t move without your approval. It’s a moving target, and I get it wrong sometimes. The signal that you’ve crossed the line is usually when your team starts waiting for your input rather than making decisions and telling you about them afterwards.

How It Changes as You Move Up

At the tech lead level, you’re still writing significant code. At the engineering manager level, you’re doing code reviews and small fixes. At the director level, you’re attending design reviews and incident reviews. At the VP level, you’re reading architecture documents and asking questions.

The form changes, but the principle doesn’t: maintain enough technical engagement that your instincts stay calibrated. Fournier describes this progression clearly, at each level, you’re further from the code but you should never be so far that you can’t smell when something’s off.

The danger at senior levels is what I think of as “technical nostalgia”, staying involved in technical details not because it helps the team but because it’s comfortable. If you’re spending your limited time debugging a production issue that three other people could handle, while ignoring the organisational problem that only you can address, you’re not staying technical. You’re hiding.

Protecting the Asset

Your IC background is an asset. It gives you empathy for the work your team does, credibility when you weigh in on technical decisions, and a bullshit detector for when someone’s oversimplifying a problem or overcomplicating a solution.

But like any asset, it depreciates if you don’t maintain it. The technology landscape moves fast, and the gap between “I used to build systems like this” and “I understand how systems like this work today” widens every year you’re not hands-on.

I protect this by carving out time, deliberately, in my calendar, for technical engagement. It’s not a lot. A few hours a week. But it’s consistent, and it’s non-negotiable. Some weeks it’s code reviews. Some weeks it’s reading a technical RFC. Some weeks it’s pairing with an engineer on a problem. The specific activity matters less than the habit.

The leaders I’ve seen lose their technical edge didn’t make a conscious decision to stop being technical. They just let it slip, one busy week at a time, until they woke up one day and realised they couldn’t follow the technical discussions in their own team’s design reviews. Don’t let that happen. The investment is small. The return is enormous.