The Technical Program Management Podcast & Interviews

Latest Episodes:

TPM Podcast with Rhea – Episode II Part III Mar 07, 2023

Show notes

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…

Full show notes at the publisher

TPM Podcast with Rhea – Episode II Part II Mar 07, 2023

Show notes

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 ev…

Full show notes at the publisher

TPM Podcast with Rhea – Episode II Part I Mar 07, 2023

Show notes

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…

Full show notes at the publisher

TPM: Running Large Scale Programs – Podcast with Rhea Mar 07, 2023

Show notes

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 thing…

Full show notes at the publisher

TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde Aug 09, 2022

Show notes

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 communit…

Full show notes at the publisher

TPM Podcast With David Glick – Part I May 01, 2022

Show notes

TPM Podcast With David Glick – Part II May 01, 2022

Show notes

TPM Podcast With David Glick – Part III May 01, 2022

Show notes

TPM Podcast With Arjun Subramanian: Burnout – EP II Part II Mar 17, 2022

Show notes

TPM Podcast With Arjun Subramanian: Burnout – EP II Part I Mar 17, 2022

Show notes