The Technical Program Management Podcast & Interviews

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,

Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the second series with Rhea, where we are talking about how you run L scale programs. If you haven't listened to part one of how you run large-scale programs, definitely check it out before you start this particular podcast, because this is a continuation of that. Hope you enjoy it. See you on the other side. Bye. One of the things to keep in mind when we design how we communicate in a log scale program. So, we spoke a lot about communication. But how do you design a communication plan for a large-scale program. Rhea Frondozo: So, you know, I think what it comes down to is making sure that you understand who you need to communicate with at what frequency at what level of communication, for what purpose and using what mechanism. So that's a lot of things I just said, right? But let's break that down. You're going to have a variety of different stakeholders who are going to need different levels of communication at different frequencies. So, if you, for example, are communicating with executives, you're going to need to be able to produce, you know, very concise executive summaries. Maybe it's going to be in a report or maybe it's going to be an executive status meeting, and it's going to be at whatever frequency that they feel that they need to be informed at, versus when you are actually managing the program with people who are say, POCs, the point of context, you're going to be wanting to have maybe status meetings where you're working through issues that they bring up. Maybe you're going to have a program tracking page where you're tracking the different, you know, initiatives that teams are working on. And you have a way that you can gather the variety of statuses that they bring to the table and risks that they bring to the table that you can discuss as a team. Or maybe there are people who just need to be informed, and they're not maybe working on the project, but maybe you want something like a newsletter where you're keeping people informed on a regular basis of what's happening with your program. Should they, you know, have an ask that comes to them later, they're not in the dark about why this is coming. So, there's definitely a lot of different potential for communication mechanisms, through emails, newsletters, status meetings, Wiki pages. It really just comes down to making an assessment of, like I said, who needs to know what, when and how do you deliver that. Mario Gerard: Yeah, I think it's a very complex, you know, we've tried to do it with some, some kind of confluence pages, which has the objective, the mission, the risks that we are going through right now and all the deliverables and milestones and the people who are responsible. So, it's kind of a table which shows who has what milestones hit when they're going to hit those milestones. Are they red, green, or yellow for those milestones? So, somebody can take a look at it at one view and see like, you know, where we are in those plans. And I think cadence is really important in all of these things. So, you have executor level meetings where you're just giving them status or you're sending it to them via email. Then you have different levels of meetings with different types of stakeholders across the board. So, it's kind of important for you to design that and to recalibrate it. Rhea Frondozo: Right, right. Mario Gerard: You have to recalibrate. Rhea Frondozo: Right. Cause I think one of the things to mention is that depending on what stage you are in a program, the frequency of communication to your stakeholders can change. In the beginning you may spend a lot of time talking to your executive sponsors or the leadership to try and get buy-in. And at that point, maybe you're, haven't even engaged with POCs yet, but once the project goes into execution mode, maybe you're working, you know, on a weekly or even biweekly basis with the POCs workin...

