Exploring the Multifaceted Nature of Technical Program Management

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.