Technical Program Manager Amazon – TPM Interview Podcast with Visva Mohanakrishnan

Welcome to this edition of the TPM podcast with Visva Mohanakrishnan a Sr. TPM from Amazon. She’s been in the industry for the last 10+ years and has worked at Microsoft, Expedia, and several other organizations. We cover what a TPM needs to be mindful of when they join a new tech organization.

We talk about

• How Amazon is different as an organization? What makes it nimble and truly agile ?
• How is the TPM role at Amazon different from other organizations?
• How is the scale factor a big difference in technical orginizations?
• What is ‘day one culture’ ?
• And a long discussion on the Leadership principles that guide the soul of the organization.
• The uniqueness of the TPM role ?
• How the TPM role is different from the SDM role.
• What have you learned as a TPM in the last 1 year ?

I really hope you enjoy it !

Mario Gerard

Podcast Transcript..

Mario: Hello and welcome to the TPM podcast with your host, Mario Gerard. In this series of podcasting, I’ve basically tried to get guests from various tech organizations to come and have conversations with us, to tell us how their life as a TPM is in different companies. So, I’ve interviewed people at Facebook, we’ve interviewed people at Google, at Oracle, the last one was a VP from Amazon and this time we have a very special guest with us, Visva Mohana-Krishnan, who is a senior TPM at Amazon. She works in the consumer payments team for amazon.com. She’s been in the tech industry for the last 10 years, she’s had a variety of roles from being a developer, an SDET, she was a TPM at Expedia, and Microsoft, I believe, and is now a TPM at Amazon. Welcome to the show, Visva, why don’t you tell us something about yourself. 

Visva: Hi, Mario, thank you for having me here and for that wonderful introduction. A little bit about myself, I’m a senior TPM at Amazon, closing in on my one-year anniversary. Prior to Amazon, I worked at Expedia, Microsoft, and the Home Depot. For the Gators out there, I’m a master’s grad from the University of Florida. I started my career as a software engineer, Mario, at the Home Depot where I learned the basics of building scalable web platforms. At Microsoft, I worked on the Skype plugin for Outlook web, those were the good old days when I was an SDET where I built the muscle for looking around corners, poking holes in tech designs, and question the product vision, which surely helps me to this day as a TPM also. My longest stint was at Expedia where I had the option to grow as a tech lead and build a career as a TPM too. 

Mario: That’s your previous job, right? Expedia was your previous job? 

Visva: Yes. Prior to Amazon, I was with Expedia for close to five years. Currently, at Amazon, I’ve worked for the consumer payments org where I’m the program owner for the currency conversion portfolio. I think we’ll be talking about it at length today.

How is Amazon different from other places you’ve worked at?

Mario: Cool. So, something which I wanted to tell all our listeners, Visva and I are going to be talking at length about her first year at Amazon, what the journey looked like. It’s definitely going to have a lot of competences which are definitely specific to Amazon but as you listen to this, understand that most tech companies generally work on the same principles. Her experience as she talks through it is going to be very similar to any experience you’d have in any tech company when you’re starting as a TPM in a large tech company, it’s going to be very similar. So, Visva, why don’t I get it started off by asking you a very fundamental question, how is Amazon different from other places you’ve worked at?

Visva: Excellent question, Mario. This is common information, yet it took me by surprise. The first thing I noticed when I started on day one at Amazon is the sheer scale of the company as a retailer and a technology giant. I have been and to date am still amazed at the size of the programs, the number of touchpoints, dependencies, and the variety of stakeholders you work with. Also, a key point to note is the impressive fact is the quality and speed of delivery achieved at Amazon which continues to set the trend across tech industry and continues to raise the bar at scale. As I said earlier, to date, I’m amazed at how we operate.

How nimble tech organizations are?

Mario: I think a lot of people who aren’t really part of the tech industry fail to understand how agile the tech industry is. I have worked at organizations, even in my current organization, where we have our teams multiple thousands of people strong. But if you need something to be done across say a hundred different teams, you could possibly orchestrate something like that and get something out in two weeks, maybe even three weeks. How nimble tech organizations are and how quickly they’re able to react is seriously impressive. Although we learn agile from scrum and all those things, this is one of the truly fundamental areas where I think tech organizations really excel at. What do you think, Visva? 

Visva: Certainly, Mario. We will be talking about leadership principles with time, but one of the interesting takes I had in a conversation I had with one of my colleagues, talks about how the leadership principles seem to highlight the agile manifesto. How we empower ourselves to function fast and how we could use these as guidelines to enable us to get there at a faster pace, making the right decisions. I don’t want to give away too much about what’s coming later in the podcast as yet, but just a note on your point. 

