Should engineering managers be technical?

Originally published in Medium

I spent the better part of two decades as an individual contributor on teams resisting the management career change until I felt I was ready. So, this is a question I can directly relate to. I’ve mentioned this topic before. I’ve seen this come up a lot lately in industry circles so I’ll share a few more thoughts. Charity Majors has written a great article capturing many of my thoughts.

https://leaddev.com/personal-development/should-engineering-managers-be-technical

My experience at smaller companies tends to be that the managers were at one point in time technical. Not always, but was typically the case. In larger companies, the difference between technical background or not was much larger.

I’ve experienced examples of people being at the company from the time they graduated university to tens of years later and they transitioned to a management career path after only say five years. In my opinion, this is too early. But hey, some desire, and may even be taught, that the only thing that matters is climbing the company ladder. They tend to not be good managers. Their motivation isn’t to be a good manager, it’s simply to climb. Spoiler: they typically plateau due to not having discernible skills.

I don’t believe anyone five years into their career knows how they fit into a company at a macro level and shouldn’t be managing other people’s fit into a company either. Let’s grab a quote from Charity’s article to explain why.

“

“You need to be able to look at a team that isn’t shipping very fast and figure out whether it’s because of under-skilled engineers, legacy code, a weak product culture, a leaky CI/CD pipeline, or a team that has given up and lost confidence in itself. And then you need to start influencing people to do things that visibly and materially improve the system.” - Charity Majors

”

In my experience, I don’t think many engineers just five years into their career will know how to approach a weak product culture or be able to fix something technical like a leaky CI/CD pipeline. That is not a knock against anyone. I wasn’t able to just five years into my career. We all have long careers, why the rush to become “senior” or “manager”? One reason is that consulting agencies can charge clients more per hour for a “senior” whomever, so as an industry we have people launched into the senior echelons as early as possible. I digress, but becoming senior in a short amount of time seems disproportionate to the length of many careers. Without the experience of fixing the CI/CD pipeline or recognizing the stressing of your existing senior engineers with responsibilities like mentorship because the team is more junior than senior, how can you help the team achieve it’s responsibilities to the company overall? You may be a great engineer and a quick learner, but early in your career you lack the experience of “working” in a company. Looking back, I certainly did and I think others with decades of experience would agree. Understanding fit. Understanding priorities and politics. Understanding personal growth. It’s not a good idea to be responsible for others, when you yourself don’t have the understanding (yet), no more how much that “promotion” looks attractive. How many times have you been hired and fired? If the answer is only the one time you’ve been hired, how are you then going to be responsible for hiring and firing others?

Let’s play this out a little with some scenarios. Say after a few years, you’re asked to take on manager duty. Your team is small, but is responsible for something critical like QA. You have a few senior QA engineers and they are all productive in the test suite they’re intimately familiar with because they were around when it was started. Now, the company decides they are going to spin up a few new feature squads. Guess what, you now have more to QA! Do you recognize the dependencies on your team? Do you know how to articulate that you need to grow in relation to the feature teams? Is your assumption that you need to have more senior QA engineers? Is this an opportunity to hire less experienced engineers? If so, do you have the foundational pieces in place to make them successful? What will onboarding looking like? Do you know how to conduct useful interviews? This example seems relatively plausible in many companies. I would not have known how to handle all of these scenarios five years into my career. After torching the team for a few months resulting in burn out it may have become obvious that the QA team needed to grow to cover the responsibilities, but after burn out it is too late. You haven’t “managed” your team.

Back to the topic of being technical, I’ve written before that I think it is beneficial. Agreeing with Charity, maybe not crucial, but I believe that understanding the hardships of your team because you’ve experienced a complicated Jenkins pipeline (what Jenkins pipeline isn’t complicated, am I right?) helps you prioritize the things needed to enable your team to accomplish their tasks. In the example above, you would have the technical know how to conduct proper screens of candidates before wasting your teams time on interviews. Protip: senior team members hate, with a cold hearted passion, conducting clearly unnecessary interviews. Understanding the nature of the test suite and who could contribute requires some technical knowledge and experience in my opinion as well. These might blur the line between social and technical skills, but I believe they lean more technical.

