How I Became an Engineering Manager

In 2014, I took two months of leave from my Engineering manager job at Google. I had just gotten a big promotion based on my work as an engineer and tech lead for the previous six years. I was a leading expert on a large, critical part of the DoubleClick online advertising system, and before I left, I had been leading technical and architectural decisions for a team of 80. But that wasn’t the role I came back to. Instead, I was on a newly-formed team of three, proposing a system that didn’t yet exist. On the face of it, this was anything but a good move for my career. So why did I make the switch?

Leaving my previous role allowed me to become a manager. By changing my career trajectory at this point, I learned the skills that ultimately allowed me to succeed at my current Engineering manager job, leading engineering for a whole company, Coord. But management isn’t the only career path I could have taken, so I want to talk a bit about why I chose to do it and what you’ll need to know to decide if you want to make the same transition.

Growing as an Individual Contributor

When I graduated from Brown University in 2008, I started working at Google. it’s a pretty standard story. I got a degree in Computer Science, applied for entry-level engineering jobs, and got one.

When you start as an engineer at a large software company, you’re what’s called an “IC”, or Individual Contributor. This means that your output is primarily made up of the code you write. You will work on a team and have tasks assigned to you that you have to complete: add this feature, or fix this bug, or improve performance of this subsystem. To move into a leadership role, however, you have to do work that is different from the coding, debugging, and testing that takes up much of an IC’s time.

The thing that makes a leader is having influence beyond your own work. Luckily, I’d gotten the chance to do a lot of writing in college, and I put those skills to use. At the time, I was implementing an advertising auction, which could have quite complex behavior depending on the exact inputs. So I wrote a document describing in great detail how this system worked. As the product I was working on grew, this document and others like it became critical to expanding the team and spreading knowledge. And when people had questions, they came to me.

I also started taking initiative in identifying and solving my team’s technical challenges: rather than wait for work to be assigned to me, I identified areas that needed improvement and suggested how we could fix them. It’s important to do this in the right way. As a new team member, it’s easy to forget that your team has already considered and rejected lots of the obvious ideas you might have. People could also resent you for focusing more on other people’s jobs than on doing your own. So remember that when you make suggestions like these, they have to come from a place of knowledge and humility. This is another reason why establishing expertise is so important: it helps people take you seriously when you make suggestions and give feedback.

In late 2010, my boss promoted me to tech lead of my team. This made leadership part of my formal engineering manager job responsibilities. I still wrote plenty of code, but I spent more time thinking about larger scale technical questions and working with the rest of the team to figure out how we would solve them. It’s important to emphasize that I didn’t come up with the answers on my own: it was my job to lead the team towards asking the questions and finding the answers together. But it was my responsibility to make it happen, and I could have an impact both by making technical contributions, like suggesting a new design or a way to refactor our codebase, and by helping my team as a whole do a better job of thinking about the issues we were facing.

Recommended book for engineering managers High Output Management

Leadership Versus Management

Google did a study about what makes teams perform well, and found out that the best teams weren’t the teams with the most talented engineers on them. Rather, they were the teams that worked best as a group. It’s the job of Engineering managers to build teams like these. This involves very different skills and responsibilities from those of a tech lead.

As a manager, your primary responsibility is to the people who work for you.  It’s your job to make sure that they do their best work and grow their careers, even if sometimes that means building the product more slowly or approving technical decisions that you wouldn’t have made personally. This is one of the things I find hardest about management: you have to step back and let your team learn by doing. Even if it would be faster to do things yourself, you have to delegate. Otherwise, your team members won’t be able to grow in their jobs.

Managers have administrative and legal responsibilities, too, like evaluating their team’s performance, managing hiring, and firing team members when necessary. They are also involved in deciding their team’s compensation, and making sure the company treats their team in a fair and legal fashion. None of these things are specifically engineering skills, which is one reason why transitioning from a purely technical role to a managerial one can be very difficult. Conversely, managers often have less input into their team’s technical decisions, which can mean that your technical skills get used less in a managerial role.

So why did I decide to make the transition? Once again, it all comes down to impact. If I wanted to build things that made a difference, I would have to learn how to build teams, not just software, and the way to do that was to be a manager.

I talked to my boss about what I wanted, and started out managing a team of four. At the beginning, my boss mentored me very closely. I had a lot to learn about how to manage, and he helped me through the growing pains. As I discussed above, one of the hardest things for me was stepping back and letting my team members make their own technical decisions even when I had a different opinion. I also had to get better at giving both positive and negative feedback in a way that would help my team members learn. These are things I still work on to this day. But by the time I left Google, I was successfully managing eleven other engineers.

Should You Be an Engineering Manager?

Now that I’m leading the engineering team at Coord, I’m very glad I decided to become a engineering manager. But it’s not the only career path for software engineers, and you should ask yourself whether it’s what you want to do. Here are some things that you have to like doing in order to be a good engineering manager:

• Mentoring. One of the most rewarding and important parts of my engineering manager job is helping my team members get better at theirs. It’s easy to get frustrated when you’re working with people who don’t know something that you’re very familiar with; as a manager, you have to move past this and let them figure things out for themselves.

• Giving good feedback. In the moment, it’s usually easier to let bad work slide than to address it, but this is a recipe for disaster. Managers have to be comfortable letting people know when they are doing well or badly, and explaining their expectations in detail.
• Taking ownership. Managers answer for the work of their team, even if they aren’t doing it personally. This can be great, but it can also be very stressful. Sometimes your team won’t get things done that you were supposed to: as a manager, you have to take responsibility for the situation and work to make it better, rather than trying to point a finger at someone else.
• Writing. One of your responsibilities as a manager is making sure your engineers have the information they need to do their job. This means that you have to be comfortable writing things down!
• System-level thinking. You’re going to have to make decisions without being the person who’s the most familiar with every line of code: instead, you will have to think about the systems you are building at a higher level, and be able to delegate the details to your team.

But if you like these things, managing is a great way to make a difference in your job, and it can also be a lot of fun!

Jacob Baskin is the head of engineering at Coord, a startup building APIs for mobility. Previously, he worked at Google as a software engineer and manager. He grew up in Toronto, Canada, and currently lives in Brooklyn, New York with his wife and their dog, Bertie. Follow him on Twitter at @jacobbaskin.