The Technical Program Management Podcast & Interviews

Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part three, the final part of how to run a large-scale program. Our conversation with Rhea, if you have in third part one and two, definitely check that out before you go ahead and listen to this part. I hope you enjoy it. Continue listening.

Talking about that trend. What are the most common pitfalls you see people make, or, or people need to watch out for?

Rhea Frondozo: So, as a breath TPM, one of the things that I know that has happened to not only me, but the TPMS that I manage is when you work on a large-scale program, you’re working with a lot of different functional area owners, and it’s your job to hold them accountable for getting their work done.

But a lot of times when you come in as the TPM and you come in as such a strong lead, they want to be able to rely on you instead to get the work done and for you to solve their problem. The issue with this is when you’re at breath TPM, you have so many different areas that you are managing, that if you were to do the work for everyone, instead of holding them accountable, ultimately you will fail.

And so, it’s really important as a breath TPM, to make sure that you understand your scope, your responsibility, your accountability, and figure out who it is that you need to rely on to do what work and hold them to that.

Mario Gerard: Yeah. And sometimes you don’t have the right people, what I’ve done in those kind of situations and say, Hey, talk to your senior leadership within your organization, and if you want, I will recommend somebody within that larger organization who I think can go ahead and do this for you, but you don’t step in and help fix somebody else’s problem, because then it becomes your problem. And then they kind of walk away.

So, you want your pocs or your functional area owners to kind of own their space and to work on the problem and then get back to you on the milestones on how they’re doing on it rather than you are running those smaller programs.

Rhea Frondozo: Right. And this is where that judgment call is really necessary. Like how much you step in to help them get them on the right track versus you continue ensuring that they keep on track versus you doing it yourself.

Mario Gerard: And where you step into help sometimes. Because sometimes they don’t have a very strong lead and then you might go in to reactivate that program or put it on the right track and then ensure that you’re monitoring it to some degree, but you’re not actually going and doing all the work.

Rhea Frondozo: And this is where trying to figure out kind of that line between how much you go in and try and help yourself versus how much you invest instead in making an escalation to leadership to ask for the help that you need.

And so again, this comes down to a judgment call of where you spend your time as a TPM to make sure that your program as a whole is successful.

Mario Gerard: Yeah. I think, I think one of the key things which I’ve learned, I am working at OCI was to always reevaluate where I’m spending my time. This is on literally on a daily basis or on a weekly basis. Like where am I spending most of my time? And is it the right place I’m spending that time, is this what I’m required to do? And is this for the necessity of the program? And is it good at help the long-term success of the program?

Rhea Frondozo: Right. Because I think goes to a second point to make about a potential pit fall that a breath TPM may have. It’s knowing when, when to rely on an SME versus is doing something yourself. Right? So it’s important to, for us as TPMS to understand a problem at hand, but knowing how deep do you need to go in that problem and how deep you need to go in the solution versus making sure that you’re pulling in the right people to do it, or just being the person that vets, are we solving it in the right way or solving the right problem.

Because at the end of the day, it’s not your job to be the SME, but it is your job to know when to utilize the SMEs for their experience and how to gut check them, to make sure that what they are delivering actually meets the business need.

Mario Gerard: Yeah. And sometimes these SMEs, like they over-engineer things, or they will complicate things, right. You’re laughing and I’m laughing. Cause we’ve been through this situation so many times. And we bring in an SME, who’s so focused in the area. They know it’s so well that they sometimes really, really over-engineer and overcomplicate things.

Rhea Frondozo: Not only that lot of times, what will happen is these goes to this, the thing that you mentioned earlier about scope creep, maybe there’s this problem that you recognize impacts to your program, and you need them to solve it. Oh, but this has been a pain point for them for the last, how many years. And now this is their chance to get buy-in to make this awesome solution that will fix everything for the problem that they have, which is only a portion of the problem that you have.

Mario Gerard: You need, you need them to solve X, but they need to solve X in hundred. That that’s their biggest customer problem, which they’re trying to solve, but they haven’t gotten an executive buying for that, but they wanted to stack it on.

Rhea Frondozo: Right. They want to, I’ve seen the, has happened multiple times where essentially, they it’s like they want to ride your coattails. Oh, you have a priority for working on this thing. Oh, that means I can get the priority for working on this whole entire thing. Because it’s associated with your program. Yeah. Which again, this ends up becoming scope creep. That ends up being a lot bigger than you really need.

Mario Gerard: Yeah. Yeah. So, it’s very interesting, like two common pitfalls. Why don’t you talk about like one of the programs, which you worked on Rhea and kind of like walk us through like the complexity, the, the objective and how you went through that.

Rhea Frondozo: Sure. Yeah. So, I’d say that the biggest and most complex program that I’ve ever owned was running the global government sector program for OCI. And this encompassed a suite of cloud regions, services, features, and processes that were needed to meet our government customer expectations.

Mario Gerard: So, it’s all like a new product.

Rhea Frondozo: It’s actually a set of products.

Mario Gerard: It’s a set of products that enable a particular government to run on our own infrastructure.

Rhea Frondozo: Right. And the reason why it’s a set of products is because you know, for governments, you’re not only looking at running on public cloud or public workloads, but they have different levels of classification. So, we had unclassified levels of workloads that they may want to run. Or you also had classified levels that are running at top secret or secret levels that require much more engineering to secure the workloads that they need to run.

Mario Gerard: And when you talk about engineering, just to elaborate a little bit, it more is physical infrastructure needs to be re-engineered people need to be re-engineered because they have certain level of clearance, the way they operate on the cloud differs the software running on the cloud differs. So literally every single thing has to be re-engineered meet this product need.

Rhea Frondozo: Right. And so, you know, the way that we had to think about it is what is the lowest common denominator, right? So how do we make sure that we have the highest level of security in a product and making sure that we run it everywhere that way so that we try to minimize that divergence.

But it did mean that we had to reengineer the products, not just for the government customers that we had or the government regions that we had, but all the way through the entire stack, down to the public versions of it, because we wanted to be able to minimize the divergence of software.

Mario Gerard: This is a very, very interesting point that we didn’t speak about this whole podcast. On all the pro we worked on, we try to intro divergence is limited. And especially when you’re working in an organization at the scale at which we worked in like several thousand people strong, right. Divergence is a very important thing that we try to avoid. Tell me, why is it so important? What is divergence for maybe for our listeners? Can you give an example of divergence? What do you mean by divergence?

Rhea Frondozo: So, you know, by divergence, I mean really the code that’s running in any… Or the way that you are operating these regions is important that we do it the same across all regions. Otherwise, the amount of work you are creating for yourself can double or triple, a quadruple, because now you have to update multiple code bases.

You have to have different processes running for different regions. You have to hire different people to do all the different work across all these different regions.

Mario Gerard: And this simply multiplies the complexity, every single team supposed, you have 200 different teams for 200 plus products. Every single team will need to operate in a different way, and you have one garment, then you other garment, then you have another garment. And so, your divergence level becomes increasingly astronomically high. And this is just not this particular problem Rhea, and I are talking about I’m, I’m talking about this.

Whenever you have any kind of large-scale program, you need to keep in mind that you’re not introducing too many divergent processes or tools or architect so that the teams don’t have to carry that burden forward in having this different way they act for this particular type of problem.

Rhea Frondozo: Cause what you’re doing is trying to make sure that the products that you are creating are scalable.

Mario Gerard: Yes, yes. This is what we always talk about. Is the process you’re creating scalable? Is the architecture that you’re creating is that ability to apply that all throughout the organization, otherwise you’re going to have just too many people.

Rhea Frondozo: What you don’t want to end up with is armies of people, all doing different things. When you could have architected your solutions in a way that allows you to scale to multiple regions without having to hire an army for every region.

Mario Gerard: Yeah. So, sorry I took you on that divergence question, but I thought that was a kind of a very important point, especially when you’re running large skill programs, but do carry on.

Rhea Frondozo: Okay. Yeah. So, the global government sector program is the largest program that I’ve owned. And when you think about the sponsors and the stakeholders that were required for this program at the end of the day, the customers were the various different governments, whether it’s foreign or domestic. And we had very specific sales organization that we were enabling by providing these products.

These were, you know, sales orgs that were the interface and to our government customers who are going to be the ones to manage the RFPs, the request for proposals and the responses that we would provide. And, you know, we’d work very tightly with them to understand and interpret requirements and provide our technical assessments of any gaps that might be missing or products, feature gaps that are, are required. And then we had the executive sponsors for this program and really this one went all the way up to our CEO at Oracle. In this case, it was Safra Catz. And this was a companywide initiative that affected all services that we delivered.

And ultimately me making this huge sales opportunity because we wanted to be able to sell all products to these governments.

Mario Gerard: And when we talk about all products, it’s kind of very interesting from an Oracle standpoint, right? Because Oracle has like more than 300 different products and government might use any of these 200 different products. Even if you cut it by half, they’d use a hundred products plus, right. And you have to ensure that these hundred plus products are going be able to run on an absolutely new type of environment.

They’re going to be able to deploy it, patch it, maintain it, or operationally manage it in this new type of environment.

Rhea Frondozo: Right. And the thing to mention there is that was of the utmost importance cause the customers had experienced where in one of our competitors, they had divergent code bases, which made it very difficult for them to scale in a way that allowed all products to enter their government re regions. And that’s exactly what our government customers did not want.

So, this is why we have to reemphasize the point of the importance of why we didn’t want to have divergent infrastructure and technologies running in these regions. So outside of the, you know, executive sponsors, we had really the entire org who are responsible for not only building the regions, but delivering the services and the features in these regions or creating new features that were needed to ensure that we met the government security requirements and that we were able to maintain parity with every other public cloud offering that we had.

Then last I’d mentioned in terms of key stakeholders were operations. You know, we had to have specialized operations teams that had to engage with this product in a way that met security standards as defined by the government. So, you know, it meant that we had to have appropriate security levels, clearance levels and operate following, you know, very specific data sovereignty rules and how we manage and access customer information.

So, these were some of the core stakeholders that we had to work with. And when it came down to running the program and running these programs and these communication mechanisms to do so there was a lot of planning involved when it came to creating the internal kind of vision for what the product was going to be defining, you know, the product definition, defining what the resourcing requirements were to do this in this case As I mentioned at Oracle, we are very big on doing write ups as opposed to PowerPoints.

And so, we started with very detailed product definition, you know, six pagers. And once we were able to get leadership buy-in then we were able to summarize these requirements and these goals for the program in what we ended up doing as a power or point roadshow where we then went to all the different leaders in the org explained to them what we were doing, making sure that we had buy-in at the next leadership level. And so that we could ultimately get the pocs assigned to our program.

And then we held bigger tech talks for the entire engineering organization, just to give everybody a heads up of what’s coming the importance of it. So that the next time we came knocking on your door, making an ask for a particular feature or a particular new service, you knew what the importance was and why it was important that you prioritize it.

Other things that we ended up doing for this program were creating weekly internal stakeholder meetings, executive reports that we would share at, you know, critical projects, stakeholder meetings created newsletters and Wiki pages and confluence pages, the track, the project, the schedules, meetings, agendas, key requirements. I mean, you name it. All of the different tools that I mentioned earlier were all employed in this particularly large program.

And the thing was when I started the program, it started as building a net new region and the program grew to owning the entire suite of cloud regions that were needed for these customers. And so, it ended up being, I started owning the program in one phase, which was the planning phase of a new region. And then I ended up taking on more pieces of this government sector in terms of building other cloud regions for other governments like international governments for maybe the UK and these ones were in different phases, not just in the planning phase, but maybe these ones were already being built.

I ended up taking on other regions that were in different phases, such as they had already been built, but they were in the support phase now where the product had been built for the u’s government. But as customers were using it, now you end up in a situation where we’re finding what gaps are missing, what features they need, what new services they need and figuring out how to prioritize, getting those requests into these regions.

Additionally, these regions that we had built ended up taking the place of older versions of the cloud regions that we had. And so, we ended up in having another program that was essentially to close out the existing regions as another kind of program in a different phase. And so ultimately this program that I owned ended up being extremely complex because not only of the different number of stakeholders that we had to work with, the amount of business opportunity that it brought opening up multi-billion dollar bid responses. But also, the complex nature of owning multiple regions, products, and various different life cycles of a program phase.

Mario Gerard: That’s so complex hearing you speak about it. It’s so incredibly complex and so many different requirements, so many different teams to deal with. And I hope our listeners got that. This is kind of the end of this particular podcast. I’d really like to thank Rhea for the amazing, amazing work of giving us all this knowledge and all the knowledge she’s built, sharing that with us.

I’ve seen her in action and then she’s like unbelievably in running these kinds of large programs. And that’s something which we’ve done together and it’s incredibly fulfilling. There’s definitely a lot of challenges, but at the same time, it’s very rewarding as well. So, I hope. I hope all of you enjoyed that. Definitely share the podcast with your friends and colleagues and subscribe to the podcast on your favorite podcasting app.

