So you want to be an engineering manager?

After a few years as a software engineer, I was contemplating what direction to take my career in. In my mind, there were two options - manager or technical architect. I know architect is a vague term, but for me it represented the pinnacle of technical growth, someone that designs super complex systems and also gets to write code.

I knew almost nothing about being a manager though. I thought I had a good idea about what my manager at the time was doing, but I didn't. It wasn't until much later on that I started to understand what an engineering manager actually does and I finally understood only after becoming one myself.

For those of you thinking about becoming a manager, I'll give you my perspective on the role, but just remember that there isn't a clear-cut definition, you'll have to carve your own path. You'll understand what I mean by the end of the article.

How do you become a manager in the first place?

As usual, it starts with a discussion with your manager about the topic. Only through partnering with your manager will you be able to progress down this path. If going from junior to senior engineer is a promotion, most of the time becoming a manager isn't a promotion (it could be depending on the company ladder) but a lateral move. That being said, if you ever needed a good plan to move to the next level, this is definitely the place for it.

Most tech companies require that you're at least a senior engineer before being eligible to become a manager. Why is that? Well for many reasons, but mainly because technical leadership, mentoring and cross-collaboration are the foundational skills that you'll need to be a good manager. I fully support this idea, so you should focus on getting to that senior level first. At that point, there's usually a fork where you can go deep on the technical track or switch to the management track. Interesting to note that staff+ engineers have a large overlap in skill-set with managers, with a different focus though.

Once you're a senior and are seriously considering becoming a manager, you will need to be exposed to different situations to have a taste of what a manager does. Everybody does this differently, but here are a few things to consider:

• Lead a project. I think this one is a must, as it'll enable you to see the many aspects that make up a successful delivery, an essential part of management. Start with smaller ones and work your way up to bigger, cross-team projects.
• Mentor others. It could be in your team or in a different team. The important part is that you focus on your mentee and actively support them on their journey.
• Be proactive. As a manager, you'll find that nobody really tells you what to do exactly, so you need to be proactive in identifying the highest impact work to do next.
• Take ownership and responsibility. Imagine what you would do if your manager didn't exist and you would be responsible for the success of the team. Think about what you would do differently and start doing it.
• Communicate a lot. Get in the habit of communicating everything from status, risks, dependencies, achievements etc. as this is a critical tool in a manager's toolbelt.

Better yet, if you're not sure what to focus on, reach out to your manager and come up with a plan together.

What does a manager do?

I could write an entire series of articles on this topic alone, so I'll just say this: a manager does everything needed to keep their team happy. That's it. There are two big ideas to unfold here, so let's break them down:

1. The first is about keeping the team happy. It might sound simplistic, but it's really all there is to it. If your team is happy, they'll be productive and deliver great products. Don't waste your time coming up with shiny new processes and org changes until your team morale and satisfaction is taken care of. How do you do that you might ask? It's complicated and a topic for another day, but I'm a firm believer that if you genuinely care about people and invest in them, you'll be set up for success.
2. The second is the everything needed part. As a manager, there is no instruction manual telling you what you need to do. You need to figure that out by yourself. And once you do, you have the freedom to do it (for the most part). Not just the freedom, you're actively encouraged to take action as a manager. Come up with ideas, try them out, discuss them with your manager and learn from what worked and what didn't.

That being said, don't forget that as a manager you're representing the interests of the company, so always think about how to keep your folks happy and the organization profitable. You'll find that the growth of the people and the company often go hand in hand. Of course, a manager does a lot more things than just being a cheerleader. A few big areas are:

• People Management
• Technical Supervision
• Product Ownership
• Cross-collaboration

People Management

This is the big one, the one that makes or breaks a manager. People management consists of all the small things that make the difference between a happy team and a disengaged one. Stuff like 1:1 meetings, team building, setting goals with your team and helping them grow in their career. It also involves some not-so-pleasant things like managing people out or difficult conversations that a manager inevitably has during their career. It's by far the most challenging part of the job and also the most rewarding one. If you don't like working with people and taking a genuine interest in their success, please don't become a manager - it's going to make life miserable for you and the team. People management hinges on building great relationships, so focus on that above all else. Remember that software is built by humans and it's your job to keep them engaged and motivated.

Technical Supervision

Although you won't code or design systems, you always need to keep your skills reasonably sharp, especially as a front-line engineering manager. You are still expected to understand what your team is doing in detail, enough to be able to reason about decisions and represent your team in larger groups. While you should delegate the technical decision-making to your team (usually your tech leads), always keep an eye on the important choices and help the team with your experience and extended organizational context.

