TPM Podcast with Ethan Evans

This is a podcast with your host Mario Gerard and with guest ‘Ethan Evans’. Ethan has been with Amazon for 15 years and is the VP of Twitch Prime. Ethan humbly says “I consider myself to be a TPM….” though he has been a VP for over 8 years.

We talk about the role of a TPM at Amazon, resumes, leadership principles, gaining influence, TPM competencies, executive communication, career transitioning from a Program Manager to a Technical Program Manager and so much more.

It’s one of those episodes that has an incredible wealth of information and Ethan articulates so very well.

Mario: Hello and welcome to the TPM podcast with your host, Mario Gerard. Today, we have a very important and interesting guest with us, Ethan Evans. Ethan’s been at Amazon for 15 years, he’s led several teams from Twitch, Prime, Digital Content. He’s currently the VP at Amazon and I’ll let him introduce himself.

Ethan: Hi Mario, thank you for having me on and everyone listening, I’m really excited to get the chance to share some of my experiences. I have been a VP at Amazon for the last seven years, been there for 15 years. Prior to that, I worked mainly in startups and then coming into Amazon, I had the chance to kick off and be the first engineering leader on Prime Video. Since then I’ve worked in games, I built the Amazon app store where I lead a global team of about 800. Then I went on to work in Twitch, the gaming subsidiary, when we bought Twitch and now, I lead Twitch Prime, the gaming pillar of Amazon Prime.

15 years at Amazon and more

Mario: Oh, that’s fantastic, 15 years at Amazon, that’s something to say. You also have a second life, you are also a coach, you coach a lot of people on Twitch and on YouTube as well, right?

Ethan: Yeah, that’s right. I was looking for how I could use our product and Twitch, of course, is normally used to stream video games. I thought, well, I’m not a good enough gamer to be interesting that way, but what could I use the platform for that I’m passionate about and I could really lean into. I do a lot of one on one coaching and it wasn’t scaling anymore, I had so many people asking me for coaching that I couldn’t take them all on, so I thought, well, let me do it in this live, interactive format. So, yeah, I have a Twitch channel under my name, Ethan Evans, and I generally stream once to twice a week. It turns out my specialty, that my audience loves, has become resume and LinkedIn reviews, helping people represent themselves and explaining how to attract the eye of a hiring manager.

Mario: I’ve seen some of those, it’s fantastic. If you haven’t seen Ethan’s Twitch channel you should definitely check it out, it’s very sharp, it’s very pointed and very precise advice on what you need to do. Then you also almost do it in 10 to 15 seconds, which is what I always feel a hiring manager takes to look at a resume, he’s not going to look at it for more than 10 to 15 seconds, at least at first glance.

Ethan: That’s right. If you don’t do something to hold the attention, the way I explain it is on a resume, every line has to earn the person reading the next line and you have to capture them in the first few lines on a resume. Hiring managers see so many resumes, I think in my career, I’ve reviewed over 10,000 and you just get very quick on skimming them. If your resume skims badly, on to the next one because there is, unfortunately, an unlimited supply of competitors for any given role.

TPM role and the culture at Amazon

Mario: Yeah. So, in this podcast, we’ll dive into what a TPM, a technical program manager role looks like at Amazon and that’s probably the first topic which we probably hit at. So, Ethan, can you explain to us what’s the culture at Amazon and how a TPM role fits into that culture?

Ethan: Yeah, I can do my best. The first thing I have to say in fairness is Amazon is approaching a million employees. Explaining anything and saying this is the Amazon culture is a little bit difficult on that scale, but Amazon’s culture is defined by a set of 14 leadership principles that you can find online. If you just Google Amazon leadership principles, they’re public and you’ll get a list. Many companies, the leadership principles or whatever the equivalent, is just a poster on the wall in the kitchen that no one looks at and really pays attention to. At Amazon, they are built into how we hire, everyone is interviewed against the leadership principles, built into how we manage, everyone’s review is based on the leadership principles and they’re used as a shorthand.

So, software engineers will be familiar with the idea of design patterns, of basically atomic units of code that you can shorthand to describe a whole concept and say, oh, this is a singleton or a class factory. For Amazon, the leadership principles serve the same way, they give a quick, bite-size version of our culture, so if you want to understand our culture, you look first at the leadership principles. The second thing I would say is Amazon is very, very hard charging, we have a reputation, some of it earned, some of it not earned, about being a difficult place to work. I think it’s very fair to say Amazon is incredibly results-oriented and you’ve got to want to work in that result’s first kind of climate. If you do, you will absolutely thrive, if that’s not the right climate for you, it’s not the right fit.

TPM role at Amazon

Mario: Cool. How would you describe the TPM role at Amazon?

