TPM: Running Large Scale Programs – Podcast with Rhea

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 programs
• How the TPM function varies across companies, teams, and seniority levels
• Core TPM skills: project management, communication, ambiguity, collaboration, and problem solving
• Depth TPM versus breadth TPM and how technical each role tends to be
• How TPMs measure impact, including what you deliver and how you lead
• Influencing without authority and how to build that skill over time
• What hiring managers look for when interviewing TPMs
• How technical the hiring bar should be depending on the program and team structure
• Tips for moving from IT services or non product orgs into product based TPM roles

Overall, the episode works like a practical TPM primer, grounded in real hiring and leadership experience rather than a generic job description.

Who Rhea Is and What Work She Cares About

Mario introduces Rhea as a senior TPM leader with about two decades of experience across IBM, Microsoft, EMC, Oracle Cloud Infrastructure, and Salesforce, where she is now a senior director leading TPMs. Rhea describes a career path that included being a developer, program manager, test manager, engineering manager, and TPM leader.

Rhea explains that after trying many roles, she learned what she enjoys most: large scale, complex programs that span multiple products, services, and processes. She is less interested in consumer facing features and more drawn to enterprise infrastructure challenges, especially cross functional technical problems that require coordination across many teams.

How Rhea Describes the TPM Function

Rhea says the TPM function is hard to describe in a single sentence because it varies so much by company, org, and team. She frames TPM as a blended role: foundational program or project management responsibilities applied to technical programs, systems, or processes.

She also emphasizes that the TPM job changes with seniority. A TPM can operate in a narrow scope and go deep in one area, or operate broadly across many organizations, depending on whether the role is closer to depth TPM work or breadth TPM work.

Core Skills TPMs Should Have

Mario asks what skills matter most. Rhea starts with the basics and then expands outward.

1. Project Management

Rhea says the baseline skill set is project management. That includes defining scope and problem space, understanding business impact, identifying stakeholders, setting goals, creating schedules, and tracking execution.

2. Communication

Rhea describes communication as essential and multi directional. TPMs need to communicate up to leadership, down to teams they are directing, and laterally across peer groups and partner organizations. The ability to clearly articulate problems, plans, and outcomes is a core requirement.

3. Comfort With Ambiguity

Rhea highlights ambiguity as a major part of the role. TPMs are often dropped into problem spaces that are not clearly defined, so being able to clarify scope and figure out what needs to be solved is critical.

4. Collaboration and Influence

She also calls out collaboration skills. TPMs work across many stakeholders, and their ability to get people to work together is a major part of the job, especially since most TPMs do not manage teams through formal reporting lines.

5. Problem Solving in a Technical Context

Rhea explains that TPM problem solving can range from deeply technical work to solving process problems in technical environments. Some TPMs need strong technical depth. Others operate more as orchestrators who understand enough to ask the right questions and drive alignment without being the architect or SME.

Depth TPM vs Breadth TPM and Technical Bar

Mario asks whether depth TPMs are generally more technical than breadth TPMs. Rhea says technical depth is often more beneficial for depth TPMs because they work directly with engineers and may need to challenge solutions and engage deeply in technical discussions.

She also notes that technical depth is not always required if the team has a strong technical lead or architect and what the team needs most is strong program management. The technical bar depends on the structure of the team and how the work is split between PM, TPM, engineering leads, and architects.

How TPMs Measure Impact

Rhea describes TPM impact in two layers. One layer is straightforward delivery: did the TPM deliver the program on time or within budget, and did the work actually solve the problem. Another layer is the “how” of execution: whether the TPM consistently brings the right people together, identifies the right problem, and leads the program in a way that earns trust and keeps stakeholders aligned.

Influencing Without Authority

Mario asks how TPMs build influence without direct authority. Rhea explains it as a skill that grows over time. Many TPMs start with smaller projects where the stakeholder group is limited, which lets them practice how to earn buy in.

Her approach starts with clarity: explain the problem, explain the business value of solving it, and make the justification strong enough that stakeholders understand why the work matters. As TPMs succeed with smaller projects, they can expand to larger sets of stakeholders by repeating the same fundamentals at a bigger scale.

What Rhea Looks For When Hiring TPMs

Mario asks what she looks for in interviews, given that she has hired many TPMs. Rhea describes hiring as a check for foundational competence first, then indicators of growth and fit.

1. Demonstrated Project Management Ability

Rhea says she assesses whether candidates have managed projects before and can explain how they defined scope, gained buy in, aligned stakeholders, and executed. She looks for track record and specifics, not just titles.