How is the TPM role at Amazon different from other places

Mario: So, moving on, we spoke a little bit about Amazon, how is the TPM role at Amazon different from other places you worked at in the past, because you worked at Microsoft, you worked at Expedia, you worked at many other companies and you’ve spoken to a lot of other people. How do you think it’s different at Amazon in particular? 

Visva: Amazon, as I said earlier Mario, paved the path for TPMing as a discipline across the tech industry, and many companies, as far as I know, adopt best practices from Amazon. Correction of error is a concept which has permeated the tech industry and I believe Amazon is one of the trendsetters in that aspect. Likewise, even in the TPM discipline, there are many skillsets that Amazon empowers people to learn and then spread it across the industry. What’s unique though is to circle back to the scale factor. When one is running programs that span across multiple organizations with multiple stakeholders, we need to ensure the teams are aligned on the goals, the roadmap, and the communication has to be crystal clear.

These large scale programs absolutely need to be broken down into smaller, achievable milestones. Amongst all the method to the madness, the voice of the customer continues to echo, should continue to echo from inception through delivery and even after. So, in that aspect, in my opinion, Amazon is a great school of learning by doing even for seasoned TPMs. It is a space where you embrace the day one culture and continue to do it on a day to day basis.

How is the scale factor a big difference in technical organizations?

Mario: You spoke a little bit about a couple of different things, we spoke about scale. Would you be able to give us, like, what is the scale factor when you say running programs which are at scale, how big is this approximately? Just give us a general understanding. 

Visva: Certainly. So, easily more than a hundred million customers, as far as I know. Let’s say there’s a button on the page, you can easily implement it, but imagine that button is going to be clicked by 2 billion people at any given point in time, then you need to think of the scale at which your page should perform. So, that is what I mean by scale, when I talk about how we work across multiple organizations for dependencies 

What is ‘day one culture’ at Amazon?

Mario: Thanks, Visva, that was fantastic, that was a great example. I think, to add to what Visva was saying, the sheer magnitude of the number of people who touch a change that you will be responsible for is so high. When that is the case, it’s almost impossible to foresee all the problems that might come but that’s the role of the TPM. You’re working with a multitude of teams for a small program like even changing a picture and the impact is really large, so the skill factor cannot be overstated. Then Visva, you also spoke about the day one culture, for the people who don’t know, can you elaborate a little bit more on Amazon’s day one culture? 

Visva: Certainly. So, the day one philosophy is unique to Amazon. The philosophy empowers one to focus on the results and less on the process. When you imagine a company of this size functioning efficiently, sometimes people may tend to focus on the process and forget the endpoint, the goal, which is providing customer value. So, the day one philosophy makes sure we do not get into that phase, day two is statis according to our philosophy. We want to continuously reinvent ourselves and think about the future and make sure we serve our customers. It is a mindset that empowers you to have a high degree of ownership, to stay curious, and be scrappy and fast. You also own an experimentation mindset where you embrace the new trends and exercise high-velocity decision making, which enables teams to move fast. 

Mario: That was a little packed, but I get the idea that you’re fundamentally trying to say that this is our first year when innovations are just fresh. Even if you’ve innovated for the last hundred days or 10 years, let’s take a step back and say every day we’re going to continue to deliver that kind of value to our customers, and it’s day one, we are just beginning our journey. Fundamentally, I think that’s something to how the day one culture is, did I paraphrase reasonably accurate? 

Visva: Yeah, you said it in the best possible way, yes Mario, that’s true. 

Amazon Leadership principles

Mario: Cool. As we are talking about Amazon, the culture, let’s also talk about the leadership principles. There are 14 leadership principles I believe and the unique thing about what I hear from people is that the leadership principles are so embodied and are part of the decision-making framework for every small and big decision. It’s part of the culture, unlike most organizations where you have leadership principles or guiding principles, which are not used often enough, or just a poster on the wall. Amazon’s is a very ingrained belief that every decision or every person is guided by the leadership principles. So, why don’t you take us through some of the leadership principles? 

Visva: Certainly, Mario, you said some of those things. There are indeed 14 leadership principles. The way I see it, these leadership principles act as a guiding path and a fabric that binds us all together. In fact, sometimes I consider them as life principles which can be even applied outside of work. I’ll give you an example, my manager recently shared a funny anecdote of an example of how her son disagrees to eat a vegetable, but after reasonable negotiation commences to having it. So, likewise, I can draw examples from my personal life where I exercise bias for action to go ahead and book that travel right after COVID is complete of course, and exercise frugality in multiple facets of life. I believe these leadership principles are set in a way to empower us to make decisions, effective decisions. At Amazon, every individual is considered a leader, Mario, and these leadership principles enable us to make decisions. As I said earlier, the two-way door and one-way door decision and take action using these principles as guidelines.

