Do Engineering Managers Need to Write Code?
One of the biggest difficulties in transitioning from a software developer to a manager is coming to terms with the realisation that producing code is no longer your primary objective.
Chances are, while you were a software developer, writing code was something that energised you. Your impact was measured by the quality of your code and the value you were able to unlock for your customers. So it’s understandable that you start feeling some amount of guilt and anxiety about your dwindling code contributions after becoming a manager.
To be considered impactful, how much code is an engineering manager expected to write?
A quick search uncovers a wide range of opinions from “not at all” to 30% to even 50%.
So, what’s correct? Unfortunately, as with many things related to management, the answer is very context dependent.
Instead of focusing on this question, let’s first take a look at a few wrong reasons to write code as a manager
1. I need to keep my programming skills sharp
As an engineering manager, you need to be able to gather context and understand the challenges your team is facing at a technical level. Doing this requires keeping your technical skills up to date.
A lot of managers use this as an excuse to continue contributing heavily to the codebase as a developer.
However, you can also accomplish this by,
- building tooling to make your team’s day-to-day work easier
- creating POCs to explore the feasibility of upcoming work
- cleaning up tech debt
- fixing bugs
- getting your coding fix outside of work
Continuing to stay technical is important, but this doesn’t have to come at the expense of you continuing to be a heavy code contributor.
2. I can do it faster. I have more context
Maybe your team is relatively junior. Maybe your tenure with the company has provided you with more historical context about the app and the domain than your team.
As a former developer yourself, it’s easy to settle into a place where you become the person everyone depends on to “build things the right way”. It feels good and it feels comfortable.
But, it doesn’t take much to realise that this way of managing a team is not sustainable or scalable. Not only does this come at the cost of your managerial responsibilities getting sidelined, but you are also building a toxic hero culture that creates an over-dependence on yourself.
Whenever you find knowledge gaps in your team, take the time to
- do knowledge deep dives (and record them for future team members)
- add documentation to your development wiki
- set up pair programming sessions to disseminate the knowledge
If you feel that your team needs to level up their technical skills in general, provide them with good resources to help them get there. Encourage them to add learning blocks to their calendars so that there’s dedicated time each week to grow and get better.
Put in the work now to invest in your team’s growth. It will pay off with interest in the future.
3. I need to maintain credibility with my team
As I wrote about in one of my previous posts, if you are a new manager who has joined an existing team, building trust and gathering context by coding alongside your team is very important.
But you don’t need to keep proving that you are still technically competent week after week. Once you are settled in, get off the critical path. Focus your energy instead on enabling the team to do their best work. You can still stay connected to the day-to-day by continuing to do pair programming, code reviews and being a part of technical explorations.
4. I’d be wasting my skills if I didn’t write code
This may sound harsh, but it needs to be said. If you feel that your technical skills are being wasted by being a manager, you shouldn’t be a manager. Management is a full time job, not a side hustle.
Don’t fall back on coding as a way to avoid figuring out what you should be doing as a manager.
Yes, your technical skills got you here. But with your new role you have inherited a different set of responsibilities with a larger surface area of impact. It’s time to let go of the past and get better at the new skills you need to do that job well.
If you are the one still doing most of the individual contribution work, you might not realise the disservice you are doing to your team.
- You are robbing someone else of their opportunity to learn and grow in their craft
- You are doing this work at the expense of doing something else that’s more closely related to your role that would have a bigger impact across the organisation
- By virtue of your position, your code will carry a different weight than what’s written by your team members, causing your work to be criticised and challenged less
- Someone else with less of a split focus could potentially do a better job than you
- You are paid more than your reports. So in essence, you are costing the company more money for doing the same work that someone else could have done.
Does this mean you shouldn’t code anymore? Of course not. Coding is still very much a part of your job. But now you need to do it for different reasons, and away from the critical path.
So, how much should I code?
No two engineering teams are the same. The expectations of your own individual contributions will differ from team to team.
Make this a discussion point in your next 1:1 with your manager. Discuss what it would look like if you were operating well within your role. You will often discover that your impact is much more tied to your team’s output than your own. Adjust your responsibilities accordingly.
Management is not easy. But that’s what you signed up for. Don’t use coding to avoid doing the hard work. Being an effective engineering manager will always require coding to be a part of your role. Just make sure you do it for the right reasons.
