TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google – Part II

Technical Program Management Podcast with the author of the popular blog Engineer Seeking FIRE. He has been a Technical Program Manager at Microsoft, Amazon, and is currently working as a TPM at Google.

Check out one of his best posts:-

• Salaries for Software Engineers are On FIRE!

In this podcast series, we talk about:-

1. The speaker’s blog -> Engineer Seeking FIRE
2. The Impact of Covid on our current work environment 
3. The TPM role at Google.
4. How the TPM roles compare across – Amazon, Microsoft, Google 
5. Interview prep for TPMs ?

This is Part -II of the series, and we discuss how the TPM role differs across Amazon, Microsoft vs Google.

The podcast series is divided into three parts.

• TPM at Google: FIRE & COVID Part I
• TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google – Part II
• TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google – Part III

Thank you,

Mario Gerard

Podcast Transcript

Hello and welcome to the TPM podcast with your host Mario Gerard. This is part two of the podcast with the author of the blog engineer seeking fire. He has worked as a TPM or program manager at Amazon, Microsoft and is currently a TPM at Google. We discuss how the TPM role varies across these three tech organizations, and the various nuances between them. So stay tuned. Also, if you haven’t listened to part one yet – here it is

Role of TPM at Google

Mario Gerard: So let’s move into the TPM world. So can you describe for me like what the TPM role at Google looks like?

Mr. ESF: Sure so there are lots of different things that the  TPM covers at Google.  So from a very high-level perspective, a TPM focuses on execution. So we want to deliver products on time, while at the same time making sure that people don’t get burned out. So we want to have realistic timelines, we want to have reliable timelines. And we are responsible to make sure that things land on time. So that’s from a very high-level perspective

Mario Gerard: Pretty much very standard right? across the industry. Google follows the industry standard of the general rule definition of what a TPM is across all the tech companies in general.

Mr. ESF: That is correct. And I can go into an example afterwards, if you want.

Challenges for a TPM at Google

Mario Gerard: Sure. Yeah, let’s do that a little later. What are the biggest challenges you think, you know, a TPM would face starting at Google?

Mr. ESF: And so one of the important things to know about Google is that Google is engineering driven. So there is lots of feedback by the engineer. So the engineers are kings of Google. if you want to call them like that. And so what you need to do as a TPM is to prove value to the engineering team. And each engineering team might be different. So one team might be doing Agile, other team  might be doing more waterfall, another team might be have different tools to track things.

So it’s very, as a TPM, the most important thing is that we need to adapt to whatever the TPM, whatever the engineering team needs, and also at the same time, we need to prove our value. So it’s not that okay. And you guys follow me, there’s no such thing. It’s I need to prove my value and gain more credibility within the team. And that’s how the team will trust me and that’s how we can move from there.
So I think it’s very, the most important thing is proving value. I think that’s how I see my job proving value and making sure that people see why I have an important position in the table. So that’s one thing. another thing is that there is no standardization. So there’s no, there are no standard set of tools that, there is no guidance saying, Okay, this is the tool that you need to do to create your project plans or this is a tool to send email. So this is the template or whatever.

So every TPM has to,  First of all, there are multiple tools, it’s not that there are no tools, there are multiple tools, and every TPM has to figure out what works for them. And so what tools works for them, what processes work for them. And then after you figure it out, then it’s about making sure that the engineering team sees value as well. So the fact that there’s no standardization is kind of a double edged sword. because there is nobody telling you what to do. But at the same time, if you figured out what you do, then that’s how you prove the value. And that’s how engineers will say, Yes, I want to work with this TPM, because she knows what he’s doing. The tools make sense, the process makes sense. So that’s another important thing for Google. Then the other part is the technical stack at Google.

There are so many different stacks, different tool sets. So as a TPM, you need to understand what’s happening there and that’s why there is a T in the TPM. There’s a technical program manager, there are also program managers at Google supposed to have both roles.  as a TPM, you need to understand the technical stack, you need to be there when people are talking about when they are creating a design when they provide feedback for design, the TPM needs to be there and needs to be very cognizant of what’s happening and when somebody goes into tech talk when the TPM needs to be able to provide value there as well.

So I think these are kind of the biggest challenges with Google. So the sort of digestion, proving the value and then the technical stack are the three of the biggest challenges.

Mario Gerard: Main challenges. When you spoke, when you started off talking about Google, you also said it’s a very engineering driven bottom up culture. Can you like give us some examples, because I’ve heard it from so many people. And I have my own idea of what that is. But I think it should come from you of giving us an example of what engineering driven bottom up culture means.

Engineering driven bottom up culture