Mario: When you say a one-way door and two-way door, which is a very common Amazonian way to talk about things, can you explain to our listeners what’s a one-way door and what’s a two-way door? 

Visva: Absolutely. In simple terms, one way door and two-way door decisions refer to irreversible and reversible decisions. Making high-velocity decisions is a key aspect of the Day One mindset, which enables teams to move fast, especially at this scale. So, you want to find a balance between waiting for 90% or all information to be available for you to make a decision versus taking a call with only 60 to 70% of input you have at that point in time. This helps Amazonians to continue to innovate and retain that experimental mindset where it enables you to move fast and pull back if you think you’ve ran into a situation or a scenario which is not as effective as you expected it to be. 

Mario: Yeah, that’s very interesting. I feel that at certain organizations where I worked in a more waterfall methodology, like ages ago, sometimes there’s this analysis paralysis phase where you’re just waiting to collect information. That might take you like six months to just collect information for you to start your program because you’re waiting for all the break ground structure to happen. You’re waiting for the estimates to come in and sometimes you probably don’t need to do that if it’s a two-way door because your decision can always be reversed if you make that decision to go ahead right now. If it’s a one-way door, it’s probably going to take you more effort to correct because the time and the energy your team is going to spend correcting that mistake is going to get longer. Is that an accurate paraphrase of what you said?  

Visva: Yes, Mario. I’ll give you another example, which also ties into the decision making process back to the leadership principles. During my onboarding, one of the core leadership principles to focus on was earning trust with my stakeholders. This was my primary goal and this enabled me to determine my onboarding roadmap and the way I operate to set myself up for success, such as connecting with the team, listening to their experiences, identifying gaps, and figuring out areas where I could generally add value as a TPM. So, whenever I came across an opportunity or a challenge, prioritizing this leadership principle enabled me to make my decisions. That helped me through my onboarding process, making my decision-making process as simple as possible. In addition to it, I also agree that the leadership principle for earning trust is a completely important one for TPMs, but just by virtue of the job because you work with multiple stakeholders. Holding onto that leadership principle and using the decision-making tool kit was very effective.  

Mario: Got it. Earning trust, I think even when you think about your first 90 days, earning trust is a core component of any TPM’s initial journey, so that’s a very interesting point. Are there other leadership principles you’d like to touch upon? 

Visva: Certainly, Mario. So, in general, the leadership principles are the core values we adopt as a team and each of them are unique and each of them are interpreted differently by different people based on their experience and expertise. However, cumulatively, they are set in place for delivering value to customers as a key result. Of all of these, my favorites are earning trust, ownership, and bias for action. I think delivering results is an inherent part of the job from my perspective, once again, that’s my take on it. Let me give you an example of why ownership, in my opinion, is a key leadership principle and inherently partners with all the other 13 of them.

Let’s say I take ownership of a program, I would like for it to succeed, which inherently makes me obsessed with my customer. I need to have good judgment to make the right decisions, I need to earn trust with my partners, I will hire and develop the best teams to execute on that program and think about the big picture and vision of the product. So, if you see where I’m going with this, all these leadership principles are actually interrelated with each other. They are designed to complement each other and elicit critical thinking.

Mario: That’s really interesting. What our listeners probably didn’t realize is the way Visva worded her last answer. She had a large majority of the leadership principles tying all back into ownership. Ownership is a leadership principle and then being obsessed with the customer is a leadership principle and because you’re obsessed with your customer, you tend to have great judgment because it’s all focused on the customer. Then you earn trust with your partners, with your team by ensuring your customer gets the best. When you’re working with your team, you’re also trying to hire and build and develop the best. 

So, in her opinion, she’s like, if you take on ownership and ownership is the cornerstone of your leadership principle, everything else kind of falls into place. I think Visva also mentioned this earlier on when we started our conversation. These are very much life-guiding principles and I think every individual picks upon one or two principles, which they love dearly and everything else kind of fits in together as a puzzle, and everybody draws different aspects of each leadership principle, so it is a very interesting way to look at things. There are also some leadership principles that appear to be in conflict, right? 

Visva: Yes, Mario, you’re right, you caught it. So, there are some principles such as are right a lot, which means leaders are expected to make the right calls and learn and be curious, which is another principle. Those are fairly conflicting with each other because I need to learn to be able to be right, so how do you exercise both of those? 

Mario: Sometimes you make a lot of mistakes before you’re right. Until you get to being right all the time, I feel we all make mistakes and you have to make mistakes and learn.