Thank you, Rhea So much for sharing all that. You want to say anything, any words, anything that you want to add?

Rhea Frondozo: No, I think, you know, I’d just like to thank you Mario, for giving me the opportunity to share all of my experience and knowledge. I think this is being a TPM and gaining this kind of knowledge is not something that you can read in a textbook. It’s not something that you can study for and achieve.

It’s something that you learn through experience. And so, what I found is the experience that I’ve gained only comes through trial and error. And being able to talk about it now with you, hopefully gives our listeners the opportunity to kind of ahead of the curve in terms of understanding what to expect when they get into the situation themselves.

Mario Gerard: Yeah. Yeah. This is an incredible rollercoaster of a journey, right? So, thank you so much. I hope all of you really enjoyed that.

And that my friends are the end of three-part series on how to run large scale programs. I really hope you enjoyed that. This is one of those most unique podcasts, I think because there’s so much information, knowledge from somebody who’s so experienced in this field. I really hope you enjoy that. If you like it definitely share it with your friends and leave us a review on your favorite podcasting apps.

Thank you so much for listening. I’m going to be producing lot more podcasts. So, if you would like me to contact somebody who you think would be great for a podcast, let know, thank you so much my friends.

Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the second series with Rhea, where we are talking about how you run L scale programs. If you haven’t listened to part one of how you run large-scale programs, definitely check it out before you start this particular podcast, because this is a continuation of that. Hope you enjoy it. See you on the other side. Bye.

One of the things to keep in mind when we design how we communicate in a log scale program. So, we spoke a lot about communication. But how do you design a communication plan for a large-scale program.

Rhea Frondozo: So, you know, I think what it comes down to is making sure that you understand who you need to communicate with at what frequency at what level of communication, for what purpose and using what mechanism. So that’s a lot of things I just said, right? But let’s break that down. You’re going to have a variety of different stakeholders who are going to need different levels of communication at different frequencies.

So, if you, for example, are communicating with executives, you’re going to need to be able to produce, you know, very concise executive summaries. Maybe it’s going to be in a report or maybe it’s going to be an executive status meeting, and it’s going to be at whatever frequency that they feel that they need to be informed at, versus when you are actually managing the program with people who are say, POCs, the point of context, you’re going to be wanting to have maybe status meetings where you’re working through issues that they bring up.

Maybe you’re going to have a program tracking page where you’re tracking the different, you know, initiatives that teams are working on. And you have a way that you can gather the variety of statuses that they bring to the table and risks that they bring to the table that you can discuss as a team. Or maybe there are people who just need to be informed, and they’re not maybe working on the project, but maybe you want something like a newsletter where you’re keeping people informed on a regular basis of what’s happening with your program.

Should they, you know, have an ask that comes to them later, they’re not in the dark about why this is coming.

So, there’s definitely a lot of different potential for communication mechanisms, through emails, newsletters, status meetings, Wiki pages. It really just comes down to making an assessment of, like I said, who needs to know what, when and how do you deliver that.

Mario Gerard: Yeah, I think it’s a very complex, you know, we’ve tried to do it with some, some kind of confluence pages, which has the objective, the mission, the risks that we are going through right now and all the deliverables and milestones and the people who are responsible. So, it’s kind of a table which shows who has what milestones hit when they’re going to hit those milestones. Are they red, green, or yellow for those milestones?

So, somebody can take a look at it at one view and see like, you know, where we are in those plans. And I think cadence is really important in all of these things. So, you have executor level meetings where you’re just giving them status or you’re sending it to them via email. Then you have different levels of meetings with different types of stakeholders across the board. So, it’s kind of important for you to design that and to recalibrate it.

Rhea Frondozo: Right, right.

Mario Gerard: You have to recalibrate.

Rhea Frondozo: Right. Cause I think one of the things to mention is that depending on what stage you are in a program, the frequency of communication to your stakeholders can change. In the beginning you may spend a lot of time talking to your executive sponsors or the leadership to try and get buy-in. And at that point, maybe you’re, haven’t even engaged with POCs yet, but once the project goes into execution mode, maybe you’re working, you know, on a weekly or even biweekly basis with the POCs working through issues as they arise.

Yeah. Sometimes you end up even in daily cadences, you know. People will have what we call war rooms. If there’s a big problem at hand that, you know, you need all hands-on deck to work on. Maybe you’re pulling in people on a daily basis, but you also don’t want to have to keep everybody on a daily basis because you may do that unnecessarily and burn people out or you may finally solve the problem and not need that.

And so, it’s really important as the TPM to constantly evaluate what communication do you need reevaluate. Do you still need that and make adjustments accordingly depending on how the program’s going?

Mario Gerard: Yeah. That makes perfect sense. The next question I have is what are the type of blockers that one comes across when you’re executing these kinds of large programs?

Rhea Frondozo: So, there’s a lot of different kind of blockers that you may run into, but I think that you can categorize them in a couple different ways. So, I think one really basic one that you often hear about are going to be scheduled delays, you know, for one reason or another, it could be somebody underestimated how long it was going to take to complete something. I mean, engineers and developers are notorious, I’d say for underestimating, how long it takes them to complete something.

And as a program manager, you typically know that you should ask for confidence levels or understand, you know, what the associated risks are and include buffers. Nothing is ever as easy as we think it will be. And if you think something’s going to be hard, it’s probably even harder than you think. Other issues that can cause scheduled delays could be things that are out of your control, whether it’s things like external dependencies that you’re counting on, like supply chains, you know, expecting hardware deliveries at a certain time, or maybe you have creditors that you’re expecting to get scheduled for looking at the products that you’ve built and assessing your clients.

Other things I could call it, scheduling delays, or just maybe you thought that you knew a solution to a problem, and it turns out you were wrong, and you have to redo it. And that can cause a scheduling delay. So, there’s a multitude of things that can cause scheduling delays. You know, other things that I’ve seen can be, you know, a misinterpretation of requirements.

A lot of times you’re trying to move fast and move in an agile approach for service delivery. But sometimes what you find out is the requirements that you thought that you were working against were actually wrong. And this is where it becomes important to fail fast and figuring out if you’ve done it wrong and redoing it can be another reason why your program is blocked, and you need to reset expectations on how to regroup on a program and come up with a solution that meets the expected requirements.

Another one I think that I mentioned, you know, like I said, technical or architectural challenges, sometimes we make the wrong assumptions for how we were going to solve a problem. And these are things that when you’re working on a problem, that’s in a space that is unchartered territory. You may be trying things for the first time and realizing that your assumptions were wrong, and you’ve got to restart or redo it.

Mario Gerard: And when you think about it as a scale at which we are operating, I think it becomes increasingly difficult. When you think about like the architectural solution that we came up with, which impacts I think like say 50 teams need to go do the particular thing, they go do it and then it doesn’t actually work.

Rhea Frondozo: Yeah. I mean, I actually have seen this happen at some of the most expensive levels I could have ever imagined where, you know, we built a whole cloud region and then realized we did it wrong and had to rebuild the entire region and that we couldn’t salvage all the work that had been done yet to start from scratch. I mean, it happens, it’s a very costly mistake, but you know, like I said, when you’re an uncharted territory, sometimes you just don’t know what you’re up against.

Mario Gerard: Other problems I can think about like one or two, which are like scope just keeps getting added to this particular large program. Because one people see, oh, these guys are running this large program and they kind of like hitch their wagon or say, hey, if you’re doing that, you need to do this as well, but you probably don’t need to do. And they kind of, as a TPM, you probably need to ensure that you’re maintaining and managing the scope of a large program.

Rhea Frondozo: Yeah. I mean, scope creep is real, right. A lot of times what you end up seeing is what you plan for and what you are resourced for is different than when you start executing, you know, people want you to deliver on. And so, you end up, you know, if you go beyond the scope of what you’ve been sized for, you end up resource constraint. And then this can cause a lot of different things in terms of scheduling delays, missed deliveries. And so yeah, scope creep is definitely something that a TPM has to keep their eye on.

Mario Gerard: And in these kinds of large programs, I think it’s increasingly, it comes back to that judgment, which we are mentioning, right? You have to be the person who’s making that judgment call to figure out like, does this belong as part of this program or not? Is this 100% critical and crucial to be part of the delivery of this large-scale program?

Other things are prioritization challenges. Like how you help like teams go back, them prioritize against other programs they’re working on.

Rhea Frondozo: Yeah. So, I’d say that one of the things that often comes up is you’ll see that there’s multiple competing business objectives that require the same resources, same teams, right? And so, what ends up happening is imagine you expected this schedule to be done by date X and then all of a sudden it takes longer than you expected. Now you’re sitting on top of another project that you are supposed to get started, then what happens.

And so a lot of times it becomes your job to figure out, you know, what is the business impact if your project gets bumped or if it doesn’t get worked on to make sure that, you know, your executive leadership understands, if we’re making the right tradeoffs to continue working on your project or to redirect resources elsewhere or to elongate schedules, because it makes sense to slot in another project in the middle of yours.

Mario Gerard: I’ve been through these prior exercises sometimes when there’s a large program that we’ve kind of started or initiated, right. And it requires so many resources, we’ve kind of gone back to all the executives and said, hey, this is what we need size this for us. And if you need like 10, 20, 30, 50 resources from every single team out there, To run this particular program, then you, once they size it, you also tell them, Hey, supposing I ask you to start on this tomorrow, literally tomorrow what’s going to get bumped off your existing commitment to our senior CIOs or CTOs or whatever.

So, they go back. Not only do they do the whole sizing effort, but they also come back and say, hey, if I do X, Y, and Z for you, and I start on it tomorrow, or next Monday, all these things are going to get bumped off. And then you take that list and then you take that to the super senior executive leadership and they actual kind of sign off on it. If it, it’s a big enough initiative that has to be done. And this is the sacrifice we are making. You’re smiling.

Rhea Frondozo: Yeah. I mean, it happens all the time on the daily, right. Cause like we said, we always underestimate the amount of work that it takes to complete something. And then you end up in a situation where there’s more work than you have resources for, I mean, that’s the nature of the beast, right?

Mario Gerard: Yeah. Any other like big challenges you see when running these kinds of large programs?

Rhea Frondozo: I think maybe there’s one more around just finding the right owners. A lot of times you end up finding a new problem to solve and it can be hard to figure out who should own it. A lot of times teams are so overwhelmed with their existing priorities that they don’t want to take on a new challenge or they don’t want to take on a new scope of the project. And so not only is it prioritization, but maybe they’re like, not it, I’m not the one that should do it. And so, a lot of times this may require an escalation to figure out who should take on the new problem that’s been identified.

Mario Gerard: Yeah. I also remember one particular case. I wouldn’t go into the example exactly. But I remember a particular case where the stakeholders we had on our table, and we brought out this problem. I think after a week we realized that none of those stakeholders actually could solve the problem. We needed as somebody completely different from a totally different part of the organization who we didn’t even first consider should be the owner of solving this problem, because we didn’t have them on our table.

They weren’t part of our original stakeholder list of who we identified when we were working through this program. So, we had to like kind of think outside the box of like, which part the organization can actually go and actually solve something like this.

So, it makes you kind of take a step back and try to figure out like, where does this actually need to fit within the organization?

Rhea Frondozo: Right. Right. Defining, you know, roles, responsibilities, and ownership of some of these problems becomes a huge challenge sometimes. And it’s one that as a TPM, it’s your job to highlight, where are you blocked by this and then ultimately get buy-in from a new stakeholder that maybe you didn’t originally plan for.

Mario Gerard: Before that even I’ve seen, I think we’ve done this, we’ve gone on a discovery mode. You go and you try to talk to like 10 different stakeholders across the organization and try to figure out like, where would this fit? Because we don’t know every single Organization’s 10,000 people strong. You don’t every single function of who owns what, right.

So, you go through this discovery phase of talking to different people within the organization to see actually what their functions are and where will this actually fit and who is the right kind of owner to solve this particular problem. Because giving it to somebody that’s not, their problem space makes a big mistake. That’s a huge mistake to make. It’s very expensive mistake because they don’t have the expertise to go and solve that kind of a problem.

Rhea Frondozo: Right. And this is where I think one of my TPMS has told me sometimes, you know, as TPMS, we’re like detectives trying to figure out based on this clue, what’s the answer. And in this case, it’s, who’s the right owner who should own this. And you go, you know, knocking from door to door to try and see out, you know, are you the right owner? Should you be the right owner?

Lot of times nobody wants to do it. Cause it just means more work for them. But at the end of the day…

Mario Gerard: And sometimes they’re not [14:46 inaudible] for it also. They might be in a situation where we’ve spoken people and they have like 20 people on their team. And we know that this is such a big problem for them to go solve that it’s in their space, but they’re not either equipped to solve that problem or they don’t have the right resources to solve problem. So, it’s like super complex.

Rhea Frondozo: Yes. Yes. So, getting them to buy into taking ownership of the problem is…