Mario Gerard: Hello, and welcome to the TPM podcast with your post Mario Gerard. This is going be a podcast with Rhea. Rhea and I worked together at OCI running large scale programs. We've split this into a three-part series, and we're primarily focusing on how we run large scale programs at tech organizations. So, stay tuned and listen in and definitely check out all the three parts to the series. And so, this is Rhea's co expertise, and this is what I’ve been doing as well for the last four years at the Oracle cloud infrastructure team. It's definitely a very unique type of a role, unique type of people who get involved in running large scale programs. And generally, there aren't many large-scale programs which are run within organizations, right? So, I'm going to ask Rhea some questions and I’ll probably add to that as well. So, the first primary question for our listeners Rhea, what is a large-scale program? How do you define a large-scale program? Rhea Frondozo: So typically, I'd say that a large-scale program is a program that spans multiple organizations. So, you’re looking at a program that maybe ranges from hundreds to thousands of developers or engineers, all working towards a very complex goal. Mario Gerard: Yeah. I just feel that that needs to kind of sink in, right? So, the programs they've run, like we've had to move like 200 teams, which takes two years. If you calculate the manpower that's required to do some of these initiatives. There are literally thousands or tens of thousands of manners of work. And so that's like so complex. Do you think about it? Rhea Frondozo: Yeah, I would say when you frame it that way, and you think about the complexity that comes with a large program, it may be the case that as a TPM, you're interacting with a core set of stakeholders. Maybe it's like 20 to 30 core stakeholders, but the multiplier under that for how many people that they are working with, how much direction that they are giving to an entire organization, it can be pretty mind blowing to know that you're trying to move a ship that has so many people all trying to row in the same direction. It's pretty incredible. Once you see the amount of effort that that takes. Mario Gerard: And this is I think, where we also differentiate depth TPMS versus breadth TPMS, you want to speak of little bit about that? Rhea Frondozo: Yeah. So, you know, as you mentioned, these large-scale programs are often run by a breadth TPM because these are going to be the TPMS who work across multiple organizations. They're going to have maybe pocs that point of context that they interact with across maybe functional different organizations and teams. Whereas a depth TPM, they're going to go deep in a particular organization or team scope of ownership. And so, they're going to maybe work more directly with the engineers on a single team and understand their problem space much more closely. Whereas the breadth TPM is going to rely on functional area owners to be the subject matter experts in that space. But they're the ones pulling these different functions together to solve a much larger, bigger picture problem. Mario Gerard: Yeah. And if you want to read more about the depth versus breadth TPMS, I’ve written a good blog post about it with my experience working at OCI. So, you should definitely go check that out. So, coming back to the skills required as a TPM, what do you think are the main skills that a TPM needs to have to run this kind of large-scale initiatives? Because I feel like the breadth TPMS definitely have a different type of problem that they're dealing with than a depth TPM, right? Rhea Frondozo: Yes. So, I would say first and foremost, when you're dealing with these large skill programs, a breath TPM absolutely must have excellent communication skills. They must be crisp. They must be clear. They must be concise. If you think about the levels of communication that are required for a breath TPM.

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...

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Priyanka Shinde. She has extensive experience as a TPM. She's worked as a TPM, a TPM manager, several organizations like cruise autonomous, Facebook and Meta. And she has over like 20 years of experience in the tech industry. She's also launched TPMify, which is a coaching and consulting organization with a mission to help TPMs and TPM organizations reach their goals faster. If you haven't checked out our blog www.TPMify.com, that's www.TPMify.com. You should definitely go check that out. It's got a lot of interesting content. She's been publishing a lot of great resources for TPMs. So do go and show some love. There aren't many TPM bloggers and people are contributing back into the community. So, the few of us who are there, I would love for all of you to go and show some love and check out her blog and all the other workshops she's trying to conduct. Priyanka and I are today going to try to discuss the various types of product manager technical and TPM product type of roles. I'm sure you've seen a lot of these roles coming up in job boards recently. And so, we're going to like try to decipher what the product manager technical role is and what the TPM product role is and how they kind of coexist. Welcome Priyanka, Welcome to the TM podcast. Could you give our listeners a quick introduction of what you've done, where you've been and your journey so far? Priyanka Shinde: Sure. Thank you, Mario, for having me on the podcast. It's great to be here. Yeah, and thank you for the introduction. Like Mario said, I have over 20 years of experience in the software tech industry across, you know, various type of technologies, AI, machine learning, AP tech, education tech. And so, it's been a really journey. I did start out as a software engineer and then transitioned to the TPM role because I really enjoyed kind of getting involved from like start to finish as well as just seeing kind of things come to life. And so that was my primary motivation of transitioning to TPM. And then once I became a TPM, I worked at startups. I worked at, you know, like big companies, like Facebook as well as companies like Cruise. And I really enjoyed kind of like the different aspects of what was being offered by these companies. But throughout these times, I kind of became more and more passionate about the TM role. So, you'll see me, that's why I write a lot. That's why I try to, you know, kind of really help back because I really feel very close to the TPM community. And I feel very passionate about building this strong TPM community because I truly feel that TPMS when leveraged correctly can make big impact on organizations. And I want TPMS to realize their own power, but I also want organizations to understand that that's my aspirational goal for us TPMS. What is TPM's role and why does the industry need a TPM? Mario Gerard: That's so well put, and you could probably do an entire podcast with Priyanka's journey of becoming a TPM because all of us have different journeys and different paths that we take it to get to where we are. So that's kind of a real interesting journey to, you know, maybe decipher one day. But okay. Let's start with, today's like first question to Priyanka. Like Priyanka what do you think the TPM role is like decipher that in your own words, like what the TPM role is and why does the industry need a TPM? Priyanka Shinde: Sure. Yeah. So, the TPM role or the technical program management role, I feel is a very special role in the sense that it has so much of that technical focus while leveraging your core program management skills and leadership skills. Sometimes I'd say, you know, TPMS drive holistic execution strategy by leveraging their deep domain expertise to basically meet the goals or deliver results, right? That's the end goal. And so, I feel like, you know,

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very interesting guest with us, David Glick. A lot of you might know him. He's been a mentor. He does a lot of linkedin posts and he's a cool person to follow, so do follow him.  He's worked at Amazon For 19 years and was a VP of Amazon fulfillment technologies. And then Amazon tickets. He left Amazon to go join as a CTO of flex. He has incredible, incredible experience in building high performing teams and building high performing organizations, some very excited to have today with us and share his thoughts.  Quick Links TPM Podcast With David Glick - Part II TPM Podcast With David Glick - Part III David, thank you for being here with us today. And why don't you introduce yourself to our audience? David Glick: Yeah. Hi, this is Dave click. Thanks for having me on Mario. You did a great job of introducing me, but I can say that most all of my career was at Amazon for almost 20 years. I've been at flex as CTO for the last three years. And so it's been a fun ride at both of those places and I'm sure we'll get into some of the things I did both at Amazon and flex. So I won't take too much time with that here. What flex is doing Mario Gerard: Do you wanna like quickly go over like what flex is doing and maybe do a pitch because I know you guys are hiring like crazy too. David Glick: So yeah. Flex is a marketplace which matches enterprise shippers. That's big retailers and brands with logistics capabilities or fulfillment capabilities. And we work with six of the top 10 retailers in the us and we are building our own WMS, building our own transportation network and so on.  And so we're always looking for TPMS engineers, product managers, basically everything. Mario Gerard: Everything, whole nine yards. Now that's amazing. Did you say four of the top 10 retailers? David Glick: Six of the top 10. Mario Gerard: Six of the top 10 retailers, you work with six of the top 10 retailers in managing their logistic process? David Glick: Yeah. Mario Gerard: That's something David Glick: My goal for 2022 has been to, i've been assigned to get the other four. Mario Gerard: That's incredible that being operational only for like a couple of years and you're able to do that, that says something about the product. So thank you so much for being here, David, to our listeners. What we are gonna do today is we're gonna split the podcast, kinda two sections. The first section, we're gonna talk about David and ask him what he thinks are the fundamentals of the TPM roles. We'll go about the, we'll asking questions about the role, the skillset, how to be a great TPM and those kinda things.  And then the second part, we're gonna ask him and we're gonna like work around the topic of how high level leaders like David, who VP of like a hundred or thousand people or several thousands of people. How do they get the right people working on the right set of problems? And that's what we're gonna focus on on the second part. So let's get started with kinda the first part here. So David, why don't you kinda give us your take on what would you describe as a TPM role and, and the function of the TPM role? David Glick: Yeah. Thank you. The number one thing that the TPM does is deliver. Like if you summed up the role in one word, it'll be delivery. And so their job is to get projects or programs over the line on schedule and under budget or at budget.  And so what does that mean? Have to be very detail oriented drive and your number one tool is the Gant chart, right? When are people going to get things done? What do they depend on, how much time is it going to take? And so you could stop there and say, that's the job of the TPM, but what I found, and I don't have a CS degree and Amazon talks about big T technical being someone who can write code and little T technical, being someone like me, who has led in technical places,