On Being a Technical Manager Beyond Coding
Navigating technical leadership without writing code
I recently finished reading the book Designing Data-Intensive Applications by Martin Kleppmann. It's a must-read for any software engineer or technical leader who takes seriously their career. The book provides an excellent overview of modern data engineering and distributed systems.
Reading this book has been like connecting the dots of my 20-year career in software engineering. It explains the fundamentals of various tools and technologies that I have been fortunate to work with, such as PostgreSQL and MySQL (relational databases), Redis and CouchDB (NoSQL data stores), and RabbitMQ and Kafka (message brokers), among others.
I find reading specialized books like the one just mentioned, technical papers, and weekly newsletters from the industry's top engineers and technical leaders critical for my profession. It helps me stay up-to-date with the latest software architecture and system design trends in my field, enabling me to provide better support to my leaders and make informed decisions in my day-to-day work.
Yet, as a manager of leaders (tech lead managers and staff engineers), I no longer write code at work, nor should I do so, except for tasks outside the critical path. When I write code, it's usually for pet projects outside of work. However, despite being a bit rusty at coding, I still consider myself a solid technical manager. Allow me to explain why.
What does being technical mean as a manager?
In software engineering, many people associate being technical with being hands-on, such as writing code, reviewing code, deploying, testing, etc. That makes perfect sense for individual contributors of almost all levels (except those ivory tower architects).
However, being technical as a manager can mean something other than being hands-on. Your responsibilities and priorities change as you move up the ladder from an individual contributor to a tech lead manager or an engineering manager. You no longer need to prioritize hands-on work like coding. Instead, your focus should shift towards empowering your team to execute well and deliver.
The best technical leaders I know have a solid engineering background and diverse technical skills, including software architecture, system design, and problem-solving. They understand complex systems and are up-to-date about the technological landscape.
Will Larson had an excellent point about this topic in his article Do engineering managers need to be technical? And what do we even mean when we say "technical"? In my opinion, being a technical manager means having a comprehensive understanding of the technical aspects of the work while excelling in managing teams and projects, leadership, communication, and strategic decision-making.
Interview story time
A few years ago, I received a message from a popular Big Tech recruiter. I occasionally got those emails since I established a decent network of connections while living in London. This time, they sought a Senior Engineering Manager to lead a large team of remote engineers. Here's how the conversation went:
Me: "Will this role involve hands-on coding?"
Recruiter: "You won't have much time for coding. However, you'll have to pass a live coding test. Our managers, regardless of their level, are highly technical."
After the call, the recruiter emailed me some helpful guidelines for preparing for the interview. I couldn't believe what I was reading:
"We suggest completing 30 'medium difficulty' leetcode challenges before the initial coding interview and 100 in total before coming onsite."
Wait, was that supposed to be a joke? Unfortunately, it wasn't. It's not bad advice if you want to have a chance at getting a job in a FAANG company. And some engineers will spend six months or more of their lives leetcoding. I understand why they would do so, as it could be a good career investment. However, if you already know me, you know that I'm not willing to put myself through that. I refuse to participate in any live coding interviews.
Should managers write code?
The real question is not whether managers should code but at what level they should stop coding. That's a better question!
If you are a Tech Lead Manager (TLM) who leads a small team of engineers, you probably want to be hands-on as it will benefit you and, ultimately, your team and organization in several ways:
Understanding technical challenges: Coding experience helps managers understand technical challenges and provide better guidance to their teams.
Communicating effectively: Managers and engineers should speak the same language to communicate technical aspects, roadblocks, and solutions.
Gaining respect and credibility: Coding experience enhances a manager's credibility and builds trust among the engineering team, making it easier to lead effectively.
Handling crises: Coding skills can help managers address crises by troubleshooting and finding quick solutions.
However, suppose you are an Engineering Manager (EM) responsible for managing a large team of engineers or multiple teams. In that case, you must prioritize high-leverage tasks over being hands-on coding for the right reasons:
Focusing on leadership: As teams grow, managerial responsibilities become more complex. Coding can divert attention from crucial leadership tasks like strategic planning, team development, and communication.
Avoiding the risk of micromanagement: Managers who extensively code may micromanage, hindering team autonomy, demotivating engineers, and stifling innovation.
Managing time effectively: Coding requires time and concentration, and managers have other responsibilities that may interfere with their leadership duties.
Focusing on strategic thinking: Leadership roles require a strategic mindset. Managers must focus on the big picture, aligning technical efforts with organizational goals. Overemphasis on coding may limit their capacity for strategic thinking.
In any case, remember that being a successful manager requires more than just technical expertise. Good managers effectively manage teams, run projects, coach employees, design systems, and communicate with other teams and customers. They provide guidance and vision to their team and can get the best out of themselves and their team. They act as a force multiplier, clearing obstacles and tirelessly boosting their team's efforts. Being an effective manager requires dedication, influential communication, an understanding of human psychology, organizational dynamics, workflow principles, leadership techniques, and strategic thinking, at the very least.
"Stop writing code and engineering in the critical path [as an engineering manager]."
— Charity Majors, Engineering Management: The Pendulum or the Ladder
Concluding thoughts
I firmly believe that managers should be technical, although the definition of "being technical" can vary among individuals and organizations, as we have just seen. For me, being a technical manager extends beyond coding.
It's undeniable that the more distant you are from the code, the more challenging it becomes to stay hands-on. As a line manager, you can take specific measures to maintain your hands-on skills. However, as you transition into a manager of managers, it's vital to recognize that opportunities for hands-on involvement will significantly decrease—an inherent aspect of managerial evolution.
The positive part is that there are numerous strategies to remain technical as a manager. In this post, I've shared some of my favorite methods, and I plan to explore even more techniques in a future article to help managers stay technically sharp.
Do you agree with my definition of being technical as a manager? How do you stay technical? Let me know your thoughts.