The Technical Program Management Podcast & Interviews

Episode Overview Go to the full transcript of the episode In the final part of the series, Mario Gerard and Rhea Frondozo focus on what can go wrong when you are running large scale programs and what strong breadth TPMs do differently. They talk about common pitfalls like taking on too much work yourself, misusing subject matter experts, and letting scope creep sneak in through the back door. Rhea then walks through the most complex program she owned at OCI, the global government sector program, to show what large-scale really looks like in practice. That example ties together everything from earlier episodes: executive sponsorship, stakeholder management, communication strategy, requirements interpretation, and the need to avoid divergence across the stack. The focus of the conversation is on: The most common pitfalls breadth TPMs need to watch out for How to draw the line between helping and taking over someone else’s work When to rely on SMEs, and how to keep SME solutions aligned to business needs How scope creep often shows up through “extra” asks attached to your program A real example: OCI’s global government sector program and why it was so complex What divergence means, why it matters, and how it can multiply long term complexity How Rhea structured communication and alignment for a companywide, multi-year program The episode closes with a clear message: large scale TPM skills are learned through experience, trial, error, and repetition, not through textbook theory. Common Pitfalls Breadth TPMs Should Watch For Mario asks about the most common pitfalls. Rhea starts with one she has seen personally and also in the TPMs she has managed: functional owners leaning too heavily on the TPM to do their work. 1. Taking Ownership of Everyone Else’s Work Rhea explains that a breadth TPM is responsible for driving accountability across many functional areas. But when the TPM is a strong lead, stakeholders may try to offload problem solving onto the TPM. If you accept that pattern, you end up doing work for everyone, and because you are managing so many areas, you eventually fail. Mario agrees and describes a simple rule: do not step in and fix someone else’s problem, because once you do, it becomes your problem and they can walk away. Instead, you want POCs and functional owners to own their space, drive the work, and report milestones and progress back to you. They both emphasize that there is still nuance. Sometimes you step in briefly to get a workstream back on track, especially if the lead is weak, but you do it to stabilize and then transition ownership back. The key is that you are monitoring and guiding, not absorbing the work. 2. Poor Time Management and Not Rechecking Where You Spend It Mario shares a habit he learned at OCI: constantly reevaluate where your time is going, daily or weekly. He frames it as a discipline that keeps you from spending too much time in the wrong places, or getting sucked into details that are not actually your responsibility or do not help the long term success of the program. Rhea ties this directly to judgment. Breadth TPMs have to decide where they invest their energy: stepping in, monitoring, coaching, or escalating. Your time allocation becomes a strategic decision, not just a scheduling issue. 3. Misusing SMEs and Going Too Deep Yourself Rhea calls out another common pitfall: not knowing when to rely on a subject matter expert versus trying to do it yourself. A TPM needs to understand the problem enough to ask good questions and to evaluate whether the solution matches the business need, but it is not the TPM’s job to be the SME. Mario adds a real world tension: SMEs sometimes over engineer or overcomplicate solutions. They are deeply invested in their domain, and that depth can lead to building something far bigger than what the program needs. 4. Scope Creep Through “Riding Your Program’s Priority” Rhea connects SME behavior to scope creep. Sometimes your program surfaces a problem that affects your delivery, and you bring in an SME team to solve it. But that same team may have long standing pain points and see your program as a way to finally get buy in for a much larger fix. In other words, you ask for X, and they try to bundle X plus everything else they have wanted to do for years. Mario frames it bluntly: you need them to solve X, but they want to solve X times one hundred. Both agree that this is a real pattern in large orgs, and it is one of the fastest ways scope creeps beyond what the program was sized for. A Real Example: OCI Global Government Sector Program To make the discussion concrete, Rhea walks through the biggest and most complex program she owned at OCI: the global government sector program. She describes it as a suite of cloud regions, services, features, and processes needed to meet government customer expectations. Mario clarifies that this was not a single product. It was a set of products and operational capabilities that allowed governments to run workloads on OCI, including environments with different classification levels. Why Government Programs Are Different Rhea explains that government workloads come with multiple security classifications, ranging from unclassified all the way up to secret and top secret. Supporting those environments requires more than software changes. It can involve physical infrastructure, how regions are operated, who is allowed to access systems, and the clearance levels required for personnel. Mario adds that in these environments, everything can change: operations processes, staffing models, tooling, and the services themselves. The program becomes end to end reengineering across the stack to meet security and compliance needs. Divergence and Why It Matters at Scale A key theme in this episode is avoiding divergence. Rhea defines divergence as running different code bases, processes, or operational models across regions. When regions diverge, the work multiplies because now you are maintaining and updating multiple versions of the same system. She explains the cost clearly: you create more code paths, more processes, and more hiring needs. The complexity can double, triple, or worse. Mario expands this point beyond government work. In any large scale program, introducing too many special cases creates long term operational burden for every team involved. They tie divergence directly to scalability. If the architecture and operating model are not scalable, you end up with armies of people doing slightly different things for each region or environment. The goal is to design solutions that can be applied broadly without needing a separate playbook for every variation. Stakeholders, Sponsorship, and Business Opportunity Rhea describes the stakeholder landscape for the global government sector program. The external customers were governments, domestic and foreign. Internally, the sales organization played a major role because they were the interface for government customers and handled RFPs and responses. The program required close partnership to interpret requirements, identify product gaps, and align delivery to bid timelines. On the sponsorship side, Rhea says this program went all the way up to Oracle’s CEO, Safra Catz. It was a companywide initiative because it affected how services were built, operated, and delivered across the stack. The business upside was massive: enabling large government deals and multi billion dollar opportunities by making OCI capable of supporting the full set of products governments might need. How Rhea Ran Communication and Alignment for a Program This Big Rhea explains that executing the program required heavy planning and structured communication. At Oracle, the starting point was detailed written documents rather than slides. She describes beginning with a strong product definition and written narratives to get leadership buy in. Once leadership buy in was secured, the team created a roadshow to align the next level of leaders across the org, so that those leaders could assign POCs and commit resources. They also ran broader tech talks for the engineering organization to make sure teams understood what was coming and why it mattered, so future asks would not feel random. From there, the program used many of the standard tools they discussed earlier in the series: weekly stakeholder meetings, executive reports, newsletters, wiki pages, Confluence pages, schedules, agendas, and tracking systems. The point was not the specific tool but the combination of visibility, alignment, and a consistent system for keeping large groups of people informed. Why the Program Became Even More Complex Over Time Rhea explains that the program expanded significantly after it began. It started as building a net new region, but grew into owning an entire suite of government cloud regions. Different regions were in different phases at the same time. Some were in planning, some were actively being built, and some were already live and in support mode where customer usage revealed missing features and new needs. On top of that, newer regions replaced older versions of government regions. That introduced another lifecycle stream: closing out legacy regions while building and supporting newer ones. Rhea describes the overall complexity as coming from three sources at once: the number of stakeholders, the size of the business opportunity, and the challenge of managing multiple products and multiple regions across multiple phases of a program lifecycle. Full Transcript of the Episode 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.

