The Technical Program Management Podcast & Interviews

Mario Gerard

The Technical Program Management Podcast with Mario Gerard

  1. 07/03/2023

    TPM Podcast with Rhea – Episode II Part III

    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

    20 min

  2. 07/03/2023

    TPM Podcast with Rhea – Episode II Part II

    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 mechanis

    31 min

  3. 07/03/2023

    TPM Podcast with Rhea – Episode II Part I

    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

    29 min

  4. 07/03/2023

    TPM: Running Large Scale Programs – Podcast with Rhea

    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, en

    15 min

  5. 09/08/2022

    TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde

    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

    42 min

  6. 01/05/2022

    TPM Podcast With David Glick – Part I

    The Technical Program Management Podcast & Interviews

    26 min

  7. 01/05/2022

    TPM Podcast With David Glick – Part II

    The Technical Program Management Podcast & Interviews

    29 min

  8. 01/05/2022

    TPM Podcast With David Glick – Part III

    The Technical Program Management Podcast & Interviews

    19 min
Tout afficher (28)

4,8
sur 5
41 notes

À propos

The Technical Program Management Podcast with Mario Gerard

Informations

Vous aimeriez peut‑être aussi