Mr. ESF: So I think if you look at historically, Larry & Sergey who are the Google founders, they were Stanford, they are graduate, so they came from engineering. So from them, the most important part was to build a great product. So building great products was awesome. So that’s what they want to do. And they had lots of great engineers, and they were focusing on making sure that design is great, and the product is great. And all sorts of complicated problems are solved. And then slowly, slowly, they started hiring other functions like product managers, and program managers. And then it was for every new function, they had to prove themselves. And very often, it was always whenever there was a conflict between let’s say, the product management team and an engineering team, the engineering director would have the final say instead of the product manager.

So if you think that google products, still most of them are consumer based products. So what this means if you look at gmail, if you look at, say, Google search, the are use by consumers, whereas for example, if you look at different companies let’s say Microsoft, most of Microsoft’s products are enterprise driven. For example, office, mostly used by enterprise. so there’s a very different set of problems there. So from perspective of Google and why they are engineering driven, for example, it’s more important in the consumer based world to have a product that is well designed, scaled correctly, and has good quality, fun to actually time, if you look at gmail, Gmail was in beta, I don’t know for…

Mario Gerard: How many years was that?

Mr. ESF: So it was way, way more important for the engineers to make sure that works correctly than to actually launch. so as a product manager, so maybe as a TPM, you want to learn, you want to say like, Hey, we’re launching, let’s say next in the next year, or we’re launching in September or whatever. But in Gmail, as we talked about the beta, it was way more important to launch when things are done than to launch on a specific time frame. So these are, this is something where the engineering driven mindset shows a lot more. I think Gmail is one of the top examples.

Mario Gerard: And engineering excellence, right? It’s about all about how solid is your engineering excellence and how reliable is the backend system, rather than focus too much on the front end, or front end product management side of things?

Mr. ESF: That is correct. And Google engineers are great engineers, very smart mind. So they are facing lots of scalability issues. Lost of reliability issue and obviously Google is known for scaling up, you know, Google about how many billions of searches. So there are so many problems, and people like to solve all the problems, and making sure that the products are great, the customers are happy with those products. And you know, it’s also engineers become very passionate about solving these types of cool problems. For example, you know, I might love to scale if I was an engineer, then I might love to scale something from let’s say a million customers to billion customers.

So I’m very happy to work on scaling up the infrastructure. And that might take much more, you know, until I’m done, I might not launch when I said as a TPM and a TPM, give me a timeframe, I might say no, I launch whenever I’m done. So I might find new problems, for example, as some.  Yes, as I’m thinking through it, as I’m testing, there might be new problems. So it’s more important from the engineering side to launch when we are done than whenever.

So that makes the TPM roll a little bit complicated because sometimes it’s very difficult to get an actual date from engineer, they might say, you know, I launch when I’m done, or ask me three months when I have a better understanding of the problem. So that doesn’t always help. So that is part of the challenging aspect of the Google work. but I think Google is getting there and is getting into the, there’s a balance, there’s obviously a balance.

Amazon vs Google – Work Culture 

Mario Gerard: That’s very interesting, right? So, as we talk about company cultures, I think each company brings out different attributes, they have a different personality. and each personality probably has its own advantages and disadvantages. And that puts them there. So it’s kind of interesting to see how that works. So since you’ve worked with Amazon as well, so how does the Amazon culture and the whole Amazon ethos differ from what we just spoke about at Google.

Mr. ESF: So Amazon is very different. So we talked about Google being more engineering driven, Amazon is much more pm driven, much more data driven, much more top down, there are more aggressive timeframe. So if you think about Amazon, Amazon has approximately 40% year over year growth.

Let’s say they make hundreds, let’s say they make $10 billion. The goal is next year, they have 40%. More. So now it’s 14% sorry, 14 million or billion dollars. And then the year after that’s another 40% growth. So now we’re in $20 billion lane. So within two years, they have to produce double the revenue. So this means that when the Amazon has to provide way more products, way more features, and there’s also lots of metrics that go behind them. So with the tracking everything in order to make sure that this happens, you know, way more fine grained data analysis than other companies. And at the same time, though, this means that there is more pressure and themes and individuals to perform.

So if you need to, you know, just that what you did two years ago, might be totally different from the requirements for today, because today, you have to produce twice more things as you did two years ago. So you need to find ways as a person to scale. At the same time, you need to help your team to scale. And you need to find ways to solve problems in a way that you multiply the effort. So just doing the same thing year after year. And let’s say you’re in year one, you got a great performance Three years later, two years later, you might be falling behind just because you need to perform twice as much. And that’s I think, is different.

Obviously, Amazon is a great company, obviously they’re launching new things very fast. So their AWS and other products as well. But they’re focused on providing on producing things is just amazing. So, again, there are two points, two views for this. It’s aggressive timelines, teams working up close to capacity or at capacity. And then there might be dependencies where you might depend on a team and the team might be overworked. So it might be difficult to schedule stuff. However, you know, at the same time, that’s how you produce that’s how you, you know, when you increase the revenues, that’s how the company grows. And another thing to point out is that you know, the Amazon is a PM, a TPM and an SPM. So from a high level perspective, the TPM role, as a TPM role is similar to what we have at google So you work with a product manager, you work with a technical, without a technical product managers, you work wit the software manager, software engineering manager. So from a high level perspective, the role is very similar.