Episode Overview and Summary Go to the full transcript of the episode In part two of the series, Mario Gerard and Rhea Frondozo continue the conversation on how TPMs run large scale programs. This episode gets more practical, focusing on how to build a communication plan, what kinds of blockers show up during execution, how you track information across huge programs, and what the TPM team structure often looks like. The focus of the conversation is on: How to design a communication plan for a large-scale program How communication cadence changes as the program evolves Common blockers: schedule delays, requirements issues, architecture problems, scope creep Prioritization and resourcing trade-offs across competing initiatives Finding the right owners and solving unclear ownership problems How to maintain program information using tools, dashboards, and centralized sources of truth How large programs are staffed, including lead TPMs, workstreams, and supporting TPMs The phases of a large program, from planning to execution to support and closeout Overall, the episode explains that large programs are won or lost through structured communication, disciplined scope and prioritization, and a TPM’s ability to keep recalibrating as reality shifts. Designing a Communication Plan Rhea explains that a communication plan is really a set of decisions about who needs information, how often they need it, what level of detail they need, why they need it, and how you deliver it. The mistake is treating communication as one size fits all. She breaks it down by audience: Executives typically need concise summaries, usually via a short report, email, or executive status meeting POCs and active stakeholders need working sessions and status meetings where you can unblock issues and track progress Broader groups who are impacted later may need lightweight updates, like a newsletter, so requests do not come out of nowhere Mario adds that, in practice, a central tracking page can help a lot. He describes using something like a Confluence page to capture the objective, mission, risks, deliverables, milestones, and owners, often in a table format where teams can quickly see status by red, yellow, or green. Cadence Changes as the Program Evolves A big point in this episode is that communication cadence should not stay fixed. Rhea explains that early in a program, you may spend more time with executive sponsors to get buy in. Later, once you are in execution mode, the center of gravity shifts toward the POCs doing the work. Sometimes cadence becomes extremely intense. If there is a major issue, teams may run daily war rooms to get all hands on deck. But Rhea also points out the danger of overdoing it. If you keep daily meetings running after the problem is solved, you burn people out and waste time. The TPM has to keep reevaluating what is needed and adjust accordingly. Common Blockers in Execution Mario asks what kinds of blockers show up most often. Rhea groups them into a few common categories. 1. Schedule Delays Rhea says schedule delays are one of the most common blockers. They can come from underestimation, external dependencies, or simply discovering that the original plan does not work. She also notes that engineers often underestimate timelines, which is why TPMs should ask for confidence levels, clarify risks, and build buffers. She gives examples of schedule drivers that are out of the team’s direct control, like supply chain timing for hardware deliveries, or depending on external reviews like accreditations or audits. 2. Misinterpreted or Changing Requirements Another major blocker is realizing the requirements were wrong or misunderstood. Rhea frames this as an area where failing fast matters. If the team built against the wrong requirements, you have to regroup, redo work, and reset expectations. 3. Technical and Architectural Mistakes They talk about how expensive architectural mistakes can become at scale. Mario points out that when a decision affects dozens of teams, the cost of being wrong multiplies quickly. Rhea shares a striking example where a cloud region was built and later found to be built incorrectly, forcing the team to rebuild the region and discard much of the earlier work. The takeaway is not that mistakes never happen, but that large programs operate in uncharted territory where assumptions get tested in real life. 4. Scope Creep Mario raises scope creep as a common issue. Once a large program is visible, other groups try to attach additional asks to it. Rhea agrees and explains that scope creep creates resourcing gaps because the program was originally sized for a different set of commitments. If you accept more scope without adding capacity, you get delays, missed deliveries, and a loss of credibility. She emphasizes that TPM judgment is critical in deciding what truly belongs in the program. 5. Prioritization and Resource Trade Offs Rhea explains that large programs often fight for the same people as other business critical initiatives. When timelines slip, new conflicts appear. You may have planned to finish by date X, but delays push you into the window of another project that was supposed to start next. The TPM’s job is to make the trade offs explicit, translate them into business impact, and help leadership decide whether to stay the course, shift resources, or accept a schedule extension. Mario describes an exercise he has used with leadership: teams estimate how many resources they would need, and then they also identify what will be bumped off their current commitments if those resources are redirected. That trade off list is taken to senior executives so they can explicitly sign off on the sacrifice being made. 6. Finding the Right Owner Another blocker is ownership. Rhea explains that new problems emerge during execution and it can be unclear who should own them. Teams may already be overloaded, or they may argue that the problem does not belong to them. Sometimes the right owner is not even on the original stakeholder list. Mario shares that he has seen cases where the current stakeholder group could not solve the problem at all, which forced the team to look outside the original circle. They describe a discovery approach where the TPM talks to many parts of the organization to find the right home for the work. Rhea compares TPMs to detectives who go door to door until they find the right owner and get buy in. They also note an added layer of complexity: sometimes a group may be the correct owner in theory, but they do not have the capability or capacity to solve it. In that case, the TPM needs to help set the owner up for success by clarifying expectations, securing the right staffing, and reinforcing why the work matters to the overall program. What to Do When a Critical Team Is Not Delivering Mario asks what you do when a stakeholder is not carrying their weight and they own a critical function. Rhea describes it as a structured diagnosis. You look for the underlying cause before jumping to conclusions. Is it a prioritization problem because they are pulled into other work? Is it a resourcing problem because the team is understaffed? Is it a skill problem because the wrong level of engineers was assigned? Is it actually the wrong owner because the work is not in their wheelhouse? The key is that the TPM cannot ignore the gap. If a critical owner fails, the whole program suffers, and the TPM is still accountable for the outcome. How Program Information Gets Managed at Scale Rhea explains that managing information in large programs requires tools and structure. She mentions wikis or Confluence pages, ticketing systems like JIRA, and internal tools used at Salesforce. She also calls out dashboards and visualizations that show progress and highlight what is in jeopardy. A recurring theme is having a centralized starting point. There should be a clear place where anyone can begin to find program information, and from there different audiences can access what they need. Executives should know where to find executive summaries. POCs should know where to post updates and track action items. People who are not directly involved should still be able to find basic context without hunting through meetings. They also discuss how this varies by company culture. Rhea contrasts environments where leaders prefer polished PowerPoints with environments where leaders expect detailed written narratives and tables. Mario adds that even within the same company, the best format can change depending on the program and the number of teams involved. The consistent point is that you have to adjust the mechanism to match what leadership and stakeholders actually use. TPM Team Structure for Large Programs Rhea explains that large programs rarely run with a single TPM doing everything. The setup varies, but usually there is a lead TPM and supporting TPMs aligned to workstreams or functional areas. In some cases, the lead TPM manages a team of TPMs and assigns sub projects. In other cases, a breadth TPM leads while functional areas bring their own depth TPMs to execute within their domains. Mario adds that the structure often evolves. Programs may start with one or two TPMs, then add more as complexity becomes clearer. As new workstreams emerge, teams staff TPMs to own those streams so execution can move in parallel while still rolling up into a single program view. Frameworks and Phases of Large Programs Rhea outlines a simple phase model: planning, execution, support or maintenance, and closeout. The tools and frameworks change based on the phase you are in. Planning Define the problem statement and the objective Run cost benefit analysis and weigh options and trade offs Build project plans, schedules, and Gantt charts Execution Run status meetings and produce status reports and executive summaries Track risks and mitigation plans through risk registers or similar mechanisms Use dashboards, tickets, newsletters, and other tools to visualize progress Support or Maintenance Assess what worked, what is missing, and what needs follow up investment Prioritize issues and decide whether to extend, rearchitect, or create a new version Decide whether to close out the current program and replace it with a new one Closeout Finalize delivery, document outcomes, and transition ownership as needed How Long Large Programs Really Take Mario asks about timeframes, and Rhea explains that large programs can take a long time just to plan. Planning might take anywhere from a few months to a year, especially when the investment is massive and requires very senior executive approval. They also describe how execution can stretch for years. Rhea shares an example of building a net new cloud region that took a year and a half before reaching accreditation, and then required major rework when validation revealed gaps. That added significant time and effort. They reinforce that when hundreds of people and many teams are involved, long timelines are normal. Even after delivery, the program continues in a support and maintenance mode, where teams respond to real world usage, missing features, and new investments. In some cases, if the outcome is not strong enough, the decision may be to shut down and start again with a replacement program. Career Impact and Visibility Mario and Rhea close by discussing why people take on these programs even though they are hard. These programs come with high visibility, late nights, real risk, and intense expectations, but they can also be career making. Success in a major initiative can lead to promotions and faster growth. They also make the point that failure is visible too. In critical projects, if a TPM is consistently ineffective, leadership will notice quickly. Mistakes can happen if you learn and correct, but repeated ineffectiveness is not tolerated because the business impact is too high. Full Transcript of the Episode 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.

