Staying Technically Sharp When Your Role Gets More Strategic

Dev Leader Weekly 135

Apr 13, 2026

TL; DR:

Staying technical starts with knowing what “technical enough” actually means for your role
Design reviews and code review exposure are your minimum baseline -- they keep your surface area alive
Trust is not a weakness: as your scope grows, being deeply expert in everything is impossible and trying will break you
Join me for the live stream (or watch the recording) on Monday April 13th at 7:00 PM Pacific!

The Technical Tightrope: Staying Sharp When Strategy Starts Eating Your Calendar

There’s a Reddit post I came across in the ExperiencedDevs community that asked a question I’ve heard a hundred times: “How do you stay technically sharp when your role becomes more strategic?”

It sounds simple. It’s not.

This is one of those things that sneaks up on you gradually. One day you’re writing code most of your day. Then the meetings start. Then the strategy conversations. Then you look up and you’re spending maybe two or three hours actually touching code out of an eight-hour day. And a quiet panic sets in: am I losing it?

I’ve been there. I was a startup engineering manager about a year into my career. I was coding for long stretches -- probably unhealthy stretches -- and then my role started pulling me toward strategy. Over time, I could feel the gap forming. So I want to share what I’ve learned about staying sharp without trying to pretend your role hasn’t changed.

You can check out my full thoughts on this in the video below:

First: Know What “Technical Enough” Means for Your Role

Before you panic about losing your technical edge, step back and ask yourself: what does your role actually require from a technical perspective?

This is different for everyone. For some people in leadership or management positions, technical depth means being able to hold your own in an architectural discussion. For others, it means knowing enough to ask the right questions and direct the right people. For others still, it means being able to jump into the codebase when needed.

My litmus test is this: if you find yourself constantly deferring in technical conversations -- like every single time the discussion gets technical, you’ve got nothing to contribute and have to say “let me get back to you on that” -- that’s a signal worth paying attention to. It doesn’t mean you need to be coding eight hours a day. It means there’s probably a gap forming that’s going to cause problems in your strategic conversations too.

Understanding the expectation is step one. Once you know that, you can be intentional about what staying sharp actually looks like for you specifically.

The Minimum Baseline: Design Reviews and Code Review Exposure

If I had to name the minimum surface area for staying technically engaged, I’d say two things: design reviews and code review exposure.

Design reviews are valuable even when they’re outside your direct area of ownership. I manage multiple sub-teams, and I make a point to get pulled into design reviews for teams I don’t directly manage when I can. I’m not there to make the decisions -- I’m there to maintain context. Even if a design discussion is in an area I’m not an expert on, the more often I’m in the room, the more I can say “I’ve seen this pattern come up before” or “I know who to loop in on this.”

Code reviews work the same way. The goal isn’t to gate every single pull request. The goal is to be automatically on the exposure path. If you’re never included in code review cycles, you’ve got to go out of your way to discover what’s changing in your codebase. That friction is enough that most people just stop looking. Being looped in -- even just as a passive observer on some reviews -- keeps the surface area alive.

Neither of these requires you to be the approver or the decision-maker. They just keep you in the conversation so you don’t fall completely off the map.

Pull in the Experts Early -- and Work With Them

One situation that comes up constantly in strategic roles is being in a conversation that slowly slides into a technical design discussion. Maybe it starts as a product conversation. And then someone draws a box on a whiteboard. And suddenly you’re three levels deep into architecture.

If you’re in those moments and you know you’re not the right technical expert, there’s a wrong way and a right way to handle it.

The wrong way: try to bluff through it, make design decisions you’re not qualified to make, and figure it out later. This is how technical debt disguised as strategy gets born.

The other wrong way: immediately hand it off entirely and walk away. “Not my area, talk to Bob.” This protects you in the short term, but it means the next time this exact situation comes up, you’re in the same position -- or worse.

The right way: identify early that this conversation needs technical depth you don’t have, pull in the right people, and work alongside them rather than delegating and disappearing. The distinction matters. When you work with the expert instead of just handing it off, you pick up context. You learn the codebase area. You understand the tradeoffs they’re weighing. And the next time this topic comes up, you’re not starting from zero.

I’ve experienced this recently with a team member moving to a different team. He took deep codebase expertise with him, and the immediate reality for me is that I probably need to step more directly into some of that code for a period -- not to become the expert, but to reduce the gap while the team adjusts. That’s not comfortable. But it’s the right call given the context.

Side Projects Are Still on the Table

This one is contentious and I want to address it directly.

If there’s a technology area where you feel like you’re falling behind and your day job isn’t giving you exposure to it, side projects are still a valid option. I know people push back on this. You shouldn’t have to work outside of work hours. That’s a fair perspective.

But I separate “should” from “can.” If there’s a genuine gap that matters to you, and the path to closing it is available outside of work, it’s worth at least considering. It doesn’t have to be something you ship. It doesn’t have to be polished. Just build something with the technology. I built a website with Astro recently just to get my hands on it. I tried deploying something with Kubernetes just to understand it better. These low-stakes explorations build real intuition even if the project goes nowhere.

You can do something similar with design patterns and software architecture -- building an extension system in C# using a plugin architecture approach is exactly the kind of hands-on project that builds the kind of deep understanding that strategic conversations rely on. Small things, real exposure.

The Part Nobody Wants to Talk About: Trust

Here’s the uncomfortable truth that I think a lot of people avoid: as your scope and responsibility grow, it becomes literally impossible to maintain deep technical expertise across everything you’re responsible for.

Not difficult. Impossible.

If you’re a deeply technical individual contributor today and your role evolves into one where you’re responsible for three different teams across three different technical areas, you won’t be the domain expert in all three. That’s not a failure. That’s the math of the situation.

The shift you have to make -- and it’s genuinely hard -- is trusting that other people on your team do have that expertise. This isn’t about abdicating responsibility. It’s about recognizing that your value in the role has shifted. You’re not valuable because you know every line of code. You’re valuable because you can make good decisions with the technical input you receive, connect the right people, and remove the right obstacles.

I’ve seen leaders try to stay so technically involved in everything that they become bottlenecks. Every decision routes through them. Every pull request waits on them. Every design needs their approval. It feels like technical leadership but it’s actually the opposite -- it’s a scaling failure dressed up as technical rigor.

If you find yourself doing that, or being tempted to, it’s worth asking whether the drive to stay deeply technical is serving your team or serving your ego. Sometimes it’s both. But being honest about that distinction matters.

What This Actually Looks Like in Practice

To bring it together: staying technically sharp as a strategic leader isn’t about reclaiming your identity as an individual contributor. It’s about maintaining enough surface area that you can be useful in technical conversations and make good decisions when they matter.

For me personally, that means:

Getting invited to design reviews, even when they’re adjacent to what I directly manage
Being on the exposure path for code reviews without trying to gate every change
Pulling technical experts in early and working with them rather than just handing things off
Being intentional about exploring areas where I feel gaps forming
And most importantly -- knowing where the line is between “I need to understand this” and “I need to trust someone else here”

The plugin architecture patterns I’ve been covering on the blog are a good example of this kind of intentional technical exposure -- even if you’re not shipping plugin systems at work, understanding the design principles keeps your architectural thinking sharp.

Don’t panic about the shift. It’s natural. The people who handle it well are the ones who stay honest with themselves about what they know, what they don’t know, and who to bring in when the gap matters.

Dev Leader Weekly

Discussion about this post

Ready for more?