Mario Gerard: And setting them up for success as well. As a PPM, you don’t want to just give somebody a problem. You want to ensure that they have the right resources and they’re putting those right level of effort and they understand the importance of this large-scale program and the impact it’s going to have on the organization to go solve that particular problem.

Rhea Frondozo: Right. Cause at the end of the day, you’re ultimately responsible for the program as a whole. And if you have a stakeholder that isn’t able to carry their weight, it’s not only a bad reflection of that stakeholder’s responsibilities, but your program as a whole, because your whole program suffers.

Mario Gerard: Let’s talk through that. If somebody’s not carrying their weight and they are a critical function, what do you do?

Rhea Frondozo: So, a lot of times this is where, you know, you end up having those conversations with the teams around what are options? Is it a prioritization problem? Is it a resourcing problem? Is it a skill problem? You know, do they not have the right prioritization because they’re working on something else or is it that they don’t have the right team assigned to it because you know, they put the junior developers on it instead more senior ones or is it that maybe we got it wrong. And they, when they started digging into the objective and the work that it really wasn’t in their wheelhouse to begin with, that can happen.

Mario Gerard: Yeah. So, it’s like, so these problems, so the next question is how do you manage and maintain information on a large-scale program? I think we spoke about this a little bit in the communication section, but generally when there are like hundreds of people, like hundreds of teams you are working with, how do you kind of maintain and manage information?

Rhea Frondozo: Yeah. So, this is where I think there’s a variety of different tools that could be used for this. And it could range from things like wikis or confluence pages. It could be, you know, work tickets from different systems. Sometimes people use JIRA, or I’ve used other kind of Salesforce tools in my current job.

A lot of times you want to be able to create D that are easy to see kind of maybe burn downs of your progress of where you’re at or you know, which items are particularly in jeopardy. A lot of times you could create PowerPoints for creating status reports or being able to do executive summaries. These reports could be PowerPoints or they could be emails or there could be newsletters that you create.

So it really comes down to, I think like what you said before, having a communication strategy about who needs to know what, and when, and then having probably a centralized place where you start from, you know, here’s a place where, you know, as a launching point for how to find the information about your program and then from here, you can figure out, you know, what are the different tailored communications that you maintain for your program.

So that if you’re an executive, you know, where you’re finding your executive summaries. If you’re a team member who is the point of contact working on it, what are your responsible for providing in terms of your updates and where, or if you’re a bystander walking by and want to know what’s happening to the program. You know, how can you find generic information on the program as a whole.

Mario Gerard: Yeah. I think also a lot comes down to how an organization manages this in general. So doing it at OCI versus doing it Salesforce, I’m sure there are certain types of differences, like how executives like to receive messages or how they want to receive the communication versus one organization versus the other.

Rhea Frondozo: Oh, for sure. I mean if you look at organizations like I’ll give you some examples. If you’re looking at Microsoft, everybody was creating very pretty PowerPoints on what their status was and what to their risks and issues were. But then you look at an organization like Amazon or OCI, which is, I think where, you know, OCI had learned from they’re looking at writing, you know, six pagers writing papers on like what the problems are or writing very detailed statuses and table formats versus pretty, you know, pictures.

So, it definitely can vary depending on the organization, depending on the leadership and depending on kind of the level of detail needed.

Mario Gerard: And even the program. If I think about OCI, right? I’ve been on so many different large-scale projects, some projects, you do a one-page summary, some projects you want to showed in table of format because you have 20 teams, or 50 teams and you want to show where each team is at. So, it kind of depends on so many different things. But you kind of got to figure it out as you go or rework your communication methodology or communication plan as the program develops as the organization depends on or you lead it, what they want to see it as how they want to see.

So, it’s a combination of different, there’s not, I don’t think there’s one size fits all here.

Rhea Frondozo: There’s definitely not a one size fits all. I think, you know, maybe you have templates or starting points that may become like anchors to a program, but as the program evolves, you know, your communication mechanisms often change and you have to be able to be responsive to what, you know, the needs of your stakeholders are.

Mario Gerard: The next question I had was in general for these kinds of large skilled programs, what is the TPM team structure? Like it’s not one TPM who generally runs such a large skill program or how do you orchestrate this? How do you explain that?

Rhea Frondozo: Yeah, so, you know, I think that the structure of a large program can vary in the sense of, you know, in some programs that I’ve ran. I managed a team of TPMS, and I owned the entire program, but maybe I was able to break off different projects within that program and assign it to different TPMS.

Or maybe you have a large program that requires multiple TPMS working on it. And you have, you know, different functional areas that you assign TPMS to that ultimately roll up to, you know, a single TPM lead or other times you may have a TPM as a lead, a breadth TPM, but maybe they’re working across a team of functional owners who have their own maybe depth TPMS that are assigned to the program.

So, it can definitely vary depending on kind of the size and scope of this large program. But I have seen it where typically there as at least a TPM lead and, you know, a number of different TPMS or functional area owner supporting them.

Mario Gerard: Yeah. I think you got to design that. Sometimes I remember like going to a program, we didn’t know how much work it would take. And then we kind of bring in people as we need, we probably start with like maybe one or two TPMS, and then you say, oh, this particular area needs so much of effort and so much work. And so much of design, program design that you actually go and bring in a GPM for that.

And then you find another problem area and you might have, so you have different work streams. That’s what used to call it right. Different work streams where we have what are many TPMS in charge of one particular work stream and that kind of all fits together into one large scale program. So, if you think about a large-scale program, you could have maybe one TPM running it, but generally it’s one lead TPM, as you said, and then multiple smaller streams of TPMS or POCs or whatever that might be.

Rhea Frondozo: Right, right. Exactly.

Mario Gerard: Do you have any kind of frameworks that you can talk about for executing these types of large programs Rhea?

Rhea Frondozo: Yeah. You know, I think if you think about a large-scale program, there’s often phases that these large-scale programs are comprised of. And so, at the core you imagine there’s the planning phase followed by an execution phase and then a phase where you’re in support or maintenance mode before you end up in a close-up phase.

And so, the frameworks that you end up applying to a large-scale program often are surrounded by kind of what phase of the program that you’re in. So if you are in a planning phase, you know, you’re going to be using tools like coming up with what is the problem statement coming up with a cost benefit analysis, where you’re weighing the pros and cons of the options for how you’re going to solve this problem and what are the associated costs of choosing one option or the other, and coming up with what your recommendation is.

And then you’re creating, you know, project plans around, you know, what needs to be, so how you’re going to solve it and how long it’s going to take. And you’re creating schedules and using Gant charts to come up with such schedules. And once you complete the planning phase, then you move into the execution phase.

And this is where you start tracking your project status. You’re coming up with status, you know, meetings or status reports, being able to come up with executive summaries on how the program is progressing, what are the identified risks and mitigation plans, you know, tracking risks under, you know, risk registers or mitigation plans.

You’re also at this phase coming up with ways to visualize what’s happening, whether it’s through dashboards or work tickets or newsletters around the program. Once you’re able to execute and build out the project or the product or the program, then you end up in what we call the support or maintenance phase.

And here you’re looking at assessing how well did you deliver on the project? And are there things that are missing? Are there things that maybe you didn’t get quite right, that you need to go back and fill in some gaps for, or maybe even redo or do a second version of, and then you end up in a scenario where you’re price prioritizing all the different issues that come up and you have to go through different exercises to figure out, you know, what do you invest in and how do you invest in it?

Is it something that you add to the existing program? Is it something that you rearchitect or maybe it’s something that you decide you close out altogether and start from scratch on a new program? So sometimes it means close out the program that you have and then figure out what is the new thing that will replace it.

And all the while, while you’re going through all of these different phases, you’re looking at kind of, you know, what is the cadence of the programs, communications that you’re in? Who are you communicating? When are you communicating and continuing to evaluate what is the different communication mechanisms that you need as you go?

Mario Gerard: Yeah. As you were talking through that, like one thing which I was thinking through is at OCI, you’ve been part of so many programs. I don’t know how many programs, probably more than five or six programs at the very least. Like what is an average time duration, do you think, think they vary, but why you tell our audience, like approximately like the first one we worked on almost took us probably more than two years, One and a half years, right?

Probably went on after we left as well.

Rhea Frondozo: Yeah. So, a lot of times for like big programs, I’ve seen programs be in the planning phase from anywhere as 1, 2, 3 months, all the way to a year of just planning, trying to figure out, you know, what investments that you need to make getting the right buy-in. Especially when you’re looking at things where you’re going to invest, you know, millions and millions of dollars.

Mario Gerard: Yeah. Hundreds of millions of dollars.

Rhea Frondozo: Hundreds of millions of dollars.

Mario Gerard: Literally like some of the material worked on are many hundreds of millions of dollars.

Rhea Frondozo: And so, a lot of times the planning for something that would like, that can take really, really long.

Mario Gerard: And it takes really long because it needs the most senior level executive buy-in. This is going up to a CEO of a company where they have like more than 150,000 employees. A multi-billion-dollar company, they have to approve an investment like that. And that’s why it takes you so long to even plan something. Because there are one, there are a lot of unknowns and two, there’s also a multi-million-dollar budget.

Rhea Frondozo: Right. Right. So definitely the amount of time that it takes for planning can vary, but I have seen it run very long. And then you add in the portion of execution, you know, execution can also vary, but for big projects, I was building a net new cloud region and I had worked on it for a year and a half before we even got to the accreditation state. Which is just verifying that what we built was the right thing.

And when we went into the verification stage, found out that we hadn’t done it all right. And had to redo some of it. And so, what was a year and a half ended up being another, add another year to that, to rebuild it and do it again. Yeah. So, I definitely, you know, from a time perspective, large scale programs can definitely take a lot of time.

Mario Gerard: Because of the amount of effort that’s required because of the number of people involved. Like these do take a lot of time.

Rhea Frondozo: And then when you’re talking about, you know, once you actually get it built, the program is still continuing right now you’re in the support or maintenance phase where people are actually using the thing. And trying to figure out, you know, what’s missing or what new things that we need to invest in.

And so, this can also be really variable depending on how successful the project is or unsuccessful in, in which case maybe it didn’t turn out as well. And there’s either investments that you want to make in it. Or maybe you want to shut the project down as a whole and start again. So yeah, it definitely can vary.

Mario Gerard: So, it’s kind of interesting to go down these one- or two-year kind of initiatives and then see it all be successful because there’s definitely a huge impact. And these are also another thing is these are things which give you your promotions.

These are things which move you from a senior TPM to a principal TPM or from a Princip of TPM to a senior principal TPM. These are career making initiatives that we are part of. This’s also a lot of risk and a lot of hard work late nights. But at the same time, there’s a lot of reward at working in one of these large-scale programs or leading.

Rhea Frondozo: For sure. I mean, it’s the kind of thing that these are the are kinds of programs that you take that have a lot of visibility that, because it makes such a difference to a business’s bottom line. If you do well and succeed, you can be heavily rewarded through a promotion or whatnot. If you don’t do well. There are probably other projects that you may be assigned to that maybe are more fitting.

Mario Gerard: Yeah. Also, I feel like we’ve done this so many times. I feel like looking at people around me, you will fail really fast If you’re not good at what you’re doing. Your senior leadership will take you off a program pretty fast. If they feel that you’re not up to the bar. So, if you’re not meaning the bar of running this really, really well, failure is very visible, very fast. That’s what I think I’m going to say.

Rhea Frondozo: For sure. In a critical project like this, if you aren’t able to effectively manage program, it’s going to show and it’s going to show at the highest levels. And so, there isn’t a lot of room for, I mean, not necessarily mistakes, but there’s not a lot of room for continued ineffectiveness. So, if you make a mistake and you learn from it and you figure out how to do it better moving forward, you know, that’s one thing, if you continue to be ineffective in your role, the business does not have a time or the appetite to continue something like that.

Mario Gerard: And that my friends is the end of part two of the three-part series on how to run blog scale programs with Rhea. Definitely check out part three as well and share this podcast, like it, and leave review on your favorite podcasting app. See you on part three.

Mario Gerard: Hello, and welcome to the TPM podcast with your post Mario Gerard. This is going be a podcast with Rhea. Rhea and I worked together at OCI running large scale programs. We’ve split this into a three-part series, and we’re primarily focusing on how we run large scale programs at tech organizations. So, stay tuned and listen in and definitely check out all the three parts to the series.

And so, this is Rhea’s co expertise, and this is what I’ve been doing as well for the last four years at the Oracle cloud infrastructure team. It’s definitely a very unique type of a role, unique type of people who get involved in running large scale programs. And generally, there aren’t many large-scale programs which are run within organizations, right?

So, I’m going to ask Rhea some questions and I’ll probably add to that as well. So, the first primary question for our listeners Rhea, what is a large-scale program? How do you define a large-scale program?

Rhea Frondozo: So typically, I’d say that a large-scale program is a program that spans multiple organizations. So, you’re looking at a program that maybe ranges from hundreds to thousands of developers or engineers, all working towards a very complex goal.

