Engineering Management

I was recently reading Aging programmer and while overall a great and insightful read, two points in particular rubbed me wrong.

• My desire to manage people is at all-time lows.
• My desire to discuss technical stuff with people, both to help and be helped, is at all-time highs.

It’s a common refrain in technical circles that engineering management is a wildly different discipline than doing engineering, and that in the Bad Old Days the only path to seniority was to move into management – which was a mistake. Both of things are true of course, but in my experience good engineering management is much closer to engineering work than generally accepted. About the only difference is: you do have to do some people stuff (reviews, calibration, hiring) and you don’t get to code (except maybe very occassionally writing random utility code to do cost forecasting or ticket updating or etc.).

Have you ever had a manager that wasn’t technical at all? It probably wasn’t a very good experience: it can feel like you’re speaking different languages. They might understand that the WidgetService refactor is behind schedule, but without understanding how WidgetService works, why it’s being refactored, or what that refactoring entails – there’s an insurmountable communication gap.

Good engineering management requires a significantly deeper understanding of the work. A effective engineering manager needs to understand the WidgetService landscape: how did WidgetService come about? who uses it? what value does it provide? what needs improving? why does it wake their team up with alerts?

If you know the answer to those things – you can much more effectively help steer your team through the work. It will involve a lot of technical discussions. Sure, you’re not going to open up an IDE and suggest a plan for the refactor – but you should be able to ask your engineers probing questions that help them derive a plan, and help them effectively communicate that plan to other engineers, and your customers or stakeholders.

• “No matter how it looks at first, it’s always a people problem”

There’s a large degree of truth to this, and as an engineering manager, this is your time to shine – you solve people problems! But you must understand the apparent technical problem at hand to do this well. You can’t solve people problems with technical work, but you similarly can’t solve technical problems with just people work. Your job is to balance this, and bridge the gap between people and technology.

In many ways, engineering management is a type of occupational therapy: your job is to enable your team to do the best work possible. To do this well requires dedicating a large portion of your time to technical discussions with other people. Your team relies on you to do more than cycle sprints in Jira every week. You’re a coach, but you have to know the game.

Certainly it’s not a calling for everyone, and it’s great that the industry has largely moved to having separate technical and management career tracks. Sometimes the people stuff is uncomfortable, and sometimes it’s uncomfortable to float in and out of technical discussions knowing that you’ll never write a single line of code in the product. But if you enjoy technical discussions and making technical and social connections across complex organizations and systems, it might just be a calling for you.