eng mgmt ep1: Should I become an Engineering Manager?

Matthew Vanderzee
9 min readAug 21, 2017

--

This is episode 1 of my series on being an Engineering Manager (1, 2, 3, 4, 5, 6, 7, 8). We start by considering the transition from a software engineer to an engineering manager.

At some point in your career as a software engineer, you will be presented with the opportunity to become a manager. You’ll be the senior engineer for a particular part of the technology, and it will be growing to a point that a proper team needs to be formed. Or your manager will move on, creating a vacancy that you could fill. Or you will spearhead a new area of work, and the company will want to devote more resources that will need leadership.

When presented with this choice, how will you decide? Some engineers (many!) explicitly don’t want to be managers. But others aren’t sure. On a number of occasions, I have been the one presenting this choice to an engineer on my team. Below are some considerations I have discussed with them as they made the big decision.

“This is the doohickey that you type on to make software go. Get to it, Jensen!” <straightens tie>

Some bad reasons to become an Eng Mgr

Before we get into the decision making, let’s dispel some common misconceptions. Here are some bad reasons to make the move to management:

A. To further my career

Nope. The management track is parallel to a just-as-rewarding individual contributor track. Manager, Director, VP Eng have symmetric IC roles: Lead Engineer, Principal Engineer, Staff Engineer, Architect, CTO. These roles earn comparable salary and equity, have proportional impact on the business, and exercise increasing latitude and influence, just like the mgmt roles do. And to really move that far up the IC ladder will take perhaps twenty years — so there is plenty of growth, learning, impact, and rewards along that path.

Any tech company that requires jumping to the mgmt track to increase one’s station is a bad company. Don’t work there — it means their technological vision is limited; the future technical direction of the company is uninspired; they don’t need or want superlative engineers to drive their growth. The higher levels of the org are instead solely management types — in other words, they are not actually a tech company. Run away.

B. For power

Similar answer to A: the higher technical IC roles have a huge impact — the good kind of power — at a company. They propose, innovate, and prototype future strategic initiatives. They interact with other leaders across the business and participate in major decisions. They drive agendas and work with people managers to ensure those goals are met. So don’t become a manager just to have influence in your company — you will have just as much in the senior stages of the IC track.

C. For fun

Engineers enjoy focusing on deep technical challenges and seeing them through to victory. In my latter years as a software developer, before I made the leap to mgmt, my job was always fun — I knew that I could build what I needed to build, and I really enjoyed the process of seeing my creations come to life. It was a ton of fun — even though it was also technically and ethically complex.

But management is rarely “fun”. There are a completely new set of stresses, challenges, and problems that you have never faced before. Success is no longer just a function of your creativity and intelligence and effort. Now it also relies on the force of your will, your personal interactions, your project management skills, the abilities of the team you’ve built, the motivation you have imparted to your folks, the engineering culture you have fostered, and your good decisions around resource allocation and prioritization.

Some good reasons to become an Eng Mgr

Now let’s point those counterpoints. Some quick motivations here, before we dive into details:

A. Multiply your impact

As a manager, you will be working through your team — so the number of things you will be involved in, that you will drive and support and worry about, will increase.

B. Foster others’ development

Those who love to teach and foster and impart wisdom into others will flourish as managers, since a large part of the role is helping others grow and succeed.

C. New frontiers

It is very hard to be a great manager, and takes a lot of work and training and education and focus and experience. Engineers who are very good at their job will be surprised at how many new things there are to learn as a manager.

Bonus points for you if you can identify which javascript framework this is.

Indirect Engineering

A good initial litmus test is “would I like a job where I rarely coded?” If the answer is a resounding “NO!”, then maybe don’t. Your first few mgmt roles will likely involve being close to the code — it will be a small team, and so the people-mgmt aspect of the role won’t take all your time. Plus, you’ll want to make sure your team is successful, and as the presumptive senior engineer on the team, the easiest way to do so is to stay in the code. That is good, and provides a nice transitional time while you expand the rest of your management skills. But at some point, if you stay on the mgmt track, you will get to a role where you won’t be coding consistently. If the thought of that turns your stomach, there you go.

And this is imperative to consider. In your first few manager roles, you could conceivably devote a lot of your time to coding — after all, technical success is how your team will be graded for any particular delivery. But: if you aren’t devoting enough time to building your people management skills, you will fail in your new role. Though your team will be hitting the mark technically, you will start to see erosion on the organizational, cultural, and team member development axes. You are the manager, and so it is your responsibility to drive these (more on that in future episodes). The key point is: to do these well, you have to devote your time to learning how! If you don’t, no one will be there to fix it, and your team will suffer. And that’s your fault.