2. Clear Communication and Learning From Failure

She also evaluates how clearly candidates can communicate what they did and what value they created. She wants to hear about failures too, especially what the candidate learned and how they recovered, because that reveals maturity and judgment.

3. Curiosity and Hunger to Learn

Rhea says she looks for hunger to learn because projects are rarely the same from one to the next. Variables change constantly, so someone who is motivated by learning and can adapt across problem spaces tends to do better over time.

4. Matching Experience to the Program Need

Mario adds that hiring also involves matching a person’s strengths to the kind of program they will run. Rhea agrees and explains that beyond generic TPM skills, you look for relevant experience, such as infrastructure programs, customer facing delivery, product delivery, or process improvement, depending on what the team needs.

5. Seniority and Independence

They also discuss how seniority affects hiring decisions. If a team has strong senior coverage, it may be easier to onboard a more junior TPM. If the role requires someone to run independently with minimal guidance, the expectation shifts toward someone more senior with proven execution at scale.

How Technical TPMs Need to Be When Hiring

Rhea repeats that the technical bar depends on the role. For depth TPM roles working closely with engineering and needing to vet and challenge solutions, technical expertise is valuable. For breadth roles, or roles paired with a strong architect, the TPM may not need deep technical specialization if they can orchestrate effectively and drive execution.

She also notes that some TPM roles focus on process improvement within technical teams. In those cases, the candidate may add more value through identifying pain points, proposing improvements, and driving adoption than through deep technical design.

Tips for Moving From IT Services Into Product Based TPM Work

Mario asks for advice for people moving from IT services or non product environments into product based TPM roles. Rhea says it can be a difficult transition, and she often sees candidates without direct product experience apply to her roles.

Her guidance is to highlight transferable work, especially examples where the candidate identified a problem or pain point, built a business case, got stakeholder buy in, and drove engineering delivery of a tool or process improvement. She explains that these skills map well to product based TPM work when framed clearly.

She also suggests a practical path: take a more adjacent role first, such as an operations focused TPM role inside a product company, then use that internal track record to transition into a product based TPM role later. The idea is to get into the right environment, prove you can deliver, and then move internally when opportunities open up.

Full Transcript of the Episode

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Rhea Frondozo. She and I have worked together at Oracle cloud infrastructure team OCI. Rhea has been a tech industry for the last 20 years. She’s worked at IBM for eight years, Microsoft for fours, EMC square. And then at OCI for six years, she’s had a variety of different roles as well. She’s been a developer, a program manager, a test manager, engineering manager, a director of TPM, and right now, is working at Salesforce as a senior director of TPMS. Her specialty is to run large scheme programs. Rhea, thank you for joining us today. And why don’t you introduce yourself to our audience to our audience?

Rhea Frondozo: Thanks Mario. As you mentioned, I have had a 20-year run in the tech industry working for several of the top tech companies in a variety of different roles.

But what I found is that I’ve always been most interested in working on large scale complex programs and products after trying out so many different roles at different companies. What I now know is that my passion tends to be working on projects that aren’t so much consumer facing in terms of features or products or services, but more on, so solving enterprise level infrastructure challenges.

I find that the problem solving I enjoy most applies to cross-functional technical challenges that typically span multiple products, services, or even processes.

Mario Gerard: Fantastic. Rhea and I actually have worked together at OCI. As I mentioned, we’ve been on the same team I’ve reported to Rhea where it was so much fun. We’ve actually solved so many large-scale programs or problems, which turned in programs and I’ve learned so much from her. So, I think this is going to be a very interesting podcast. So how we have designed today’s podcast is the first section. We are going to just go over some very fundamental TPM questions with Rhea. And the second half of the podcast, we’re going to go very much into the details of how you’ve run a large-scale program.

So, let’s start with the first section, right? So, Rhea, how would you describe the TPM function?

Rhea Frondozo: So, the TPM function I have to say is not a very easy one to describe because it typically is something that varies from company to company and organization, to organization, team, to team. It’s a newer function I think that has a blended role within many organizations.

So, if you can imagine at the base, you have the project management or program management responsibilities, then you apply that to some kind of technical project, program process that needs to be solved for. And so, it also can vary tremendously depending on seniority level. And so, the scale at which you operate can be very small and narrow, more depth focused If you are a depth TPM, or it can be very large and crosscutting across entire organizations or entire companies, if you’re looking more at the breadth TPM role.

Mario Gerard: And what would you say are the core skills TPM should generally have?