Episode Overview Go to the full transcript of the episode In this episode of the TPM Podcast, Mario Gerard sits down with Rhea Frondozo to talk about what it really looks like to run large scale programs inside big tech companies. Both of them draw from their time at Oracle Cloud Infrastructure (OCI), and Rhea also references experiences at Salesforce and elsewhere. The focus of the conversation is on: What counts as a “large scale program” The difference between breadth TPMs and depth TPMs The skills you actually need to run these programs How executive sponsors fit in Why these efforts matter so much to the business Why constant problems and ambiguity are normal in this kind of work The whole episode paints a pretty realistic picture of a TPM acting as the person in the middle of a huge, complex effort, trying to keep everyone aligned and moving. What Is a Large-Scale Program? Rhea describes a large scale program as something that: Spans multiple organizations Involves hundreds or even thousands of engineers Is aimed at a complex, high stakes outcome Mario gives an example from their time at OCI, where they had programs that required moving around 200 teams over a period of two years. When you add up the effort, you are talking about thousands or tens of thousands of person hours. From a TPM point of view, you might only be working directly with a core group of 20 to 30 stakeholders. But each of those people represents entire organizations underneath them. That is where the scale really shows up. You are essentially trying to get a huge group of people, spread across many functions, to row in the same direction. Breadth TPM vs Depth TPM They spend some time on the difference between two kinds of TPM roles. Depth TPM Focuses on a single team or a small area Works very closely with engineers on that team Understands the technical problem space in detail Breadth TPM Works across many teams and organizations Interacts with points of contact for different functional areas, such as security, operations, infra, platform teams, and so on Relies on those functional owners to be the subject matter experts Focuses on connecting all of these functions to solve a much bigger problem Large scale programs are usually handled by breadth TPMs. They are the ones tying things together across many moving parts, rather than going deep on one specific system. Skills You Need To Run Large Scale Programs Rhea and Mario highlight three main skills that matter the most. 1. Strong Communication For a breadth TPM, communication is basically the core of the job. You have to be able to: Explain complex programs clearly and concisely to executives Talk to engineering leaders and individual engineers about what needs to be done and by when Adjust the message depending on the audience, without changing the underlying facts Mario points out that most of a large scale TPM’s day is spent in conversations. You are: Giving direction Clarifying problems Repeating the overall story of the program in different ways so that different teams can translate it into their own work Writing reports and updates If you cannot communicate crisply, you will struggle to keep a program of this size aligned. 2. Defining Clear Objectives and Scope For a big program, a fuzzy problem statement is a recipe for chaos. The TPM has to: Nail down a clear, specific objective Define the scope so people know what is in and what is out Make sure all stakeholders understand the same problem, even though they see it from very different angles Security, operations, various product teams and platform teams will each interpret the goal through their own functional lens. Because of that, you end up repeating and refining the objective many times, so each group can translate it into concrete work. Good scoping becomes the reference point for whether everyone is actually solving the right problem. 3. Problem Solving in Ambiguous, New Situations Large scale programs are usually doing something the company has not done before. That means: You do not know what problems will show up tomorrow You can plan a lot, but you cannot plan everything There are always surprises, dependencies, and unknowns Rhea stresses that TPMs need to be comfortable operating in ambiguity and reacting in real time. There will be curveballs, and the TPM is expected to assess the situation, figure out options, and help steer to a new plan. Mario compares it to playing against a team you have never seen before, or exploring an unknown space. Every day brings some new challenge, and that is just part of the nature of the work. The TPM As The “Quarterback” Rhea uses a sports analogy to describe the TPM role. Being a TPM on a large scale program is like being the quarterback of a team. You are calling the plays You are responsible for how the team moves toward the goal Your decisions and judgment are a big factor in whether the program ultimately succeeds Mario adds that a breadth TPM makes a lot of decisions on a daily or weekly basis. These might involve sequencing work, handling trade offs, deciding escalation paths, or choosing between alternative approaches. You might check with others, but you are still the one driving direction. Rhea also points out that a major part of the job is unblocking issues. You start with a plan, and almost immediately reality does not match the plan. Every day something goes wrong, and you need to: Pull in the right people Rework dependencies or priorities Call an “audible” and adjust the plan If you cannot lead through issues like that, it is very hard to keep a large program on track. How A Large Program Gets Kicked Off When Rhea talks about her playbook for starting a large program, she starts with one thing above everything else: executive sponsorship. Getting Executive Buy In The TPM needs to: Clearly define the problem statement Clearly define the program scope Present this in a way that makes sense at the executive level Only then can you get an executive sponsor to sign up for the program and support it. If you do not have that: Other teams will keep prioritizing their own roadmaps over your program Points of contact will struggle to justify spending time on your effort You spend most of your time fighting for attention and resources Once you do have an executive sponsor: They help get other leaders on board Stakeholders nominate points of contact to represent their teams You can hold kickoff meetings to align on scope, goals, roles, and responsibilities What An Executive Sponsor Should Do Rhea explains that a good executive sponsor: Understands what problem you are solving and why it matters Is willing to back the initiative when there are priority or resourcing conflicts Uses their influence with peers to secure people and funding from other teams Mario describes a typical situation. An executive sponsor might need people from five or six different organizations. Each of those peers already has a roadmap and commitments. It takes real executive pressure to get them to shift their people to the new program. The TPM’s job is to give the sponsor enough context and data so that they can make a strong case for why this program deserves those resources. It also helps a lot if the program is one of the sponsor’s primary goals, for example something on their SVP goal list at Amazon, or on their V2MOM at Salesforce. When that happens: The executive is watching the program closely Other leaders are more likely to align their own goals and teams It becomes much easier to coordinate many teams in the same direction Rhea briefly explains Salesforce’s V2MOM system, where some goals inform other teams (informing goals) and some are responsible for execution (executing goals). Getting the same initiative on multiple leaders’ V2MOMs ensures that both sides are accountable. Why These Programs Matter To The Business Large scale programs are not side projects. They usually have a direct impact on revenue, cost, or strategic positioning. Mario gives a concrete example from OCI. One of the programs he and Rhea worked on was moving every Oracle SaaS product onto the new Oracle Cloud Infrastructure platform: Around 200 SaaS products Each with its own team Moving from existing data centers to a new cloud platform This kind of effort touches around 200 teams and requires huge coordination. In return, it can produce: Large cost savings over many years Better margins Revenue opportunities that would not be possible otherwise Rhea shares another example from her experience: competing for very large government contracts. These deals can be worth many billions of dollars. To even be in the running, the company might invest millions of dollars in infrastructure, engineering, and people. In both cases, these programs are “make or break” type efforts. They can change the bottom line of the company, which explains why: So many senior leaders are watching Resourcing is high Expectations are intense Constant Problems Are Normal A big theme in the conversation is that problems are not a sign that the TPM is failing. They are a sign that the program is large and complex. Rhea says that on big programs, she deals with multiple problems every single day. The more complex the program, the more issues you have to manage. Some examples they mention: Key people getting sick or leaving Supply chain issues, such as a pandemic affecting hardware delivery Technical plans that looked good on paper but do not work in practice New constraints or hidden dependencies that nobody anticipated The TPM’s value shows up in how they react: They stay calm and do not let problems drain their motivation They keep adjusting the plan while holding on to the end goal They bring in the right experts and know when to escalate They are willing to try, learn, and try again Mario notes that executives are usually ok with delays or changes in the plan, as long as: The TPM explains what went wrong There is a clear explanation of why it was hard to predict There is a concrete plan for what to do next Rhea gives an example of a TPM who was worried that schedule slips meant she was failing. Rhea reframes it. The real failure is not that the schedule moved. The real failure would be not communicating, not surfacing issues, and not resetting expectations. Communication, Judgment, And Avoiding “Watermelons” Near the end of the episode, they talk about how important it is to be honest about the real state of the program. Rhea explains that executives rely heavily on the TPM’s judgment. The TPM has to: Decide which issues are serious enough to escalate Flag real risks early, instead of waiting until the end Be transparent when timelines, scope, or outcomes need to change Mario shares an executive comment about “watermelon” projects. These are projects that are green on the status reports but actually red inside. Executives hate this situation, especially when they hear about problems from other teams before hearing it from the TPM. The right pattern is: As soon as you understand there is a meaningful problem, you communicate it You describe the issue clearly You present options and recommendations You reset expectations on schedule and scope When TPMs do that consistently, they build trust, even when things are hard. The program might still be risky, but leadership will see the TPM as someone who tells the truth and manages issues responsibly Full Transcript of the Episode 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.