Mario Gerard: Yeah. I just feel that that needs to kind of sink in, right? So, the programs they’ve run, like we’ve had to move like 200 teams, which takes two years. If you calculate the manpower that’s required to do some of these initiatives. There are literally thousands or tens of thousands of manners of work. And so that’s like so complex. Do you think about it?

Rhea Frondozo: Yeah, I would say when you frame it that way, and you think about the complexity that comes with a large program, it may be the case that as a TPM, you’re interacting with a core set of stakeholders. Maybe it’s like 20 to 30 core stakeholders, but the multiplier under that for how many people that they are working with, how much direction that they are giving to an entire organization, it can be pretty mind blowing to know that you’re trying to move a ship that has so many people all trying to row in the same direction. It’s pretty incredible. Once you see the amount of effort that that takes.

Mario Gerard: And this is I think, where we also differentiate depth TPMS versus breadth TPMS, you want to speak of little bit about that?

Rhea Frondozo: Yeah. So, you know, as you mentioned, these large-scale programs are often run by a breadth TPM because these are going to be the TPMS who work across multiple organizations. They’re going to have maybe pocs that point of context that they interact with across maybe functional different organizations and teams.

Whereas a depth TPM, they’re going to go deep in a particular organization or team scope of ownership. And so, they’re going to maybe work more directly with the engineers on a single team and understand their problem space much more closely. Whereas the breadth TPM is going to rely on functional area owners to be the subject matter experts in that space. But they’re the ones pulling these different functions together to solve a much larger, bigger picture problem.

Mario Gerard: Yeah. And if you want to read more about the depth versus breadth TPMS, I’ve written a good blog post about it with my experience working at OCI. So, you should definitely go check that out. So, coming back to the skills required as a TPM, what do you think are the main skills that a TPM needs to have to run this kind of large-scale initiatives? Because I feel like the breadth TPMS definitely have a different type of problem that they’re dealing with than a depth TPM, right?

Rhea Frondozo: Yes. So, I would say first and foremost, when you’re dealing with these large skill programs, a breath TPM absolutely must have excellent communication skills. They must be crisp. They must be clear. They must be concise. If you think about the levels of communication that are required for a breath TPM. A lot of times you’re dealing with very complex programs that are being watched by the highest levels of executive leadership within an organization. So, you have to be able to communicate very crisply and concise to them.

You also are going to be working across a lot of different problem spaces and having to work across many other leaders or engineers and being able to get to the point quickly of what you need to solve by when and how is also really important. And so, communication is definitely key to your success and running a large program.

So next I would say is a long in the lines of communicating, but your ability to define a clear objective and scope a large program is going to be very, very complex. And if you don’t have the right objective laid out for all of these people to follow, it’s going to be very difficult to make sure that everybody’s running in the right direction. And so being able to define a clear objective and scope ends up, you know, being like we said before, a good measurement of whether or not you’re solving the right problem.

Mario Gerard: And I think to add to that, right, I think why that’s super important is every stakeholder who comes to your table, who’s part of your large-scale program has a different function at times. You might have security, you might have operations, you might have 10 different teams providing 10 different pillars of software. So, everybody has a different output they’re going to generate, right?

And your problem definition, and your objective needs to be super clear because everybody’s going to interpret it kind of differently from the functional perspective. And that’s why you’re going to keep re recreating and retelling your story. You are retelling your objective multiple different times, but the people are consuming it at translating into what they each need to do.

Rhea Frondozo: Right, right. Great point.

Mario Gerard: So, what are the other skills you think are kind of important?

Rhea Frondozo: So, you know, I think another one that we had touched on earlier is just your ability to problem solve in an ambiguous or unfamiliar situation. When you have a large-scale program, a lot of times you don’t know what’s coming, you don’t know what kind of problems you’re going to run into. You can try to plan as much as you want, but there are so many variables that come with running a large-scale program that it’s very difficult to predict what can go wrong.

Mario Gerard: Or what problem you going to encounter tomorrow? You wouldn’t even know that.

Rhea Frondozo: Right. Right. And so, when it comes down to it, there’s always going to be these curve balls that get thrown at you and you can prepare for as many that you think you may know, but it’s hard to predict. And so, knowing how to deal in real time with a problem at hand is very, very important.

Mario Gerard: So, we spoke with three skills, communication, the ability to define clear problems and scope and the problem-solving skill and the being able to deal with ambiguity. So why are these like so important in the large-scale program?

Rhea Frondozo: So, if you can imagine being a TPM, it’s like being the quarterback of your program, you you’re the one calling the plays, which ultimately makes you the key player responsible for determining the success or the failure of the program.

Mario Gerard: To recreate that, right? So, you are calling the shots most of the time. You are the person giving direction of what needs to be done, how they need to be done or what direction they need to take. So, [07:57 inaudible] program, which we run, right. There are so many decisions, a TPM who’s running a breath program takes on a daily, if not a weekly basis. They might have to go and recheck that with somebody. But there’s so many decisions, so many directions he, or she’s giving them.

Rhea Frondozo: Right. Right. A lot of times what happens is when you are in a breath TPM role, your job is to unblock issues that come up. So, you work on this plan, you come up with what you think is going to work. And then day after day, something goes wrong. And it’s your job to figure out, how do you call an audible on what you should do instead, or what you should do differently or who you need to pull in. It’s really your job to take the lead role in not only determining what needs to be accomplished and bringing all the people to do it, but also figuring out what happens when everything goes wrong, and it doesn’t pan out as you expected.

And so, the reality is if you aren’t able to communicate crisply and clearly you can’t leave the team by setting a clear objective and you can’t help unblocking obstacles when you game plans are required. And if you can’t do these, then chances are you won’t be successful in running your program.

Mario Gerard: Yeah. I think we have a question later on about this, but I was doing this, say that a lot of times, why things go wrong or why there’s so much ambiguity and why there are new problem discount on a daily basis, or a weekly basis is because most of the times when, at least the program we run, right.

They’ve never been done before. These are brand new initiatives, which are kind of game changing. Like no man has traveled down this road before. Nobody’s gone there. So, it’s like discovering space. You don’t know what you’re going to hit every day is an adventure. And you got to just take it as it comes, and you got to be able to deal with that.

Rhea Frondozo: Right. So, a lot of times, you know, I think of it, like if you are, let’s bring it back to the team analogy. If you’re working on a project that you’ve never worked on before or a program that you’ve never seen before, it’s like playing a team that you’ve never played. You haven’t had a chance to scout out the challenges that they’re going to bring you are, you haven’t had a chance to see how they operate. And so instead you’re learning as you go.

And so, every day becomes a challenge. And that at it’s some kind of new thing that you didn’t expect to come, and you’ve got to figure it out, you know, on the spot.

Mario Gerard: Yeah. Coming back. So how does a TPM kickoffs a large program like this? What’s your go to playbook?

Rhea Frondozo: So, one of the biggest things that is really required and kicking off a large-scale program is getting buy on the problem statement and program scope from an executive sponsor. If you can’t clearly articulate the problem statement and you can’t define the program scope, there’s no way that you’re going to get buy-in from anybody, let alone your executive sponsor.

But once you’re able to get an executive sponsor, then you can get buy-in from the rest of the key stakeholders. Now, what happens typically is you have stakeholders then that nominate pocs or points of contact who end up working on the program themselves. And then you end up doing stakeholder kickoff meetings to make sure that you get everybody on the same page with what the program scope is, what you’re trying to accomplish and what everybody’s kind of roles and responsibilities are in the program.

If you don’t have the appropriate buy-in on the prioritization at the executive levels, then what happens is that you end up continuously fighting an uphill battle, trying to get the pocs to work with you on any kind of program initial often, because there ends up being competing priorities that they will choose over yours.

Mario Gerard: Yeah. That makes perfect sense. Coming back to the question on execute sponsor, right. What do you think is the execute sponsor’s role? What do you expect from an execute sponsor?

Rhea Frondozo: So, I expect the executive sponsor to really understand the problem statement of what we’re trying to solve and really put their weight behind why we are solving this. And if there ends up being a question of priority or a criticality for the project that we’re working on, they’re ones to stand up and essentially back you on the asks that you may have, it could be from the perspective of resources that you need to work on a program.

Mario Gerard: It could be because these resources are in other teams. So visually what I’m trying to see is think about an executive sponsor. They have five other counterparts, Or six other counterparts. So, this executive sponsor now needs five of his colleagues who have five different functional areas that they’re responsible for to give you X number of resources from every team.

Some teams might give you like 50 people. Some things might give you a hundred people. Some teams might just give you four or five, but that executive sponsor now needs to go and convince his fellow colleagues That he or she needs all these people from their teams. Probably these people already have a roadmap they assigned up to deliver. Or features or product work. But now they need to be re-tasked to go and solve this particular problem.

Rhea Frondozo: Right. Right. So, this is where your job to inform your executive sponsor on the importance of the initiative, to give them the ammunition that they need to go make those asks to other teams becomes so important.

Mario Gerard: Yeah. It also helps if the program, the large program that you are working on is a goal for your senior executive or your executive sponsor. Ideally that is the number one deliverable.

Rhea Frondozo: If their success is tied to this program, then typically it means you’re going to get whatever help you need. Yeah. For them to be successful means the program will be successful.

Mario Gerard: Yeah. So generally, if you think about a senior executive, they probably are delivering like maybe four or five things every quarter or every six months. And if your program is part of, one of your primary goals, it becomes much easier to drive that initiative. At Amazon They have SVP goals. Is this project or program that you’re going to work on? Is it part of an SVP goal? So, SVP might have like 3000 people or 2000 people around with them.

And if this particular large-scale program has a backing of a senior execute, they are closely watching it, then everything, all the cogs like fitted together and magically work. Otherwise, it’s very hard to get all these teams to row at the same time to that cadence.

Rhea Frondozo: Exactly. We have a similar thing at Salesforce. They call it V2 moms.

Mario Gerard: What is it again?

Rhea Frondozo: V2 moms, where you have your method and your obstacles and your measurements That are required for completing whatever goals that you sign up for. And you’re exactly right. That if you get your program or your project on, you know, an executives V2 mom, it means that they are going, going to be watching the success or failure of that project and whatever help that you need for that to be successful, they are going to back you on that.

And so, a lot of times it means that they’re going to ask that another peer of theirs yeah. Have the same goal on their V2 mom. Because we want to be able to hold them accountable for the work that is needed for this program to be successful. So very, very similar in nature in terms of the hierarchy [15:37 inaudible].

Mario Gerard: Yeah. And it’s very interesting how this works, right? Because sometimes the vice president, the executive driving this might not actually be spending a lot of resources to deliver that objective. The resources are coming from his or her peers. And it’s fascinating if you think about it right. Or how this large program kind of operates and works.

Rhea Frondozo: Right. So, what we call that Salesforce actually is some of the goals that we have are sometimes what we call informing V2 mom goals, where we are informing other teams of this, what we need from them. And other times you have these executing V2 Mons where you’re actually executing on this work. That has been given to you from another V2 mom That was the informing V two mom.

Mario Gerard: Yeah. It’s fascinating. So let me ask you another question. So why are these large, scaled programs like why they important to an organization?

Rhea Frondozo: So typically, programs that are critical to the business are the ones that require the most investment. And it means that a large-scale investment across multiple teams is really going to determine the success or failure of the program and whether or not this program succeeds ultimately impacts the business’s bottom line.  And so, you’re going to end up looking at projects that have a huge impact to the bottom line as your kind of large-scale critical projects that need to be funded.

Mario Gerard: Yeah. As you said, right. This is like moving a large ship. This needs to be so many pieces that kind of come together. One of the things which I can think of was the programs, which we first originally worked on, which Rhea and I worked on at OCI was to bring every single Oracle SAS product onto the newly built cloud and infrastructure platform.

So, Oracle has said 200 plus SAS products. And the goal was to bring every single product onto this platform, which when we are spinning up, like 200 different teams are going to go and work on something and they need to move from an existing data center to the new data center. So just think about the sheer scope of that work and how many teams it kind of spans. But at the end of the day, that particular initiative brings in a lot of revenue or a lot of car savings for the entire organization, probably like billions of dollars of cost saving over like 10-year period.

And that is why this kind of large-scale programs are like so important to organizations. They’re like critical. They’re almost like liberalized situations or game changing in the Marketplace. That’s why it’s so critical that these large programs have to be run properly. And that’s why they have the executive back.

Rhea Frondozo: Right. So, another example that I would give is in addition to the project that you and I worked on about moving the SAS products to OCI, a lot of times there are, when you talk about game changers, big business opportunities that can change a company,

Mario Gerard: Bottom line revenue.

Rhea Frondozo: Bottom line. And so, some of the ones that I had worked on really came from the potential to win big government bids. These are bids that are worth, you know, multi-billion dollars. And the ability to not only participate in responding to the bid is one thing. But winning the bid itself is where that game changing happens.

Mario Gerard: Yeah. And we could spend millions of dollars to win that multibillion-dollar engagement.

