In this video, I sat down with Tom Weingarten, an Engineering Manager at Google, to talk about what Engineering Managers do. We also discussed what he likes about engineering management, what he doesn't like, whether he ever considers going back to software engineering, and what his 20% time project is at Google.

Check out the second half of the conversation I had with Tom here: https://youtu.be/QiQiuNhNbtU

AlgoExpert: https://www.algoexpert.io/clem
SystemsExpert: https://www.systemsexpert.io/clem
My LinkedIn: https://www.linkedin.com/in/clementmihailescu
My Instagram: https://www.instagram.com/clement_mihailescu
My Twitter: https://twitter.com/clemmihai

Prepping for coding interviews or systems design interviews? Practice with hundreds of video explanations of popular interview questions and a full-fledged coding workspace on AlgoExpert - https://www.algoexpert.io - and use the promo code "clem" for a discount on the platform!

The way that Google does leadership is a little different than how some people expect.

Engineering managers get called into weird situations.

So I'm doing a 20% project in the research space.

So today I've got a very exciting video and a very special guest.

Tom is actually 1 of my former managers at Google and he's still working there as an engineering manager.

We actually didn't get a chance to work super closely together because he was going to be my manager in the team that I was about to join right before I left.

Kind of a long story, but I'm really excited.

He's going to be sharing who he is, what he does as an engineering manager.

This is stuff that you don't really hear about on YouTube or online.

So Tom, why don't you just introduce yourself a bit before we jump into questions?

I'm very excited for this opportunity to talk to you about this today.

I currently work in the Google Cloud as part of the data integrity team.

Before that, I had an experience in academia and in startups.

But for the last 5 years, I've been here at Google as an engineering manager.

And so I guess this segues perfectly into the first question, the question of the hour, which is, what do you do as an engineering manager?

To someone who doesn't know what an engineering manager is or who is vaguely familiar with it, what do you do?

So every day looks a little bit different when you're an engineering manager.

A lot of people when they start out as an engineering manager it looks a lot like being a software engineer because most people kind of have a little bit of a curve into it.

But where I am at my point where I'm fully engineering managing and not writing code, my job kind of shifts between you know the different months and the different times of year, whether I'm focused on be it semester planning, so planning out for our future goals that we have, OKRs, we call them, things like that.

Or if it's performance review time of year, then I'm spending a lot of time focusing on performance reviews, doing what we call calibrating, where different managers will get together and share best practices for what are the ways we're providing feedback to our reports, where are we level setting to make sure that we're all reviewing people fairly, that sort of thing.

And then of course you have all the regular events, right?

So everyone knows managers have lots of meetings.

A lot of those are like one-on-ones, right?

Where I try to get the pulse of how everyone on my team is doing.

A lot of those are team meetings, similar goals.

So things are constantly happening and the manager typically becomes the backstop.

So if anything happens and there's not somebody else to pick up that issue, The manager's job is to make sure that nothing's falling through the cracks and that things are getting where they need to go, even when nobody really knows where something needs to go.

So that's sort of the high level example of what we do.

Yeah, and that's really interesting, but I think the key thing here that at least to me kind of pops out is the fact that as an engineering manager, you're really a people manager, right?

Like you are not a necessarily doing actual engineering or doing like product development.

So could you just talk about that a little bit?

Like what's the difference or what's the emphasis on the people managing side of things?

And this is a really important distinction.

And it's also 1 of the ones that people coming from startups to bigger tech companies can struggle with sometimes.

Because if you're the CTO at a startup, a lot of times you are the product manager and the engineering manager, right?

You're setting the culture in terms of how we treat each other.

And you're setting the culture in terms of what we're building all that.

Like, depending on what team you're on inside a place like Google.

So in Google Cloud, because our product is so technical, engineering managers do wear a little bit of a product manager hat too.

And that, you know, at the end of the day we are responsible for the product.

But our primary role is making sure that we have the team in place, a well-functioning, you know, very psychologically safe, very happy team that's gonna be able to make those decisions and execute them well, right?

A manager's job is not to go in and make every decision themselves.

They want to empower their team to be able to make those

to empower their team to be able to make those decisions.

So the difference between the product manager and the engineering manager here is the product manager is going to spend a lot of time talking to customers, going to spend a lot of time thinking about how do we describe what we need to build, coordinating the people across UX and UI design, across research, across all the different areas that come together.

And then they'll work closely with the engineering manager who is trying to make sure that, especially the software engineers, but also everybody else is culturally well set up, is coached properly, has the skills they need, unblocks conflicts, things like that.

