Staying Technical as an Engineering Manager
It’s Friday afternoon and you’re coming out of a week where the important work was mostly conversations. You look at the backlog and it hits you again: “I’m not doing enough technical work. I’m losing my edge. My identity. Damn.”
This is a topic I keep returning to, and one I’ve been thinking about seriously for the last few years. This is where I’m at.
Your gut still needs the craft
A while back, you faced the IC vs Manager choice. You weighed it and chose management. But it wasn’t easy.
It was a choice with a non-negotiable: the engineering part stays.
You read about the Engineer/Manager Pendulum1 and made a pact with yourself — you’re not going to become a Generic People Manager. You are an Engineering Manager.
Done. Your role is clear now. And management is awesome — huge leverage and impact through expanded visibility, people, processes, and high-level decisions.
But there’s something icky you keep coming back to: your original source of energy came from technical craft, and that pull is still there.
The problem? Given everything else on your plate and the lack of daily hands-on practice, how do you stay technical? How do you keep your engineering knife sharp — in a way that helps your team without taking control of it?
Why management, then?
Why trade technical problem solving for a combination of processes, strategy, and sociotechnical problems? This is a classic checkpoint all software engineers step into.
For me, it wasn’t easy. The craft of software engineering is a passion of mine. Writing that piece of code with care and solving that tricky bug is so fulfilling and beautiful. At the same time, the management part was also enticing, challenging, and something I wanted to explore.
I chose to step into the Engineering Management path in the end for a few reasons.
The first one was curiosity and growth-oriented. “Let’s learn this side of the story”. As an engineer, you have limited authority when it comes to the final decision. In healthy teams, that decision evolves naturally most of the time, but sometimes there is a decision you strongly disagree with and your manager still takes it. You mostly trust your manager, but there was a question lingering: “What’s behind that?”
The second reason was impact. As an engineer, I’ve always been drawn to platform/dev tooling rather than feature building.
Part of this was the low-level technical complexity of this kind of work, but the most important one was the impact. Sharing a library can make the devs’ life 10x easier.
Well, leverage and impact as an EM is usually much greater than from an IC position. From technical decisions to empowering people and setting direction, you see your decisions directly affect how people perform — and whether the software succeeds — at a scale rarely comparable to individual contribution alone.
The last reason was people empowerment and compounding influence.
I’ve been part of healthy and unhealthy teams in my career. I’ve had annoying colleagues and unbelievably talented colleagues. And I’ve seen underperformers becoming top performers and talented people declining because of bad management.
This intrigued me. I decided I wanted to step into the high complexity of human nature and team dynamics to explore this side of the story.
I didn’t see this back then, but there’s nothing more fulfilling than empowering a person to achieve their potential. The human connection alone is priceless.
Why stay technical?
The natural progression of the IC vs Leadership track choice is staying technical or abandoning the low-level technical world.
Some might dismiss the magnitude of the follow-up choice. But it’s another major checkpoint. Some engineering leaders leave the technical side completely and focus solely on people management and process-oriented leadership. Others choose to stay technical.
My take? You have to stay technical — at the very least, at a level where you can understand, challenge, and appreciate the technical work you oversee. Ideally, you can also do the work — maybe not efficiently, but effectively. It’s the old common advice: be comfortable discussing and appreciating at least one level of abstraction below your current role.
Why? As a leader, you are accountable for the technical excellence of your team.
You need to recognise overengineered solutions, identify missing factors in the decision-making process, and evaluate tradeoffs. Execution is not only about frameworks and processes2. Architecture choices, technical inefficiencies, and engineering practices can create huge leverage — or quietly drag performance down.
Sounds good, but why do people consciously choose the pure people management path? I think the strongest case for the other side is team trust and time allocation. I still don’t buy it.
I’ve worked with managers who were too far removed from the technical work, and it really didn’t work well.
They pushed for “simpler”, faster solutions without understanding the side effects. They valued vocal engineers instead of effective engineers. Over time, they lost respect from ICs, struggled to have meaningful technical conversations with their reports, and never fully utilised the potential of the team.
The conflict and the identity crisis
You get it now. You are an engineering manager and you understand that you need to stay technical. The irony? The craft you chose to step back from out of curiosity and impact is now the craft you miss.
The tension is there, and you see the conflict. To be successful, you spend your hours in 1:1s, hiring loops, roadmap reviews, alignment meetings, incident response, performance cycles. To stay technically sharp, you’d spend those same hours in code, design docs, production debugging, deep reading. There are 40 hours and a backlog that simply doesn’t end. Pick.
It’s real and it’s frustrating. And this is the beginning of your identity crisis. All these years you defined yourself as an engineer. Your sense of competence, the thing you reach for when someone asks what you do, is anchored in technical work. Now your days are filled with meetings, interviews, documents, Slack messages. You don’t produce anything tangible at the end of the week. Your team has shipped 10 features, and you shipped… what exactly?
And the truly sad part? Most people at this phase resolve this by quietly letting the technical side go. “I’ll find some time this week or next week”. The meetings win every time, week over week, and one day you realise that months have passed since the last time you touched something technical and you can’t read the new design doc without effort.
I didn’t want that. And I don’t think anyone wants that either. But the meetings fight back, and the day still has 8 hours.
What staying technical means
Before we dive into the how, let’s get some things straight. What does technically sharp mean for an Engineering Manager?
Coding and designing small features are no longer your best use of time. And neither is controlling every single solution to your deliverables. This is a common trap, especially for new EMs. The reflex reaction is to design everything, leave 100 nitpick comments in code reviews that don’t add real value, control the solutions, and push for your ideas. That’s the bad side of ego creeping in. That’s the old identity fighting to survive. But sooner or later you see it: that’s neither sustainable nor efficient — it’s a recipe for burnout or disaster. Or both.
So, what does staying technical mean in your new role? Staying technical as a manager is about technical depth and vantage — not technical control.
The technical depth is what enables you to challenge technical decisions and ask the important questions. That’s all you need. Challenge complicated proposals and help simplify them. Identify missing factors in the tradeoff analysis. Help your team set constraints by understanding the technical expectations. And depending on your level, contribute meaningful comments to code reviews.
How is depth different from what you used to do? It’s narrower.
You drop the library-specific knowledge and keep the concepts. You follow important architecture and programming developments without practicing them thoroughly. You stay at a level where you can still do the work, slower than you used to, but you’d get there if needed. You know where to start and how to look.
And what about the vantage point? You have unique visibility into external systems and access to external insights that your own team members don’t have. That’s a superpower. The combination of these insights and technical depth is what helps you set the technical direction and vision of your team. Without that combination, it’s hard to set a technical direction that is both realistic and useful.
Depth to do the work. Vantage to direct it. That’s the combination.
How I practice it
My philosophy and approach to this in a sentence: don’t lose it first, then expand opportunistically.
Maintaining depth
The opportunities that Engineering Leaders have to at least maintain their skillset are vastly underrated.
The effort is truly minimal. What people don’t realise is that maintaining is not a hard task — it’s a prioritisation and a selection game. Want to keep your programming skills? First, review code regularly. Weekly as an EM, monthly as a SEM, quarterly as a director. Second, open a PR occasionally. Even one PR per quarter keeps these muscles active. Now, with AI, things are easier — but deliberate practice is still needed occasionally.
Want to refresh concepts and topics? Leverage your expertise. For example, I’ve always loved software design concepts like Clean Architecture and DDD. Quite often, I share thoughts with engineers, do presentations on these topics, and get involved in workgroups and trainings about them. It keeps the knowledge intact, and it even expands it through feedback loops.
And my favourite supertool? Writing. Technical writing. What many people don’t realise is that writing is foremost a thinking tool for the author, and only secondly for knowledge sharing or proposal communication. It keeps the muscles active and forces you to think broadly and deeply at the same time. Engineering Leaders need to be communicators by the nature of the job, so writing is essential — and it serves both you and the audience.
Lastly, pet projects. This one comes and goes and is life-phase specific. If you truly love the technical work and see it as a hobby and not only work, then you’re lucky to have this option too. The insights you gain from pure hands-on practice and from recent developments are a huge advantage.
Using your vantage point
Using your vantage point as an Engineering Leader mostly comes naturally through your day-to-day work.
How do you gain visibility outside your team? You already participate in cross-team communications. Engaging, asking questions, and giving full attention are the only things you need to gain exposure. Read design docs from teams you don’t manage.
How do you expand your technical breadth? Follow up with peers to seek solutions to technical problems your team brings to you.
And my favourite: horizontal engineering initiatives. They’re your way to fill knowledge gaps and level up. For example, never seen how testing is managed at an org level? Join the testing strategy workgroup. Chase them. Invest time in them. They drive huge impact in both your organisation and your growth.
Conclusion
I’m not sure if this topic is really concluded, but this is where I’m at. I’ve been in leadership roles for the last 6 years, and I’ve truly found meaning and fulfilment in management. However, I get occasional glimpses of the internal conflict and the fear of losing the technical side.
Next Friday afternoon, when the thought comes back, remember: if you still care about the craft, protect it. Staying technical is possible — keep the depth, use the vantage. Lose them, and you’ll feel it in every decision you make.