Rhea Frondozo: Right. And that’s exactly what we did, right. I mean, these are not small feats to try and to win a multi-billion-dollar opportunity. You’re talking about millions of a dollar investment and not only infrastructure and hardware and the engine engineering that’s required and the people that are needed to run these products. It’s a massive Orgwide initiative to be able to compete for such a bid.

Mario Gerard: Yeah. And that’s why they’re kind of so important and there’s so many eyes on it. I think we go into a little bit more detail later on about that. What are the top things you think we need to keep in mind when running this kind of large-scale initiatives or programs as TPMs?

Rhea Frondozo: Gotcha. One of the things that comes top of mind goes back to communication, right? Being able to communicate effectively at all levels, whether it’s to highlight risks or issues or the progress to executives, or whether your problem solving with engineers or pulling in engineering leaders and managers to help with prioritization, you have to be able to do it all and you have to be able to do it all effectively through good communication.

Mario Gerard: And I think that’s like, we can’t reiterate that point because as a large scale TPM, I think the primary job in running this large-scale program is communication. The number of meetings you are in per day, you’re generally giving people, I wouldn’t say a direction you’re giving people direction. You’re telling people what to do. You’re understanding problems.

You’re re communicating that problem to somebody else. You’re trying to problem solve that with 10 other teams. So, communicating articulating the ability to understand is so crucial and giving the right level of importance of [20:58 inaudible] type of problem. So, it’s really, really crucial that you have good verbal communication, good written communication. You’re able to produce good reports, all of those things.

Rhea Frondozo: Right. Right. Exactly. Exactly. I think, you know, something else to keep in mind when you’re running these large programs outside of just, you know, the communication is, you know, as we mentioned, when you run a large complex problem, you always have to expect that something is going to go wrong. I’ve never seen a program, especially a large one run so smoothly where nothing goes wrong.

Mario Gerard: How many program problems you general you had if you think about a month.

Rhea Frondozo: I think about it in a day, every day, I’m dealing with multiple problems.

Mario Gerard: It’s just like crazy number of problems that you have to go solve.

Rhea Frondozo: The more complex the program, the more problem ones that you’ll have. And what ends up happening is that the value add that you bring as a TPM is your ability to work through these issues, by collaborating with your stakeholders and coming up with the mitigation strategies that are needed to get these programs back on track.

Mario Gerard: And I can think of another one is these problems Shouldn’t phase you out. They shouldn’t take away the steam that you have. You have to have that steam every time you hear about a new problem, that you’re going to take it out and you’re going to go and solve for it.

Rhea Frondozo: Yeah. Because at the end of the day, like it’s the nature of the beast and your job really is to problem solve. And so, you create plan as a starting point, but all that is a starting point. And every day, you know, these problems will take you in a different direction and you have to figure out how do you keep course correcting to get to your end game. And there is no straight-line path that I’ve ever seen a program take.

So being able to be flexible, to respond to issues that arise to be creative and how you solve problems to know when to pull in the right people. Cause a lot of times you’re not solving these problems by yourself. You have to know who to bring in and when to escalate for when you need help.

Mario Gerard: Yeah. Why do you think there are so many problems Generally?

Rhea Frondozo: I think it’s because you know, like we mentioned there is, no two programs are the same. And so, no matter how much planning that you think that you do for one program, the variables will always change. You know, you’re never going to know if you’re going to have somebody get sick or quit and that’s a critical resource to your project. Or maybe there are things that you didn’t plan for like a pandemic that affects your supply chain and limits your ability to get resources on time. Or maybe there’s this crazy technical challenge that nobody’s ever solved before.

And you think you have a plan, but when you try it, you realize it doesn’t work and you need to go back to the drawing board and figure out a new game plan. I mean, at the end of the day, a lot of times what happens is that you’re venturing into unchartered territory and it’s the kind of scenario where you end up having to try, try and try again until you get it right.

Mario Gerard: And this is also, I think when we, as TPMS need to be okay with these types of small failures and executives are very understanding. Actually, if you think about it, right, it’s just that you have to communicate why this came about, why we didn’t see this and what we are doing and if they have any suggestions or ideas to go and [24:22 inaudible].

Rhea Frondozo:  Actually, you know, you bring up a great point. I once had a TPM tell me that she was really worried that she was going to be seen as a failure because her project kept getting delayed or kept getting moved out. And what I told her is there is no project that I expect that the reality is we’ll finish as you expected on time. And what I do expect is that your job is to communicate when things are going wrong, communicate what our options are, communicate what challenges you’re facing and what help you need and then reset expectations on a path forward.

And so, if you can do that, then that to me is a measure of success. If what you do though, is wait till the very end and then say you failed and you didn’t come in time. That to me is a failure to communicate, which is one of the key things that we said earlier. You have to be able to communicate what’s happening with your program. And even if it means the program or timelines change, that’s okay. As long as you’re resetting expectations.

Mario Gerard: Yeah. And I think you mentioned a very, very important thing, which I was just thinking through that you have to communicate that really soon. If you know about a problem today, ideally your executive knows about depending on the size of the problem, depending on the impact of the problem, ideally, your executive knows about that by four o’clock today, right?

Like you need to be able to articulate, communicate that and let them know so that they also are thinking about the problem. They also are trying to vett whether the direction or the route we are taking is the right route, For the program itself. So not sitting on it and sweeping it under the rug. I think you got to have the courage

Rhea Frondozo: And the judgment. I think one of the things, the value add that you bring is your judgment to a situation and an executive isn’t going to be working in the trenches with you. So, they’re relying on your judgment to know what issues are real things that they need to worry about. Versus things that you guys can handle on a micro level. Right.

And so being able to identify what are real risks to your program that need help by making the right judgment call really is what an executive is relying on you for.

Mario Gerard: Yeah. And keeping them informed about these kinds of things as early as Possible, but not somebody else telling them, hey, I heard that this is going wrong, you know about this, right? So, it’s that judgment and the courage that you have probably to bring it up and to go to them, ideally with both solutions and a very clear problem statement and solutions to their problem, statement of your, how you’re going about handling that situation.

Rhea Frondozo: Exactly. And I will say, and even just in my current role, I’ve been in situations where the amount of confidence that your executive will have in you is going to be much higher. If they see that you come to them with problems that have arisen, as well as, you know, potential solutions that you’ve thought through for their input, you know, for what is it that they recommend or what are you recommending them to do versus them hearing from other teams that the project is going awry. But you keep saying that the project is green and on track.

So, it definitely is in your best interest to be able to articulate ahead of time, what’s going wrong, Why and what are you doing about it? Then assume that if you just say the project is green and think that you’ll figure it out as you go without keeping your executive informed, that ends up not biting you later.

Mario Gerard: Yeah. I remember sitting through one of the executive meetings where somebody said are these all watermelons where all of these are green on the outside, but they’re all steaming red inside. How are you telling me all this is green while I keep hearing from everybody else that these are so much in bad shape. Why are you not surfacing this out?

Rhea Frondozo: Right. Right. Exactly. That’s exactly what you don’t want to do.

Mario Gerard: And that my friends is the end of part one of the three-part series on how we run large programs, a conversation with Rhea, definitely check out part two and three. I’ll see you on the other side. Bye. Bye.

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Rhea Frondozo. She and I have worked together at Oracle cloud infrastructure team OCI. Rhea has been a tech industry for the last 20 years. She’s worked at IBM for eight years, Microsoft for fours, EMC square. And then at OCI for six years, she’s had a variety of different roles as well. She’s been a developer, a program manager, a test manager, engineering manager, a director of TPM, and right now, is working at Salesforce as a senior director of TPMS. Her specialty is to run large scheme programs. Rhea, thank you for joining us today. And why don’t you introduce yourself to our audience to our audience?

Rhea Frondozo: Thanks Mario. As you mentioned, I have had a 20-year run in the tech industry working for several of the top tech companies in a variety of different roles.

But what I found is that I’ve always been most interested in working on large scale complex programs and products after trying out so many different roles at different companies. What I now know is that my passion tends to be working on projects that aren’t so much consumer facing in terms of features or products or services, but more on, so solving enterprise level infrastructure challenges.

I find that the problem solving I enjoy most applies to cross-functional technical challenges that typically span multiple products, services, or even processes.

Mario Gerard: Fantastic. Rhea and I actually have worked together at OCI. As I mentioned, we’ve been on the same team I’ve reported to Rhea where it was so much fun. We’ve actually solved so many large-scale programs or problems, which turned in programs and I’ve learned so much from her. So, I think this is going to be a very interesting podcast. So how we have designed today’s podcast is the first section. We are going to just go over some very fundamental TPM questions with Rhea. And the second half of the podcast, we’re going to go very much into the details of how you’ve run a large-scale program.

So, let’s start with the first section, right? So, Rhea, how would you describe the TPM function?

Rhea Frondozo: So, the TPM function I have to say is not a very easy one to describe because it typically is something that varies from company to company and organization, to organization, team, to team. It’s a newer function I think that has a blended role within many organizations.

So, if you can imagine at the base, you have the project management or program management responsibilities, then you apply that to some kind of technical project, program process that needs to be solved for. And so, it also can vary tremendously depending on seniority level. And so, the scale at which you operate can be very small and narrow, more depth focused If you are a depth TPM, or it can be very large and crosscutting across entire organizations or entire companies, if you’re looking more at the breadth TPM role.

Mario Gerard: And what would you say are the core skills TPM should generally have?

Rhea Frondozo: So, at the most basic, you know, skill that I would expect TPMS to have been first and foremost, project management skills. These are just your basic project management skills around being able to define scope, a problem space, understand business impact, being able to identify key stakeholders and goals that you want to solve for as well as, you know, creating schedules and tracking execution.

But outside of just your project management basic skills, the expectation would be that you have to have very solid communication skills. The ability to communicate both up down and laterally, whether it’s your having conversations with Lee leadership, having conversations with team members, who you are giving direction to, or maybe peers or TPMS that you are trying to get to work on your project, who are maybe peers.

Outside of communication Some other soft skills that I think are important are just the ability to deal with ambiguity. Having a project manage background typically means that you might get applied to a variety of different problem spaces that aren’t often clearly defined. And so being able to be dropped into an ambiguous situation and figure out, you know, what is the scope that you have to solve for is hugely important.

A few other ones to note, I’d say, are your ability to collaborate with People. Being a program manager means that you’re going to be working across the board with a number of different stakeholders and your soft skill of being able to get people to work with you becomes essential.

Maybe the last two dimension come from the perspective of your technical focus. You have to be able to solve problems but solving could mean in a way where the T is a capital T a big T where you’re solving very technical problems or maybe a little t, where you’re solving more process problems in a technical space, but maybe not being the subject matter expert or the architect that has to solve those problems.

Mario Gerard: You spoke about the capital key of being like, you know, somebody who’s solving like very technical problems, and then somebody’s not solving too big of a technical problem. Would you say a depth TPM generally is more technical versus a breadth TPM might not need to be that technical?

Rhea Frondozo: So, I would say it’s definitely beneficial for a depth TPM to be more technical because you’re often going to be in conversations with engineers directly, even be managing a project where your key stakeholders you’re working with are engineers. It may not be absolutely necessary if you’re paired with maybe a technical architect or maybe a technical team lead that in that case, it may be the case that your core project management skill sets or what that team is lacking. And then you can still add value to the team that way.

But in general, yes, if you have more technical skills, it definitely makes it easier to perform in a depth TPM role.

Mario Gerard: Cool. How do TPMS measure impact as you spoke about like TPMS helping teams out, how do they measure impact?

Rhea Frondozo: Well, so similar to any kind of program that you may have, you can measure your own KPIs as a TPM, depending on some of the deliverables that you have as an individual, whether it’s, you know, were you able to deliver your program on time or within budget? Were you able to deliver a solution that actually solves the problem at hand? Are you delivering the right solution, so these are some of the things that you can measure from the program perspective, but there’s also a way that you can measure your value by what soft skills do you bring to the table?

Are you someone that can bring the right people together? Do you have the ability to lead a team and to identify the right problem to solve? And so, the how you deliver is something that can also be measurable.

Mario Gerard: That’s interesting. When you talk about how a TPM is bringing people together, the first question that comes to mind is influencing people because you don’t have anybody actually reporting to you directly as a TPM, what would be your guidance and how TPMS can build something like that, like influencing without authority.

Rhea Frondozo: So that’s a great question. A lot of times when you get into a TPM role, this is maybe something that you might not be familiar with at first. And so usually a TPM will start with working on much smaller projects where the set of stakeholders that they have may be rather limited. And the number of people that you have to influence can be pretty small.

And you have the opportunity to kind of practice how you get their buy-in to the project that you have by typically being able to explain clearly, what is the problem at hand? What is the business value that you would be delivering if you guys can solve this problem and then ultimately starting small, and then you end up being able to grow the number of stakeholders that you work across by being able to work across more stakeholders, you have to be able to continue being able to deliver a good business justification that helps people understand the necessity to work on your program.

