Should engineering managers write code?

For engineering managers who started out as engineers, there comes a time when you yearn for the simpler life.

You fondly recall getting into flow, fingers flying across the keyboard, and pages of code scrolling around in your favorite text editor. The feeling of satisfaction of finally getting some code to work or resolving a tough bug has been difficult to replicate since you took on leadership responsibilities.

Spending time in meetings and working through complex team relationship issues leaves you feeling more drained than energized most days. You look longingly at your team and feel a slight tinge of envy. You want to code again.

The good news is that you can! The bad news is that you shouldn’t. At least not directly on your team’s codebase and not on any critical path work.

There has been a trend where good engineers are ‘promoted’ into management positions (this isn’t a promotion by the way…it’s a job change). Few are given any guidance on how to be managers or what the new expectations are in their new roles. Inevitably, these engineers-turned-managers fall back into their comfort zones and revert to being engineers.

In the best-case scenario, they work on side projects, write tests, or fix bugs. But in the worst-case scenario, they take on critical path work and try to build features for the product alongside their team. While this initially satisfies their need, their actual job eventually collides with their joyful coding experience. Now instead of helping their team and getting some coding in, these managers have become a bottleneck and are hurting their teams.

So, should managers still write code?

This question is often asked and the answer is usually, ‘It depends’. Perhaps the question should be more nuanced: ‘Is there a particular level of engineering leadership where my ability to write code is no longer relevant?’ Now that’s a great question!

If you’re a first-level engineering manager and directly managing engineers, it’s perfectly reasonable for you to still write code. However, this should be done carefully and in moderation. The guidance to avoid critical path work still applies. Your role is to be a communicator and facilitator, not a direct contributor to the work.

Want to help fix some low-hanging fruit bugs? Go for it. Observe there are a few areas missing unit tests? Write them and submit a pull request for review. See an exciting feature on the backlog that you’d love to see working? Back away from the keyboard!

While it is both fine and expected that you retain your technical skills as a first-level manager, do not equate that with being just another engineer. You’re not. Not anymore. You are a manager and the expectation of you is to enable your team to deliver, not to deliver the output yourself.

One of the major shifts that occurred when you change roles is that the impact of your work is no longer immediately apparent. It may take weeks, months, or even years to see the results of your labor. This can be a huge shock coming from an engineering background where the results of your daily work are immediately apparent and measurable.

As you continue to move up the management ladder, there are diminishing returns in maintaining your coding skills. Obviously, if you get joy from writing code, you should continue to find impactful ways to do it. But be aware that once you get to second and third-level management roles, writing code is not what anyone expects of you. Your engineers certainly don’t want you doing it and neither does your manager. Your role is so interrupt-driven and communication heavy that no one expects you to have the time to focus and write quality code. So why do you expect that you can?

But I really want to code!

If this is the case, ask yourself if you really want to be a manager. There’s no shame in returning to the individual contributor ranks. It happens all the time and, in fact, there’s a lot of benefit in people spending time going between the two roles. People who do gain greater understanding and empathy, and usually increase their value to the organization.

Assuming you do want to stay in a management role but want to ‘scratch the itch’ of coding, there is another way. Most teams have ideas for new features or products that aren’t on the near-term roadmap. Or, there are new technologies like serverless or WebAssembly that no one has had time to explore to assess their applicability in your environment.

These are opportunities to be the advance scout and ‘look ahead’ in these areas. Do some research, follow some tutorials, and build a small prototype to gain understanding. Then write up what you’ve done, what you’ve learned, and share with your team. Congratulations! You’ve successfully scratched your itch and provided some value to your team.

Reflections

The key thing to remember is not to overdo it. Your exploration can easily become a negative for your team if you don’t leave enough for them to do. It’s one thing to implement a proof of concept in WebAssembly. It’s another thing completely to rewrite your product’s key feature using it. Strive for doing enough to demonstrate value or provide clarity regarding the unknown. Avoid rewriting complete features or even applications. If you do, you’re taking away valuable learning opportunities from the engineers on your team. So go ahead, explore and report back but don’t go and try to conquer the brave new world by yourself.