Ethan: I think I look at the TPM role as owning when something is going to get done. In my mental model, there’s a product manager, and the product manager is the owner of what the team is going to do. So, they’re looking at what the customer needs, what the team is shooting for, what is its goal. Of course, everyone has input and opinion and that’s fine, but in the end, the product manager owns what we’re going to do. The software development manager owns the details of how we’re going to do it, the final analysis of how this is going to be built. The TPM sits in the middle and is translating both the ‘what are we going to do’ into the top-level technical plan and then specifically, the win.

How is this going to stack up? What are our dependencies? How are we working with them? What is the schedule? What is the phasing of sprints or releases or versions? So, they’re driving the project to get the thing to shipment. I want to say early in this conversation, I consider myself to be a TPM, so as a vice president of technology, some of my peers would say that’s completely wrong, that they are vice presidents of software engineering or software development. My core skill set, the thing Amazon has always valued me for is getting products out the door. When I think of my core skill set, I am a TPM because the TPM’s job is to get the product out the door.

Where does the TPM report to – Single threaded leader

Mario: That’s amazing, the way you phrase it, that’s really beautiful and that’s what I feel TPMs are. If you ask me what the core responsibility is, it’s getting the job done. It might be a small program, it might be a large program, it might be a program that might be impossible to do and that’s pretty much what you’re given and you’re going to go and execute on that. In an organization, where does the TPM report to, who does he report to in general? What are your thoughts on TPMs reporting into TPM org’s or TPMs reporting into their managers?

Ethan: At Amazon, there’s no one organizational model, we favor something called a single-threaded leader. A single-threaded leader is the idea of having all the resources for a given project reporting to one leader. That leader can come from a business background to be non-technical, they can come from a tech background and be a former engineer of one form or another. Generally, we avoid program management offices, they start to become large, centralized bureaucracies and we don’t like that, we like this structure where everybody is in one team. So, the TPM may report to an STM or they may report to a leader where you have an STM, a TPM, and a PM reporting to the so-called single-threaded leader. I think what’s key is the TPM has to have ownership over getting the job done, they have to be the person who is saying, this is what it’s going to take and this is when it’s going to happen and then driving towards that.

Across organization programs

Mario: When you have TPMs running programs which are across organizations, how does that work at Amazon?

Ethan: That’s a good question. I am normally making new products, so I have relatively fewer cross functional TPMs, but I have worked as a part of that structure. The biggest example I could give is when I ran the Amazon app store and we were launching Kindle tablets, those had to bring together all the apps on the tablet, all the hardware, all the software, and those were huge teams. So, we did have very high-level TPMs and even teams of TPMs working to track all those dependencies and sort of roll up the central schedule and they’re always working. The key role of the TPM, in that case, is to prevent slips, what do you do when one team is going to make 40 teams late? So, that becomes the central job they’re trying to do.

I think in that place, the TPM’s job, (a) becomes a lot of influence, they need to be tight with everyone and (b) becomes a lot of diligence staying on top of whose schedule can I trust and what are the warning signs? It’s not that anyone ever purposefully lies, but the engineers are famously optimistic, so TPMs have to be really good at sniffing out when is your green and yellow? We have this funny name for things inside Amazon called a watermelon goal and I never knew what it was, it came up in the last couple of years. A watermelon goal was a goal that looks green on the outside but you cut it open and it’s red and people are reporting green, we’re green, we’re green, but you scratch the surface and it’s really that they’re red and they are having trouble admitting it either to themselves or others, so the TPM has to find the watermelons.

How to gain influence as a TPM

Mario: Yeah, that makes a lot of sense. You also spoke a little bit about influence, how do you think a TPM should gain that influence? What’s the best way of gaining that influence of people or teams?

Ethan: Influence is always earned, not given, TPMs in our org and DNA, I think commonly, but they never manage the resources who are going to do the work. So, they have to be able to influence and influence comes from being respectful in the sense of listening, of being helpful, and that I’m not just here to beat you up about a date. I’m here to understand where you’re at, to actually understand the challenges you face and add some value to what you’re doing, whether it’s information or suggestion or technology or help. What we don’t like and we don’t have is project managers, we have program managers and the key difference is early in Amazon’s history, there used to be a somewhat derogatory term for what they call the clipboard carrier.

So, someone who just came around and wrote down status but added no value. So, the key to earn that influence is to be a source of help, whether that help is better architecture or that help is providing resources or escalating conflict or giving clarity. TPMs earn influence by being useful and if they’re just saying, what’s your date, tell me your date, I need to report your date, they are paper pushers and that won’t get you anything.

Mario: I think it’s adding value to the people you’re reporting into and at the same time, adding value to the teams that you’re working with and you need to do that both ways.

Ethan: Yes, I agree.

Product Manager vs The SDM vs The TPM