Mario Gerard: That’s a very good way of explaining that I think. So, you’ve hired hundreds of TPMS. You’ve probably interviewed thousands of TPMS. What do you look for when you hire TPMS?

Rhea Frondozo: So, I think a lot of it comes down to those basic skills that I mentioned earlier that you have to have, I think first and foremost, when I’m creating, say a loop for a TPM, I’m definitely checking to make sure that we’re assessing their project management skills. Have they managed projects before? Can they tell me about a project that they’ve had to define, had to get buy in on, had to get stakeholders to agree, had to identify the right scope, the right goal to accomplish, and then, you know, what’s their track record on executing against projects that they’ve had to manage.

Other things that I look for is, you know, their ability to communicate. Are they able to clearly articulate what projects that they’ve had, the value that they’ve been able to bring? Tell me about times where they failed maybe and what they’ve had to do to recover or what they learned from those failures.

Also, in general, I think when I’m hiring TPMS, I’m looking for what kind of hunger that they have to want to learn. It’s not very often that you get two projects that are always the same from one to the next. Projects always change. Project to project variables is always different and somebody who is able to continue growing in their space and taking on different challenges and being able to navigate different problems and being interested in doing so is something that I’m always looking for.

Mario Gerard: Also, there’s probably one more aspect, right? As I was thinking through this is that you try to, when you’re hiring somebody for a particular program, you might also look at what that program would need and then hire the right type of person for that particular program. Or once, sometimes we hire like three or four people and then we match them to the right program. Like the skills from doing the interview, fixing on a candidate.

And if you have like a bunch of candidates, we then say, hey, this person’s going to be good for this particular program that person’s going to do well in that particular program.

Rhea Frondozo: Right. That’s a good point that you bring up. Cause part of what I would say outside of just kind of the generic skills you have; you’re also going to be looking for what particular expertise do they bring to the table? Is it someone that’s worked in an infrastructure space? Is it someone that’s worked on customer facing projects? Is it someone that’s worked on delivering products? Is it someone that’s done process improvements? So, depending on what project that you are program, you’re looking for somebody to take on, matching their experience with that project also goes long way.

Mario Gerard: And probably the seniority level as well, right? Depending on how senior they are, you probably say, well, they don’t need too much guidance, or they can run with this. Or my expectation is that they run with this.

Rhea Frondozo: Right. So depending on the structure of the team and the complexity of the project at hand, you may be able to take on somebody that’s saying more junior, if you have more and your people on the team, or if you’re looking for somebody who can run independently, then you’re probably going to want somebody more senior who you know has a demonstrated track record of running large scale projects on their own.

Mario Gerard: And as we are talking through hiring TPMS, how technical do you think TPMS need to be when you’re hiring them? Or what’s your bar? How do you evaluate that?

Rhea Frondozo: Yeah. So, I also think that this can vary depending on the position that you’re hiring for. So, as we mentioned earlier, if you are hiring for say a depth TPM, that’s going to work very closely with engineers and having to work in a space where engineers are creating solutions and you need to be able to make sure that your TPM can vet those solutions and challenge those solutions If necessary. Having a technical background or technical expertise is going to be very valuable in that case.

But if you’re looking at other maybe projects that are very large scale, across many different teams, maybe you’re going to have, have a different structure for the team where there is a pairing with a more technical architect that you work hand in hand with. And it’s not as necessary for you to have a TPM that has, you know, both of the project management and the technical skills, or it could be the case that you’re working on a process improvement that is applied in a technical space. But if they have the ability to identify pain points, ability to identify process improvements that are possible, then it could be the case set. It’s not as necessary in that case either.

Mario Gerard: Yeah. That makes sense. The last question I have in this section is do you have any tips for people who are moving from an IT services industry or a non-product-based organization who’re looking to move into a more product-based organization or a product-based company.

Rhea Frondozo: Yeah. So, this can be a pretty tough move for someone to make a lot of times.

Mario Gerard: And you’ve been hiring a lot of people, right? I think this is one of those difficult problems that you face when you’re looking at resumes of people who are not completely in the product space.

Rhea Frondozo: Right. Right. So, I do have applicants that often apply to my roles who are coming from say a service industry and don’t have specific experience working on a product. In that case a lot of times what I’m looking for is if they can tell me about maybe projects that they’ve had in their roles, where they’ve had to identify a problem space, and they’ve had to identify maybe a pain point that required some kind of improvement or buy-in from stakeholders to get engineering to deliver on a tooling or process improvement.

If they can do that, where they can show that they’ve been able to demonstrate, you know, a way to assess a product or a product gap, assess a process gap, figure out how to prioritize the work that would be needed by defining the business impact that it has. These are the types of skills that could be transferable to working in a more product based TPM role.

Another alternative I would say is if you have of a, more of like an operations TPM role in a service industry, which could be something that you could take a, maybe a parallel job in a company that has, you know, product based TPM roles. And then once you get there, try, and make a transition internally to a product based TPM role based on a track record that they can vet from sister teams.

Mario Gerard: Yeah. And then move more organically once they’re within the organization. That makes perfect sense.

And that my friend’s end of the first part of the podcast with Rhea. We have a full three-part series after this, where we are discussing how one would run a large program in a tech organization. So definitely check that out. That’s going to be a very, very unique episode. Thank you so much. I hope you enjoyed this. If you do, like it, share it with your friends, share it on LinkedIn and definitely leave us a review on your favorite podcasting app, thank you so much.

Check out the next episode here.

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Priyanka Shinde. She has extensive experience as a TPM. She’s worked as a TPM, a TPM manager, several organizations like cruise autonomous, Facebook and Meta. And she has over like 20 years of experience in the tech industry. She’s also launched TPMify, which is a coaching and consulting organization with a mission to help TPMs and TPM organizations reach their goals faster.

If you haven’t checked out our blog www.TPMify.com, that’s www.TPMify.com. You should definitely go check that out. It’s got a lot of interesting content. She’s been publishing a lot of great resources for TPMs. So do go and show some love. There aren’t many TPM bloggers and people are contributing back into the community. So, the few of us who are there, I would love for all of you to go and show some love and check out her blog and all the other workshops she’s trying to conduct.

Priyanka and I are today going to try to discuss the various types of product manager technical and TPM product type of roles. I’m sure you’ve seen a lot of these roles coming up in job boards recently. And so, we’re going to like try to decipher what the product manager technical role is and what the TPM product role is and how they kind of coexist.

Welcome Priyanka, Welcome to the TM podcast. Could you give our listeners a quick introduction of what you’ve done, where you’ve been and your journey so far?

Priyanka Shinde: Sure. Thank you, Mario, for having me on the podcast. It’s great to be here. Yeah, and thank you for the introduction. Like Mario said, I have over 20 years of experience in the software tech industry across, you know, various type of technologies, AI, machine learning, AP tech, education tech. And so, it’s been a really journey. I did start out as a software engineer and then transitioned to the TPM role because I really enjoyed kind of getting involved from like start to finish as well as just seeing kind of things come to life. And so that was my primary motivation of transitioning to TPM.

And then once I became a TPM, I worked at startups. I worked at, you know, like big companies, like Facebook as well as companies like Cruise. And I really enjoyed kind of like the different aspects of what was being offered by these companies. But throughout these times, I kind of became more and more passionate about the TM role. So, you’ll see me, that’s why I write a lot. That’s why I try to, you know, kind of really help back because I really feel very close to the TPM community. And I feel very passionate about building this strong TPM community because I truly feel that TPMS when leveraged correctly can make big impact on organizations. And I want TPMS to realize their own power, but I also want organizations to understand that that’s my aspirational goal for us TPMS.

Mario Gerard: That’s so well put, and you could probably do an entire podcast with Priyanka’s journey of becoming a TPM because all of us have different journeys and different paths that we take it to get to where we are. So that’s kind of a real interesting journey to, you know, maybe decipher one day. But okay. Let’s start with, today’s like first question to Priyanka. Like Priyanka what do you think the TPM role is like decipher that in your own words, like what the TPM role is and why does the industry need a TPM?

Priyanka Shinde: Sure. Yeah. So, the TPM role or the technical program management role, I feel is a very special role in the sense that it has so much of that technical focus while leveraging your core program management skills and leadership skills. Sometimes I’d say, you know, TPMS drive holistic execution strategy by leveraging their deep domain expertise to basically meet the goals or deliver results, right? That’s the end goal.

And so, I feel like, you know, the industry has moved on from like program management or, I mean, we still have program managers, but the TPM role, I feel came more into prominence over the last maybe couple of decades because of the technological advancements that we are seeing in the products, right. Products are becoming more complex.

Now you have, you know, you don’t have kind of like single screen things or website it’s now, you know, like I can talk about autonomous [04:15 inaudible] all day long in terms of complexity, right? Yeah. And so, what that does is that you now, you know, you cannot just have coordination, facilitation, tasking, all of those are still important, but by having some of that technical expertise and domain knowledge, you actually elevate your program management skills. So that’s why I feel like the TPMs kind of is a role that has kind of evolved as well as gain more prominence in the last couple of decades.

Mario Gerard: Yeah. I’ll add a little bit to that. Like the complexity of the programs have gone up so much and there’s so many teams that own separate confidence and do any complex program. All these teams need to get really well and interact so much that the need for somebody to step in, it could be a TPM. It could be an engineering manager, it could be anybody with different titles, but the role they’re trying to play is trying to bring these teams together to accomplish the final goal of the program. And that’s where you’ve seen the technical program manager role kind of blossom the last decade as Priyanka said. What are the skills do you think TPMs require?

Priyanka Shinde: Yeah, so of course, you know, we talk about technical, like the team TPM, largely, so you of course need the technical or the domain expertise. And that can be based on whatever background you have, or you can build on it, right. Or you can continue to like to evolve based on if you change domains. But besides the technical skills, you need strong program management skills, right. Something you just said, Mario, who is we have to be able to work with multiple teams. Like it’s a highly cross-functional role. And so being able to kind of have all of these balls up in the air, knowing which team to go to for what, and like managing all of this, the ability to see big picture and look around corners like, that to me, is very, very important in the TPM role.

Related read: Meta TPM Interview Guide

Besides that, I think TPMS need to have really strong communication, both written and verbal, right? We are to be working with a lot of different teams. We work all the way from our peers, other teams, that partner teams, as well as leadership and executives. And so, we need to be able to communicate exactly what we are seeing in a way that kind of brings confidence, but also provides clarity to our audience. And finally, like we need leadership skills, right? TPMS are there, they’re influencing without authority. We hear that, right. We are working again with multiple stakeholders. We have to build relationships. We have to motivate these teams. We have to manage the conflicts. Like there’s so much of all these people skills involved here. And it is a core part of this TPM role as well. So, I say those are the core things in terms of skills.

Mario Gerard: Yeah. Yeah. Definitely, communication is so important. Like we talk a lot about communication, but at the same time, unless you are a TPM and you’ve been in a role like that, you don’t understand the value of communication, how succinct you need to be sometimes. How you need to communicate at different levels within the organization, as you just mentioned, and the leadership skill, I think you called it a few, right? Like influencing with that authority is so important. Building relationships is so important. Motivating teams, as Priyanka said, super important when you don’t have a team reporting to you, especially, right.

This is completely like influencing without authority. And it’s so key, if you think about TPM skills. Let’s switch gears and move to the product manager role, because we’re going to be talking a lot about the TPM product and the product manager technical role. What does a product manager do and what is, his or her role?

Priyanka Shinde: Yeah. So, you know, sometimes there’s so many ways to define what the product manager role. And of course, we have a product manager here. They might say something. So, I’m going to kind of try and frame it the best I can without, I mean, I did kind of played a part product part program manager role at one point. But you know, of course in a lot of times when, even from a TPM perspective, we say, oh, product managers mainly define what, right? They are identifying significant opportunities. They’re driving product vision, strategies, roadmaps in the context of like the broader organizational strategy and goal.

They, of course, you know, in corporate data, research, market analysis to inform their product requirements and the priorities that they want to make. And of course, in all of this, you know, they’re defining requirements, they do this in collaboration, of course, with research, design, engineering TPM. And so, you know, sometimes even in small teams or startups product manager may do their own research, right. Or build their own wire frames or even like execute. This is where we start seeing overlap in responsibilities. But kind of that’s how I think about it is like PMs are defining the what in a nutshell, and then the TPMS do when and the how a little bit. So that’s kind of my take on the product manager responsibility. 

Mario Gerard: Yeah. We also, I think from a product perspective, they also probably do a little bit of the why, like what and why, right. It kind of goes hand in hand of doing like, why are we doing this, explaining especially to the dev team to tell them what the vision looks like, what is the vision and why do our customers care about this. Because we’re embarking on a mission of say spending like $10 million in developing costs and in infrastructure costs and what is the revenue rate of return, we can expect.

Addition to that, what do you think are the skill sets, the PMs possess? And then you’ll probably go into a little bit of the overlap between the two, but what skills do PM’s, product managers generally possess when they’re trying to be a product manager when they’re a product manager.

