The Technical Program Management Podcast & Interviews

Mario Gerard

The Technical Program Management Podcast with Mario Gerard

  1. 07.03.2023

    TPM Podcast with Rhea – Episode II Part III

    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, the amount of work you are creating for yourself can double or triple, a quadruple, because now you have to update multiple code bases. You have to have different processes running for different regions. You have to hire different people to do all the different work across all these different regions. Mario Gerard: And this simply multiplies the complexity, every single team supposed, you have 200 different teams for 200 plus products. Every single team will need to operate in a different way, and you have one garment, then you other garment, then you have another garment. And so, your divergence level becomes increasingly astronomically high. And this is just not this particular problem Rhea, and I are talking about I’m, I'm talking about this. Whenever you have any kind of large-scale program, you need to keep in mind that you're not introducing too many divergent processes or tools or architect so that the teams don't have to carry that burden forward in having this different way they act for this particular type of problem. Rhea Frondozo: Cause what you're doing is trying to make sure that the products that you are creating are scalable. Mario Gerard: Yes, yes. This is what we always talk about. Is the process you're creating scalable?

    20 мин.
  2. 07.03.2023

    TPM Podcast with Rhea – Episode II Part II

    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 working through issues as they arise. Yeah. Sometimes you end up even in daily cadences, you know. People will have what we call war rooms. If there's a big problem at hand that, you know, you need all hands-on deck to work on. Maybe you're pulling in people on a daily basis, but you also don't want to have to keep everybody on a daily basis because you may do that unnecessarily and burn people out or you may finally solve the problem and not need that. And so, it's really important as the TPM to constantly evaluate what communication do you need reevaluate. Do you still need that and make adjustments accordingly depending on how the program's going? Mario Gerard: Yeah. That makes perfect sense. The next question I have is what are the type of blockers that one comes across when you're executing these kinds of large programs? Rhea Frondozo: So, there's a lot of different kind of blockers that you may run into, but I think that you can categorize them in a couple different ways. So, I think one really basic one that you often hear about are going to be scheduled delays, you know, for one reason or another, it could be somebody underestimated how long it was going to take to complete something. I mean, engineers and developers are notorious, I'd say for underestimating, how long it takes them to complete something. And as a program manager, you typically know that you should ask for confidence levels or understand, you know, what the associated risks are and include buffers. Nothing is ever as easy as we think it will be. And if you think something's going to be hard, it's probably even harder than you think. Other issues that can cause scheduled delays could be things that are out of your control, whether it's things like external dependencies that you're counting on, like supply chains, you know, expecting hardware deliveries at a certain time, or maybe you have creditors that you're expecting to get scheduled for looking at the products that you've built and assessing your clients. Other things I could call it, scheduling delays, or just maybe you thought that you knew a solution to a problem, and it turns out you were wrong, and you have to redo it. And that can cause a scheduling delay. So, there's a multitude of things that can cause scheduling delays. You know, other things that I’ve seen can be, you know, a misinterpretation of requirements. A lot of times you're trying to move fast and move in an agile approach for service delivery. But sometimes what you find out is the requirements that you thought that you were working against were actually wrong. And this is where it becomes important to fail fast and figuring out if you've done it wrong and redoing it can be another reason why your program is blocked, and you need to reset expectations on how to regroup on a program and come up with a solution that meets the expected requirements. Another one I think that I mentioned, you know, like I said, technical or architectural challenges, sometimes we make the wrong assumptions for how we were going to solve a problem. And these are things that when you're working on a problem, that's in a space that is unchartered territory. You may be trying things for the first time and realizing that your assumptions were wrong, and you've got to restart or redo it. Mario Gerard: And when you think about it as a scale at which we are operating, I think it becomes increasingly difficult. When you think about like the architectural solution that we came up with, which impacts I think like say 50 teams need to go do the particular thing, they go do it and then it doesn't actually work. Rhea Frondozo: Yeah. I mean, I actually have seen this happen at some of the most expensive levels I could have ever imagined where, you know, we built a whole cloud region and then realized we did it wrong and had to rebuild the entire region and that we couldn't salvage all the work that had been done yet to start from scratch. I mean, it happens, it's a very costly mistake, but you know, like I said, when you're an uncharted territory, sometimes you just don't know what you're up against. Mario Gerard: Other problems I can think about like one or two, which are like scope just keeps getting added to this particular large program. Because one people see, oh, these guys are running this large program and they kind of like hitch their wagon or say, hey, if you're doing that, you need to do this as well, but you probably don't need to do. And they kind of, as a TPM, you probably need to ensure that you're maintaining and managing the scope of a large program. Rhea Frondozo: Yeah. I mean, scope creep is real, right. A lot of times what you end up seeing is what you plan for and what you are resourced for is different than when you start executing, you know, people want you to deliver on. And so, you end up, you know, if you go beyond the scope of what you've been sized for, you end up resource constraint. And then this can cause a lot of different things in terms of scheduling delays, missed deliveries. And so yeah, scope creep is definitely something that a TPM has to keep their eye on. Mario Gerard: And in these kinds of large programs, I think it's increasingly, it comes back to that judgment, which we are mentioning, right? You have to be the person who's making that judgment call to figure out like, does this belong as part of this program or not? Is this 100% critical and crucial to be part of the delivery of this large-scale program? Other things are prioritization challenges. Like how you help like teams go back, them prioritize against other programs they're working on. Rhea Frondozo: Yeah. So, I'd say that one of the things that often comes up is you'll see that there's multiple competing business objectives that require the same resources, same teams, right? And so,

    31 мин.
  3. 07.03.2023

    TPM Podcast with Rhea – Episode II Part I

    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. A lot of times you're dealing with very complex programs that are being watched by the highest levels of executive leadership within an organization. So, you have to be able to communicate very crisply and concise to them. You also are going to be working across a lot of different problem spaces and having to work across many other leaders or engineers and being able to get to the point quickly of what you need to solve by when and how is also really important. And so, communication is definitely key to your success and running a large program. So next I would say is a long in the lines of communicating, but your ability to define a clear objective and scope a large program is going to be very, very complex. And if you don't have the right objective laid out for all of these people to follow, it's going to be very difficult to make sure that everybody's running in the right direction. And so being able to define a clear objective and scope ends up, you know, being like we said before, a good measurement of whether or not you're solving the right problem. Mario Gerard: And I think to add to that, right, I think why that's super important is every stakeholder who comes to your table, who's part of your large-scale program has a different function at times. You might have security, you might have operations, you might have 10 different teams providing 10 different pillars of software. So, everybody has a different output they're going to generate, right? And your problem definition, and your objective needs to be super clear because everybody's going to interpret it kind of differently from the functional perspective. And that's why you're going to keep re recreating and retelling your story. You are retelling your objective multiple different times, but the people are consuming it at translating into what they each need to do. Rhea Frondozo: Right, right. Great point. Mario Gerard: So, what are the other skills you think are kind of important? Rhea Frondozo: So, you know, I think another one that we had touched on earlier is just your ability to problem solve in an ambiguous or unfamiliar situation. When you have a large-scale program, a lot of times you don't know what's coming, you don't know what kind of problems you're going to run into. You can try to plan as much as you want, but there are so many variables that come with running a large-scale program that it's very difficult to predict what can go wrong. Mario Gerard: Or what problem you going to encounter tomorrow? You wouldn't even know that. Rhea Frondozo: Right. Right. And so, when it comes down to it, there's always going to be these curve balls that get thrown at you and you can prepare for as many that you think you may know, but it's hard to predict. And so, knowing how to deal in real time with a problem at hand is very, very important. Mario Gerard: So, we spoke with three skills, communication, the ability to define clear problems and scope and the problem-solving skill and the being able to deal with ambiguity. So why are these like so important in the large-scale program? Rhea Frondozo: So, if you can imagine being a TPM, it's like being the quarterback of your program, you you're the one calling the plays, which ultimately makes you the key player responsible for determining the success or the failure of the program. Mario Gerard: To recreate that, right? So, you are calling the shots most of the time. You are the person giving direction of what needs to be done, how they need to be done or what direction they need to take. So, [07:57 inaudible] program, which we run, right. There are so many decisions, a TPM who's running a breath program takes on a daily, if not a weekly basis. They might have to go and recheck that with somebody. But there's so many decisions, so many directions he, or she's giving them. Rhea Frondozo: Right. Right. A lot of times what happens is when you are in a breath TPM role, your job is to unblock issues that come up. So, you work on this plan, you come up with what you think is going to work. And then day after day, something goes wrong. And it's your job to figure out, how do you call an audible on what you should do instead, or what you should do differently or who you need to pull in. It's really your job to take the lead role in not only determining what needs to be accomplished and bringing all the people to do it, but also figuring out what happens when everything goes wrong, and it doesn't pan out as you expected. And so, the reality is if you aren't able to communicate crisply and clearly you can't leave the team by setting a clear objective and you can't help unblocking obstacles when you game plans are required. And if you can't do these, then chances are you won't be successful in running your program. Mario Gerard: Yeah. I think we have a question later on about this, but I was doing this, say that a lot of times, why things go wrong or why there's so much ambiguity and why there are new problem discount on a daily basis, or a weekly basis is because most of the times when, at least the program we run, right. They've never been done before. These are brand new initiatives, which are kind of game changing. Like no man has traveled down this road before. Nobody's gone there. So, it's like discovering space. You don't know what you're going to hit every day is an adventure. And you got to just take it as it comes, and you got to be able to deal with that. Rhea Frondozo: Right. So, a lot of times, you know, I think of it, like if you are, let's bring it back to the team analogy. If you're working on a project that you've never worked on before or a program that you've never seen before, it's like playing a team that you've never played. You haven't had a chance to scout out the challenges that they're going to bring you are, you haven't had a chance to see how they operate. And so instead you're learning as you go. And so, every day becomes a challenge.

    29 мин.
  4. 07.03.2023

    TPM: Running Large Scale Programs – Podcast with Rhea

    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,

    15 мин.
  5. 09.08.2022

    TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde

    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, the industry has moved on from like program management or, I mean, we still have program managers, but the TPM role, I feel came more into prominence over the last maybe couple of decades because of the technological advancements that we are seeing in the products, right. Products are becoming more complex. Now you have, you know, you don't have kind of like single screen things or website it's now, you know, like I can talk about autonomous [04:15 inaudible] all day long in terms of complexity, right? Yeah. And so, what that does is that you now, you know, you cannot just have coordination, facilitation, tasking, all of those are still important, but by having some of that technical expertise and domain knowledge, you actually elevate your program management skills. So that's why I feel like the TPMs kind of is a role that has kind of evolved as well as gain more prominence in the last couple of decades. What skills do you think TPMs require? Mario Gerard: Yeah. I'll add a little bit to that. Like the complexity of the programs have gone up so much and there's so many teams that own separate confidence and do any complex program. All these teams need to get really well and interact so much that the need for somebody to step in, it could be a TPM. It could be an engineering manager, it could be anybody with different titles, but the role they're trying to play is trying to bring these teams together to accomplish the final goal of the program. And that's where you've seen the technical program manager role kind of blossom the last decade as Priyanka said. What are the skills do you think TPMs require? Priyanka Shinde: Yeah, so of course, you know, we talk about technical, like the team TPM, largely, so you of course need the technical or the domain expertise. And that can be based on whatever background you have, or you can build on it, right. Or you can continue to like to evolve based on if you change domains. But besides the technical skills, you need strong program management skills, right. Something you just said, Mario, who is we have to be able to work with multiple teams. Like it's a highly cross-functional role. And so being able to kind of have all of these balls up in the air, knowing which team to go to for what, and like managing all of this, the ability to see big picture and look around corners like, that to me, is very, very important in the TPM role. Related read: Meta TPM Interview Guide Besides that, I think TPMS need to have really strong communication, both written and verbal, right? We are to be working with a lot of different teams. We work all the way from our peers, other teams, that partner teams, as well as leadership and executives. And so, we need to be able to communicate exactly what we are seeing in a way that kind of brings confidence, but also provides clarity to our audience. And finally, like we need leadership skills, right? TPMS are there, they're influencing without authority. We hear that, right. We are working again with multiple stakeholders. We have to build relationships. We have to motivate these teams. We have to manage the conflicts. Like there's so much of all these people skills involved here. And it is a core part of this TPM role as well. So, I say those are the core things in terms of skills. Communicating at different levels within the organization - What does a product manager do? Mario Gerard: Yeah. Yeah. Definitely, communication is so important. Like we talk a lot about communication, but at the same time, unless you are a TPM and you've been in a role like that, you don't understand the value of communication, how succinct you need to be sometimes. How you need to communicate at different levels within the organization, as you just mentioned, and the leadership skill, I think you called it a few, right? Like influencing with that authority is so important. Building relationships is so important. Motivating teams, as Priyanka said, super important when you don't have a team reporting to you, especially, right. This is completely like influencing without authority. And it's so key, if you think about TPM skills. Let's switch gears and move to the product manager role, because we're going to be talking a lot about the TPM product and the product manager technical role. What does a product manager do and what is, his or her role? Priyanka Shinde: Yeah. So, you know, sometimes there's so many ways to define what the product manager role. And of course, we have a product manager here. They might say something. So, I'm going to kind of try and frame it the best I can without, I mean, I did kind of played a part product part program manager role at one point. But you know, of course in a lot of times when, even from a TPM perspective, we say, oh, product managers mainly define what, right? They are identifying significant opportunities. They're driving product vision, strategies, roadmaps in the context of like the broader organizational strategy and goal. They, of course, you know, in corporate data, research, market analysis to inform their product requirements and the priorities that they want to make. And of course, in all of this, you know, they're defining requirements, they do this in collaboration, of course, with research, design, engineering TPM. And so, you know, sometimes even in small teams or startups product manager may do their own research, right. Or build their own wire frames or even like execute. This is where we start seeing overlap in responsibilities. But kind of that's how I think about it is like PMs are defining the what in a nutshell, and then the TPMS do when and the how a little bit. So that's kind of my take on the product manager responsibility.  What do you think are the skill sets, the PMs possess? Mario Gerard: Yeah. We also, I think from a product perspective, they also probably do a little bit of the why, like what and why, right. It kind of goes hand in hand of doing like, why are we doing this,

    42 мин.
  6. 01.05.2022

    TPM Podcast With David Glick – Part I

    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, but can't write code.  Anyway, What I always found is that if I was a little more technical, I would be more effective. And I guess if I was a lot more technical, what would be a lot more effective, but the point being, being able to understand deeply the trade offs, both in technology, as well as in your domain makes folks much more effective tpms.  And so you own the schedule, you own the resources, or you don't actually own the resources, but you control the resources that you don't own. And then you have to be good at making trade offs and getting people to commit. Large Scale Project - Managing heavy dependencies and resource management Mario Gerard: That's an interesting take. I also like about when you spoke about G charts. That's a very interesting take because though we work in tech, it's interesting that a lot of large scale tech projects are actually managed, though They worked at an agile level, right? Like teams are working independently, they are managed at a milestone level.  And I think it's kind of forgotten sometimes that large scale projects we do use Gant charts. We do use Microsoft project to something very similar it to that Smartsheet or something like that, where we manage these heavy dependencies and resource management, right? David Glick: Yeah. And I was working on a project for, at Amazon around pricing and we were working with a subsidiary team and they were in San Francisco. This was before everybody was remote, but they were in San Francisco. We were in Seattle and we weren't getting the progress we wanted from them. And so my boss said, okay, let's get on a plane. We flew down to San Francisco and we sat with them all day. And we like went through all the stories and the sticky sheets and all the things you do for agile.  And at the end of the day, I said, great. When can you deliver? And the guy said, well, many software development professionals today think it's not necessary to have delivery dates cause it's not effective. And I was like, look, I'm about to fly back to reality. And there's an angry guy with an SVP on his t-shirt who's gonna yell at me if I don't have dates. And so it is fine and dandy to have this agile.  And by the way, i've run agile teams. And I think it's actually the right way. But You have to have some high level understanding because if you've got teams, you know, dozens of people or hundreds of people working together on a project, it all has to come together at the end. Mario Gerard: And there's no way to do it rather than go old school tradit and use Gant chars and use Microsoft project or something. Some kinda similar type of a tool, which gives you that level of granularity and tracking because otherwise you're not gonna be successful, especially if you're running these large scale projects.  David Glick: One of my colleagues and friends from early days of Amazon, we didn't use Gant charts. We used, he just used Excel. And in the end, like a project or a TPMS job is to get a set of action items and then action items defined as sort of a description, an owner and a date, get a set of those and probably a dependency, get a set of those written down with owners and dates and that will allow you to March forward.  And so he would just come in and say, what are the five most important milestones on this project? Yeah. And you know, who's the owner and when's it gonna be due. And if we couldn't get a date, we got a date for a date.  Mario Gerard: Yeah. And that's just the simplest way to take things forward. It doesn't need to be fancy. Doesn't need to be too complicated, especially if you are working with teams and you can just work off Excel. That means your teams are ideally meeting those targets. And as long as they're meeting those targets, you don't need to do it too much of over-engineering in creating the project plan.  If they're unable to meet the milestones of this slipping or those kind of things, I think the TPM probably needs to get a little more involved there and help out more.  David Glick: Yeah. And I would say what you wanna do is front load all your dependencies. And so, because the thing that kills projects are not, it's not hardware and it's not software. There was a book called Peopleware. Which is working together and communicating with each other is the things that kills projects or not working together and not communicating. And so if you have one team who has a little bit of work to create an API, to unlock other teams. They should do that work first, even if it's a stub that returns assertions or returns dummy variables, at least you can know it's working and the other team can be unlocked and move forward. Computer Science Degree - Being technical? Mario Gerard: Absolutely. David, you spoke about, you know, big T and the little T, you also spoke about that you are, you don't have a computer science degree, but you are the CTO. You've been a VP for a very long time at Amazon leading one of the big technology, you know, development teams, both at AFT and Amazon tickets. And you're a CTO now, like how do you say that? Or why do you say humbly that you're not very technical? David Glick: Well, I got my CS degree from the school of hard knocks at Amazon. I got the Amazon MBA, the Amazon CS degree and so on. But basically what I, the way I sort of upscaled my game was I got CC'd or called into every Sev 1 that we had in the fulfillment centers for like many years in the early days of Amazon. And I read all the Sev 2 tickets.  And so I could see what breaks and what makes a bad system and what makes a good system. But then in 2004, I had worked as a, I was actually called a PM, not a TPM, but I worked my first couple years as a PM, then a manager and systems and networking. And then I did deployment and QA and sort of all the things that aren't software development. And in 2004, I went to work for a woman named Kim Racmiller, who was sort of the first TPM at Amazon.

    26 мин.
4,8
из 5
Оценок: 41

Об этом подкасте

The Technical Program Management Podcast with Mario Gerard

Вам может также понравиться