Visva: Certainly. Likewise, we have the dive deep and bias for action and in my mind, if I’m diving deep, I am delaying action, so that does not bear well with the bias for action leadership principle. However, I think this is by design and this is where your individual critical thinking comes into effect.

Describe TPM role

Mario: Each situation might demand different things. Do a lot of people think about conflict as a negative thing, I think what you said here makes a lot of sense. Conflict actually brings about something good. If you think about it that way it completely changes your perspective because two people are fighting, or two people are trying to come to an agreement on something and both of them have different values and beliefs. So, I think most of those situations result in a better end result when there is conflict and when these people care about something, I think it’s very different, so that’s a very interesting thought. Let’s continue to talk about the TPM role, in your journey, in your current role, how do you define the TPM role? Let’s talk a little bit about how you see the role, how you see the mean skills that are needed for the role, so let’s start with how do you describe the role, you as an individual, how do you describe the TPM role? 

Visva: Mario, for every time I’ve been asked that question, I wish I could describe it in one short sentence but that’s not going to happen.

Mario: Doesn’t it change with the org? It changes with the company you’re in, it changes with the business unit you’re in, it changes with the team, it changes so much, right?

Visva: It even changes with the person you’re interacting with at that point in time because they have a completely orthogonal understanding of what these roles are. 

Mario: Yeah, so what’s your take?

Visva: It’s a very malleable role, Mario, I don’t need to explain more but it varies based on the needs of the team and you wear different hats at different points in time. However, from my perspective, the simplest way to explain is, a TPM owns seeing a product end to end from inception to delivery and even after that. In a sense, is the glue for executing and successfully delivering a program. I can break down further into tasks, I understand this is a very vague and ambiguous description, I can give a little bit more objective tasks which TPMs generally do. This includes things like managing your stakeholders, delivering roadmaps, managing the priorities and risks in your program. 

You want to report and bubble status up the leadership chain and provide visibility generally into what’s happening with your product. You focus on the process engineering, improvisations that are on the team, you contribute to technical design and the vision of the product, in addition to numerous other things TPMs do on a day to day basis. One key thing which I believe is quite essential for TPMs is to be the voice of the customer, to be able to develop a peripheral vision and look around the corners to make sure that your team’s hard work cannot be derailed and what are all the ancillary tasks which need to be done in order to make your program succeed in general. So, it’s a specialized role, Mario, and all teams do not require a TPM, it’s a very uniquely required role. Especially at Amazon, being a technology company, the “T” in TPM brings immense value for you to be able to make the right decisions for your program. 

Mario: Let me ask you that, I was just talking yesterday with somebody at Amazon and we were having the discussion on when a TPM is really necessary and I think you touched upon that. I don’t know how many people know this, a lot of teams at Amazon might not have TPMs, they don’t need to have TPMs. The engineering manager, which we will also talk about later from a role perspective, but an engineering manager might actually do the job of a TPM if the team isn’t big enough or if the team doesn’t have too many touch points or if the team is just doing something in league one where they’re just developing a product, they might not need a TPM.

So, it comes down to that real part where Visva did describe very clearly. There are a hundred things that the TPM does, but it’s very vague or kind of odd to see that it’s a role that helps the team scale in a sense. It’s a role that owns the end to end product, it’s kind of the glue when there are multiple teams in play. Visva also mentioned this, she said a TPM helps in executing a program really well and sometimes it’s that laser focus that a TPM has in getting a program done. A program might not be the responsibility of a team, it might have to be done across several other teams and the only person who is owning that as a program would be a TPM. Does what I’m saying makes sense?

Visva: Yes, Mario, you are right. When it comes to programs, or products, which are very limited or have a scope which is within internal teams, an engineering manager predominantly can take care of some of the TPM skill sets. However, when it comes to programs that span across multiple touchpoints, multiple different teams, you have innumerable dependencies to manage. You want to align on their roadmap, you want to engage with those teams, you want to bring some structure to the chaotic project management which happens over there. Also make sure that the technical aspects of things, for example, you might be working with three or four different teams who have different versions coming up in the next year and you are probably working on the current version. 

You need to manage the risk for your team, you want to understand that, hey, next year, that version is going to change, the technology version is going to change, so how do I account for that today in my current program roadmap? These are the kind of futuristic thinking which a TPM should exercise and that’s the reason why it’s a specialized role because these are very abstract. What I’m telling you now is abstract, and it is not prescriptive at all and it is not always going to happen, but these are things to anticipate for. That is where the TPM plays an excellent role and sits in the middle of the tech, the business, the non-tech stakeholders, and pull them all together and move the program forward.