Priyanka Shinde: Yeah. Yeah. So, I think something you just said, right. Vision, like they need to have a vision and the ability to create a strategy to realize that vision, right. That is important. And that’s why like, telling, talking about the why and explaining it to other people is important. Some of the other things that I feel like product managers possess is an understanding of the market and the customer. Again, that is very important in terms of figuring out what vision is needed and what is the strategy to develop. They of course need solid prioritization rationale. Which, what do we do first versus what do we do next? And then we start getting into some of the things which can have overlap with TPM role, but like they also need to have strong communication skills. They need to be able to convince people to spend X amount of dollars to build a particular product. They need to be influenced; they need to be persuasive. But they also need to be very data driven and analytical.

Because you do need a lot of that. Like we know data informs like decisions. And so having that is critical. So, a lot of times I see product managers are very depth focused. They’re kind of taking one problem, one big problem and trying to kind of solve for that. So those are some of the things I feel like PMs should process.

Mario Gerard: It’s so interesting. As Priyanka is talking about the skills, there’s just tremendous amount of overlap of skills, of what a TPM kind of naturally possesses. Most TPMs naturally possess very good, we just spoke about what the TPMS role was and what the TPM skills are. And there’s, you can see that there’s definitely at least like a natural 30, 40% overlap maybe of similar types of skills and similar types of probably personalities as well to a large degree, right. Because a product managers kind of influencing up to his senior leadership of embarking on this mission. And then he’s also influencing below to the engineers that, hey, this is something we must do. And this is something that’s important to our customers. But at TPM is influencing a totally different perspective of, you know, getting things done.

So, it’s so interesting to see kind of the overlap between the product and TPM. As we’re talking about this Priyanka, like how do PMs and TPMS collaborate? They’re very boxed into the product manager role and there’s a TPM role in an organization. How do they collaborate? And do they even complement each other?

Priyanka Shinde: Yeah. So, let’s talk about that. You know, one of the things that kind of I just remembered is, one of the first companies I worked at, like the product manager role was very external facing. And then the program manager role was very much internal facing. So, kind of like how, where you’re taking the external, like market specifications and turning them into product requirements. And that is where a little bit of that boxing was done. And it was OK. It worked, right? But I think as again, like we talked about the evolution of both of these roles, the evolution of the products and the complexity around it. The product management role has also become a little bit more external as well as internal facing.

And this is where we kind of see this overlap in some of the skill sets as well as the responsibilities. So, one of the things that, you know, we used to stay at Facebook and we were trying, when we were trying to help everyone understand kind of how these roles complement each other and then how has they still different and still need it. So, the thing is to say is product managers lean towards vision and strategy and TPMs lean more towards execution and delivery.

And the key here is leads, which basically means that yes, we do more of that thing, that doesn’t necessarily mean we cannot do the other things if needed. This is where I feel like the overlap is there, but we also complement each other. Like these two roles I feel are very complimenting, right? Product managers sometimes are very forward looking. They’re thinking about that vision and what happens or how we can do this. They’re looking in the data and what is the next thing we need to develop? How do we grow this product?

But TPMs are saying, okay, I have this vision, I have the strategy. I have the priorities. I’m going to go and execute. I’m going to take care of the present and get things done. Doing both at the same time while possible in certain scenarios is not always effective. So, this is where I feel like PMs can, you know, work with TPMs to kind of execute on their vision. And then they can leverage the TPMS knowledge of like technical systems, and they can influence the requirements or the strategy to build like robust Futureproof products. But they can then really go and like go talk to the customers because that takes time, like go to your market research. So that’s how I think they can complement each other.

Mario Gerard: Yeah. And I feel that the role is definitely more of a marriage, right. It’s like a partnership role. If you work with PMs, sometimes there’s a little bit of love and hate because they want different things in life. But at the same time, they have to work together and they have to like complement each other. They are partners for the betterment of the organization, for the betterment of the feature set, for the betterment of the product itself. And so, it’s kind of very important partnership and you have to like, or love your counterpart and they are your counterpart. And they kind of, sometimes I also feel you fill gaps in their skill set and they kind of fill gaps in your skillset as well.

Because as you said, lean is a key word there. Leaning in and helping the other person out. And that person helping you out is a very, very close, collaborative partnership between the TPM and the product manager themselves. That’s a phenomenal way of looking at how these roles are almost coupled together.

Priyanka Shinde: It’s a coupling for sure. Like I was going to say that, you know, it’s the chemistry of a PM and a TPM. You never know how it comes around. And a lot of times, you know, TPMs are like, can we have like this R and R between these two functions and it’s very difficult. Like you can print out an R and R and you can stick it up on your desk, but the way to work with each other is to talk like, you know, sit down, talk, you know, what are your strengths? What are the gaps like you said, and then that’s where you can build that partnership? Cause sometimes you want to the same things also, right. Not just different, you want the same things. And that is when you start stepping on each other’s toes.

So, yeah, just talk to your PM or TPM counterpart. And figure out how best to work together.

Mario Gerard: Yeah. I remember like having, I have this very close product managers who are still friends with, I worked with them like six, seven years ago and we used to have so much conflict, but then every day after that, we used to go for lunch and then beer in the evening. So that’s why I said it’s a little Love and hate is you might have disagreements because you want different things. But that disagreement is what brings you closer and what benefits everybody together. It’s a natural chemistry with the natural push and pull, which kind of finds its natural balance in an organization.

So that’s so well said there. And I also, I don’t know if you caught what Priyanka said, she was like, when we were defining the role at Facebook, it’s very interesting to talk to people like Priyanka, who’ve been through organizations, even large organizations who are identifying and recalibrating on what a particular role does.

And so, every organization goes through this and every, probably every decade, the role definition might move a little bit, might change a little bit as the industry evolves. And that’s why, the reason I’m bringing this up is the product manager technical role and the TPM product role is also a slight evolution of what was originally there and what the needs of the industry today are. And so, it’s kind of important to understand that you might not find so many product manager technical roles or so many TPM product roles. We talk a little bit more about this, but you’ll see them slowly, slowly, like the prominence of those roles are slowly increasing. And that is that our organizations are evolving, and the roles are also constantly evolving. So that’s something we keep in mind.

So, okay, Let’s on our next question. What is the reason for the evolution of the product manager technical role Priyanka and why do organizations even need this?

Priyanka Shinde: Yeah, so I think, I mean, we can talk a little bit about both, right? I think not all organizations need the product manager technical role, right. But many organizations need them because they’re working with highly technically complex products and systems. So again, you need product managers with that domain knowledge, that domain expertise, right. So, I’ve also seen where companies may not necessarily distinguish between a product manager and a product manager technical role, but they just look for that particular skill, If they are hiding for a product manager in a particular technical [18:10 inaudible].

Mario Gerard: A more technical product manager you mean, a more technical leaning. Okay.

Priyanka Shinde: Yes. So, they may not like differentiate by titles, but they might just look for that technical skill to put them in a more technically oriented role. But, you know, you can still call it a product manager technical role. And of course, you know, a lot of times what happens is there are many challenges that where your big teams, multiple teams, you have very complex products. It’s difficult for PM to be the TPM at the same time. And so, this is very, it’s helpful to have like a PM, product manager technical work alongside a TPM as well. And I do think like this role has gained a lot of prominence, especially in the past few years, like you were saying. What I think it does having those separate titles is it helps in distinguishing during hiring.

It becomes very clear during hiring that this is the skill it could require. It can also help certain people, you know, who kind of maybe come from a technical background and they really want to stay technical, but they want to kind of shift more into this product or TPM role. And so, it might help them look for those jobs that kind of satisfy their like technical curiosity a lot more. So, I feel like that’s why there is that differentiation in terms of title itself.

Mario Gerard: Yeah. That’s kind of interesting. That’s definitely interesting. How do you, like if you take a product manager, how does that differ from a product manager who’s technical? Like what would you say are like key, like two differentiators or three differentiators between the two roles?

Priyanka Shinde: I think like again, the focus for the product manager technical or technical product manager there is like, these terms [19:43 inaudible] is more technical, right? You need more domain specialization. So, for example, if you’re dealing with artificial intelligence, machine learning, there can be parts that are user facing. And then there can be parts that are more developing the algorithms, but some technical specifications in mind, or maybe you’re trying to develop the core AI platform, right. And that platform needs to be able to support the developers who are creating these AI algorithms.

So actually, at Facebook, I used to work for the Facebook assistant team and I used to work with both product managers and product managers who were more on the technical teams or kind of, we call, we kind of thought of it as the back end of the AI system. Even though the titles were not distinguished, their focuses were very different. And so, what that would have the PMTs or the technical product managers would then also work with the product managers who are more customer or user facing to also come up with the technical roadmap.

So now in case of a technical product managers, they have to come up with more of a technical roadmap and they have to think about the platform. They have to think about how the systems interconnect with other things. They need to know what is the product managers, customer focus roadmap is going to look like so that they can develop their underlying infrastructure in advance of that.

Mario Gerard: That’s so interesting that you see that within a team, which is kind of working together, you have both product managers and product manager technical folks. And they have different kind of responsibilities and they, or they own different platforms, or they have kind of either their one set is facing customers and then more focused on the front-end side. And there’s one focus completely on the back end, because the skills are kind of different. And it’s also interesting that you pointed out the distinguishing factors primarily helped during hiring.

And it’s also probably gives the manager who’s hiring a good insight to just think, what kind of skill am I even looking for. Because it’s not only from a candidate perspective that you should look at this, but you should also look at it from a manager who’s trying to grow his or her team. Like they’re trying to think like, who would be the best fit here? What are the kind of skills I kind of need for this person to solve the problems that we are going throw at them? So, it’s kind of interesting.

So, what are the companies that you’ve seen with the product manager technical role, which companies have you kind of encountered in that space?

Priyanka Shinde: Yeah, so of course, you know, at Cruise we definitely had like technical product managers. So, we had both like technical product managers, as well as consumer facing product managers. Like kind of, that’s how I call them. But I’ve seen this role particularly come up at Amazon, Intel, PayPal, Adobe, and a few different startups as well. I’m seeing more of these in the last few years, as opposed to maybe five years back. That is definitely telling something.

Mario Gerard: So, do you think these, when we talk about these companies, do you think they are hiring both technical product managers and they’re hiring also TPMS product also, right. So, it’s kind of, they’re doing both or they’re doing one or the other or?

Priyanka Shinde: Yeah. So, the TPM product role, that one is very much coming out of Facebook, at least kind of based on my context and association with that. And so yes, like Facebook obviously like has a lot, like it’s a huge company, right? There’s so many different teams. So, they have TPM product, they have PMs and then they have, sometimes they have these kind of underlying technical product manager roles that may or may not be distinguished by titles.

But for example, at Cruise, because I was there, I can tell you, like they hired both consumer PMs, which was like the traditional PM role, The product role. As well as technical product managers or PMT, sometimes technical product managers is also called PMT, just so that all the letters don’t end up being the same. But they’re then focused on defining, say the behavior of the car. They’re defining the requirements on how the car should behave in certain situations.

And they sometimes maybe informed by the user, which the other PM is telling them about. So yes, so they do hire both depends on what is the type of product you’re building.

Mario Gerard: Priyanka, why don’t you kind of give me like a, for people who don’t know a lot about crews, why don’t you give them like a two minute pitch of what does Cruise do for people who don’t know Cruise. If you don’t know, Cruise, you’re probably living under a rock, but then you should probably just tell our listeners, like what does Cruise do?

Yeah. So, Cruise is an autonomous driving company, right. They work on self-driving software. They are a company that is owned by GM. So of course, they are working very closely with GM in terms of developing the car. So more recently, like if you read the news, they got the permit to charge customers in San Francisco.

So, if you are in San Francisco, you can potentially hail a driverless car. And so, you’ll see these Cruise Chevy bolts along in San Francisco city if you’re ever here. But they’re primarily working on autonomous software. And the reality, like sometimes we see this it’s, it feels very science fictiony. But now it’s closed. Of course, Waymo is the other company That is been working on self-driving cars. And so, Cruise and Waymo, both doing really great and progressing ahead.

Mario Gerard: Yeah. And this comes back very interestingly, this comes back to the problem of solving complex problems, right? Like you need different types of people, different types of roles, however you define it. These are technical challenges that need to be solved either with the product hat, technically thinking how you solve these problems and with the execution hat, which is more of the TPM side.

And so, you see these companies which are trying to solve these never before solved problems, like Cruise trying to do this. And that’s why they kind of coming back to why we need this role. So, do you see a difference between the TPM that’s technical program manager product versus the product manager technical role?

Priyanka Shinde: Yes and no in some ways. The TPM product role is more of a TPM in product facing projects or consumer facing areas. So, for example, at Facebook ads or Instagram, for example, those are things that people use, right. There are interfaces or UI that people are using. And so TPMS in those spaces are more kind of product leaning. And so, they are the TPM product and they’re kind of leaning, They need to have a little bit more of the product sense.