Mario: You also spoke a little bit about the difference between a product manager and the SDM and the TPM. It was very clear when you said the product manager owns the vision and what the product should look like and the product should do. Then the SDM owns the architecture and the design?

Ethan: Well, they definitely own the final implementation. I think sometimes TPMs get into the architecture and we respect very much the TPMs who are able to be architects across products, but often that’s left to a principal engineer. The key for the TPM is to be able to follow the architecture and importantly, to figure out the implications of the architecture. So, a good TPM can talk to the engineer and say, oh, well that means we’re going to have to make changes in whatever, the file system, the UX. So, the TPM can help turn that into what does this architecture means? Which groups do I have to get ahead of? Who has to scale up? Who has to make changes?

Like everyone in life, I have projects slip and one of the ways they slip is it turns out nobody thought to ask so and so team whether or not their system could handle the change. So, you discover late in the cycle, well, we got far down this and then we started testing and the system downstream fell over because no one worked with them on our new load. That’s where TPMs work tightly with architecture, they have to know, well, who does this architecture mean I have to talk to? Going to your earlier point about cross-team, where TPMs are super valuable is knowing who does this impact and talking to them in advance before it lands on their plate.

Mario: Sometimes I think being in a system of being in an organization, you know all the ins and outs, it’s very easy, right? So, you know if something like this is going to happen by past experiences, you know that you need to go talk to people XYZ or teams XYZ. Sometimes they are fairly new in an organization where you don’t have that luxury.

Ethan: Yeah. I think a lot of jobs are aided by tribal knowledge or by organizational knowledge, but I think TPMs, it’s fairly strong because of knowing where the dependencies are. Also, frankly knowing which teams are going to have a hard time making changes and which aren’t. In other words, in every company, there’s the one team that because of where they sit, their code and their projects and their services are like spaghetti and they’re very fragile, then there’s the other team that’s like all on top of it and can pivot on a dime. The TPM who has been there a little while knows who they better get to first in the cycle because it’s going to be hard. If you’re new, you can be smart but there’s no substitute sometimes for experience.

Mario: Yeah. Your previous point to influence, of TPMs having that influence and knowing what’s going to work and what’s not going to work, I think that also changes if you have more tenure within the organization.

Ethan: Just to add, a really key trait for a TPM, therefore, is to be curious and go dig into things yourself. That’s why some level of technical acumen matter, it’s why the T is in TPM, you’ve got to be able to go dig in, whether it’s read the Wiki, read the code, talk to an engineer because if you’re new, you’re going to have to learn on your own. At least at Amazon, nobody is going to teach you, TPMs are never straight out of college in our organization. They’re already experienced either is TPMs elsewhere or are engineers who choose to go down the TPM path, so they’re very much expected to be able to figure it out, to self-educate. You and I agreed that a TPM’s job is, quote-unquote, to get it done and part of getting it done means to figure it out. If you’re someone who wants your work handed to you on a platter and go do what has been set before you, that’s not a good match for a TPM. If you’re a person who’s like, no, no, no, I like pulling on the loose threads and figuring out how stuff work, I’m the person who disassembled everything in my house to see how it works, that’s more the TPM tray.

The ‘T’ in the TPM

Mario: Got it. To follow up on that, you did mention the T in the TPM, how do you see the T across a spectrum of a very, very low T versus a very, very high T, how do you see those candidates across what you’ve seen at Amazon?

Ethan: Earlier at Amazon, there was a very hard bar, a very firm that said a TPM should be able to write, code, and build systems at an equivalent level of an entry-level software engineer. So, if you couldn’t take the seat of at least an entry-level software engineer, you weren’t considered qualified. That’s been flexed a little bit in places over the years. One place it was flexed was we started doing things that weren’t software and we needed TPMs. Being able to write software if you’re going to TPM a hardware project is not as useful. So, it got moved in those circumstances to say, well, no, they just need to be technical in the domain.

I think this is a hard question to answer and the reason it’s hard is some TPMs could be a little bit more high level in their technical knowledge because they’re incredible influencers. They’re incredibly quick at detail and providing value or earning trust with teams through their encyclopedic knowledge and energy. The fundamental is you’re going to work with engineers and STMs, you need a way to hold their trust. If they think you’re clueless you’re not going to get anywhere, so you’ve either got to be extremely influential, like naturally good at getting engineers to be patient with your thinner technical expertise, or you’d better be technical enough that engineers don’t have to repeat themselves.

Engineers will explain slowly to people they like, and they’ll explain quickly to people that follow them. What they won’t do is explain slowly to people that they don’t like, they’ll just flip the bozo bit and then you’re done in that role. So, I realize I’ve hedged the answer, but either you better be naturally outgoing or technical, ideally both. I know because we talked about what we might discuss, it’s very hard for completely non-technical people to break into being TPMs in a technical institution, that is not a very easy path in an Amazon which prides itself on being hyper-technical.

