So, You Want to be an Engineering Manager

If you would have told me 7 years ago I’d end up in management, I’m not sure I would have been happy with the prospect. I always considered myself a hardcore tech guy, perhaps not a nerd, but at least geeky. I started programming when I was 9, and did barely anything else for the next decade or two. How could that lead to something as boring as management, where your schedule is filled with meetings and you barely write a line of code?

One of my favorite teachers at university used to say: “those who can do; those who can’t teach.” I believe many engineers would happily replace teach with manage in that saying.

Nevertheless, here I am are a decade or two later with various VP Engineering titles in my past and currently functioning as Head of Engineering. There’s no denying it. I’m a manager and I’m ok with it. Note I said “ok” not “proud,” but hey. Baby steps. I believe it’s the right choice for me. Not because I can’t do (or so I make myself believe), but because I believe I can make a heck more of an impact in leadership roles than I can writing code myself. And that’s why I’m perfectly comfortable having picked this route, and I’m perfectly happy recommending it to you, in principle.

So, let’s talk about you.

If you’ve been in the business for a while, and have reached the ranks of senior engineer, there should be this nagging question: What’s next?

Many companies — I’d boldly claim: the good ones — will have a career path split, usually after the senior engineer level: technical or management path. So which should you pick?

I think the most natural option — as in: nothing revolutionary will change if I pick this — is the technical path, usually progressing to tech lead, principal engineer, distinguished engineer and the like. So I won’t talk about that (boring stuff, really).

Let’s talk about the other option: the management path, and see if that could be for you.

To give you a sense what the position of Engineering Manager is all about, I’m going to do the logical thing, I’m going to decompose the job into its linguistic components: “engineering” and “manager”. Let’s start with the less shocking part.

Engineering

In my view, to be a good engineering manager, you have to be a good engineer — which is where the whole “those who can do, those who can’t _manage_” falls flat immediately. There are two reasons for this:

1. It is your job to guide people in terms of engineering practices, and to do that, it’s pretty damn useful if you’re capable at doing it yourself at a solid level.
2. People tend to listen to people they respect, and this is much easier to achieve when you’re “one of them,” or can fake it enough to sound legit (“I remember building blockchains in a serverless Haskell fruppet-deployed cloud environment using stateless database like it was yesterday.”)

When I say engineering practices here are some of the things I expect you to understand and have an opinion on:

• Process: What are the steps to go from idea in a product manager’s head, to live product that people actually use? I’m talking everything from creating tickets in JIRA, to refinement, to planning, to writing code, to writing tests, to code reviews, to deployment to test environments, to release management, to roll outs, to monitoring, to maintenance, to removing of the feature (although the latter is too uncommon unfortunately).
• Quality: Unit tests, integration tests, end to end tests. How many of each? What coverage would we like to achieve? How do you measure if you’re doing well, improving, regressing?
• Code reviews: do we do them? Who should review? Do we enforce a certain number of approvals? What are the expectations of a code review, do we focus on style, correctness, architecture, documentation, or primarily on code indentation and variable naming? Are we getting any value out of them?
• Technology choices: are we using the same technology the company has always used, or are we introducing something new? If we’re using something new, have we evaluated the risks and benefits properly, or did we just pick whatever is trending at Hacker News that day? Do we need to check with anybody, or ask for input?
• Release management: how do we release? How often do we release? Can we automate everything? Do we want to automate everything? Should we automate everything? Do we do load tests first? Do we roll out gradually? What if all of this release was a giant-ass disaster, first if all: how do we find out before our customers do, and second: how do we roll back?
• Architecture: How do we find the right balance between delivering something in the short term, with having something maintainable long term? How do we design things so that it doesn’t blow up in production?
• Technical debt: how do we make sure our development pace doesn’t grind to a halt in time due to all our clever shortcuts? If we have a significant amount of technical debt, how do we handle it? Do we rewrite from scratch? Negotiate a part of the sprint to address it? How do we communicate the importance of this to other stake holders?

This is the part that probably many highly technical people are interested in naturally (except perhaps for the process aspects), once they reach a certain seniority level.

