Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part three, the final part of how to run a large-scale program. Our conversation with Rhea, if you have in third part one and two, definitely check that out before you go ahead and listen to this part. I hope you enjoy it. Continue listening.

Talking about that trend. What are the most common pitfalls you see people make, or, or people need to watch out for?

Rhea Frondozo: So, as a breath TPM, one of the things that I know that has happened to not only me, but the TPMS that I manage is when you work on a large-scale program, you’re working with a lot of different functional area owners, and it’s your job to hold them accountable for getting their work done.

But a lot of times when you come in as the TPM and you come in as such a strong lead, they want to be able to rely on you instead to get the work done and for you to solve their problem. The issue with this is when you’re at breath TPM, you have so many different areas that you are managing, that if you were to do the work for everyone, instead of holding them accountable, ultimately you will fail.

And so, it’s really important as a breath TPM, to make sure that you understand your scope, your responsibility, your accountability, and figure out who it is that you need to rely on to do what work and hold them to that.

Mario Gerard: Yeah. And sometimes you don’t have the right people, what I’ve done in those kind of situations and say, Hey, talk to your senior leadership within your organization, and if you want, I will recommend somebody within that larger organization who I think can go ahead and do this for you, but you don’t step in and help fix somebody else’s problem, because then it becomes your problem. And then they kind of walk away.

So, you want your pocs or your functional area owners to kind of own their space and to work on the problem and then get back to you on the milestones on how they’re doing on it rather than you are running those smaller programs.

Rhea Frondozo: Right. And this is where that judgment call is really necessary. Like how much you step in to help them get them on the right track versus you continue ensuring that they keep on track versus you doing it yourself.

Mario Gerard: And where you step into help sometimes. Because sometimes they don’t have a very strong lead and then you might go in to reactivate that program or put it on the right track and then ensure that you’re monitoring it to some degree, but you’re not actually going and doing all the work.

Rhea Frondozo: And this is where trying to figure out kind of that line between how much you go in and try and help yourself versus how much you invest instead in making an escalation to leadership to ask for the help that you need.

And so again, this comes down to a judgment call of where you spend your time as a TPM to make sure that your program as a whole is successful.

Mario Gerard: Yeah. I think, I think one of the key things which I’ve learned, I am working at OCI was to always reevaluate where I’m spending my time. This is on literally on a daily basis or on a weekly basis. Like where am I spending most of my time? And is it the right place I’m spending that time, is this what I’m required to do? And is this for the necessity of the program? And is it good at help the long-term success of the program?

Rhea Frondozo: Right. Because I think goes to a second point to make about a potential pit fall that a breath TPM may have. It’s knowing when, when to rely on an SME versus is doing something yourself. Right? So it’s important to, for us as TPMS to understand a problem at hand, but knowing how deep do you need to go in that problem and how deep you need to go in the solution versus making sure that you’re pulling in the right people to do it, or just being the person that vets, are we solving it in the right way or solving the right problem.

Because at the end of the day, it’s not your job to be the SME, but it is your job to know when to utilize the SMEs for their experience and how to gut check them, to make sure that what they are delivering actually meets the business need.

Mario Gerard: Yeah. And sometimes these SMEs, like they over-engineer things, or they will complicate things, right. You’re laughing and I’m laughing. Cause we’ve been through this situation so many times. And we bring in an SME, who’s so focused in the area. They know it’s so well that they sometimes really, really over-engineer and overcomplicate things.

Rhea Frondozo: Not only that lot of times, what will happen is these goes to this, the thing that you mentioned earlier about scope creep, maybe there’s this problem that you recognize impacts to your program, and you need them to solve it. Oh, but this has been a pain point for them for the last, how many years. And now this is their chance to get buy-in to make this awesome solution that will fix everything for the problem that they have, which is only a portion of the problem that you have.

Mario Gerard: You need, you need them to solve X, but they need to solve X in hundred. That that’s their biggest customer problem, which they’re trying to solve, but they haven’t gotten an executive buying for that, but they wanted to stack it on.

Rhea Frondozo: Right. They want to, I’ve seen the, has happened multiple times where essentially, they it’s like they want to ride your coattails. Oh, you have a priority for working on this thing. Oh, that means I can get the priority for working on this whole entire thing. Because it’s associated with your program. Yeah. Which again, this ends up becoming scope creep. That ends up being a lot bigger than you really need.

Mario Gerard: Yeah. Yeah. So, it’s very interesting, like two common pitfalls. Why don’t you talk about like one of the programs, which you worked on Rhea and kind of like walk us through like the complexity, the, the objective and how you went through that.

Rhea Frondozo: Sure. Yeah. So, I’d say that the biggest and most complex program that I’ve ever owned was running the global government sector program for OCI. And this encompassed a suite of cloud regions, services, features, and processes that were needed to meet our government customer expectations.

Mario Gerard: So, it’s all like a new product.

Rhea Frondozo: It’s actually a set of products.

Mario Gerard: It’s a set of products that enable a particular government to run on our own infrastructure.

Rhea Frondozo: Right. And the reason why it’s a set of products is because you know, for governments, you’re not only looking at running on public cloud or public workloads, but they have different levels of classification. So, we had unclassified levels of workloads that they may want to run. Or you also had classified levels that are running at top secret or secret levels that require much more engineering to secure the workloads that they need to run.

Mario Gerard: And when you talk about engineering, just to elaborate a little bit, it more is physical infrastructure needs to be re-engineered people need to be re-engineered because they have certain level of clearance, the way they operate on the cloud differs the software running on the cloud differs. So literally every single thing has to be re-engineered meet this product need.

Rhea Frondozo: Right. And so, you know, the way that we had to think about it is what is the lowest common denominator, right? So how do we make sure that we have the highest level of security in a product and making sure that we run it everywhere that way so that we try to minimize that divergence.

But it did mean that we had to reengineer the products, not just for the government customers that we had or the government regions that we had, but all the way through the entire stack, down to the public versions of it, because we wanted to be able to minimize the divergence of software.

Mario Gerard: This is a very, very interesting point that we didn’t speak about this whole podcast. On all the pro we worked on, we try to intro divergence is limited. And especially when you’re working in an organization at the scale at which we worked in like several thousand people strong, right. Divergence is a very important thing that we try to avoid. Tell me, why is it so important? What is divergence for maybe for our listeners? Can you give an example of divergence? What do you mean by divergence?

Rhea Frondozo: So, you know, by divergence, I mean really the code that’s running in any… Or the way that you are operating these regions is important that we do it the same across all regions. Otherwise