Episode Overview Go to the full transcript of the episode In this episode, Mario Gerard introduces Rhea Frondozo and sets up the foundation for a broader series on TPM work. Rhea shares her background across multiple major tech companies and explains why she has gravitated toward large scale, cross functional infrastructure programs rather than consumer facing feature work. The first half of the conversation focuses on “core TPM fundamentals.” Mario asks Rhea to define what a TPM does, what skills matter most, how TPM impact is measured, and how to influence without authority. They also cover what Rhea looks for when hiring TPMs, how technical TPMs need to be depending on the role, and advice for people trying to move from IT services into product oriented TPM work. The focus of the conversation is on: Rhea’s background and why she prefers large scale infrastructure programs How the TPM function varies across companies, teams, and seniority levels Core TPM skills: project management, communication, ambiguity, collaboration, and problem solving Depth TPM versus breadth TPM and how technical each role tends to be How TPMs measure impact, including what you deliver and how you lead Influencing without authority and how to build that skill over time What hiring managers look for when interviewing TPMs How technical the hiring bar should be depending on the program and team structure Tips for moving from IT services or non product orgs into product based TPM roles Overall, the episode works like a practical TPM primer, grounded in real hiring and leadership experience rather than a generic job description. Who Rhea Is and What Work She Cares About Mario introduces Rhea as a senior TPM leader with about two decades of experience across IBM, Microsoft, EMC, Oracle Cloud Infrastructure, and Salesforce, where she is now a senior director leading TPMs. Rhea describes a career path that included being a developer, program manager, test manager, engineering manager, and TPM leader. Rhea explains that after trying many roles, she learned what she enjoys most: large scale, complex programs that span multiple products, services, and processes. She is less interested in consumer facing features and more drawn to enterprise infrastructure challenges, especially cross functional technical problems that require coordination across many teams. How Rhea Describes the TPM Function Rhea says the TPM function is hard to describe in a single sentence because it varies so much by company, org, and team. She frames TPM as a blended role: foundational program or project management responsibilities applied to technical programs, systems, or processes. She also emphasizes that the TPM job changes with seniority. A TPM can operate in a narrow scope and go deep in one area, or operate broadly across many organizations, depending on whether the role is closer to depth TPM work or breadth TPM work. Core Skills TPMs Should Have Mario asks what skills matter most. Rhea starts with the basics and then expands outward. 1. Project Management Rhea says the baseline skill set is project management. That includes defining scope and problem space, understanding business impact, identifying stakeholders, setting goals, creating schedules, and tracking execution. 2. Communication Rhea describes communication as essential and multi directional. TPMs need to communicate up to leadership, down to teams they are directing, and laterally across peer groups and partner organizations. The ability to clearly articulate problems, plans, and outcomes is a core requirement. 3. Comfort With Ambiguity Rhea highlights ambiguity as a major part of the role. TPMs are often dropped into problem spaces that are not clearly defined, so being able to clarify scope and figure out what needs to be solved is critical. 4. Collaboration and Influence She also calls out collaboration skills. TPMs work across many stakeholders, and their ability to get people to work together is a major part of the job, especially since most TPMs do not manage teams through formal reporting lines. 5. Problem Solving in a Technical Context Rhea explains that TPM problem solving can range from deeply technical work to solving process problems in technical environments. Some TPMs need strong technical depth. Others operate more as orchestrators who understand enough to ask the right questions and drive alignment without being the architect or SME. Depth TPM vs Breadth TPM and Technical Bar Mario asks whether depth TPMs are generally more technical than breadth TPMs. Rhea says technical depth is often more beneficial for depth TPMs because they work directly with engineers and may need to challenge solutions and engage deeply in technical discussions. She also notes that technical depth is not always required if the team has a strong technical lead or architect and what the team needs most is strong program management. The technical bar depends on the structure of the team and how the work is split between PM, TPM, engineering leads, and architects. How TPMs Measure Impact Rhea describes TPM impact in two layers. One layer is straightforward delivery: did the TPM deliver the program on time or within budget, and did the work actually solve the problem. Another layer is the “how” of execution: whether the TPM consistently brings the right people together, identifies the right problem, and leads the program in a way that earns trust and keeps stakeholders aligned. Influencing Without Authority Mario asks how TPMs build influence without direct authority. Rhea explains it as a skill that grows over time. Many TPMs start with smaller projects where the stakeholder group is limited, which lets them practice how to earn buy in. Her approach starts with clarity: explain the problem, explain the business value of solving it, and make the justification strong enough that stakeholders understand why the work matters. As TPMs succeed with smaller projects, they can expand to larger sets of stakeholders by repeating the same fundamentals at a bigger scale. What Rhea Looks For When Hiring TPMs Mario asks what she looks for in interviews, given that she has hired many TPMs. Rhea describes hiring as a check for foundational competence first, then indicators of growth and fit. 1. Demonstrated Project Management Ability Rhea says she assesses whether candidates have managed projects before and can explain how they defined scope, gained buy in, aligned stakeholders, and executed. She looks for track record and specifics, not just titles. 2. Clear Communication and Learning From Failure She also evaluates how clearly candidates can communicate what they did and what value they created. She wants to hear about failures too, especially what the candidate learned and how they recovered, because that reveals maturity and judgment. 3. Curiosity and Hunger to Learn Rhea says she looks for hunger to learn because projects are rarely the same from one to the next. Variables change constantly, so someone who is motivated by learning and can adapt across problem spaces tends to do better over time. 4. Matching Experience to the Program Need Mario adds that hiring also involves matching a person’s strengths to the kind of program they will run. Rhea agrees and explains that beyond generic TPM skills, you look for relevant experience, such as infrastructure programs, customer facing delivery, product delivery, or process improvement, depending on what the team needs. 5. Seniority and Independence They also discuss how seniority affects hiring decisions. If a team has strong senior coverage, it may be easier to onboard a more junior TPM. If the role requires someone to run independently with minimal guidance, the expectation shifts toward someone more senior with proven execution at scale. How Technical TPMs Need to Be When Hiring Rhea repeats that the technical bar depends on the role. For depth TPM roles working closely with engineering and needing to vet and challenge solutions, technical expertise is valuable. For breadth roles, or roles paired with a strong architect, the TPM may not need deep technical specialization if they can orchestrate effectively and drive execution. She also notes that some TPM roles focus on process improvement within technical teams. In those cases, the candidate may add more value through identifying pain points, proposing improvements, and driving adoption than through deep technical design. Tips for Moving From IT Services Into Product Based TPM Work Mario asks for advice for people moving from IT services or non product environments into product based TPM roles. Rhea says it can be a difficult transition, and she often sees candidates without direct product experience apply to her roles. Her guidance is to highlight transferable work, especially examples where the candidate identified a problem or pain point, built a business case, got stakeholder buy in, and drove engineering delivery of a tool or process improvement. She explains that these skills map well to product based TPM work when framed clearly. She also suggests a practical path: take a more adjacent role first, such as an operations focused TPM role inside a product company, then use that internal track record to transition into a product based TPM role later. The idea is to get into the right environment, prove you can deliver, and then move internally when opportunities open up. Full Transcript of the Episode 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.

