When should engineering managers write code?

Many engineers who make the transition to a management role face a bit of a conundrum – if I stop doing hands-on work, my team will lose a strong engineer and instead will gain an inexperienced manager.

When I became a manager three years ago, this thought kept popping into my head, especially in the first few months, and breaking out of this mindset was one of the biggest challenges in my transition from maker to manager.

When you become a manager, you need to be more deliberate about how you spend your time – after all, you will suddenly have way more tasks on your plate, including overseeing your reports, engaging with company strategy and helping craft the product roadmap. Therefore, coding activities may become a distraction from what is really important in your new position.

“Not only do you get more empathy for your reports, but you also develop a deeper and more practical understanding of their work”

However, engineering managers who, every now and again, allow themselves to do some hands-on coding work usually see a few benefits:

• Increasing empathy: Spending time writing code can reinforce this crucial managerial skill, as it helps you better appreciate the challenges faced by your reports.
• Developing deep knowledge of your reports’ work: Not only do you get more empathy for your reports, but you also develop a deeper and more practical understanding of their work, enabling you to better manage their workload and project timelines.
• Maintaining respect: When your reports see you’re willing and able to do coding work, it can help cultivate and maintain their respect in you as a manager.

Depending on your circumstances, you’ll get different mileage out of these benefits. But if we can agree that engineering managers should not entirely give up hands-on work, the real question to be asked is not if engineering managers should write code, but when should they write code, and when should they avoid it. Here are some simple guidelines I like to consider when I’m tempted to dive in and get my hands dirty.

When should you write code?

When onboarding in a new team

When I joined Intercom, my manager asked me if I wanted to onboard as an engineer or as a manager. My answer was instant: I wanted to onboard as an engineer. I felt that if I worked as an individual contributor first, I’d be able to get quickly acquainted with what my team was working on and would get a good sense of the challenges and technical debts they were facing daily.

After two months working as an engineer, I felt that I was thoroughly prepared to begin my journey as a manager, with way more context and knowledge about Intercom and my reports’ work was than if I had put that early focus into management.

Code reviewing pull requests

In my experience, writing code takes about 20% of an engineer’s time whereas reading code takes up the remaining 80%. Again, that’s a rough guesstimation, but reading code is an important part of an engineer’s job.

“A quick rule of thumb is to ask whether your team would pick that issue to fix if they had extra bandwidth”

As such, code reviews are a way to carve out time to “code” as a manager. It’s also a good way of strengthening your programming skills and keep an eye on your reports’ work.

Fixing tiny issues

As with reviews, fixing small issues generally doesn’t require writing so much code. Therefore, managers should consider rolling up their sleeves to fix tiny bugs, but be methodical about what issues you should be fix.

A quick rule of thumb is to ask whether your team would pick that issue to fix if they had extra bandwidth. If the answer is yes, then you should feel comfortable working on it. On the flip side, if the answer is no, then look for another issue that will have more impact when solved.

For example, if your team’s operational dashboard needs to be tweaked, and it requires little effort, but never becomes a priority, that sounds like an excellent opportunity for engineering managers to get their hands dirty.

When should you not write code?

When you are putting yourself into the critical path

If you are an engineering manager who wants to write some code, make sure that you are not getting yourself into the critical path – don’t ever find yourself in a position where you might hold up a release just because you are working on something that proves to be a release blocker.

When impact can be achieved elsewhere

Depending on your team and/or company size, you will likely have a range of important tasks to accomplish such as recruiting, roadmap ideation, career conversations, 1:1s, team rituals, etc.

“You should zoom out to ensure that you are spending your time in a way that maximizes your team’s impact, not just your own”

While any one of these things might seem less important than writing code, cumulatively they are all part of your role, and above all they are things that no one else in your team is in a position to do.

It is all about prioritizing impact, so you should zoom out to ensure that you are spending your time in a way that maximizes your team’s impact, not just your own.

When you want to get away from your managerial responsibilities

Beyond just maximizing your impact, it’s vital to remember that your duties as an engineering manager are always more relevant than any “IC” work you might be able to contribute. In particular, there can be times when your managerial responsibilities can feel too challenging, when you’re faced with tough team dynamics or cross-functional difficulties.

In these situations, it can be very tempting to take refuge in writing code – after all, that’s something you definitely know how to do, right? It’s critical that you resist that temptation and focus on your managerial responsibilities, because it as these moments that your team needs you most.

“You must avoid the temptation to find distraction in the editing window”

Sometimes, of course, those managerial responsibilities can feel boring, and you must avoid the temptation to find distraction in the editing window then too. If you want to get out of your comfort zone, look for new organizational problems to help resolve rather than falling back on an area that you already know.

Should engineering managers code at all?

I believe that engineering managers should feel comfortable in setting some time aside to work as an individual contributor. Therefore, yes, engineering managers should definitely write code, they just need to find the right motivation, make the time, and ultimately assess the right moment.

Remember, great managers should be able to identify the areas in which they can have the most impact. Sometimes that impact will be found in the code editor, but less because of what code will get written or reviewed, and more because of the related benefits for the team.