Mario: Yeah, and when I try to classify companies when I talk to people, I try to classify them as tech companies versus non-tech companies, not to say that banks aren’t technical. In my opinion, most banks, mobile carriers, and those kinds of companies, the primary use of technology is more of an enabling function rather than using technology to differentiate itself. That’s what I see Amazon and if you look at Netflix and Google, these fine companies, in general, have used technology to differentiate themselves against the competition. In these kinds of companies, if you are coming in as a TPM, it becomes incredibly important to be as technically savvy as you need to be.

Ethan: Yeah, I agree with you strongly and it’s funny, I would have, I’m going to use the word picked on, I would have picked on banks too. When you started talking

I thought, oh, banks and you’re right. The key is, just echoing what you’ve said, different words, are we building technology to invent something new that’s a technology product, or are we harnessing technology to better deliver a business service? Banks are delivering a business service and so you need it. In that case, what you need to understand is block-level architecture so that you can stick together components to create a solution. The simplest way I can think of to express the difference is, am I sticking together blocks or am I inventing what’s in the block? Because if I am inventing the new thing that’s going to be someone else’s block and that’s the product, you better be very technical. If what I’m doing is taking off the shelf blocks and working with my developers to kind of glue them together like Lego to make a car then I can be a little bit less technical. I think largely that’s the bank versus Fang company distinction.

TPMs needed to write codes?

Mario: That’s a very interesting way to think about things. Coming back to the original question, you said that originally TPMs needed to write codes.

Ethan: They were tested like an SDE, they were tested and that’s backed off, I would say it’s rare now for a TPM to be handed a whiteboard marker and asked to reverse the link list or something. I won’t say it never happens because again, different groups have different expectations. Mostly, TPMs will be asked architectural type questions to block diagram something, to talk about how they handled an outage or how they handled the last time their team needed to choose between stacks or technologies or language or deployments, they’ll be asked more tech process questions.

Mario: The reason for that is so that this TPM coming into the organization can have a well-educated, well-rounded conversation, and provide some value if possible, with the development organization he’s working closely with.

Ethan: Yeah, it can earn trust, it can hold the trust because we can say some engineers who do this shouldn’t be this way. For a lot of engineers, if they feel like the person they’re talking to can’t track the conversation and is asking clueless questions or misinterpreting things or misrepresenting them, they will stop engaging, they’ll start giving very superficial answers and it’s not meanness, it’s hard. If you’ve ever spoken to someone in a country other than your own who only has a limited command of your language, or you only have a limited command of their language, after a while that conversation becomes frustrating. Yes, it’s enough to order dinner and for you to tell me where the bathroom is, but we’re not really going to discuss philosophy if you don’t speak my language very well or vice versa. I think for a TPM to be successful, they need to go deeper than I would like some pizza for dinner.

Scope at different TPM Levels

Mario: Yeah, that makes sense. Let’s move on, so if you think about different levels of TPMs, can you talk a little bit about how Amazon looks at levels, and what is the impact and scope that TPMs at different levels handle?

Ethan: Yeah, so in many ways, probably 99% or 98% of all TPMs at Amazon fall into one of three levels. We have a level five, level six, and level seven, level seven is also called principal TPM. A level five TPM is generally working with a single team or a very small number of projects. A level five TPM would typically be someone who’s been a developer for two to four years and has decided they want to move to the TPM role, it’s not the only way but it’s the most common. So, they’ve got two, three, four, five years roughly of development experience, technical experience, and then they want to get into program management. This person may often serve as the scrum master, that’s a role that often overlaps with TPM because you’re responsible for clearing the blockages and keeping track of where the team is and organizing.

Generally, there’ll be working internally or with a small number of teams and on a relatively contained or defined project, not that the project may not be hard, but we won’t give them some spiraling pool of dependencies. The next level, which we call level six and gets called a senior TPM, the senior TPM may still act as a scrum master but is commonly working across several teams and a larger number of dependencies. So, they may be coordinating with five, 10, 15 teams, they may also be more in the role of reporting up to executives. Not that they’re hard line reporting but they may be the answer person when an executive says, oh, where is project Fu or what’s the problem with project bar? The TPM may be the one to step up and say, this is the exact status and handles that.

The last level, principal TPM, which is also level seven, principal TPMs are responsible for very large projects that may span dozens or even hundreds of teams. So, an example I think I can offer is when Amazon launches in a new country, so I’m going back ways. When we stood up Italy and Spain as marketplaces, we hadn’t previously done business in Italy with a Dot-IT appendage or domain, that took approximately a hundred different Amazon teams to fully bring Amazon retail natively to Italy. Well, that’s a principal TPM’s job and that principal may have several other TPMs or even a lot of other TPMs working with or supporting him or her. The job of running the year-long project, to coordinate a hundred teams, to start a new marketplace in a new country, that’s the scope of a principal TPM, obviously, that’s a big, hairy project.

