Should you Stay Technical as an Engineering Manager?
Navigating the Balance Between Engineering Management and Technical Expertise
During my first year as an Engineering Manager, one of the things I struggled with the most was the growing pain of not having enough time to keep up with all the technical aspects. Even more so, I had no time to write code and play with systems like I was used to when I was an individual contributor.
Reflecting on it today, I recognize that these were all natural feelings. However, I still remember that period as particularly stressful, and it took me quite some time to make the mental switch from being someone who was building things to someone who was leading and managing people who were building things.
But in the end, after many years, did I manage to stay technical? And for you, as an engineer growing into leadership positions, should you stay technical? Should you still write code or be hands-on?
I frequently receive these kinds of questions from other engineers or first-time EMs who are struggling with similar issues. While many have written and still write about this topic, I always see two factions:
The Managers’ Ambassadors: those who advocate that a manager should primarily focus on their people and delegate all technical responsibilities to engineers.
The Engineers’ Ambassadors: those who argue that managers should remain hands-on; otherwise, they risk losing the ability to lead engineers effectively and may become ineffective.
As with many other topics in the engineering journey, I believe it’s more complex than that, and in today’s newsletter, I’ll delve deeper into these concepts, trying to answer the questions above.
Before beginning, let me introduce a new sponsor that I'm honored has decided to support the newsletter.
CTO Craft Con: London 2024 (Sponsor)
Following two sold-out conferences in 2023, CTO Craft Con will return to London on May 8-9th, welcoming over 500 CTOs and aspiring technology leaders.
Early Bird tickets are on sale now. The CTO Craft team has kindly provided me with a promo code (HH10), so you can get an additional 10% off your ticket.
CTO Craft has a global community of over 8,000 members, of which I’m proud to be a part. It offers a safe space for tech leaders to find connection, and it’s totally free to join!
Find out more: https://ctocraft.com
👨💻 Staying Technical vs Being Hands-On
Before diving into what an Engineering Manager or someone growing from an Engineer to a leadership position should do, it's important to understand the difference between staying technical and being hands-on, since they are often confused.
Staying Technical refers to maintaining knowledge of technologies being used in your environment and understanding how things work, even if one is not directly involved in technical tasks.
Being Hands-On means actively engaging in technical work, such as coding or building systems, and working directly with technology.
Looking at these definitions, we already somehow have the answer to our first question:
Should an Engineering Manager stay technical?
Yes, I can confidently say that an Engineering Manager, like a Tech Lead, but also a Tech Director like I am today, should stay technical. We will discuss the reasons, methods, and necessary depth of technical knowledge later.
However, what is less clear, and often a subject of debate, is whether these roles need to be hands-on.
Generically speaking I’d answer with the following graph.
So, while the need to stay technical as you progress into leadership roles remains high and constant, there's a notable decline in hands-on involvement. However, as is often the case in the engineering world, this is generally true but comes with exceptions.
Who Needs to Be Hands-On?
I see two scenarios where it makes sense for an Engineering Manager to take on hands-on roles:
Small Startup: in the startup world, it's quite common to encounter smaller engineering teams, often led by a co-founder or an early member who takes on the role of EM. Given the nature of startups, it can be practical for such roles to be hands-on, especially when the team is small and there may not be sufficient resources dedicated only to managing people.
Forming Stage of a Team: when a team is in its early stages, much like in a startup, a high level of contribution from EMs is crucial. Therefore, during the initial phases of team formation, it could be beneficial for an EM to spend time on hands-on tasks.
In most other situations, I believe that being hands-on as an Engineering Manager is less justifiable and can even lead to delays or other kind of issues.
As a team expands and becomes more structured, the role of an Engineering Manager should increasingly move away from hands-on activities.
Criticisms of Not Being a Hands-On EM
While scrolling through LinkedIn, Reddit, Hacker News, and other platforms, you often come across threads where engineers criticize EMs for not being hands-on.
Let's explore some of these criticisms and attempt to debunk them.
If you're not hands-on, you can't make technical decisions because you don't understand what's happening in the software.
I believe this statement is not only inaccurate but also represents the wrong approach. The era in which the manager makes all decisions has, in my opinion, passed. I prefer to make technical decisions collectively by listening to those who are on the front lines every day. To achieve this, an EM simply needs to grasp the overall picture to effectively guide these types of conversations.
If an EM is not hands-on, they won’t be able to ensure developers are doing their job.
Once again, I believe the concept of one person "controlling" others is somewhat outdated. Developers and system engineers should feel a sense of ownership over their work, and the team should collectively maintain high standards and self-regulate from a technical standpoint. While this needs a highly cohesive team, in other scenarios, the EM can rely on Tech Leads or experienced engineers through delegation, without needing to be hands-on.
If an EM doesn’t remain hands-on, they risk losing touch with technology, which could be detrimental to their career.
I've been there, and this feeling is absolutely legitimate. However, while the “hands-on decay” is inevitable as you progress in structured leadership positions, it shouldn't be a big concern if you remain technical and approach it the right way. Though it may take some time, if you stay technical throughout your career, when you eventually decide to switch back to a hands-on position, it will be much easier.
🛠️ Staying Technical as an Engineering Manager
We've discussed the difference between being hands-on and staying technical, and why as EMs, we should prioritize the latter. But why is staying technical so important for EMs and engineers who hold leadership positions?
Here are a few reasons:
💡 Understanding Challenges: staying technical helps you understand the challenges that your team is facing and guide them through finding solutions.
🗣️ Speaking the Same Language: effective communication with your team is crucial, and speaking the same technical language facilitates this.
📈 Making Informed Choices: remaining technical as an EM enables you to participate in technical decisions and make informed choices.
🤝 Building Respect: while respect should always form the baseline of your team culture, especially during technical discussions, engineers tend to have a special appreciation for other engineers.
📚 Continuous Learning: staying technical encourages ongoing learning, which can be immensely beneficial for future career changes.
🧭 Guiding Growth: you can better plan how your team can learn and improve their technical skills by staying technical yourself.
How to Stay Technical
There are multiple ways of staying technical within your domain, but before delving into them, I believe it’s important to spend a couple of words on how to structure this continuous learning path, which, in my opinion, is officially part of every EM’s duties (do you remember The Good Engineering Manager Framework?).
One good strategy I've discovered and continue to find valuable is to commit part of your weekly time to staying technical. I believe a good balance between your managerial duties and keeping up with technical aspects is to dedicate 20% of your time to learning and getting involved in technical matters.
So what I regularly do is allocate 8 hours a week to activities that help me stay technical, while the remaining 80% of my week is dedicated to pure managerial duties.
This ratio can vary based on your specific needs, but I've found it to be a useful guideline.
Let's now explore some activities that can help you maintain your technical skills, along with their benefits and effectiveness.
🤝 Join Tech Meetings
There’s no better way to stay technically active than by immersing yourself in tech discussions and developments. Technical meetings offer this opportunity, and as an EM, you should always try to attend them. Even today, as a department director, I still join some technical meetings. While I often listen more than speak, they remain a valuable way to cultivate my technical knowledge.
💡 BENEFITS:
You stay up-to-date and learn new technical concepts.
Demonstrates your interest and participation to your team.
Helps you stay informed about what’s happening within your team, reducing the need for constant updates.
EFFECTIVENESS: 🟢🟢🟢🟢🟢
📝 Contribute to Documentation
Writing is one of the best ways to solidify concepts and learn new things. It forces you to think critically, simplify complex ideas, and gather any necessary information you might lack.
💡 BENEFITS:
Contributing to documentation produces tangible results, giving a sense of accomplishment and showing your commitment to the rest of the team.
Helps alleviate some of the burden on your team by assisting with documentation tasks.
EFFECTIVENESS: 🟢🟢🟢🟢🟢
🛠️ Build Internal Tools
Being less hands-on doesn’t mean you can’t code during your "stay technical" time. I recall when I was an engineering manager, I built a Slack bot to manage incidents during my learning time. It was built in Python and API-first, aligning with the stack we used for other projects.
💡 BENEFITS:
Allows you to create something useful that saves time for your team.
Keeps you engaged with coding and may utilize the same tech stacks as production projects.
Building something always feels rewarding.
EFFECTIVENESS: 🟢🟢🟢🟢⚪️
🎤 Present what Others are Building
While not always a favorite duty, presenting what your engineers are building is an effective way to stay in touch with technology.
BENEFITS:
Similar to writing documentation, it requires you to understand and simplify concepts for your audience.
Showcasing your team's work to upper management or the rest of the company boosts team morale and success.
EFFECTIVENESS: 🟢🟢🟢🟢⚪️
💡 Build Side Projects
While not always easy to pursue outside working hours, building side projects or contributing to open-source projects can be highly beneficial for staying technical. These projects don't necessarily have to be complex products; even simple initiatives can be valuable. For instance, given my teams’ focus on Kubernetes, I maintain a small personal cluster to host my blog and a few other applications. While this doesn't mean I'm ready to manage production clusters at an expert level, it does allow me to experiment with new stuff and stay fluent in the technical language my engineers use.
BENEFITS:
Allows experimentation with new technologies that sometimes are not easy to test in the workplace.
Keeps coding/system engineering skills sharp and exposes you to other essential areas like product and marketing (in case you have to promote your side project).
EFFECTIVENESS: 🟢🟢🟢🟢⚪️
👀 Participate in Code Reviews
Participating in code reviews keeps you updated with the codebase and engineering practices while providing mentoring opportunities. However, it can be time-consuming and occasionally slow down team progress.
BENEFITS:
Helps you understand your team's progress and the codebase they're working on.
Fosters connections with your team and positions you as a supportive resource.
EFFECTIVENESS: 🟡🟡🟡⚪️⚪️
🎙️ Join Tech Talks and Conferences
Attending tech talks and conferences, either as a participant or speaker, exposes you to new technologies, methodologies, and industry trends.
BENEFITS:
Keeps you updated with industry trends.
Improves public speaking skills and facilitates networking with peers.
EFFECTIVENESS: 🟡🟡🟡⚪️⚪️
👩💻👨💻 Pair Programming
Occasionally pairing with team members can keep you engaged with the codebase, help learn new techniques, and understand daily challenges. However, it can be time-consuming for team members.
BENEFITS:
Keeps you connected with the team and their projects.
In some critical situations you could act as a backup.
EFFECTIVENESS: 🔴🔴⚪️⚪️⚪️
📚 Online Courses and Certifications
Enrolling in online courses or pursuing certifications can complement hands-on learning, though it may be time-consuming and not always directly applicable.
BENEFITS:
Provides formal recognition for your skills, which can be beneficial for future career changes.
Some courses or certifications may include practical exercises that help maintain hands-on skills.
EFFECTIVENESS: 🔴🔴⚪️⚪️⚪️
📖 Read Technical Books
While reading technical books can provide different perspectives, it may not be as impactful without the opportunity to apply what you've learned.
BENEFITS:
Requires minimal time investment and can be done anywhere.
Can offer inspiration and new viewpoints.
EFFECTIVENESS: 🔴⚪️⚪️⚪️⚪️
These are just some suggestions on how you can remain technical as an EM or someone covering even higher leadership positions. After years of following these practices while holding leadership and managerial positions, I can confidently say that I was able to keep up with technology.
Does this mean I would pass an interview today to become a Senior Software Engineer or a Cloud System Engineer? To be completely honest, probably not. However, I am fairly sure that it wouldn't take much effort to fill my gaps, because I consistently kept up with training my general technical knowledge.
In other words I stayed technical.
🏁 TL;DR
Today we went through many different concepts, so let’s summarize the most important ones:
For engineers transitioning from individual contributors to leadership roles is natural to face challenges in maintaining their technical skills.
“Staying technical" (maintaining knowledge of technologies and understanding technical processes) is different from being "hands-on" (actively engaging in coding and system building).
The need to be hands-on decreases with leadership progression, except in specific scenarios like small startups or during a team's early stages.
Staying technical is crucial for EMs for understanding team challenges, making informed decisions, and communicating effectively with the team.
Dedicating 20% of weekly time to technical activities to stay technical is a good balance.
Suggested activities for staying technical include:
Joining technical meetings to stay up-to-date and engaged with the team.
Contributing to documentation to solidify understanding and assist the team.
Building internal tools to maintain coding skills and create useful resources.
Presenting team projects to understand and simplify technical concepts.
Participating in code reviews to stay connected with the codebase and team.
Engaging in continuous learning through attending tech talks, conferences, and online courses.
📢 Weekly Findings
These are some interesting articles I read this week.
Sign Posting by
: a very interesting article that teaches you how to use “sign posting” to deliver complex ideas to your readers.You are hurting your team without even noticing by
and : honest stories about how managers’ ego can hurt their teams.2024 Guide to Mentoring for Software Engineers by
: a comprehensive guide to become a mentor.
✌️ That’s all folks
That's all for today! As always, I would love to hear from my readers (and if you've made it this far, you're definitely one of the bravest). Please don't hesitate to connect with me on LinkedIn or Twitter and send a message. I always respond to everyone!
Thanks for the great summary! I really like the separation between hands-on and technical, and agree with you on your assessment that engineering leaders should remain technical during their careers to be effective.
When I have this question asked from me by entry level Engineering Managers, or developers considering the leadership path, I answer with the impact aspect. How can this person have the biggest impact for the team and the organization - sustainably, in the long term? The answer is different for everyone, and can change in time, but this mindset helps deciding where one should spend their time.
One risk I saw in some senior engineers turning into managers is that in challenging times, when the team doesn't deliver or struggles with other issues, they fall back to rely on their comfortable knowledge and double-down on hands-on contributions. Thinking about the impact aspect can help them understand that they need to focus on learning how to get results through others, even if it's outside of their comfort zone.
Another important aspect is motivation. There's a huge difference between "coding because my team needs an extra pair of hands to meet deadlines" and "coding because I want to understand the real developer experience so I can prioritize actions to improve it". The former is firefighting, the latter is fireproofing your house.
So, like most things in life, I think ultimately the answer to the question depends on many things: the manager, the team, the organization -- and it can change in time.
Very thorough, as usual. I loved the 20% time-aside part. I try to follow a similar approach, of 40% of my time set aside for technical tasks - in my case, as I lead a smaller team, I go for hands on tasks, as part of the team's sprint.
In my opinion, a part that was missing in the 'how to stay technical' part is the hands on tasks, if you decide to take them. WHICH ones to take makes a huge difference.
There are various approaches:
1. Doing the tasks that you feel comfortable with (easiest choice)
2. Going with small tasks like bug fixes, not being a critical part of the delivery
3. Doing things that can teach you something about what your developers are going through.
I think that in addition to the great ideas you mentioned for staying technical, once in a while it's worth developing something for the company. Seeing the state of the CI/CD, the local environment process, working with feature flags/ A/B tests and so on. This can highlight some areas that you need to improve in your company, and also bring your closer to the teams.