Should Engineering Managers know how to code ? Should they code as part of their job ?
oh boy
TL;DR: Yes to knowing programming if they manage a team of engineers, but they won't have time to code. BUT - this is not a good question, the real question is What makes an Engineering Manager successful at my company ? The answer is: clear expectations and career path describing impact and expected outcomes.
In the last 2 weeks or so the question above appeared on mentoring sessions with people of diverse backgrounds. I think that happened because Elon Musk tweeted:
I'm not a fan of Elon's smarts. Also, why these kinds of comments always comes with military analogy ? Coding, engineering, product development and so on have little to do with war. Teams as we know have little to do with armies too. It is all more or less like the kitchen of a really busy restaurant and… ok, no analogies.
I think I understand why this tweet sparkled these questions. I deal with people that moved recently from programming to management. And sometimes when the going gets rough, they miss their (perceived) sunny past (a bias known as Rosy Retrospection). Asserting that they need or don't need to know coding to do their job becomes some kind of defense for other things that may not be working right.
At some companies, there is no clarity of what is expected of a manager - project, program, product and engineering managers may overlap in their attributions and will answer the title question in different ways.
My personal view about Engineering Management is that you won't be able to manage what you don't know. I believe that anyone can learn how to code, build systems and run them. I also believe that everyone can learn to manage and that's no magic skill either.
Given the above, the best scenario when moving to management is that you have a progressive change as splitting your responsibilities (not doubling them) between management and technical duties. That will push you out of coding real fast because
1) You don't want to burn out committing to double shift.
2) You won't block your team just for the sake of proving you still technically relevant but not delivering what you promised because you are busy elsewhere
3) You won't have that much time to code but you will find that you can support your team technically in many different ways (reviews, RFCs, stakeholder management, incidents and culture)
We good ? All right ? Not yet.
It is interesting to look at more traditional research about the manager/team relationship. Harvard Business Review published an article titled "If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work" that explores surveys about employee happiness and productivity based on being managed by someone that understands what they do. Google's re:work states that managers have ""key technical skills to help advise the team".
That said we can't compare managers across companies in an easy way. There are companies where the managers are project managers - it doesn't matter how you do it, only what and when. Other companies’ managers are engineering managers, accountable for quality, onboarding and design - the How and the What - sometimes the When. If you cross the beams - hire project managers on engineering heavy teams or engineering managers at process heavy companies - that will go sour real quick.
If we read on the Harvard Business Review research, it is inevitable that in some place up in the hierarchy there will be someone that won't understand what you do. In both scenarios I've described above, managers coming from a technical background may feel that their peers are “faking it”. Managers from delivery and project management background will think their technical peers are spoiled. But if the person up the chain doesn't understand one of these well, they will make it all worse by bringing in the consultants to understand why quality or velocity is suffering.
So I think that my answer for the title question is that it is not a good question. The missing piece is what makes an Engineering Manager get their work done, given a company culture, needs and product, so the question should be "What makes an Engineering Manager successful at my company ? ”. If you only lean heavily on code outcomes for a manager, you will miss the big picture. If you leave that behind, you will lose on team support and guidance. The CTO can't stretch that far on a medium sized company.
To support this question we need to use company values, expected outcomes and a clear career path mapping impact/blast radius, execution, communication and leadership examples. This is called a “Career Ladder” and we usually spend so much energy doing it for engineers that we forget to do for managers/directors/VPs.
If you never saw one of these, you can check my example at this link which define Engineers and Managers levels ordered by impact - meaning where the work creates most of the visibility. This is the baseline to start a career ladder because it will imprint what is important for your company regarding individuals.
Then you should check Rent The Runway Engineering and Management tracks for comprehensive examples and engineeringladders.com example of Tech Lead versus Engineering Manager career focus. Tech leads are usually the start of the career pendulum, where an engineer can start moving their effort from coding and leading to managing, always depending on the company culture of course.
After that we want to be able to describe “What makes an Engineering Manager successful at my company” with clarity and ways that they really have success and don't waste energy hating each other for faking or being spoiled.
Hey, I've just published a book called “The CTO Field Guide” that can be found at https://ctofieldguide.com. If you are changing careers, got a new job or want to read on about company organizations, metrics and how to get started, check it out !