Note that while engineering managers may get their hands dirty with many of the things listed above, that’s not essential and really depends on the team. Sometimes it’s the best idea to get your hands dirty and write code, do code reviews, help with architecture, put your scrum master hat on; sometimes it is not. Either because of lack of time, or because you’re blocking the development of your team (more on this later).

So let’s move on to the part of the job that will be the biggest shock to everybody who takes this job. The people part. Yes, there’s people involved — didn’t realize? goto technical-track.

Manager

As it turns out, the engineering part is the easy part (at least this is my experience). You think you understand computers — good for you — try getting some people to do “what they should.” Completely different job.

Let me repeat that: COMPLETELY DIFFERENT JOB.

A month or two into my first management job I remember thinking how shocking it was that nothing, absolutely nothing in my B.Sc., M.Sc. and PhD in computer science had me prepared for any of the work that you need to do as a manager.

So, get ready to start from scratch once more.

Here are some of the management aspects of the job:

• 1x1s: Build a relationship with your people, understand how they think, if they’re happy or sad, frustrated or fulfilled, believe we’re heading for success or fantastic destruction.
• People development: Do you know your peoples’ hopes and dreams? What direction they want to develop themselves in? Do they see themselves on the technical track? Management track? Full stack? What are you doing to make this happen, or to change their mind?
• Conflict resolution: some people work together well, some fight. How do you ensure no serious conflict persist? Use any means. More common than internal conflicts? Cross department ones, how you go about resolving those?
• Feedback: Do your people know if they’re doing well? Do you give them regular positive feedback? Constructive negative feedback?
• Outward communication: your boss (hopefully) wants to know what you’re up to, so talk to him or her. There will also be occasional “why aren’t you guys delivering (on time)?” question, so managing expectations is important too, both towards your boss and all stakeholders. Keeping everybody in the loop is essential but needs to be balanced (somewhere between “we don’t care what you had for breakfast” and “who are you?”).
• Team composition: what people are in your team? Do you have the right skills there? Are they balanced properly? Do you have all juniors, or all seniors, a mix? Do you need QAs? Data scientists? Product analysts? DevOps? Frontend engineers? Backend engineers? Full stacks?
• Hiring: If you don’t have the perfect team already, it’s your job to fill the gaps. What are you doing to address this? Chances are you have recruiters in your company, are you working actively with them to find the right people for you? Do you participate in the interviews, do you sell candidates on your team’s mission?
• Firing: Are certain individuals underperforming? Why? Is this a case of the right person in the wrong place? If so, how about a transfer? Does the person know they’re underperforming? Have you spoken with HR about next steps? Ultimately, are you willing to let somebody go?

Putting it together

Engineering management roles are an interesting mix of people and technology. Sometimes the tech aspects need more attention, sometimes it’s the people aspects. It’s interesting work, but you have to be good at the balancing act, and have to accept you cannot spend all your efforts on just one of them. In fact, as you “move up the chain” balancing priorities becomes a bigger and bigger part of the job, as scope increases and the amount of people that want something from you increases.

Nevertheless, when you do it right, you will start seeing results. Not as instant as engineering work, but results nonetheless. Somebody under your mentorship being promoted. Eliminating meetings so your team is less distracted and more productive. Making some great hires. Changing people’s attitude towards work for the better. Shipping a 1.0. Helping people get better insight in what the direction they want to go in their careers. Figuring out how to turn a project perceived as maintenace-only into a technological playground. Being able to take a vacation, coming back, and discovering that the team kept on improving the way they work as you were absent. People who you once hired, moving up to become a CTO or CIO elsewhere. Some things will be invisible, many hard to take credit for, and some will be life altering.

Welcome to management.

So, 1800 words later, do you think this is for you? Happy to hear it. I’ll collect suggested reading on a bunch of topics at some point, but until I do, I highly recommend two books to start:

1. The Manager’s Path — This is the tech management book I wished existed when I started. It describes the career path from engineer, to tech lead, to engineering manager and beyond, clearly describing expectations at each level. A great read.
2. Managing Humans — rands is my tech management idol. He offers good insight, he’s funny. Love this book. You can find most of this on the rands in repose blog as well.

Good luck!