Mario: That’s fantastic how you encapsulate the whole thing. There’s also this other piece where sometimes when you work with developers, they try to get into the nitty-gritty of things and how something is going to be executed, how do you do that? Sometimes as an engineering team, we forget the voice of the customer, so the TPM is also one of those people who has a broader lens to look at everything from we are on week one, what happens when week two comes along? At the same time, what is my impact on the customer? So, that’s a beautiful way to put it. You also spoke about the T in the TPM, how important is the T, in your opinion, and how do you classify whether somebody is technical enough for a TPM? I think I asked all the people I’ve ever done a podcast with because you get a variety of answers with this.

Visva: Certainly, Mario. So, this is my way of looking at things. Of course, the TPM works with engineers on the engineering on a day to day basis. So, when we run into engineering roadblocks, the TPM should be positioned enough and have the aptitude to be able to foresee the repercussions of that particular issue or design decision which is being made. In addition to the technical aptitude, the TPM, that is why they are sitting with the business too because you need to have an idea of what the future road map is for the product, so that you make sure your engineering is not designing something which cuts them into the corner without having the ability to expand into a future version or a future roadmap for that product.

As you said, and I think I’m going to quote Ethan Evans over here, engineers are infamously or famously optimistic. So, they focus on, let’s say I ask my engineers to build a phone, they’re going to immediately jump on it, get the chips, get the product, start coding the software, and focus on developing the phone. What they fail to see are all the other aspects, am I meeting the regulatory conditions for this phone? How will it behave when it’s thrown into a fire? Is it going to be childproof or do I need to inculcate something which requires a child’s safety? So, these are a lot of things which are independent of writing code and independent of implementing a product. From my perspective, the TPM works with the product manager, the marketing, sales, a lot of tech and non-tech people to bring all these ideas to the table, cohesively make it into a program planned and works on executing it. 

See also – Technical Product Manager Role

Being customer-obsessed

Mario: I don’t know how many people realize that Visva said, oh, quoting Ethan Evans. Ethan Evans was my previous podcast interview which I did. You spoke about the phone and how an engineer would go and build it, I think Ethan mentioned this in his podcast where he talks about TPMs being generally curious. If you aren’t curious, you would not do all the things Visva just spoke about, like what’s going to happen if you throw it into the fire, what are the regulatory requirements? Nobody is going to tell the TPM to go do all these things, a TPM putting on his customer hat needs to think what are all the things I need to do which I’m not doing and that’s his bread and butter. You really need to think from that perspective as a TPM, that’s being customer-obsessed, the first and the most important point, according to Visva on the leadership principles. You’re talking about being customer-obsessed, that is being customer-obsessed, what do you think, Visva? 

Visva: Yes, spot-on, Mario. I think these are also thought processes that TPMs accumulate as and when they go through multiple product development. Certainly when someone is just coming into a TPM world, they may not have the exposure, but very quickly they will learn these things because that’s when they realize the responsibility and importance of thinking from the customer’s perspective and bringing it to the table every day at work and with everyone you interact with. 

Mario: Sometimes when you bring about these questions, even the regulatory one which you mentioned, I think it’s a phenomenal example when you’re building a phone. Maybe halfway through your program, you realize that there’s an external factor that could jeopardize your entire program. The question is how quickly can you bring it to somebody’s attention and how quickly can you understand what the implications are and sometimes that’s a very scary road to go down as a person, as a human being. That’s what TPMs need to do, they need to have the guts to look danger in the eye sometimes and go on that journey to figure out what the implications of those things are. Those are things that people don’t talk about. 

Visva: Mario and I’ll add one more thing. You will eventually learn about these peripheral items that you said, the regulatory, compliance, security, and whatnot, but another important thing which a TPM needs to do is to bring that back to your team and influence your team to absorb it and execute on it. You need to ensure all the people who you work with also see the constraints that you see in some of your perspectives and are able to think of the implications and quantitatively determine how to factor it into the implementation plan. I think this is where influencing without authority is a paramount trait for the TPM and it plays strongly together with many of Amazon’s leadership principles and in general for TPMs who are working on high-impact products altogether. 

Mario: Yes, that is true. I think that was a very good conversation, let’s move on. Since you’ve started at Amazon, it’s been close to a year now, what are all the things that you’ve learned as a TPM in this one-year span?  

Visva: Mario, Amazon is an excellent school of learning, specifically for TPMs who are excited about products that have large scale impact, considering Amazon continues to lead the industry and setting a very high bar for what TPMs can accomplish. Let me break this question down a little bit more. If you asked me what I learned during ramp-up time or what one would learn during the ramp-up time, there is a ton of information.