So that's sort of a high level how we decide.

In practice, a lot of times though, we all work closely together.

So, I've had situations where we were in between product managers and it's like, well, all right, engineering manager, you're gonna wear the product manager hat for a few months now too, while we transition that role or something like that.

And I remember even like when I worked at Google, sometimes product managers, for example, would demand a lot from the engineers.

And sometimes it was a little bit too much, right?

There's always the constant push and pull between engineers and PMs.

And so the EM, the engineering manager, sometimes comes in between, right, and has to kind of be the, not necessarily the peacekeeper, but the person to kind of try to make the PM understand why the engineers might need more time or things like that.

Communication is a huge part of the job, right?

You need to be able to speak business to a product manager and you need to be able to speak technically to the engineers and, you know, every way in between.

So communication is a tremendous part of it.

And also at the end of the day, you are the person who makes the decision that says, okay, I got all the input I needed from the product manager.

I got all the input I needed from the software engineers.

If they can't decide, I need to make the call or I need to escalate to someone who does, right?

And so this might actually segue well into my next question, which was about the comparison between EMs and software engineers.

But before we touch on that, I guess you just mentioned that At Google, EMs are very technical, especially, for example, in cloud, right?

I'm curious, can you speak a little bit more about that?

Because I know that in some other companies, especially maybe not startups, actually, but maybe more like legacy non-tech companies, you have engineering managers who aren't actually engineers themselves.

They've never maybe even coded in their life.

I know that at Google, that's like very different, right?

It's a really key part of Google's culture is that engineering is a big part of the decision-making process all the way up through the company.

So our current CEO is our first CEO who was a product manager and not an engineer.

And it's going fine, but I'm not saying it's a bad thing, it's a great thing.

But we have so many engineers who are very, very high levels of authority and of leadership in the company.

So the way that Google does leadership is a little different than how some people expect.

I think a lot of people think that if you're a software engineer and you want to keep getting promoted, eventually you have to become a manager.

And we really feel strongly the opposite.

We want to make sure that anyone who wants to stay an engineer can just stay as an engineer.

And you can get to just as high a level, you can have just as much leadership, just as much money and that sort of thing, right?

You're going to be compensated just as well.

So the same ladder level is going all the way up.

But you can also decide that you want to become an engineering manager.

But even though you're going down that route and you're saying, I don't wanna be a software engineer anymore, now I wanna be a manager, we still expect you to be just as technically competent as the software engineers.

Right, an engineering manager needs to understand very broadly how the engineering changes are gonna affect all sorts of parts of the company.

Whereas a tech lead or a high-level software engineer can be a little more narrowly focused and really get into a deep expertise on something.

And I was, you know, very pleasantly surprised, I suppose, when I was at Google, because it did seem like all the managers actually had walked the walk.

They could sometimes, I remember either with you or with my other manager, we're in a technical conversation with other engineers and then you suddenly go to the whiteboard and start actually talking about the code and stuff that we didn't know about.

But I suppose now let's dive into that question about the comparison with software engineers.

Overall, how do you differ from a software engineer?

Is it just that mainly these days you just don't write code anymore?

I think the biggest difference is like at the end of the day, what you care about, right?

And of course you all care about the same things, but like where you focus your time, right?

An engineering manager really has to be very selective in focusing their time on what we call like force multiplier activities.

So things I can do that are going to empower my team to be better, right?

If an engineering manager sits down and gets really into a bug and like really focuses on it and understands it better than anybody and solves it, that's probably not the best use of an engineering manager's time.

They probably should have delegated that to somebody else.

And that is 1 of the things that new engineering managers and old engineering managers, including myself, sometimes struggle with, is it's hard, right?

It's hard to share your Legos with other people, but when you share your Legos with other people, you can build something much cooler and much more complicated than you could have otherwise.

You're gonna get more perspectives and you're gonna get more diversity of thought in there.

But when you ask, like, what's the difference between an engineering manager and a SWE, it's that specificity is 1 of those things, right?

A SWE can really take the time to focus on a single problem for a while, whereas an engineering manager needs to be available to a whole large number of different problems simultaneously.

And an engineering manager's job is really to get something to the point where someone else can take it over and then let it go.

And that's like, if you're doing that, you're probably doing a good job as an engineer.

And it's funny because like that expression, I guess that you used force multiplier activity, it sounds like this kind of, you know, corporate speak kind of BS, but I think it actually makes a lot of sense.