Product Ownership

This is somewhat debatable, but in my mind, an engineering manager is responsible for the product and has direct ownership of what gets done. Sure, you have product managers, designers and other folks that are more involved in the direction of things, but you're just as responsible for the deliverables and overall feature set of the product. Here your role is to assess the feasibility of requests and provide the engineering context needed to decide what gets done.

Cross-collaboration

This is a big one as well. While you're managing your team, you also need to manage across. This implies a lot of things, from representing your team in various circles to coordinating projects that spawn multiple groups to working with other orgs such as sales, support, recruiting etc. As a manager, you're the main point of contact for the team and it's your job to let enough information pass to and from your team. This means giving visibility, sponsoring people, bringing in more projects for your team and overall creating opportunities for them, which translate to opportunities for you as well.

What doesn't a manager do?

There are a lot of stories about engineering managers doing all sorts of work, from actively coding, agile delivery and whatnot. Let me give you my take on it.

A manager should never code, period. Sure, there might be circumstances where this is warranted, but in general, you should never write production code. You can (and should) help the team with minor stuff like scripting, deployment work etc. but don't ever be an active contributor in your team. You'll either do a mediocre job at best or you'll do a good job, but you'll neglect your main responsibilities as a manager. As a manager, you'll get pulled into a lot of stuff, so there's a high chance to become a bottleneck for your team. Even if this somehow doesn't happen, you're trading growth opportunities for people in your team for the sake of product delivery, and this is seldom the right choice. I know you'll be missing being hands-on, but know that a manager's impact doesn't come from churning lines of code.

Don't be a technical decision maker for your team, unless there's an obvious wrong choice or you need to be the tiebreaker. Empower and trust your team to make technical decisions without depending on you. Go one step further and even allow them to make (small) mistakes, knowing that they'll learn and grow from them. Encourage your team to use you as a sounding board, but let them drive the technical direction of the product end-to-end. Of course, you should always maintain a level of supervision such that things don't fall off track, but coach and mentor your team instead of being prescriptive. Use your best judgment though, knowing when to be more directive vs. giving full autonomy.

You should not speak the most in (the majority of) meetings. Learn to listen instead. I see a lot of instances where managers talk a lot in an attempt to solve issues and this robs the other folks (especially their reports) of valuable learning opportunities. What I found over the years is a few well-thought questions and active listening are a lot more efficient than just trying to direct the conversation too much. Again, it depends on the situation but get in the habit of doing this and I guarantee you that meetings will accomplish more over time.

Don't be a "Scrum master" (or equivalent) in the team. I know many teams do Scrum, but it shouldn't be you in that role. If you need to, have one of the senior engineers be the Scrum master, especially if you have a tech lead/team lead. If you coordinate multiple smaller teams, always delegate someone to be the "lead". This will force the teams to self-organize and figure out what works best for them. It could be a rigorous process, it could be more freeform, and each team is different from this point of view. Of course, you need to support the team, but keep them accountable and have retrospectives with them, which will teach folks a lot more as opposed to having you be the coordinator.

An important note is to never have favorites or treat any member of your team other than as an equal. Your success depends on the entire team, not just one or two engineers. Invest in the growth and well-being of each of your reports and always treat them fairly. People feel when this happens (or doesn't).

As a final note, a manager should never shadow their team. You'll not be judged on your individual performance, so don't try to look cool by doing a lot of stuff instead of delegating that work to your team. You should delegate as much as you can, guide your team through it and give them visibility in the larger group. It's a win-win: it's a learning and growth experience for your reports and yourself, setting you up for greater success along the way.

Final thoughts

If you've read this article and thought "ok ok, this makes sense, but many of these points are pretty vague" then you're absolutely right! As I mentioned at the beginning, it's hard to get into specifics because it heavily depends on who you are as a person and the particular company you work at. Some managers lead small teams (2-4) and can afford to be more hands-on, some lead large teams (10+) and have to emphasize mentorship and delegation a lot more. Some managers are more involved in the day-to-day of the team, while others like to look forward and prepare for the road ahead. Some managers enforce a lot of processes, while others leave their teams to self-organize.

There are a lot more dichotomies like the ones here. These choices heavily impact how your team looks and define who you are as a manager. There's no right or wrong answer here. One idea that I had, in the beginning, was asking the question "when I was an IC, what would I have liked my manager to do?" and trying to be the manager that I wish I had. But as I grew as a manager, the question changed "what does every person in my team want me to be?" and I changed my style accordingly. Because at the end of the day, it's about them, not about you.