Show Notes
Episode Overview and Summary
Go to the full transcript of the episode
In part two of the series, Mario Gerard and Rhea Frondozo continue the conversation on how TPMs run large scale programs. This episode gets more practical, focusing on how to build a communication plan, what kinds of blockers show up during execution, how you track information across huge programs, and what the TPM team structure often looks like.
The focus of the conversation is on:
How to design a communication plan for a large-scale program
How communication cadence changes as the program evolves
Common blockers: schedule delays, requirements issues, architecture problems, scope creep
Prioritization and resourcing trade-offs across competing initiatives
Finding the right owners and solving unclear ownership problems
How to maintain program information using tools, dashboards, and centralized sources of truth
How large programs are staffed, including lead TPMs, workstreams, and supporting TPMs
The phases of a large program, from planning to execution to support and closeout
Overall, the episode explains that large programs are won or lost through structured communication, disciplined scope and prioritization, and a TPM’s ability to keep recalibrating as reality shifts.
Designing a Communication Plan
Rhea explains that a communication plan is really a set of decisions about who needs information, how often they need it, what level of detail they need, why they need it, and how you deliver it. The mistake is treating communication as one size fits all.
She breaks it down by audience:
Executives typically need concise summaries, usually via a short report, email, or executive status meeting
POCs and active stakeholders need working sessions and status meetings where you can unblock issues and track progress
Broader groups who are impacted later may need lightweight updates, like a newsletter, so requests do not come out of nowhere
Mario adds that, in practice, a central tracking page can help a lot. He describes using something like a Confluence page to capture the objective, mission, risks, deliverables, milestones, and owners, often in a table format where teams can quickly see status by red, yellow, or green.
Cadence Changes as the Program Evolves
A big point in this episode is that communication cadence should not stay fixed. Rhea explains that early in a program, you may spend more time with executive sponsors to get buy in. Later, once you are in execution mode, the center of gravity shifts toward the POCs doing the work.
Sometimes cadence becomes extremely intense. If there is a major issue, teams may run daily war rooms to get all hands on deck. But Rhea also points out the danger of overdoing it. If you keep daily meetings running after the problem is solved, you burn people out and waste time. The TPM has to keep reevaluating what is needed and adjust accordingly.
Common Blockers in Execution
Mario asks what kinds of blockers show up most often. Rhea groups them into a few common categories.
1. Schedule Delays
Rhea says schedule delays are one of the most common blockers. They can come from underestimation, external dependencies, or simply discovering that the original plan does not work. She also notes that engineers often underestimate timelines, which is why TPMs should ask for confidence levels, clarify risks, and build buffers.
She gives examples of schedule drivers that are out of the team’s direct control, like supply chain timing for hardware deliveries, or depending on external reviews like accreditations or audits.
2. Misinterpreted or Changing Requirements
Another major blocker is realizing the requirements were wrong or misunderstood. Rhea frames this as an area where failing fast matters. If the team built against the wrong requirements, you have to regroup, redo work, and reset expectations.
3. Technical and Architectural Mistakes
They talk about how expensive architectural mistakes can become at scale. M