Mario Gerard: And where do they use it? Can you give us an example of where they would use like a TPM? When they call TPM product, where would they use that product sense that you’re talking about? Like gimme a small example if you could.

Priyanka Shinde: Yeah, for sure. And again, like, I have always been what I would say a product TPM, because I’ve always worked in programs that have a product. I mean, that has a user or consumer focus. So, what happens is like when you are working on such kind of program that has an end user, right. It’s important to understand like the why, why is this, you know, what would the user do? How would the user react? Like it’s good to have because you build that customer empathy. And that also helps build your product sense.

Because when you are also talking to the product manager, right. We talked about it being a partnership. So, you don’t want just to take the requirements and move into execution. You want to understand the rationale behind the requirements. You want to, you know, sometimes you need to kind of demonstrate your product thought leadership in addition to your technical thought leadership.

And so, I would say that it’s important to understand part of why the product is being built, why it is important to build certain features now versus later. And that’s what I mean by having a little bit of that product sense, what kind of metrics or what is the success criteria for this product, right. That is the difference between say a purely said like opposite, that is an infrastructure program, right? So, we have sometimes [27:35 inaudible] TPMS that are focused on backend technical systems. And so, you’re kind of really your primary things might be capacity, latency, performance, all of this, Yes. Eventually they do impact whoever the end user is, but you’re thinking more in those terms as opposed to what a user sees or how the user interacts with the product itself. So that’s kind of the difference.

Mario Gerard: So TPM product, when you talk about customer facing metrics and KPIs and being more closer to the customer, do they actually define the metrics or are they like more, does the metrics, would you think the metrics are define the KPIs, the OKRs or whatever they are, right. Are they defined with a product manager, or would they be defined with TPM in this case?

Priyanka Shinde: I think it needs to be again a collaborative.

Mario Gerard: Both collaborating.

Priyanka Shinde: Yeah. Ideally that would be best, right? Because you’re both informing based on certain understanding or knowledge that you have, right. The PM comes with the market knowledge, the research that has been done. The TPM comes with, you know, understanding of the technical systems and things like that. And so, then they can both work together and say, yes, this is what the metrics might look like. And some of those metrics are very much user facing and some of those can be a little bit more technical, right? So, say for example, performance. Like performance, If the site is slow to load it’s both technical metrics, but for the user, all that it means is that they’re waiting X number of seconds. I’m giving you like a simple example. That is what I mean.

Mario Gerard: That makes so much sense. That makes so much sense. We did talk little bit about that the role is gaining prominence that both these technical product manager roles and the TPM product manager roles gaining prominence, why do you think it’s gaining that kind of a prominence?

Priyanka Shinde: Yes. I think let we talk a little bit about the TPM product role first, and then we’ll also jump into PMT because this is something we talked about a little bit earlier, right? So, on the TPM product side, that role, I think gained prominence and I was there at Facebook in the early days when this role was evolving and some of it was again, TPM product is basically another type of TPM product, but it has been distinguished so that we can kind of hire properly. We can distinguish those skills and it also helps people understand what they will be working on.

So that’s kind of why the distinction is made. Similar to the PMT role, the product manager technical role, where you might want to hire somebody with a more technical background or expertise. And so, we talked about like, you know, what are the difference between those two roles and so while PMTs work in more, they need a more of a technical sense. You know, how I talked about TPM product needs more product sense. The PMT needs more technical sense. And that’s where kind of, they are complimenting each other in different areas with their counterparts as well.

Sometimes you can have both on the same team. And that usually helps with managing the size, the breadth, the complexity, balancing, like building a future roadmap versus like the current roadmap needs to be delivered.

Mario Gerard: And you think that there’s like an overlap of responsibilities. We did talk about overlap between product and TPM generally. But between the PMT and the TPM, do you think there’s a lot of overlap?

Priyanka Shinde: I think there is. So, in some, you know, in some cases or earlier in highly like these technical areas, the TPM used to kind of play the PMT role that we see today. I think they can both to a certain extent, like define the requirements, work in collaboration with other teams, but in smaller teams, like the PM might just do the research or kind of like even to execute a little bit. They both have understanding of the, or system architecture or the constraints that the technical constraints that might want to fix. They both can do the execution and deliver in certain cases.

So, I think yes, like, but again, when you have both of them, the time to bring, have both PMT and a TPM on a team is when the product is highly complex. It is like the breadth of the program is huge. You are maybe dealing with 5, 10 teams, you have to go talk to X number of people you have to deliver on this roadmap. So, there’s a lot happening and it’s too much for one person to do it effectively. That’s when you would have both on the team.

But can one person do the other things? Yes. On smaller teams, like if you have, you know, the small product, maybe 10 people that you’re working with, you could potentially do both.

Mario Gerard: That makes a lot of sense, like the scope of the program and how many people or how many teams it is touching is really important when you kind of design your team with these different types of roles. Let’s move on to the next question, like from a skill perspective, tell us what are skillsets a PMT should have. And then we’ll probably go to the skillset for a TPM, right. And connecting the two. But a PMT, a product manager technical, what are the kind of skill they need to have?

Priyanka Shinde: Yeah. So, the PMTs similar to like your product manager role, right? A lot of the skill sets are similar, right. They need to be able to identify these significant opportunities, develop the product vision, the strategy, go talk to the broader organization. A lot of times now you are going and talking in terms of more technical product, you’re using more of that technical system knowledge with those conversations. Of course, you know, the skillset, the additional skillset that is needed, I would say is that technical depth and expertise.

But you also, you know, of course, you know, there might be incorporating the data, the research, but it’s maybe in a different form, right. Maybe it’s more from a system performance perspective rather than like getting a user, you know, how many clicks they’re doing or things like that. So, I would say that’s the skillset that a PMT needs. Yeah. And then we can also like move on to the TPM role. We obviously talked about like some of the TPM skills, but what the TPM can do really is when the scope is huge, like they can connect the dots.

They’re talking to a lot of different people while they’re kind of trying to execute on the program so they can see the big picture. They need to understand the technical constraints. They need to be able to manage risks, mitigate risks, and manage the dependence. Cause I think that is a very critical aspect of the TPM role.

Mario Gerard: And at that scale, right? And when you’re talking to like 20 or 30 or 50 teams, that becomes a pretty big piece of what the TPM does.

Priyanka Shinde: Definitely. I think risk management and managing the dependencies is really, really critical to the role. I mean, even if you have like five teams, but yes, like it exponentially becomes harder when you have more and more people involved. So, I think, yeah, I mean the TPM can sometimes kind of go broad, right? Because you can deal with more people which helps manage these big problems. Whereas PMTs have to kind of stay focused on the problem set that they’re trying to solve the vision they’re trying to create. But they can take support of the TPM to kind of, you know, manage all of these different, different stakeholders in order to deliver the product.

Mario Gerard: Cool. Do you think between the product manager, technical and the TPM, if there’s one person, can they switch like back and forth between these two roles? Not immediately, but from a career perspective, would you think that, you know, we spoke a little bit of the skills, they all seem to a little, have a little overlap. So, do you think like I’m thinking whether they can switch between roles? Like can I be at TPM today and like six months later say, hey, I’m going to go and try this product manager technical role out for some time.

Priyanka Shinde: Yes, I think so. I mean, there are so many overlaps in responsibilities and then skill sets that definitely, I think shifting between these two roles is easy, at least for personnel. I think why, or when you should do it is dependent on, you know, kind of what are the things you enjoy doing more? Do you enjoy, you know, kind of like creating that vision strategy roadmap, or sometimes you try want just execution and delivery is your thing. So, depending on what you enjoy doing, you can kind of pick one, but yes, I think you can easily change and kind of switch back [35:11 inaudible].

Mario Gerard: That’s so interesting. Like I want to double down on what Priyanka just said, that when you are choosing roles, whether you’re an engineer trying to become a TPM or an engineer trying to become a dev manager or a dev manager becoming a TPM, a TPM becoming a dev manager, all of these roles, people move between these roles a lot. And I think what Priyanka said is so important is that you need to figure out like what your skillset is and what you want to do and what you’re good at, right? Like it’s so important to figure that bit out. And then the role becomes easier.

Because if you are doing vision, then maybe you want to go more towards the product manager technical route, where you still have the technical chops, but you’re more interested in the vision and talking to the customers and those kind of things. But if you want to be more on the execution side and that’s your thing, then you go on the TPM side. I think I have one last question for you Priyanka, the product manager technical role. Do you know where it came from? And what’s the history behind that? I think we spoke a little bit about this earlier, but I think when we were talking about it, you were talking about meta previously and you were saying you could share some context of where this role originated from.

Priyanka Shinde: Yeah. So, I think that mostly I’ve seen the TPM product role at Facebook or Meta. And so, when I joined Facebook in 2016, again, I was kind of part of this product TPM organization. It was kind of, it’s [36:42 inaudible] stages at that time. It was ads. And then we had business platform, which was, you know, a different team. And so, I think maybe there were around 20 TPMs there. And of course, you know, the [36:52 inaudible] TPM organization within Facebook had existed for a much longer time. Because that is where the TPM organization or the hiring started, which is understandably so.

So, I think what we experienced is how do we want attract the TPMS into our teams? How do we make sure that we are hiring with the right skillset? And then how do people know that what they will be working on or what is the type of things that they will be doing, right.

Cause when you only see one type of a role or then, then that is kind of what becomes much more widely known. And so, the product TPM role was an effort to basically help distinguish for hiring purposes, understanding the skill sets we need. Like I was mentioning a little bit of product sense that you need, right? So, during interviewing for the product TPM role, the questions that we would ask would have a little bit of that, you know, gauging of, does this person understand why we develop these metrics? Or is there like, you know, that little product sense, you know, understanding of the customer, do they have that?

And so, while they may not a sit and write requirements, It was just that understanding that helps them become a better TPM when they’re working on the product side. So that is some of the history.

And so, there was a set of TPMs myself and a few other TPMs. We worked on kind of evangelizing that role a little bit, set up the interviewing framework as well as I think there was some external articles or publishing that was done, just an effort to help people. Because also what happens in this situation is there’s sometimes already a product manager, right?

Most of these teams already had a product manager from the beginning. So now it was also important to distinguish how this TPM role, the product TPM role and the product manager role is still both are still needed. And they’re not really kind of encroaching on each other’s space. So, there was also an effort to make sure that we kind of distinguish the product manager versus the product TPM role as well. And this is where, you know, that whole statement about leaning more towards vision strategy versus leaning more towards execution delivery came from. So that’s the context on product TPM at Meta.

Mario Gerard: That’s like so interesting. You hear the history and the context of how these roles evolve, because it also gives you a sense of what the vision of creating this was, right. What does the team think that was missing or possibly missing and what are they trying to address? And so, it’s like, it’s really interesting to hear these stories from people like Priyanka who’ve been there, who were in the weeds while this whole movement was coming along. So, it’s like very nice to hear that from Priyanka.

Thank you so much Priyanka for sharing all your thoughts on the product manager, technical and TPM product roles. It was really, really insightful.

Priyanka Shinde: Add one thing. Something you mention earlier, right. Switching between PMT and TPM roles, even switching between a product TPM and a product manager role. I think that is also something that people do often. So, you know, that is also that option because if you are a product TPM and you realize, okay, down the line, you really just love kind of developing that vision and strategy. Then the product manager role is also something you can totally do.

And so, we talked a lot about like, what are you good at? What do you enjoy doing? Because after all those are our strengths, right? And so like, if we lean into our strengths, I think the work becomes much more enjoyable.

Mario Gerard: Yeah. And easier, easier and enjoy. Absolutely. Thank you so much for, you know, doing this with me today. I’m hoping to have Priyanka more and you know, have more conversations with her and do some podcasts. But definitely check out her website. She’s publishing a lot of very, very interesting, very insightful content for technical program managers. And she’s also offering like resume workshops and career management sessions. So, there’s a lot you’re going see from Priyanka. So definitely check her out and it’s going to be fun.

And I invite more people to come and blog and share the experience on the technical program management domain. Sometimes I feel that there isn’t enough being done. You see have a lot of people on the product side, I think the product people are, you know, they’re so evangelistic about their role. And there isn’t, you know enough said about the TPM role. And there are equal number of TPMS product managers receive most organizations. So definitely encourage more of you to write on LinkedIn or write in other mediums and then definitely encourage the people who are newly coming to write and contribute back to the community. Thank you so much again Priyanka, thank you for being here with us today and hope to see more of you.

Priyanka Shinde: Yeah. Thank you, Mario. It was great chatting with you, and I have to also thank you for kind of spreading the love on the TPM community and doing everything that you do. I mean, Mario has been great, you know, the courses you have and everything. So, it’s great for like aspiring TPMs. So yeah, like Mario said, we need more of these. We need to kind of rally around our community. So, you know, kind of please do so. And we’ll be here. I mean, we’ll be rooting for you.

Mario Gerard: Take care folks. See you on the other side.

Mario Gerard