At the same time, though, the day to day tasks are very different based on what we said, you know, Amazon is it’s a very top down very hierarchical, whereas Google is way more bottoms up, as we said. Also, one thing is that I forgot to mention about Google is that, in google, the term Googler is very important. So when you start you have, you’re a Googler, so you’re kind of protected, you are in a bubble, and for six months, your main goal is there to learn. Your level doesn’t matter. you’re there to learn. So you’re you might be protected from lots of things, you might have, you know, the goal is to do whatever you want to do in order to learn and productivity is kind of secondary. So That’s very important for Google. And then even after that you are hired to be a Googler.

So you can change things, even maybe without the interviews just because you are a Googler. So everything trusts you. So you might just talk to the hiring manager. And then the next day, you might be switching things if your is good for example. So in Amazon, you need to be productive. So just because there is always aggressive growth, and all these needs for additional people, from week one, you’re asked to make decisions, you’re asked to be productive, you are evaluated, and then your actions are being evaluated from day one. there is no better or worse. It’s just that this is what’s happening in these two companies.

Mario Gerard: Yeah, it’s very different. And I know that I think at Amazon, generally they say if you make it through your first year, then you’re going to be all set. But there’s a large percentage of people who don’t make it through the first year, because the expectations are either too high or whatever reasons, right. But the first year is make or break, you know, whether you’re going to do well at Amazon or not. So that’s like very different from what you mentioned that Google where literally for the first six months is, you know, you’re given the opportunity to go and learn and discover things, and even change teams. And then probably even the first year right is almost written off.

Mr. ESF: Yes, there’s lots of value on helping the employee learn and take their own pace and figured out what Google is about and in order to be productive. And that I think pays in the long run, as with Amazon is more aggressive, so yes, I think many people leave within the first year. And the people who stay for Amazon, they love Amazon, and they you know, they might stay, for 6, 10 years. And maybe there’s also a filter, because I think what  I’ve heard, obviously haven’t been on Amazon for quite some time now. But what they’ve heard is that, at this point, Amazon, it’s way easier from the interview process to get hired at Amazon, at the same time, for example at Google or Facebook or anywhere else. But at the same time, at least one of the big companies, but at the same time, it’s more difficult to stay there for a long time.

Mario Gerard: To survive.

Mr. ESF: Amazon culture there.

Mario Gerard: Yes, to survive at Amazon, I think is definitely what I’ve heard from my friends and colleagues. It is definitely a much more strenuous environment in general. That’s maybe too much generalizing.

Mr. ESF: I think that’s a very valid point, it is a great disclaimer there. I’m sure that there are people who are listening to this from either Google or Amazon, they’re like, what is this guy talking about? You know, I’m working at Amazon, and I’m working 20 hour weeks. And then you know, I take vacation whenever I want, I am going to Hawai every weekend, obviously there are things like I think we’re generalizing here. So things are on average. So it’s not that everything is very stressful on Amazon. Everything is just rosy at Google. you know, it’s mix and match however, I think this is more of a generalization. So thanks for pointing it out. I want to clarify that as well.

How is Microsoft PM culture different from Amazon and Google?

Mario Gerard: Good time to put in a disclaimer. So let’s move into the Microsoft. So you spent quite some time at Microsoft, right as well as a pm and as the [18:31 inaudible] as well. So how is the Microsoft world so different from the first two companies we spoke about?

Mr. ESF: So Microsoft, is quite different from multiple perspective. So first of all, Microsoft doesn’t have a TPM role, they have a program manager role. And this program manager role does, kind of has to wear both hats, both of the product manager and of the technical program manager. So as a program manager at Microsoft, you have to do the product management work, like defining the product, handling KPIs, talking with sales, talking with all sorts of marketing, making sure that the product looks great, and making all the product based decisions. And at the same time, you need to be the TPM where you figure out okay, when are we launching, create the project plan, do all them maybe even do with a good engineering manager. So it’s kind of a mix.

See also – Microsoft program manager interview

So it’s one little way you do both things. And so that’s a huge difference. And it’s very difficult as a kind of a Microsoft program manager to do both. So cannot do a full product management role plus a full technical program manager role. because the same position in another company would need two people. so ask one person you cannot obviously scale from one end to the other end.

So you kind of have to figure out what are your priorities there and in some things Program Manager works more as a product manager where as in another team, they might work more like a technical program manager. And it also varies based on the product lifecycle. So maybe in the beginning of the product, the more product management work, and then as time goes by you do more technical product management work. So that’s it changes us as time goes by. So that’s a very big difference. Yeah,