Mario: Would you say that approximately 90% or 80% of TPMs are generally senior TPMs and they’re probably like four or five percent principal TPMs?

Ethan: Yeah, a small number. I don’t know if you wanted me to cover this, but from that point, the next level would be our level which is the director level, there have been and there are a few directors of technical program management. An example of one of them I knew, he ran program management for all Kindle products. So, E-readers, tablets, fire phone, fire TV, he was responsible and had an org of program managers responsible for making sure all those devices come out on schedule. There is still an up from there, but that would be like less than 1%. The rest of the technical program managers, they migrate to being what I called earlier, single-threaded leaders, so they branch out to owning, I’m going to own the engineering resources, I’m going to own the product management resources. I’ve built my career on delivering things, now I’m truly going to own delivering them, I’m going to own getting them built and getting them defined, they branch out in that way.

Mario: They become leaders of products or leaders of services.

Ethan: Correct and that’s what I did right. I came to Amazon as a software development manager, but I said, I consider my core skill set being a TPM. Over time, I’ve moved from being a software development manager to being a general manager where I own all kinds of functions, whether it’s marketing or business development or things that are very unusual. That was a process of expanding out from a core of shipping thing.

Going to the next level at TPM

Mario: Got it, that’s super cool. When you have a level six TPM or a level five TPM, a senior TPM, what does it take to go to the next level?

Ethan: Trust, executive trust. In other words, the leaders above you have to believe this person is going to be able to tell me reliable truth. What I mean by that is they have to believe that not that you can get everything done or solve every problem, but that you won’t let problems go hidden or fester. You will raise your hand early enough to either reliably say, no, we’ve got this, it’s going to ship on time or, hey, this is not on track, I need help, we need to change this. They’re going to be looking for good judgment and then they’re going to be looking for incredible proactivity and grit. More than any role, because I’ve said the TPM is responsible for delivery, the TPM is the one who kind of never says die, who never says this slip is unrecovered. Not never, of course, but fights as hard as possible to say, okay, we’re behind, do we need to move the date, or can we move that up?

Okay, we’re under-resourced, do we need to ask for more resources or slip the schedule or is there some place we can get clever or what can we cut and who can bring together the meeting quickly? I think for TPMs to get promoted, you have to be seen as this person who fights to deliver and that trait at Amazon, of course, is super highly valued. I think at any company, I remind all employees, you’re not paid to do hard work, you’re paid to deliver a solution for customers, to deliver a result. A lot of people work hard but the actual thing you’re rewarded for is did you bring value because just being at your desk 90 hours a week is a type of martyrdom, but in 40 hours a week or 50 or 60 or 90, did you cause the result to happen? So, TPMs who cause results to happen get promoted, that’s the simplest state.

Mario: Yeah, that’s a lot to decipher, I think, several good points though. So, you said be proactive, have grit, always speak the truth, and don’t let things fester. When you do come across a problem, be as resourceful as you can to get to the bottom of how you can solve that problem rather than just take the problem to your executive leadership, and chase things down so that you get most likely positive results.

Ethan: Yeah, and listening to you replay that, I agree with everything I said, and they all are a little bit variation of each other. They’re all about, as I said at the beginning, never giving up, believing that delivering matters and then doing it in a timely way matters and that that’s your job and you’re going to try everything you can to make that happen. I think TPMs need to be a combination of realist and optimist, they need to be realistic about what the state is, but they need to be very optimistic of we can solve this. It’s that relentless drive to results that is the core of everything I said.

How should TPMs communicate and engage?

Mario: Makes sense. Thank you for that, that was really a really amazing. Moving in the next large topic which is how to engage with executives, what’s your take on how TPMs should communicate and what are the big things they need to keep in mind as they grow and as they communicate more with executives?

Ethan: Yeah, I thought about this question a little bit ahead of time because you had shared it with me. I think two things, one, give executives a TLDR, in other words, executives worry a lot, it’s kind of what we’re paid to do. They want to know upfront, is this good news or bad news, like is the top-line summary, this project is on schedule or is the top line summary, we have a problem and it’s beyond our ability to handle and this is a request for help, so they want to know right away which bucket is this in. The second thing I would say is reliable communication, meaning frequent. If your executive is at a company like Amazon and is tuned in, the executive has two choices, he either gets information from you or he has to pull you and ask for it.

You may feel like you’re mailing your status reports into a black hole because you don’t get a reply on every one of them or even any of them. That actually can be good in that if you have an executive that you know is reading them, if you tell me what I need to know as an executive, I won’t bother you, but if you don’t tell me and I’m on top of my job, I will ask every time. There’s a saying ‘no news is good news’, but in fact, that’s never true, no news means terror because I don’t know where something is. Just like your job is still to deliver your project or your product, my job as an executive is to deliver everything in my portfolio.

