https://twitter.com/shreerangp
Engineering managers should write code occasionally to enhance their empathy, deepen their understanding of their team's challenges, and maintain respect from their reports. Balancing managerial responsibilities with hands-on coding can be beneficial, but managers must choose the right moments to engage in coding tasks. For instance, onboarding as an engineer before transitioning to management can provide crucial context about the team's work. Key Points: - Empathy and Understanding: Coding reinforces empathy for team challenges and provides practical knowledge of their work. - Respect from Reports: Managers who can code garner respect from their teams. - When to Code: - Onboard as an engineer to gain context. - Review code as a significant part of an engineer's job. - Fix small issues when they align with team priorities. - When Not to Code: - Avoid critical paths that could delay releases. - Focus on impactful managerial tasks over coding. - Resist coding as a distraction from managerial responsibilities. - Conclusion: Engineering managers should find opportunities to code, maximizing their impact on team dynamics while fulfilling their managerial roles.
This article is crucial for Engineering Leaders as it addresses the challenge of balancing managerial responsibilities with technical involvement, emphasizing how coding can enhance empathy and understanding of team dynamics. An actionable takeaway is to selectively engage in coding tasks, such as onboarding or code reviews, while prioritizing leadership duties that maximize team impact.
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.