Because like, yes, if you can empower someone, an engineer, to just do their work like 2x times better, you know, or 2x times better or more productive, that's definitely going to work.

And I'm feeling it too, you know, on a completely different side now, running my own company, where the more you grow the company, the more you have to start to delegate things out.

But delegating things out means like trying to make people just be able to do the job better themselves and you do things that like you might only be privy to.

And on that note, by the way, forgive me, Tom, but I have to plug in my company for my viewers.

So if you're a software engineer who wants to get into Google, maybe you want to become an engineering manager, and we're going to talk about how to become 1 soon, then you want to prepare for your technical interviews, coding and systems design.

Go to algoexpert.io and use the promo code Clem, CLEM for a discount on the platform.

But so let's talk about some fun stuff about EMs compared to like being a software engineer.

Cause you were a software engineer before, at least you wrote code before in the past, which is harder if you had to pick 1.

Do you ever think, like, I would like to go back to becoming a software engineer.

Let me answer the first 2 questions there first, right?

I think are kind of, I'm gonna kind of cheat and answer them as the same question.

They're both super hard, but different parts of them are different amounts of hard to different people, right?

So like 1 of the reasons why I chose to be an engineering manager instead of a software engineer is that a lot of the stuff about management that a lot of software engineers find super hard and super not fun is stuff that I actually find a little bit relatively easier and fun.

Coaching is a really critical activity that engineering managers have to do.

But I really enjoy kind of like putting my work aside for a second and being like, reflect to me what's going on?

How can I really get into your shoes and understand what you're going through and try to help you find a way through this?

I really enjoy kind of like difficult conversations, you know, Or at least I should say I don't enjoy them less than other people.

You enjoy the challenge and probably the unique flavor that they bring.

I realize that you're probably not always looking forward to having a difficult conversation.

But I've been told, and I think there's some truth to this, that I have a, you know, a resilience towards those conversations.

And it means that I can be the person in the room who can, you know, take on a lot of that stress that other people are feeling, help them deescalate a little and then get to a better place.

For some people, they'd be like, that's a lot harder than software engineering.

And right, no, it can be, but it's a different kind of hard.

It's like emotional work, instead of, you know, intellectual work, banging your head against a bug or something like that.

So I think it's, you know, if you find yourself in a position, the advice I would give people listening to this is if you find yourself in a position where you're hearing these things, you're hearing like, yeah, coaching, having really difficult conversations about careers and interpersonal issues and stuff going on outside of work and how it's affecting work.

And you're hearing that and you're like, yeah, I love that part.

Maybe engineering manager is a path worth considering.

And don't get me wrong, like SWEs should be coaching each other too, like software engineers, SWEs, SWE, they should be coaching each other too.

But it's a question of like, which is your primary job?

And which is your, you know, additional skills that you bring?

And here, I will add just, I think that there are some software engineers who have this preconceived notion about engineering managers and they kind of view them poorly, maybe because of a past experience that wasn't good.

But I do think that it's very easy to underestimate the difficulty of an engineering manager's work.

Like it's very easy, for example, to say, oh, you know, all they do is sit in meetings all day and like, you know, ask you about like how you're doing.

But like you said, like, it goes way beyond that.

Like 1 difficult conversation can be extremely difficult.

And figuring out how to deal with it, because it's not just a matter of getting through it, right?

There's, you have to make the person grow, or like, it might have all sorts of ramifications.

At the end of the day, this was 1 of my most viewed posts on LinkedIn that I posted a long time ago where I was quoting my other Google manager, which is that, you know, people are, engineering is easy, people are hard.

And I think that that's pretty true, right?

I can easily sit and wake up at 10am on a Saturday and code and code straight through Sunday evening and like barely notice the time go by.

But if I had to do that for 1 on 1 meetings, like I would be exhausted, right?

So that kind of interpersonal 1 on 1 stuff, even if you're enjoying it, and even if you like it, it is exhausting work.

Like it's, first of all, when you get someone to where they want to go in their career, right?

Like when you help someone through a problem, or when someone's not really having a problem so much as they just like, they're like, Hey, I have the skill and I want to get 10 times better at it than I am.

And it clicks and they're happy and the team's happy and they're working well together.

And that's on a good healthy team like when you get good at being a manager and you know how to build a team and how to hire the right people and all that.

And then there's a lot of other fun stuff with engineering managers.

I used to manage The Google public DNS was 1 of the teams I used to manage.

And it didn't occupy a lot of my time because it was just 1 of a few teams I was managing.

But every now and then they would have some really weird outage or something crazy situation.

You get to come in and help out with that.

