How to decide if you should become an engineering manager

Don’t over-index on how much (or little) coding you think you’ll be doing as a manager.

Joe Greenheron
Practical Empathy
3 min readMay 6, 2019

--

“Harana” by Natsue Makino

There are lots of articles written about what to do after you’ve decided to transition from engineer to engineering manager (see below), but not so many about how to make the decision in the first place. (I did find this one which was a great read)

The conventional wisdom is to ask yourself the question “When I get to work in the morning and open my laptop, do I want to see an IDE or a spreadsheet?” In other words, do you want to continue writing code or not?

This is a dangerous way to decide since it puts the most traumatic part of the transition front-and-center: not writing (as much) code. Each new manager has to come to terms with writing less (or no) code in their new role, but it doesn’t need to happen right away.

Personally, I made my peace when I realized that management is a form of leverage (this’ll sound familiar to folks who’ve read High Output Management): writing software is a high-leverage way to solve problems at scale, and when done well it can solve a lot of problems. Managing a team of software engineers — creating an environment where they can do their best work together — is much higher leverage, when done well.

So instead of focusing on whether or not you want to continue coding, instead focus on whether you want to learn and grow in the key skills of managing a team:

  • hiring, training, and mentoring your team
  • fostering an environment of psychological-safety
  • providing clear measurements of — and tools for — success
  • constantly and consistently setting expectations

You don’t need to be any good at this stuff right away. You do need to dedicate yourself to setting goals, failing, learning from failures, and being vulnerable as you take on a new role.

Think this is your path? Here are some great resources:

--

--