“

Good engineering managers have both social and technical skills, and they take an interest in the personal development of their engineers (or support their very senior engineers). - Charity Majors

”

Plus one to that! It’s key, but can be damn hard given the organization you’re in. This may fall into the bucket of “transparency” in some organizations. How much can you let your team know about as their manager? Not that you’re hiding things, but properly setting expectations on how much you can actually control personal development might be the best thing you can do. I’ve been in organizations where the manager wasn’t able to “promote” an engineer. As a manager, you elected someone for a promotion on a schedule (once a year). Then some far off committee decided based on budgets and other unfair factors who from the large list actually received a promotion (title and/or compensation increase). Needless to say, it was hard to be a manager responsible for personal development when you felt you couldn’t recognize growth other than saying “you’re doing a great job” in a one-on-one. Obviously, you should do that, in explicit detail, but it’s nice to be able to back it up with public recognition. Not having that control or even the influence over it, doesn’t meet most people’s expectations of their manager. Managing your organization’s process is now another thing to add to your plate. Lucky you!

“

This is the ideal situation for a team: to have a technically-skilled manager who can weigh in but knows their boundaries - Charity Majors

”

Plus one to that as well! Charity is on a roll! Without the proper technical background how do you know your team is painting the entire picture? Without understanding what a test suite should cover, can you help ensure that you have adequate coverage? Without understanding deployment and observability strategies, can you help the team successfully ship? Without understanding data models, can you help the team set a proper foundation to build off of in the future? Sure, tech leads or other senior engineers can help make all of these decisions but if you don’t know what questions to ask because you’ve been there, you may miss a critical opportunity. If you’ve never been on a support rotation, can you understand why it takes so long to hunt down a production issue?

“

Now I know how Joan of Arc felt - Morrissey*  This is important, because your manager is going to inevitably ask the dreaded question: “what is taking so long”? In the insightful words of Morrissey “Now I know how Joan of Arc felt”. When you’re getting interrogated asked to explain an outage or production issue or timeline, you’ll be able to speak and represent your team well. Like Charity mentioned, you aren’t making the decisions, the team is, but you need to be informed.

”

Note, being informed doesn’t necessarily mean that you are contributing to the code base or system on the regular. Maybe you are, but not in the feature sense. Maybe you are adding some logging so you can improve observability needed during the last support issue. Maybe you are building a dashboard fulfilling some Product requests and need to add instrumentation here and there. Again, the point being, having technical skills allows you to get your hands dirty and be informed. Not to mention, relatability. This might be underrepresented in everything I’ve read on this topic. Personally, I would feel really uncomfortable leading a team and not understanding what they are generating with their keyboard. On top of that, I would expect them to have feelings of unrelate-ability. Like Charity said, put yourself on a support rotation, open a few PRs and go through the process. Be familiar with the frustrations of the teams day to day, but remember the purpose is to be informed so you can represent the team and prioritize the essentials needed to enable the team to ship.

Hopefully you aren’t labeling me as ageist. I’m certainly not trying to be. I’m simply projecting my self-reflection on my career thus far. Like I said in the beginning, I resisted making the career change to management. I was asked a few times if I wanted to pursue it, but I said no. I didn’t think I was ready. Partially because I still really enjoyed building things and knew that as a manager that was not going to be my primary responsibility. I was right, but I eventually thought I had enough experience to help teams accelerate. The desire to be on a well-performing team outgrew my desire to spend more time inside VIM. I’m not saying everyone should follow my same path or wait until they have nearly two decades of experience before making the change. However, I’m sharing some of the scenarios where I would have fallen down and let my team down, should I have been a manager without the experience I felt was sufficient.

Lastly, to bluntly answer the question this article addresses. Yes, I think it helps to come from a technical background if you are going to be the manager of a team of engineers and from my experience, engineers agree with that.

• Being burned at the stake is an unfair comparison to being asked questions by upper management, but it can feel that way sometimes. Unless you are responsible for curing cancer, try not to let it. Some organizations make production issues and timelines feel as important as curing cancer, they’re not. You aren’t being burned at the stake. This too shall pass.