Mario: That might be a hundred different things.

Ethan: It might be and that’s why I want that simple TLDR. Let’s say I have a hundred projects, I can’t read the details of a hundred status reports, what I can do is, let’s say I have 10 to make this simpler, I can read the first nine that are green. No, we’re really green and you’ve worked with me and you can trust me, this is green, green, green, green, green, red. Okay, better read the rest of this one to figure out what to do, green, green, green, green, yellow. Okay, read the yellow, how bad is it? Do I need to get involved yet or do they have a plan? I’m literally cycling through in my head what things do I need to worry about today. What I need from you is, tell me if you’re on the worry list or not and do it reliably enough.

In this example I just gave you, what’s even worse is green, green, green, red, green, green, red, no report, no report, no report. With the no reports, I have to assume they’re red because as a leader, I can’t just blindly say, well, they’re probably green. The other thing that scares me about that, if I’m reading a report from you that says this is red, at least I know. If I don’t hear from you, I don’t even know and I have to remember to remember, meaning, oh, I haven’t heard from Mario in two weeks, I better ask. That’s scarier to me than getting a red because red, at least I can get on with you. You’ve recognized it’s red, you’ve told me I can jump on it with you and help you. If you’re silent, then I remember three weeks later and I ask you and you’re like, oh yeah, it’s kind of not going that well, now we’ve lost that time and I’m less happy.

Mario: We could have fixed it three weeks earlier.

Ethan: We could’ve fixed it three weeks earlier if you told me. So, I would say escalate early, you don’t want to be chicken little and running your boss all the time and saying it’s red, it’s red. If there is a problem, I need to know early because my job is to help. Now, I talk about this a lot on my channel, some people have bad bosses, there are bad managers whose response is to punish, why is it red? What have you done wrong? Well, that isn’t a good environment and if you’re in an environment like that, I encourage you to find other leadership. A good manager, they want to know there’s a problem so they can help. They may ask you what you have done about it and they may push you to do more about it, but a good manager is never like, oh, you brought me bad news now I’m going to rage at you, that’s a terrible leader.

Working on programs with executive visibility

Mario: Yeah. How do you get to work on programs especially if you’re just starting out as a TPM, how do you get to work on programs which have some kind of executive visibility?

Ethan: Great question. I have a saying I use a lot, that results are the currency of credibility. So, people who get things done are rare, people who drive and have the traits I listed earlier, the grit, they aren’t that common. It’s sad in our society, but a lot of people want to do the minimum work and, unfortunately, they only have a limited amount of drive to deliver, so deliver a couple of things in whatever capacity you’re asked for. If you’re asked to take out the trash, take out the trash super reliably, but then talk to your manager and say, hey, I’ve been really good, I think, about taking out the trash, have I been good at it? Am I doing that well? Great, I’d like to do something of more impact. What do you need done that I can help with?

Remember, this is very important, I said earlier, managers worry a lot, executives worry a lot, they always have a list of worries. The powerful question is, what are you worried about that I can help with? I can guarantee you, any executive worth a damn is worried about one or more things, and they want someone, they desperately want help with it. So, if you want to get on a project with executive sponsorship or executive visibility, just ask the executive what he’s worried about. If he’s worried about it, once you start working on it, he’s now going to be worried about you until you prove to be reliable, that’s against an executive connection, and as soon as you prove to be reliable, you’re in.

Amazon has several of these VPs, peers of mine who are Jeff Bezos firefighters, they’re the people that have earned Jeff’s trust and he literally moves them from project to project when there’s a problem. They just get put on like, oh, this project is not going well, I don’t have time to dig into all the details, get this person who always fixes things and put them there. You can become that as a TPM, you can become the person who gets put on the problem. That’s a hard job, but if you want executive visibility and sponsorship, there’s a thing I guess the Navy SEALs, I’ve never been in the military, but they have a quote where they say ‘Navy SEALs run towards the gunfire’. Most people obviously, if they hear gunfire, their first thought is how do we get out of here? Be the person who runs towards the problem and you’ll be rewarded.

Mario: Yeah. It’s easy to say that having been in situations like that, it takes an incredible amount of, I don’t know what the right word is. It’s very hard to get into a situation like that because the whole world seems against you and everything is falling down and you’re trying to figure out all the pieces that need to get fixed. Even doing a deep dive analysis of where things are going wrong takes effort and time and grit.

Ethan: I mentioned judgment earlier, I think TPMs have to be really good at prioritization. In other words, a book you might find useful or you’ve probably heard of is this, Jocko Willink, Extreme Ownership. Do you know this book?

Mario: No, I haven’t heard of that.

