How Technical Should an Engineering Manager Be?
Is being a highly technical engineering manager the best way to go these days? I am answering this question in this article.
This week’s newsletter is sponsored by Blitzy.
Blitzy is an autonomous software development platform built for enterprise-scale codebases. With deep understanding of your codebase and design standards, it helps teams ship up to 5× faster → from Figma designs to production code.
Some of its core capabilities include:
Self-improving knowledge graph that understands millions of lines of code and their dependencies.
Figma integration that turns designs into responsive frontend code connected to your backend.
Agent orchestration with 3,000+ specialized agents that plan, build, and validate production-ready code.
The result? Up to 80% of the work delivered autonomously. If you're working on a large enterprise codebase, Blitzy is definitely worth checking out.
Thanks to Blitzy for sponsoring this newsletter. Let’s get back to this week’s thought!
Intro
There’s a lot of debate these days regarding what the work of engineering managers should look like. The overall sentiment is pointing a lot more towards being technical, and the trend is pointing in this direction as well.
Especially since the lines between Architect, Staff Engineer, and Engineering Manager are becoming increasingly blurred, and it’s often expected that one person can wear all three hats when needed.
But do I believe that you need to be technical as an EM in all situations? Not at all. I am sharing my reasoning in this article.
Let’s start!
As an engineering manager, your goal is to do what’s best for the team and organization
This is a very important point to always keep in mind as an engineering manager.
Your overall performance is judged by the success of your team, the impact you have on others, and the whole organization, not your individual contribution.
So, that automatically puts you in a position to be an enabler for others → helping everyone do their best work possible, and ensuring that the team is going to be successful.
I always viewed a lot of the EM work as “filling the gaps of the team”. Specific examples:
If the team lacks good communication and cross-functional collaboration, the EM should be doing a lot of that.
If the team is lacking technical seniority, the EM should be filling the gap
If the team needs help contributing with tasks, the EM should be doing that
If the team needs help with setting clear priorities and boundaries, that’s what the EM should be focusing on, etc.
These are some of the examples. And then there are 2 options you have. Either fill the gaps yourself as an EM or hire someone that would fill them.
Now that we understand the overall focus of an EM role, let’s go through the difference between the people manager and technical manager.
People manager vs technical manager
You can’t be the best at both. There is a limited amount of time every day, and it all depends on how you spend it.
People manager
As a people manager, you spend more time growing your team, unblocking them, communicating with stakeholders, aligning with the leadership team, and ensuring your team has everything they need to be successful.
Technical manager
As a technical manager, you spend more time reviewing architecture docs and tech specs, as well as reviewing code, while contributing to the codebase as well. You’re also a lot more involved in overall discussions when it comes to making technical decisions.
Over the course of my career, I’ve seen both types work well. I’ve personally been a mix of them, and for some situations I’ve been the first one, especially when I grew to Head of Engineering, VP, and CTO.
And I’ve been the second one as a Team Lead and Engineering Manager. But as an EM, I’ve also changed over time to being more like a people manager, as the teams I led grew to be more autonomous.
So, both types can work well, but it’s important to understand that being best at both is not possible. If you spend more time on technical direction and contributing to the codebase, you’ll spend less time communicating, unblocking, and growing your people.
Now that we understand the differences, let me share my recommendation.
Should you be a people manager or a technical manager?
There’s a time and place where both are very much needed. Especially at this time, when the work is being accelerated with AI, the people work might be worth even more, because you can unblock your team to move faster that way.
The problem these days is that a lot of companies might not understand how important people work is, and are forcing a lot of managers to be more hands-on.
The problem with this approach is that it’s not what every team needs. Every team is different, and if the team is already great technically, they need more help with communicating, aligning, and unblocking, so they can move faster. In this case, you need more of a people manager.
And if the team is new and doesn’t understand the codebase well, and you potentially do, you can help the team by being more technical and help everyone get up to speed that way.
So, that takes us to the beginning of the article, where I mentioned that the goal of engineering managers is to do what’s best for the team and the overall organization.
The role of a manager is to make their team better
I definitely recommend staying technical, with no need to be the best coder, but it’s important that you understand the details. If you do, you can help your team a lot better with both wih people and tech-related issues.
And also, there’s a time and place where the team needs a certain type of a manager, so in order to help the team the most, you need to either change your manager type or hire someone else to fill the gaps.
If you decide to hire to fill the gap, that’ll take more time, but if you can fill the gap yourself, that’ll help the team a lot faster.
But this is very important to understand: the narrative that goes around these days that you need to be highly technical as a manager, is simply not true. This is a good example:
If you can enable your team of 5-8 engineers to be 20-30% more productive, that’s a LOT more valuable than just your own contribution.
If you are doing that, it’s important that you communicate your impact the right way and ensure that everyone understands how important your work is.
Individual contribution is a lot more “visible” and “tangible” by default, but the work where you multiply everyone around you is a LOT more impactful. Make sure to communicate that accordingly.
From people manager to technical manager
If you’ve been a people manager for a while, and you feel that you’ve lost a bit of technical chops, I definitely recommend getting more technical. And especially with AI-assisted engineering being the standard for building software these days, it’s a lot more accessible.
As mentioned, there’s an increase in expectation of roles such as EM, Architect, and Staff Engineer to be close together.
And that’ll only help, as when you understand the issues that your team is dealing with, you are able to much more easily help everyone to be successful.
Therefore, let me share some of the ways you can stay more technical as a manager next.
First, separate your schedule into manager and maker time
This is the prerequisite, because if you don’t do that, you won’t be able to dedicate any of your time to staying technical. You’ll end up in meetings for a whole day and being “busy”, but not really productive.
If you haven’t already, make sure to schedule focus blocks inside your calendar. I highly recommend you split your time as a manager to:
Maker time
This is your “head-down” time. Time where you focus on strategy, learning, building, reviewing, etc. There should be no interruptions, no emails, no Slack messages at that time. You, focusing on doing → that’s what this time is all about.
This time is crucial in order to stay technical as an engineering manager.
Manager time
This is the rest of the available time that you have. That’s where you have meetings, 1:1s with your team, your manager, and peers, and that’s when you are responding to Slack messages and emails.
It’s a lot harder to focus at this time, so you mostly do things where you don’t need a bigger time block in order to finish them.
Those are 2 very different ways of working, and if you try to have them together, you’ll end up context-switching constantly and draining your energy quickly.
This is how I separated the manager and maker time as a full-time CTO:
How to stay technical as an engineering manager?
Now that we have specific time blocks available for focus, let me share specific strategies to utilize the focus time as best as you can.
Building proof-of-concepts
This is what I did the most as a full-time CTO. Everytime, there was a business idea, that either I had or someone else from the leadership team, I quickly started prototyping on how feasible that would be inside our system.
That helped me to ensure I have a good view of what’s possible and what’s not, how hard it would be to develop that idea, and if it even makes sense, based on the certain tradeoffs we took in our system.
That helped me a lot to stay technical while primarily being an enabler of the team. Additionally, if I didn’t do that, I’d need to assign the PoC to someone else from the team, which would take the time away from building, and then also I’d lose out on understanding the whole system.
I highly recommend you include this as part of your process, and now it’s easier than ever with AI-assisted engineering. You can really quickly build solid prototypes, get explanations of certain parts of the codebase, and get a good idea of how feasible a certain project might be, before it even comes as a priority to the team.
Reviewing tech specs, architecture docs, PRs
And also attend the architecture/tech spec discussion meetings. It’s a great way to stay up-to-date via discussions, understand the trade-offs, and get to hear how people think about different problems.
Additionally, using LLMs to get explanations on certain topics and decisions will help you as well.
If you are a part of a smaller company, then most probably such discussions happen ad-hoc or before/after the daily meeting, which is great. But if you are a part of a mid+ size company, such meetings are organized separately, and you might need to be asked to be added.
Also, reviewing PRs is another great way to stay up-to-date. That’s also where AI can help you a lot. If you don’t understand a certain line of code, you can simply ask the LLM for an explanation.
But please, make sure you don’t generate any comments with AI. That’s a big NO from my perspective, and if I see that, the person loses a bit of credibility in my eyes. If you do a review, use AI to get the understanding and to learn, but make sure to write the comment yourself.
Contribute to the codebase on a certain project
But importantly, DON’T take the hardest tasks, as you’re going to be a bottleneck. If you try to take on the hardest and most important tasks for a specific project, you won’t have the time to properly finish them or continue to support them, which can be quite problematic.
Instead, I recommend taking on bugs, issues, small improvements, UX-related improvements, etc. Something that’s not going to be crucial for the success of the project.
As an engineering manager, what I did was take on tasks where there was something that needed to be fixed in our legacy system, while our team was working on the new system to replace it.
Build a side project
And last, but not least, now with AI-assisted engineering, you can build a quick MVP pretty quickly (of course, it depends on what you are building), but you can get something out a lot faster than it used to take.
So, that’s a great way to stay technical, especially if you build something that you are passionate about. Maybe you like basketball, football, or volleyball? Maybe you like video games, or maybe you have a certain hobby and would like to share your work online?
If you build something that you are passionate about, you have fun building it, and at the same time, you are also staying technical!
Last words
Let’s end this article with the following:
The question isn’t whether engineering managers should stay technical. The real question is: What does your team need from you right now?
Stay technical, that’s important, but at the same time, make sure to do what’s best for your team and the overall organization + communicate your impact the right way.
You got this.
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
Great read, Gregor!
Gap-filling is how I think about it too. Though if you fill a gap for too long, there's a risk that it slowly becomes your job for good. If a team is short on senior technical skills and EM keeps covering that, they're less likely to get the push to build it themselves.
For me, it works to step in when needed, but I try to be clear from the start about when I’ll step back out.
Thanks for this. I came across this at the perfect moment in my life where I’m transitioning from IC to manager. At first, I was resistant to being a manager but now I see it as engineering with people instead rather than code.