Should Engineering Managers Code?
Why I think this is the wrong question, and my suggestions on how to approach the right question
Hello Readers,
Today's article touches on a topic that is often considered controversial.
As I've been discussing it quite often lately, including responding to people quoting a few out-of-context sentences from Elon Musk's biography, I decided it it would be a great time to share my thoughts with all of you.
Let's delve into it!
First of all, let's align on what is the duty of an Engineering Manager.
🎯 The Primary Duty of an Engineering Manager
Engineering Managers (EMs) juggle many responsibilities and hats, but in my view their primary duty can be summarised as follows:
The primary duty of an Engineering Manager is to ensure that their team is always operating at its optimal state.
There is a lot to unpack there, let's break it down into components.
As an engineering manager you typically operate in these areas:
👬 People. You need to make sure you have the right people in the team, and that they are both motivated and set up for success with clear expectations and goals.
🗺️ Plans. You need good plans in place for your team at any point in time, on different time scales. Such as yearly, quarterly and weekly.
⚙️ Processes. To ensure a smooth and efficient execution, you need the right level of processes in place.
🏋🏼 Practices. Establishing good engineering practices is key to build high quality software at scale and sustainably.
🛠️ Paraphernalia. This basically means tools, but I wanted to continue with the ‘P’ alliteration. The right tools in place will ensure your team members can be productive and focus their energy on where it matters most.
Ensuring all these are in a good place requires in itself a lot of hard work.
As an EM, this is where you need to focus most of your focus and energy.
As you might have noticed, coding doesn't appear on that list.
Does that mean an EM should never code?
Not necessarily.
Before answering that question, let's first clarify what's the required technical background of a good EM.
💾 Technical Background of an EM
EMs need to be able to assess, guide and support the growth of people reporting to them. It would be very difficult to do so without deep insights and experience on how the job is performed.
Engineering Managers need to be technologists at hearth. They need to have familiarity with the types of problems their team is dealing with, and be able to speak the same language. They need to diagnose skills gaps and support their team members become better professionals.
This does not mean that they must be the most competent engineer in the team.
That might be the case in certain situations, especially with newly formed team with mostly junior members. It should only be a temporary state though.
An effective EM will make sure strong seniority is built within the team either through direct experience or external staffing.
How much technical competence is required for someone to be a good EM?
As usual, the only honest answer is: it depends.
As a rule of thumb, I generally require an EM to have attained the level of Senior Software Engineer before they can move on to the manager's track.
This ensures they are used to work with a high degree of autonomy. It also equips them with the required technical depth to be able to support their team effectively.
They should have seen enough complex cases to be able to easily identify patterns and potential approaches.
I have found this rule to be very useful, though I recommend you don't apply it rigidly and stay open for the occasional exception.
👩🏼💻 To Code or Not To Code?
Back to the core question.
Since an effective Engineering Manager is supposed to have Senior level skills and competences, should we just waste that capacity altogether by disregarding their potential contributions to the code base?
The answer to this question is mostly up to the EMs themselves. Or rather, to their ambitions.
Let's take a step back.
I believe the goal of any professional is to eventually outgrow their role. They should automate themselves out of some decent chunks of the job.
For an Engineering Manager, this typically means they will get to a point where the team is operating very smoothly with minimum maintenance.
This stage can roughly be mapped with the Performing stage of the 4 stages of a team development model.
One side effect of reaching this point is that the EM will have succeeded at freeing up a considerable amount of their time.
Assuming you've gotten to this point, now it's up to you - with the support of your direct manager - to decide how to best invest that freed up time.
You can choose between two main avenues: coding, or picking up more responsibilities.
The choice isn't trivial, and is not without long term implications.
⌨️ Spend time coding!
You have reached the point where you can responsibly dedicate 10% to 20% of your time coding.
You feel the excitement of getting back into an area where you find peace and comfort!
Before you get too worked up, make sure you set some useful rules for you and the team.
My recommendation would be the following:
You should prioritise the well functioning of your team over any coding work. This is the most important rule, everything else is a side effect of it. Say it out loud before moving to the next point. I mean it.
You should be able to drop any ongoing coding work at the first sign of stress on the system. This is what prioritising your team means. Not “I'll deal with that fire once I'm done with this PR”.
Your team should not make assumptions on your contributions, and not plan with your added capacity in mind. Your ability to code will fluctuate a lot from one week to another, often unpredictably.
Don't assign to yourself tasks or features that are in the critical path for delivery. You don't want to be the one accidentally causing an important release to be delayed. Seriously.
If you follow these rules very closely, you should be able to find a good balance between managing the team and satisfying your inner need to continue coding part-time.
This will not be without frustration though as you know that coding requires long stretches of uninterrupted focus, and it's unlikely you'll be able to find time for that on a regular basis. It's more likely that you will be able to free up one hour here and there than three to four hours in a row. You are welcome.
If you are still inclined to go down this road, be mindful that it will not be without implications.
That's because you could instead decide to invest that time on something else.
🪴 Take on more responsibilities
Instead of going back to the comfort of dealing with code, you can decide to take up more leadership duties.
You can start by picking up some responsibilities from your manager. Ask them what areas they'd be happy to delegate to you, and pick one.
The exact details will vary depending on your situation, but some of these could include:
Help running some cross-team activities.
Work with the broader engineering organisation to improve certain practices or processes that would benefit multiple teams.
Take ownership of a new important initiatives that your manager doesn't have the bandwidth to kick-off
This will give you an opportunity to stretch your skills and learn new ones. You will also signal to your manager and to the organisation that you might be ready to move on to a new role, which often means a promotion. 🎉
⚖️ Time to make your choice!
Instead of asking yourself if should code or not, my recommendation is to ask a different and more important question: what's your long term ambition?
I don't expect you to predict the future, and your plans might and will likely change over time. At any point in time though you should have a clear goal you are working toward. A goal that you can re-evaluate on a regular basis.
If you're an Engineering Manager, I can see two main directions you might want to follow:
You want to grow into more senior leadership roles. It this case, I honestly believe coding will be a waste of your time and energy. Coding will not help you reduce the gap between your current job and the job you aspire to have in the future. There is nothing bad in coding per se, and indeed you might want to continue practicing it in your personal time. If you want to aim for senior leadership roles, you should invest your time and energy in developing other skills.
You are comfortable as an EM or are considering moving back to the IC track. In this case coding might be the ideal choice. Just make sure that you're not operating in a company that applies a strict Up or Our approach to career development. Also make sure you don't end up in a limbo where you want to keep the two options open forever. Indecisiveness is the best way to undermine progress.
The choice is yours, but I recommend you evaluate it thoroughly and are able to weight short term comfort against long term growth. As it turns out, these two concepts are often at odds, and this is no exception.
👋 Conclusions
The question on whether or not an Engineering Manager should code is the wrong question.
The right question should be around their growth ambitions.
If you're facing this dilemma, here is a useful flowchart you can use to guide your decision making process. I hope the dryness of a flowchart will help with rationality and with keeping emotions at bay:
To summarise it in 3 simple steps:
Make sure you team is operating as close to perfection as possible, then
If you want to grow into senior leadership positions, forget about coding and focus on leadership skills;
If you instead are comfortable being an EM for a long time, or are considering a move back to the IC track, then coding is a good use of your time. But probably not for too long.
I hope this helps!
I know this is a topic that triggers a lot of strong reactions and heated debates.
I invite you all to share your thoughts in the comment section!
Until then, see you all next Wednesday!
I like your point, and the most I like was your recommendations about spending time coding.