Épisodes

  • TPM Podcast with Rhea – Episode II Part III

    TPM Podcast with Rhea – Episode II Part III
    Mar 7 2023
    Episode Overview 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 forHow to draw the line between helping and taking over someone else’s workWhen to rely on SMEs, and how to keep SME solutions aligned to business needsHow scope creep often shows up through “extra” asks attached to your programA real example: OCI’s global government sector program and why it was so complexWhat divergence means, why it matters, and how it can multiply long term complexityHow 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 ...
    Afficher plus Afficher moins
    20 min
  • TPM Podcast with Rhea – Episode II Part II

    TPM Podcast with Rhea – Episode II Part II
    Mar 7 2023
    Episode Overview and Summary 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 programHow communication cadence changes as the program evolvesCommon blockers: schedule delays, requirements issues, architecture problems, scope creepPrioritization and resourcing trade-offs across competing initiativesFinding the right owners and solving unclear ownership problemsHow to maintain program information using tools, dashboards, and centralized sources of truthHow large programs are staffed, including lead TPMs, workstreams, and supporting TPMsThe 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 meetingPOCs and active stakeholders need working sessions and status meetings where you can unblock issues and track progressBroader 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. ...
    Afficher plus Afficher moins
    31 min
  • TPM Podcast with Rhea – Episode II Part I

    TPM Podcast with Rhea – Episode II Part I
    Mar 7 2023
    Episode Overview 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 TPMsThe skills you actually need to run these programsHow executive sponsors fit inWhy these efforts matter so much to the businessWhy 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 organizationsInvolves hundreds or even thousands of engineersIs 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 areaWorks very closely with engineers on that teamUnderstands the technical problem space in detail Breadth TPM Works across many teams and organizationsInteracts with points of contact for different functional areas, such as security, operations, infra, platform teams, and so onRelies on those functional owners to be the subject matter expertsFocuses 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 executivesTalk to engineering leaders and individual engineers about what needs to be done and by whenAdjust 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 directionClarifying problemsRepeating the overall story of the program in different ways so that different teams can translate it into their own workWriting 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 objectiveDefine the scope so people know what is in and what is outMake 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 tomorrowYou can plan a lot, but you cannot plan everythingThere 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 playsYou are responsible for how the team moves toward the goalYour 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 ...
    Afficher plus Afficher moins
    29 min
  • TPM: Running Large Scale Programs – Podcast with Rhea

    TPM: Running Large Scale Programs – Podcast with Rhea
    Mar 7 2023
    Episode Overview 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 programsHow the TPM function varies across companies, teams, and seniority levelsCore TPM skills: project management, communication, ambiguity, collaboration, and problem solvingDepth TPM versus breadth TPM and how technical each role tends to beHow TPMs measure impact, including what you deliver and how you leadInfluencing without authority and how to build that skill over timeWhat hiring managers look for when interviewing TPMsHow technical the hiring bar should be depending on the program and team structureTips 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, ...
    Afficher plus Afficher moins
    15 min
  • TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde

    TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde
    Aug 9 2022
    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 communityWhy the industry needs TPMs as products and systems become more complexCore TPM skills: domain depth, program management, communication, leadership, and people skillsWhat product managers do and how their skills overlap with TPMsHow PMs and TPMs collaborate and why the partnership can be challenging but valuableWhy Product Manager Technical roles exist and what makes them different from traditional PM rolesWhat TPM Product means and where “product sense” shows up in TPM workWhen teams need both PMT and TPM, and what overlap looks like in practiceCareer mobility between TPM, PMT, and PM rolesThe 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 ...
    Afficher plus Afficher moins
    42 min
  • TPM Podcast With David Glick – Part I

    TPM Podcast With David Glick – Part I
    May 1 2022
    Episode Overview In this episode of the TPM Podcast, Mario Gerard is joined by David Glick, former Vice President at Amazon with nearly 20 years of experience and current CTO at Flex. David brings a senior executive perspective shaped by building large-scale systems, leading thousands of people, and repeatedly delivering mission-critical programs in high-pressure environments. The conversation is split into two broad themes. First, David shares his perspective on the fundamentals of the TPM role, what great TPMs do differently, and why the role is so critical to execution. Second, he discusses leadership at scale: how senior leaders ensure the right people are working on the right problems, how organizations execute reliably, and how trust, clarity, and discipline shape high-performing teams. David’s Background and What Flex Does David spent almost two decades at Amazon, where he served as a Vice President leading Fulfillment Technologies and Amazon Tickets. After leaving Amazon, he joined Flex as CTO, where he has spent the last three years helping scale a fast-growing logistics technology company. Flex operates a marketplace that connects enterprise shippers, including major retailers and brands, with logistics and fulfillment providers. The company works with six of the top ten retailers in the United States and is building its own warehouse management system, transportation network, and supporting infrastructure. As David notes, Flex is hiring aggressively across TPM, engineering, and product roles. How David Defines the TPM Role David describes the TPM role in one word: delivery. In his view, the TPM’s primary responsibility is to get programs over the finish line on time and within budget. This means owning schedules, understanding dependencies, coordinating resources that do not directly report to the TPM, and driving commitments across teams. While TPMs may not formally own resources, they effectively control them through influence, structure, and accountability. David emphasizes that large-scale projects require rigor. Even in agile environments, major initiatives are still managed at the milestone level. Tools like Gantt charts, spreadsheets, or Smartsheet are essential for tracking dependencies and ensuring alignment when dozens or hundreds of people are involved. Agile Execution vs Reality David shares an anecdote from Amazon that highlights the tension between agile philosophy and real-world delivery. A team resisted providing delivery dates, arguing that deadlines were unnecessary. David’s response was blunt: regardless of methodology, large programs must converge at a specific point, especially when senior leadership and customers are involved. Agile execution at the team level still requires traditional planning and milestone tracking at the program level. Without that structure, large initiatives fail to come together. Dependencies Are What Kill Projects According to David, projects rarely fail because of software or hardware alone. They fail because of people, communication breakdowns, and unmanaged dependencies. One of the most effective TPM strategies is to front-load dependencies. If one team needs an API from another, delivering a stub early can unlock progress and prevent downstream teams from being blocked. Reducing or eliminating cross-team dependencies is one of the most powerful ways TPMs increase delivery success. Being Technical Without a Computer Science Degree David is candid about not having a traditional computer science degree, yet he has led some of Amazon’s most critical technical organizations and now serves as CTO at Flex. He describes earning his technical education through experience: being pulled into high-severity incidents, reading postmortems, and observing firsthand what makes systems fragile or resilient. He credits early mentorship at Amazon, particularly from one of the company’s first TPMs, with shaping his understanding of how technical leadership evolves over time. Early in a career, value comes from individual output. As seniority increases, value shifts toward process, people, and organizational effectiveness. Why David Strongly Believes in the TPM Role David believes TPMs are indispensable once an organization has product-market fit and direction. At that point, success depends almost entirely on execution. He shares an example from Flex, where a major customer required multiple features before committing. The organization agreed to deliver but lacked a clear plan. Hiring a strong TPM immediately changed the situation. Within a week, the TPM created an integrated execution plan linking JIRA and Smartsheet, clearly exposing ownership, dependencies, and schedule risk. This, for David, perfectly illustrates the value of TPMs: turning commitments into credible execution. Core Skills TPMs Must Have David highlights several foundational skills for TPMs: Extreme attention to detail: TPMs must know what every contributor is working on and how it ...
    Afficher plus Afficher moins
    26 min
  • TPM Podcast With David Glick – Part II

    TPM Podcast With David Glick – Part II
    May 1 2022
    Afficher plus Afficher moins
    29 min
  • TPM Podcast With David Glick – Part III

    TPM Podcast With David Glick – Part III
    May 1 2022
    Afficher plus Afficher moins
    19 min