Ethan: Okay. It’s called Extreme Ownership and it’s written by these Navy SEAL guys I was talking about, and it goes a lot to grit, but they have this saying, I guess, in the SEALs which is ‘take a breath, look around, make a call’. Their point is you’ve got to be good at prioritizing what you need to handle first and in one of those situations, when you get yourself into a mess, you do have to be good at deciding what am I going to handle? The other thing I think TPMs need to be good at to get out of the situation, so when they jump into the fire, they need to be good at politely but inspirationally asking others to go above the call of duty. You do have to be able to look an engineer in the face, look a designer in the face and say, look, I know it’s Friday, I do really need this by Monday. It’s not because I want to punish you and have you work the weekend but we are in trouble and we’re blocked, in this case, this one time, I need you to step up.

To be able to ask that, but you can’t do it every week, you can’t keep going back to the same person week after week, but you need to be able to make that ask and say, look, no one can make you, I’m not your boss, but you can see we need this, would you do it? Most people will step up once or twice and you need to be able to ask with a straight face and then, of course, it also means you have to lead by example. The TPM can’t be like, hey, I really need you to do this by Monday, I’ll check in with you Monday, I’m going to be on the golf course. It doesn’t mean you have to work all the time but you do have to, in the scrum analogy, the TPM can’t be a chicken, they have to be the pig, the person who is committed.

Mario: Yeah, well said, that hits the nail on the head because you can’t make it something that you’re going to ask people again and again and again. That’s not the right thing to do, that means your planning is bad, obviously. So, it needs to be, if you can articulate exactly, why this happened and why we need it, people will step up, hopefully.

Ethan: One of the questions you mentioned that I think I’ll comment on in this context is TPMs should not attempt unachievable goals and when you discover that something is unachievable, it’s fair to reset it. I don’t think in the modern world, whether you call them death marches, it doesn’t really matter how you describe a given project that’s gone bad and everyone’s working crunch time, there are many names for it. I think the TPM earns  credibility by being the person willing to stand up to leadership and say, this is not going to happen, this goal is red, we’ve looked at the alternatives, we’ve tried to be inventive. Just working the team to death and having the team work extra hours is not going to bring the project in on time and it’s going to burn out people and lead to attrition.

Again, if the TPM has their facts straight and has built a reputation of being creative and yet also being the oracle of truth, the good manager says, okay, well, either I have to agree to a date change and sell it up the management chain, or I have to get you more resources. I think the TPM has to be willing to step up and say what’s not possible just as they have to be willing to step up and ask for extra effort. That’s a two-way street because then your ask for extra effort is credible, if it’s just all the time then you’re in the role of being the slave driver, which is a terrible roll.

Advice for inexperienced TPMs

Mario: Cool. Let’s move on maybe to the final section of non-tech PMs transitioning to TPMs. I don’t know how much because you did say it’s a hot tea bar.  What’s your advice for inexperienced TPMs who don’t have a lot of tech background but maybe worked in tech companies or IT type of environments?

Ethan: I can definitely talk a little bit about what I think is possible. So, one thing is it’s possible to become a technical program manager over time. In other words, if it’s really important to you, you can work your way into it, but to our earlier discussion, you’re probably going to make your way there over the course of starting in less technical companies where you’re more managing interfaces and high-level dependencies. You’re also going to have to, I said earlier, it’s important for a good TPM to want to learn things themselves. I was talking about learning about a dependent system, but if you are the source, there are plenty of self-educated developers.

It is possible to self-educate yourself to be an architect, to be conversant in software development without having been a developer by asking enough questions and being intellectually curious enough. What that takes is when you’re working with a system you can’t stop at, oh, the system told us what day they’d be ready, I’m done talking to them. You’ve got to be curious to say, how does this system work? I need to learn more, what underpins it, what technologies are built on. I’m explaining this poorly, but for example, if you learn a system as a database and you’re non-technical, you better be curious enough to over time wonder, well, what kind of database does it use and why was that database chosen over the others, and what are the properties of it, you just keep unraveling it.

So, it is possible, but you have to be intellectually curious and you have to be motivated. The key point with any career transition, which is what you’re asking about is if you’re transitioning careers, what is going to be your motivation to learn. That motivation can be money, it can be advancement, it can be natural curiosity, but before you make a move that’s going to require you to reeducate yourself, you better know why you’re going to invest that. If it’s just like, oh, this sounds like something cool and new to do and I hear TPMs are paid more but you don’t have a plan, it’s probably not going to work out.

Mario: So, it’s a combination of on the job learning at the place you probably currently are at and reading from books, websites, and those kinds of things where you can probably go and learn things on your own with all the information that’s available online, right?