Episode Overview In this episode, Mario Gerard talks with Priyanka Shinde, a longtime TPM leader with experience across startups and large tech companies, including Cruise and Facebook or Meta. Priyanka also runs TPMify, a coaching and consulting organization focused on helping TPMs and TPM teams grow faster. The conversation is centered on role clarity and role evolution. Mario and Priyanka break down what TPMs do, why the industry needs the role, and how TPMs compare and collaborate with product managers. They then zoom in on newer job titles that have become more common on job boards, including Product Manager Technical and TPM Product, and explain why these variants exist, what skills they imply, and when organizations use them. The focus of the conversation is on: Priyanka’s background and why she cares about building the TPM community Why the industry needs TPMs as products and systems become more complex Core TPM skills: domain depth, program management, communication, leadership, and people skills What product managers do and how their skills overlap with TPMs How PMs and TPMs collaborate and why the partnership can be challenging but valuable Why Product Manager Technical roles exist and what makes them different from traditional PM roles What TPM Product means and where “product sense” shows up in TPM work When teams need both PMT and TPM, and what overlap looks like in practice Career mobility between TPM, PMT, and PM roles The origin story of the TPM Product role at Meta and why it was created The overall theme is that these roles keep evolving because organizations keep trying to match hiring, responsibilities, and product complexity with the right skill sets. Priyanka’s Background and TPMify Mario introduces Priyanka as a TPM leader with more than 20 years in tech, including roles at Cruise and Facebook or Meta. Priyanka shares that she started as a software engineer and transitioned into TPM because she enjoyed being involved end to end and seeing systems come to life. She explains that she has worked across domains like AI, machine learning, ad tech, and education tech, and that the more she worked as a TPM, the more she became invested in the craft. That is part of why she writes, coaches, and builds resources through TPMify. Her stated goal is two sided: help TPMs realize their own impact, and help organizations understand how to leverage TPMs effectively. What Is a TPM and Why Does the Industry Need TPMs? Mario asks Priyanka to define the TPM role. Priyanka describes TPM as a role that blends technical focus with program management and leadership. She frames TPMs as owners of holistic execution strategy, using domain expertise to deliver results. She also explains why the role became more prominent. As products became more complex, pure coordination is no longer enough. You need someone who can manage cross team execution while also understanding technical constraints and system complexity. Mario reinforces this by pointing out how many teams own different components of modern programs, and how important it is to have someone whose job is to align those teams toward a single outcome. Skills TPMs Require Priyanka lists the core skills she sees as essential for TPMs. 1. Technical or Domain Expertise She starts with technical depth. Domain expertise can come from your background or be built over time, but a TPM needs enough technical understanding to operate confidently in complex systems and make decisions grounded in reality. 2. Strong Program Management Priyanka emphasizes classic program management skills, especially in cross functional environments. A TPM needs to juggle multiple teams, understand who to go to for what, manage moving parts, and keep the program aligned. She also calls out the ability to see the big picture and “look around corners.” 3. Communication at Every Level She highlights written and verbal communication as a core competency. TPMs communicate across peers, partner teams, leadership, and executives. The goal is to provide clarity and confidence, not just status. 4. Leadership and People Skills Priyanka treats leadership as a core part of the job. TPMs influence without authority, build relationships, manage conflicts, and motivate teams. In her view, these people skills are not secondary. They are central to making execution work. What Product Managers Do and What Skills They Have Mario shifts to product management to set up the later comparison. Priyanka describes PMs as primarily owning the what, and often the why, by identifying opportunities, shaping vision, building strategy and roadmaps, and using research and market analysis to inform priorities and requirements. They discuss key PM skills: vision and strategy, customer and market understanding, prioritization rationale, strong communication and persuasion, and being data driven and analytical. Priyanka also notes that PMs tend to be depth focused, going deep on a specific customer problem. Mario points out that there is meaningful overlap between PM and TPM skills, including influencing leadership and working across teams. The difference is often the center of gravity: PMs lean toward shaping direction, while TPMs lean toward getting the program delivered. How PMs and TPMs Collaborate Priyanka explains that earlier versions of these roles were often separated by external versus internal focus. PMs were heavily external facing and program roles were more internal. Over time, product complexity and org needs drove overlap. PMs became more internal as well, and responsibilities became less cleanly separated. Her framing is that PMs lean toward vision and strategy while TPMs lean toward execution and delivery. The word lean matters because both roles can do pieces of the other when needed, but trying to do everything in one role is not always effective. She describes PMs as more forward looking while TPMs focus on getting the current roadmap executed, managing the present, and keeping teams aligned. Both emphasize that the partnership works best when the PM and TPM explicitly talk through strengths, gaps, and where responsibilities might collide. Priyanka notes that even with a written responsibilities document, the real fix is direct conversation, ongoing alignment, and building chemistry as counterparts. Why Product Manager Technical Roles Exist Mario asks why Product Manager Technical roles have become more common. Priyanka explains that not all organizations need this title, but many do because their products and systems are highly technical. Some companies do not create separate titles but still hire PMs with strong technical depth for certain problem spaces. She also says the title helps in hiring. It clarifies the skill profile during recruiting and helps candidates who want to stay technical while shifting closer to product and strategy identify the right roles. Product Manager vs Product Manager Technical Priyanka describes the main difference as domain specialization and platform thinking. Technical product managers often own the underlying systems and platforms that enable user facing product work. They build technical roadmaps based on architecture, system constraints, interdependencies, and platform capabilities. She gives an example from Meta where teams effectively had both types of product focus even when titles were not formally distinguished. Some PMs were more user or customer facing, while others focused on the backend infrastructure that supported AI systems. The technical product managers needed to understand the user facing roadmap so they could build enabling infrastructure ahead of time. Where These Roles Show Up Priyanka mentions seeing technical product manager roles at companies like Amazon, Intel, PayPal, Adobe, and startups, in addition to Cruise and Meta. She also notes that the increase in job postings over the last few years is a sign that companies are formalizing these needs more explicitly. TPM Product vs Product Manager Technical Mario asks how TPM Product compares to Product Manager Technical. Priyanka explains that TPM Product is still a TPM role, but in a consumer or user facing environment where having product sense matters more. She describes TPM Product as a TPM who needs stronger customer empathy, context on why certain features matter, and a better sense for how success metrics tie back to user outcomes. She contrasts this with infrastructure focused TPM work. In backend systems, TPMs tend to focus on metrics like capacity, latency, and performance. Those still affect users, but the thinking is more system first than user experience first. How Metrics and Success Criteria Get Defined Mario asks whether TPM Product defines customer facing metrics or whether the PM does. Priyanka describes it as collaborative. PMs bring market knowledge and research. TPMs bring system understanding and technical feasibility. Together they define success metrics that might include both user facing outcomes and technical performance. Why TPM Product Roles Are Gaining Prominence Priyanka explains that TPM Product became more formal at Meta partly for hiring clarity. The distinction helps teams interview for product sense, not just execution skill. It also helps candidates understand what kind of work they are signing up for. She parallels this with Product Manager Technical roles, where the title can signal the need for deeper technical expertise. She also explains how these roles can exist together on the same team, especially when the product is large, complex, and requires balancing near term execution with longer term platform and roadmap planning. PMT and TPM Overlap Priyanka says there can be meaningful overlap, especially in highly technical areas where TPMs historically took on work that looks like PMT today. In smaller teams, one person may cover parts of both roles. But when products are highly complex and span many teams, having both roles helps avoid overloading a single person and improves overall effectiveness. Her rule of thumb is that teams add both PMT and TPM when the breadth is large, there are many stakeholders, and the roadmap is too complex for one person to handle well. PMTs focus on shaping the technical roadmap and product direction. TPMs connect the dots, manage dependencies, track risks, and keep execution moving across many teams. Product Manager Technical Skills Priyanka describes PMT skills as overlapping with PM skills, with added technical depth. PMTs still identify opportunities and build vision and strategy, but they apply that work to technical platforms and system constraints. Their data and research may be less about user clicks and more about system performance, scaling needs, reliability, and architectural requirements. She also reinforces what TPMs bring at scale: connecting stakeholders, managing dependencies, identifying risks, mitigating risks, and maintaining big picture visibility. She highlights dependency and risk management as core TPM strengths that become more difficult as more teams are involved. Career Switching Between PMT, TPM, and PM Mario asks whether people can move between these roles. Priyanka says yes, because the overlap in responsibilities and skill sets makes transitions realistic. She frames the decision as personal fit: if you enjoy creating vision and strategy, PMT or PM may fit better. If you enjoy execution, delivery, and driving programs to completion, TPM may fit better. They also mention that product TPMs sometimes transition into product management if they discover they want to focus more on product vision and strategy. The consistent advice is to pay attention to what you enjoy and what you are strong at, because leaning into strengths makes the work easier and more satisfying. Origin Story of TPM Product at Meta Priyanka shares how TPM Product evolved at Meta. When she joined in 2016, product TPM was still early and concentrated in areas like Ads and business platforms, while infrastructure TPM hiring had existed for much longer. The goal of creating a distinct label was to attract TPMs into product teams with the right expectations and skill profiles. She explains that the interview framework was adjusted to include product sense, such as understanding customer context and why metrics matter, even if the TPM is not writing product requirements. There was also a deliberate effort to clarify why both product managers and product TPMs were needed so the roles did not feel like they were encroaching on each other. She connects this to the leaning framework again: PMs lean toward vision and strategy, TPMs lean toward execution and delivery. That framing helped teams explain the difference clearly while still acknowledging overlap. Closing Thoughts Mario thanks Priyanka and encourages more TPMs to write and contribute back to the community, noting that product roles are often more publicly evangelized than TPM roles even though many organizations have comparable numbers of TPMs and PMs. Priyanka echoes the sentiment and reinforces the idea of rallying around the TPM community. She closes by encouraging aspiring TPMs to lean into their strengths, collaborate actively with counterparts, and keep building shared knowledge through writing and mentoring. Full Transcript of the Episode 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. What is TPM’s role and why does the industry need a TPM? 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. What skills do you think TPMs require? 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. Communicating at different levels within the organization – What does a product manager do? 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.  What do you think are the skill sets, the PMs possess? 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. How do PMs and TPMS collaborate? 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. Product Manager Technical Role – Why do organizations need this? 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. Product Manager vs Product Manager (Technical) 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. What does Cruise do ? 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. Why The ‘TPM Product Manager’ Role Is Gaining Prominence? 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. PMT & TPM – The overlap? 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. ‘Product Manager Technical’ Skills 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]. Importance of figuring out what you want to do? 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 Ready to rock your TPM Interview?  A detailed interview prep guide with tips and strategies to land your dream job at FAANG companies. Explore ‘Ace Your TPM Interview’ course!