Rhea Frondozo: So, at the most basic, you know, skill that I would expect TPMS to have been first and foremost, project management skills. These are just your basic project management skills around being able to define scope, a problem space, understand business impact, being able to identify key stakeholders and goals that you want to solve for as well as, you know, creating schedules and tracking execution.

But outside of just your project management basic skills, the expectation would be that you have to have very solid communication skills. The ability to communicate both up down and laterally, whether it’s your having conversations with Lee leadership, having conversations with team members, who you are giving direction to, or maybe peers or TPMS that you are trying to get to work on your project, who are maybe peers.

Outside of communication Some other soft skills that I think are important are just the ability to deal with ambiguity. Having a project manage background typically means that you might get applied to a variety of different problem spaces that aren’t often clearly defined. And so being able to be dropped into an ambiguous situation and figure out, you know, what is the scope that you have to solve for is hugely important.

A few other ones to note, I’d say, are your ability to collaborate with People. Being a program manager means that you’re going to be working across the board with a number of different stakeholders and your soft skill of being able to get people to work with you becomes essential.

Maybe the last two dimension come from the perspective of your technical focus. You have to be able to solve problems but solving could mean in a way where the T is a capital T a big T where you’re solving very technical problems or maybe a little t, where you’re solving more process problems in a technical space, but maybe not being the subject matter expert or the architect that has to solve those problems.

Mario Gerard: You spoke about the capital key of being like, you know, somebody who’s solving like very technical problems, and then somebody’s not solving too big of a technical problem. Would you say a depth TPM generally is more technical versus a breadth TPM might not need to be that technical?

Rhea Frondozo: So, I would say it’s definitely beneficial for a depth TPM to be more technical because you’re often going to be in conversations with engineers directly, even be managing a project where your key stakeholders you’re working with are engineers. It may not be absolutely necessary if you’re paired with maybe a technical architect or maybe a technical team lead that in that case, it may be the case that your core project management skill sets or what that team is lacking. And then you can still add value to the team that way.

But in general, yes, if you have more technical skills, it definitely makes it easier to perform in a depth TPM role.

Mario Gerard: Cool. How do TPMS measure impact as you spoke about like TPMS helping teams out, how do they measure impact?

Rhea Frondozo: Well, so similar to any kind of program that you may have, you can measure your own KPIs as a TPM, depending on some of the deliverables that you have as an individual, whether it’s, you know, were you able to deliver your program on time or within budget? Were you able to deliver a solution that actually solves the problem at hand? Are you delivering the right solution, so these are some of the things that you can measure from the program perspective, but there’s also a way that you can measure your value by what soft skills do you bring to the table?

Are you someone that can bring the right people together? Do you have the ability to lead a team and to identify the right problem to solve? And so, the how you deliver is something that can also be measurable.

Mario Gerard: That’s interesting. When you talk about how a TPM is bringing people together, the first question that comes to mind is influencing people because you don’t have anybody actually reporting to you directly as a TPM, what would be your guidance and how TPMS can build something like that, like influencing without authority.

Rhea Frondozo: So that’s a great question. A lot of times when you get into a TPM role, this is maybe something that you might not be familiar with at first. And so usually a TPM will start with working on much smaller projects where the set of stakeholders that they have may be rather limited. And the number of people that you have to influence can be pretty small.

And you have the opportunity to kind of practice how you get their buy-in to the project that you have by typically being able to explain clearly, what is the problem at hand? What is the business value that you would be delivering if you guys can solve this problem and then ultimately starting small, and then you end up being able to grow the number of stakeholders that you work across by being able to work across more stakeholders, you have to be able to continue being able to deliver a good business justification that helps people understand the necessity to work on your program.

Mario Gerard: That’s a very good way of explaining that I think. So, you’ve hired hundreds of TPMS. You’ve probably interviewed thousands of TPMS. What do you look for when you hire TPMS?

Rhea Frondozo: So, I think a lot of it comes down to those basic skills that I mentioned earlier that you have to have, I think first and foremost, when I’m creating, say a loop for a TPM, I’m definitely checking to make sure that we’re assessing their project management skills. Have they managed projects before? Can they tell me about a project that they’ve had to define, had to get buy in on, had to get stakeholders to agree, had to identify the right scope, the right goal to accomplish, and then, you know, what’s their track record on executing against projects that they’ve had to manage.

Other things that I look for is, you know, their ability to communicate. Are they able to clearly articulate what projects that they’ve had, the value that they’ve been able to bring? Tell me about times where they failed maybe and what they’ve had to do to recover or what they learned from those failures.