Ethan: Yeah, and I do want to encourage people in this sense, Google plus, Wikipedia will explain about any technology on earth to you to a reasonable level for a TPM. Ask a few developers you know, make friends with a few developers who’d like to teach. If you put in half an hour a night on average, five days a week, that’s 125 hours a year, you can learn a lot, but you have to do it consistently. I believe that a modestly technical person who actually put in that kind of work over the course of a year or two would become much more technical. Most people just don’t have that appetite, as soon as they get to the end of their required work for the day, which admittedly in many hard-driving companies may take nine, 10, 11 hours, they’re done, they’re exhausted and they’re done. If you want to transition careers, you better have a plan where you will put in that extra half hour every day. I think you can learn a huge amount by being intellectually curious.

Mario: I think one point which you mentioned was this is a real career transition and I think you need to take that into consideration. The first program manager to a TPM is a significant jump and the core skill sets that you need for a TPM, the technical aptitude and the technical know-how does take us an incredibly long time to understand and to learn about.

Ethan: You’re absolutely right, Mario, you’re replacing a four-year college degree, your direct path there is that I went to school in computer science, that’s the direct path. The good news is when people go to school for computer science, they also take all these other classes that aren’t computer science, so you don’t have to replace four years of full-time school, but you do have to replace, I don’t know, a year and a half of full time effort. How long is that going to take you? The thing I would also encourage because I know everyone listening to your podcast, the fact that they are listening to a podcast about program management means they’re interested and they’re willing to invest beyond whatever their day job is. Whether they’re driving in the car or on a jog or in the gym right now, the person listening is putting in the time to better themselves, so they’re on the right track.

What you need to do is be a little bit patient with yourself, I’m 50, I’ve had a 25-year professional career after graduate school. I have the advantage of the lens of history of saying, you want to go from PM to TPM six months from now, well, that may not be possible, but if you plan out and invest, it may take a year, it may take two years, it may take three years. In the scope of a 25-year career, that is not a big deal, but if you’re listening to this and you’re 22, I realize telling you something may take three years is incredibly depressing. I’m just trying to give you a view from the other side of that, but when you’re 50 and you’ve had a 25-year career, you realize something you did for three years early in your career was just one more step on the path. So, having a little bit of a long-term view matters.

Mario: Having said that, TPMs do evolve into product managers or into SDMs or single treaded owners. The opportunity, I feel, after you become a TPM is really endless, you could choose many different parts ahead and it’s fairly like a Swiss army knife, that’s how I see a TBM.

Ethan: I agree.

Mario: They have multiple skills.

TPM Core Skills

Ethan: Well, in the end, what are their core skills? Their core skills are deciphering what it’s going to take to deliver something, caring about delivering that, and then going out and influencing to make it happen. Those skills are domain independent almost, they can be applied because they’re someone who wakes up and says, what are we trying to do? What do I need to make that happen? How am I going to do it? That can be applied to, I don’t know, losing weight and inventing cold fusion and all kinds of problems in your life, that can be applied very broadly. The thing I would say is this is an overgeneralization, but it is broadly true, no one starts their career as a TPM, no one ends their career as a TPM. They start in something else and they discover, oh, there’s this thing called TPM, TPM isn’t on the menu when you go to graduate school or to school, computer scientist is on the menu.

To some degree, product manager is on the menu via an MBA, program manager is not really on the menu anywhere, which means everyone comes from somewhere else. Then later in their career, TPMs find a specialty and whatever it is they do, they move on to product management, software development management, general management, again, not universally. This space in the middle where you’re perfecting these TPM skills can be 10 years long, very valuable, even longer, maybe. Understand that TPM is like a graduate degree, it’s a graduate degree in getting shit done and that’s the most powerful degree there is. If you think about it from a company viewpoint, if there really was a degree that certified this person who gets things done, those people would be snapped up by any company. This person has a degree in ‘guaranteed get it done’ they’d be hired by everybody and that’s TPM university.

 

Mario: Yeah, that’s a nice catchphrase for your LinkedIn profile. That’s a fantastic, a lovely conversation, Ethan, thank you so much and thank you so much for sharing all your thoughts during the covid time as well. I know we’ve been trying to get this podcast recorded for quite some time, so thank you for making the time to share your thoughts on TPMs and how TPMs are at Amazon. Do you have anything more to add?

 

Ethan: No, I think I wrapped up strongly. I would just say I’ve really enjoyed this discussion and I hope everyone listening, whether or not you ultimately become a TPM, understand the value of the TPM skill set. The traits of a TPM and the skills required to be a good TPM are useful in so many other areas. I can’t say they’re applicable to everything, but knowing how to systematically break down a problem, organize a group of people to tackle the problem and keep them on track until they resolve and provide value at the end of the problem, that’s a very powerful skill set and TPMS are the specialist at that, so I hope that’s inspirational.

 

Mario: Thank you so much, Ethan.

 

Ethan: It’s my pleasure.

Want to Ace Your Technical Program Management Interview? Here