And it's like, that can be really fun too.

If you like working on a bunch of different areas, like if you like kind of switching mentally between different things, that can be a really fun part of engineering management too.

Yeah and the fact that like you said earlier, like you don't necessarily need to narrow in on a specific problem a ton.

Sometimes you might, but overall you might not have to, but you get to kind of, you know, be plopped into these situations.

I suppose like maybe this segues into this question pretty well.

Is there something that you don't like about engineering management?

Maybe hate is a strong word, but maybe something that really has pushed you at times to reconsider going back to normal software engineering?

Yeah, and I realize we skipped your question about going back to software engineering, so I want to come back to that too, Because I do think that's actually important.

The yeah, well, I think, you know, the hardest part about engineering manager, for me, is when you are in a situation with someone who does not want to work with you, right.

So I practice what's called a servant leadership model, where the idea is the manager is really just there to help the reports, right?

They're there like, you know, I don't want to call it like an API call because you need to be much more proactive than that.

But at the end of the day, each report owns their career and owns a substantial part of the team's health and the team's success.

And the manager's job is to facilitate that.

And so when you have someone on the team who is pushing against the manager, who for whatever reason, personal or professional, is pushing against to the team and doesn't want to or doesn't agree with the process to a point where it becomes problematic, that can be a really challenging part of the job.

And so that's something as an engineering manager, like if you take this role, you're going to have to deal with those situations and you don't get to say no.

You don't get to be like, I choose not to work with this person, because that's your job.

Cause like when I, hosted interns at Google, I got a small glimpse at true engineering management.

I mean, I had amazing interns, but I remember feeling that where there were some days where I just kind of like was in a bad mood.

You know, everybody's in a bad mood or you have a shitty morning or whatever, but you go in that meeting with your direct report and you kind of like you can't get out of it, right?

And even worse, if you if it's like, like you said, if it's someone who's kind of against you for whatever reason, or you have to deal with it.

I feel like that's like people, again, they underestimate the difficulty of that.

They only think that it's just, oh yeah, you're just entering a meeting, super easy, but damn.

No, I do want to touch on that bad mood thing, because that's an interesting point too, right?

A lot of people think if you're an engineering manager, if you're a manager at all, that means you have to always be on.

1 of the hardest things that engineering managers struggle with, and everybody struggles with this at some point, is knowing that it's okay to separate yourself, And in fact, you should, right?

Like I try to take a couple full 1 week vacations every year where I completely disappear.

And then I come back and I see what happened when I was gone.

Because if I'm a good manager and I'm doing my job right, Literally nothing should happen.

And if I come back and it's like, oh yeah, nobody checked in on the stock, so we didn't make any progress or this.

And I'm like, okay, these processes are not set up right.

So you want to make sure that you're building that bench in a sense.

And right, because leadership should be coming from everywhere.

It shouldn't just be coming from the manager.

Like all the suites should be leading in their own way.

All the TPMs and the product managers, everybody, all the different acronyms.

But they should all be leading and they should all feel ownership.

And it's your job to make sure that the processes are in place that that make that smooth and make that keep going so that you can say I'm having a really shitty day I'm not gonna go to work today because I'm not gonna be useful to other people and you can just stay home A little bit harder with an intern though, because that's a tougher 1.

Yeah, because interns, they're here for such a short period of time and you're kind of expected to maybe babysit the wrong term, but to give them a great experience and be there whenever they need questions.

And it's like, you're this, you're this kind of silent bedrock foundation for the team, you know, in a sense.

Was there anything else that you wanted to add about like, if you ever considered going back to Sui or did you touch on that?

And I think every manager also at times wants to switch teams and change teams.

The same way, like if you're a SWE working on a really deep infrastructure project, every now and then you might get a, like, you might be like, I kind of want to go work on a product focused product.

Like you get kind of the same itch sometimes.

So I have a 20% project And I work on the weekends.

And so on the weekends, I get to pretend to be a software engineer.

But I do feel like if I were to become a suite, I, I think that what I would end up doing is just kind of like, becoming an engineering manager.

But wait, when you say when you say the weekends, like, you're, you're doing a 20% project, like for Google, but you happen to allocate your weekend time to it?

Yeah, so 20% projects are kind of a neat thing.

So I'm doing a 20% project in the research space, right?

So 20% projects are things that Google owns them, and they should ultimately be useful to Google, but that is painted with a really broad brush.

See all Clément Mihailescu transcripts on Youtube

What Does A Google Engineering Manager Do? (ft. Tom Weingarten)