Also, in general, I think when I’m hiring TPMS, I’m looking for what kind of hunger that they have to want to learn. It’s not very often that you get two projects that are always the same from one to the next. Projects always change. Project to project variables is always different and somebody who is able to continue growing in their space and taking on different challenges and being able to navigate different problems and being interested in doing so is something that I’m always looking for.

Mario Gerard: Also, there’s probably one more aspect, right? As I was thinking through this is that you try to, when you’re hiring somebody for a particular program, you might also look at what that program would need and then hire the right type of person for that particular program. Or once, sometimes we hire like three or four people and then we match them to the right program. Like the skills from doing the interview, fixing on a candidate.

And if you have like a bunch of candidates, we then say, hey, this person’s going to be good for this particular program that person’s going to do well in that particular program.

Rhea Frondozo: Right. That’s a good point that you bring up. Cause part of what I would say outside of just kind of the generic skills you have; you’re also going to be looking for what particular expertise do they bring to the table? Is it someone that’s worked in an infrastructure space? Is it someone that’s worked on customer facing projects? Is it someone that’s worked on delivering products? Is it someone that’s done process improvements? So, depending on what project that you are program, you’re looking for somebody to take on, matching their experience with that project also goes long way.

Mario Gerard: And probably the seniority level as well, right? Depending on how senior they are, you probably say, well, they don’t need too much guidance, or they can run with this. Or my expectation is that they run with this.

Rhea Frondozo: Right. So depending on the structure of the team and the complexity of the project at hand, you may be able to take on somebody that’s saying more junior, if you have more and your people on the team, or if you’re looking for somebody who can run independently, then you’re probably going to want somebody more senior who you know has a demonstrated track record of running large scale projects on their own.

Mario Gerard: And as we are talking through hiring TPMS, how technical do you think TPMS need to be when you’re hiring them? Or what’s your bar? How do you evaluate that?

Rhea Frondozo: Yeah. So, I also think that this can vary depending on the position that you’re hiring for. So, as we mentioned earlier, if you are hiring for say a depth TPM, that’s going to work very closely with engineers and having to work in a space where engineers are creating solutions and you need to be able to make sure that your TPM can vet those solutions and challenge those solutions If necessary. Having a technical background or technical expertise is going to be very valuable in that case.

But if you’re looking at other maybe projects that are very large scale, across many different teams, maybe you’re going to have, have a different structure for the team where there is a pairing with a more technical architect that you work hand in hand with. And it’s not as necessary for you to have a TPM that has, you know, both of the project management and the technical skills, or it could be the case that you’re working on a process improvement that is applied in a technical space. But if they have the ability to identify pain points, ability to identify process improvements that are possible, then it could be the case set. It’s not as necessary in that case either.

Mario Gerard: Yeah. That makes sense. The last question I have in this section is do you have any tips for people who are moving from an IT services industry or a non-product-based organization who’re looking to move into a more product-based organization or a product-based company.

Rhea Frondozo: Yeah. So, this can be a pretty tough move for someone to make a lot of times.

Mario Gerard: And you’ve been hiring a lot of people, right? I think this is one of those difficult problems that you face when you’re looking at resumes of people who are not completely in the product space.

Rhea Frondozo: Right. Right. So, I do have applicants that often apply to my roles who are coming from say a service industry and don’t have specific experience working on a product. In that case a lot of times what I’m looking for is if they can tell me about maybe projects that they’ve had in their roles, where they’ve had to identify a problem space, and they’ve had to identify maybe a pain point that required some kind of improvement or buy-in from stakeholders to get engineering to deliver on a tooling or process improvement.

If they can do that, where they can show that they’ve been able to demonstrate, you know, a way to assess a product or a product gap, assess a process gap, figure out how to prioritize the work that would be needed by defining the business impact that it has. These are the types of skills that could be transferable to working in a more product based TPM role.

Another alternative I would say is if you have of a, more of like an operations TPM role in a service industry, which could be something that you could take a, maybe a parallel job in a company that has, you know, product based TPM roles. And then once you get there, try, and make a transition internally to a product based TPM role based on a track record that they can vet from sister teams.

Mario Gerard: Yeah. And then move more organically once they’re within the organization. That makes perfect sense.

And that my friend’s end of the first part of the podcast with Rhea. We have a full three-part series after this, where we are discussing how one would run a large program in a tech organization. So definitely check that out. That’s going to be a very, very unique episode. Thank you so much. I hope you enjoyed this. If you do, like it, share it with your friends, share it on LinkedIn and definitely leave us a review on your favorite podcasting app, thank you so much.

Check out the next episode here.