In some blog post that I can no longer locate, the author makes the point that moving to management means your focus shifts from building great technology to building teams that build great technology. And that is a context shift from what you are used to. When faced with a technology problem, your thinking needs to evolve from “How can I solve it” to “How can I support my team solving it?” Especially as your career grows in management, the problems are bigger, the teams are bigger, and the stakes are bigger, and so you need to ensure that you can pursue a solution indirectly via the team you have fostered. This transition will happen over time, so you have time to grow into that mode. You’ll never be completely disconnected from the code; you just won’t have a lot of time to touch it. Even now, I dive into code whenever I can add value. Or, just for fun! But my success is not dictated by my coding time — it is my work to facilitate the team’s coding time.

What you’ll do instead

Ibrahim Bashir of Twitter has a solid post about what an Engineering Manager does — read through his long list of dimensions of the role, and get a sense for whether you are interested in doing that. For many engineers, it is a strong NO: all of that is distracting from the technology — the fun part.

In the next episode, we will cover how to spend your days as an Engineering Manager. But for now, let’s quickly cover some of the key aspects to the role:

Painting the picture

As the leader of a team, you need to set the course: what will your team be working on, what are the goals your group will achieve, and what does success look like. You need to do this internally, so that your folks know what they are fighting for, and you need to do this externally, so the rest of the company knows what to look forward to. You need to socialize these concepts and get buy-in internally and externally. You need to paint the picture that will get everyone excited and motivated.

Walking the line

You have to balance business needs and technology needs, balance pragmatism (build it fast) and idealism (build it perfectly), balance deadlines versus deliveries, and more. Your success at the role will be determined by how well you navigate all these decisions, and how well your team delivers on all these fronts.

This picture contains walking and lines. “Walking the line” metaphor successfully visualized.

Always be pushing

You’ll be pushing your team to move faster, pushing your technology architecture to be as solid as possible, pushing the Product team to align on roadmap and delivery, pushing the business for resources and other needs, and pushing to the future through creativity and innovation. And amidst all that pushing and driving, you’ll need to be able to maximize cohesiveness and positivity across teams.

Enforcing quality

You will need to define what successful, high-quality delivery looks like for your team, and then ensure that you achieve that. Software quality is the kind of thing that outsiders notice only when it is bad — and if they notice it, it is already too late. So you need to hold the line. You need to set aggressive, strict, objective criteria that demonstrate high quality: minimal bugs found in the field, minimal broken builds, etc.

Process, culture, and environment

The policies, processes, and toolset you put in place will have a huge impact on the velocity and the culture of your team. One of the most important aspects of an eng mgr’s job is ensuring the team can operate efficiently, effectively, and easily. How well you do this will be reflected in the culture and atmosphere of the team.

Recruiting

Recruiting is always the most important thing you do. Whether because you have open roles that need to be filled yesterday, or you need to level up the team’s skillset and effectiveness, your success is only through other people, so you need to get the best people to make that happen. This means hours spent reviewing resumes, talking to candidates, honing your screening process.

Most or all of these skills and activities are not learned in school. And, when you get to the choice to become a manager, maybe ten years into your career, your roles until then have likely not touched on all of these. This means you have to learn these skills fast, since your success depends on them. If that sounds like an exciting challenge — if you want to take on these areas of work — do it!

How to choose

So why become a manager? For me, it was the new frontier — I wanted to take on all these challenges. I had gotten good at engineering, and I wanted to try something completely different. And since I trend towards introversion, this seemed like a huge challenge. But it turns out — I love the human side of the job. Much of my days now are talking to people — 1:1s with my team and others, meetings and brainstorming about various initiatives we are driving, spending time with leadership strategizing how to make this company hugely successful, and conveying to candidates the vision of what we are trying to accomplish.

You need to evaluate whether you want this kind of role. Being an engineering manager isn’t just being a software engineer plus the ability to fire people. It is a completely different job. If you like the sound of the role as outlined above, it may be a great fit for your career!

Stay tuned to future episodes as we get into the mechanics of being a manager, what to do when things go wrong, and how to do everything you need to do in not enough time.

Read episode 2 now

There’s a little clapping icon or thumbs up or +1 button — click that if you’ve found this post useful!

Photo credits: Markus Spiske, Gert Boers, and energepic.com.

--

--

Matthew Vanderzee

CTO at Crisis Text Line; father of three; half of Veloureo (veloureo.com); creator of some novels / short films / eps of Squishy and Plate.