『The Technical Program Management Podcast & Interviews』のカバーアート

The Technical Program Management Podcast & Interviews

The Technical Program Management Podcast & Interviews

著者： Mario Gerard
無料で聴く

このコンテンツについて

 The Technical Program Management Podcast with Mario GerardCopyright The Technical Program Management Podcast 2017
エピソード
  • TPM Podcast with Rhea – Episode II Part III

    TPM Podcast with Rhea – Episode II Part III
    2023/03/07
    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 ...
    続きを読む 一部表示
    20 分
  • TPM Podcast with Rhea – Episode II Part II

    TPM Podcast with Rhea – Episode II Part II
    2023/03/07
    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. ...
    続きを読む 一部表示
    31 分
  • TPM Podcast with Rhea – Episode II Part I

    TPM Podcast with Rhea – Episode II Part I
    2023/03/07
    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 ...
    続きを読む 一部表示
    29 分
まだレビューはありません