Episodios

  • TPM Podcast with Rhea – Episode II Part III

    TPM Podcast with Rhea – Episode II Part III
    Mar 7 2023
    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,
    Más Menos
    20 m
  • TPM Podcast with Rhea – Episode II Part II

    TPM Podcast with Rhea – Episode II Part II
    Mar 7 2023
    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...
    Más Menos
    31 m
  • TPM Podcast with Rhea – Episode II Part I

    TPM Podcast with Rhea – Episode II Part I
    Mar 7 2023
    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.
    Más Menos
    29 m
  • TPM: Running Large Scale Programs – Podcast with Rhea

    TPM: Running Large Scale Programs – Podcast with Rhea
    Mar 7 2023
    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...
    Más Menos
    15 m
  • TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde

    TPM & PM At Meta/Facebook - Podcast w/ Priyanka Shinde
    Aug 9 2022
    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,
    Más Menos
    42 m
  • TPM Podcast With David Glick – Part I

    TPM Podcast With David Glick – Part I
    May 1 2022
    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,
    Más Menos
    26 m
  • TPM Podcast With David Glick – Part II

    TPM Podcast With David Glick – Part II
    May 1 2022
    Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the three part series with David Glick. If you haven't listened to part one, definitely go and listen to that. I hope you enjoy this. Another question I had for you, David is TPMs Generally don't have people reporting to them, right? So they always have to influence without authority. What would be your key guidance on building this skillset or give like a playbook for us? How do you influence without authority? David Glick: A lot of that comes from the organization as much as from the TPM, you know, I’ve led projects and call it PM or TPM or director or VP or whatever. I've led projects, where everybody was aligned. You know, Jeff Bezos is like, this is the most important thing. And Dave Clark and Jeff Wilke, those are very easy projects to TPM. Mario Gerard: When you have that executive backing David Glick: Yeah. And you can influence without authority. And then if this is a project that some junior person came up with and asked you, Hey, go do this thing. That's much less fun and it's harder to influence without authority. So one way to do it is by picking the right projects because everybody's bought into those and maybe that's delegated authority or sort of reference authority. Mario Gerard: I completely what you're saying, I see that you are riding on somebody else's authority or you're riding on a combined single vision. The organizational vision. David Glick: Yeah. And in getting the way to influence without authority is too early on get agreement and buy in from all the people you need. Again, that's easy if it's tap down mandate to some extent, but bottoms up mandates are better broadly. If everybody, all the engineers are bought in and excited about building something from nothing or building this new feature or growing the revenue or all those things. And so I think it's a skill to get people excited and get them bought in before you ever start writing code. Responsibility - Product manages / TPM / Dev Manager Mario Gerard: And the skill to being brought in and get excited is definitely like a very valuable skill we need to have in today's environment. Is that more of a product manager's responsibility you'd think? Or is it like a TPM responsibility or is it a dev managers responsibility? David Glick: The answer is always all, all the above, but most of my time at Amazon, we didn't have product managers. Mario Gerard: Oh, really? Back in the day, just because it was like AFT and tickets. You were like very young organizations. David Glick: Yeah. I mean all the way back to pricing, you know, I led the pricing team in 2005 and 2006, 2007, I think. And there was no product manager. Jeff B was kind of the product manager. He told us what to do, but like I was the person who operationalized what we were going to do from the product. Mario Gerard: That's so interesting. David Glick: And this was the idea that two pizza teams. Is you don't need a separate organization of product. And we did that for a long time and it was sort of the [03:00 inaudible], the glory days of development, because you didn't have multiple organizations making decisions together. You had your subject matter expert or customer who was asking you to do something. And then as the dev leader, I was doing that for them. And so in many ways that was great. But we also built a lot of crappy software back then, you know, poor usability, didn't take into account edge cases, all those things, because we didn't have the skill of the product manager. Many of my friends tell me, oh, you hate product managers, which is not true. But I do remember when we introduced product managers and that was around the time we started building devices, like Kindle hardware is much harder to build than software. Mario Gerard: And once it goes out into the world, there is nothing you can do about it. David Glick: Yeah. And so product managers came in and said,
    Más Menos
    29 m
  • TPM Podcast With David Glick – Part III

    TPM Podcast With David Glick – Part III
    May 1 2022
    Mario Gerard: Welcome to the TPM podcast with your host Marion Gerard. This is part three of the three part series with David Glick. If you start here, I would definitely recommend going and listening to part one and two. How do you ensure that information flows to you and other leaders within the organization? Yeah, well said. The other the question I had David was when you're running these larger organizations, 300 is fairly large, 3000 at Amazon, which we're early talking about that's also fairly large, right? Extremely large. How do you ensure that information flows to you and other leaders within the organization? How do you ensure that you kind of get a sense of where are my resources utilized? How are my programs running? What's the health of my team. Like you want to know so many things. And how do you ensure that kind of information flows to you and other leaders with the organization? David Glick: This one's very hard for me. When I was growing up. When I was originally at TPM in like 1999, my skip skip skip level was Charlie Bell. He was the VP. He's pretty famous Now, he was the number two at AWS. He just went to Microsoft, but he would get all the managers and TPMs in a room. And at the time it was about 20 people in his organization. And he'd have a project list, which was managed by the manager of projects, manager of TPM or whatever. We'd go through red, yellow, and green, and he'd ask questions and we'd sit there for like two hours. And these things always expand in the number of people, the amount of time you spend. And over time, it became sort of normal for everybody to sit there and type on their laptops while the meeting was going on. And so you'd have this background noise of keys chattering, and Charlie was really good at it. And he could hold the attention to the room. I was just never good at it. And so it was like pulling teeth for me and everybody else who was there, hated it because they had to be there. And they'd talk about their one project. And then they'd sit there for another hour and a half. Mario Gerard: It's an expensive meeting. David Glick: It's a very expensive meeting. AWS is famous. They scaled that up to operational review meeting of three hours every week, which Charlie ran. And what I found is the bigger the meeting, the bigger a leader you need. And Charlie was the biggest leader I know after Jeff Wilkey and Jeff Bezos. So maybe Dave Clark. And so he was able to keep the attention in the room and he would teach. And so it was expensive, but it was valuable for everybody to learn from the lessons of others and learn from Charlie's wisdom. I was never as good at that as others. And I never liked to have this idea of a central PMO, because what it meant was every time it was a big project, someone would come to me and ask me to sign a TPM or a PM or someone to the project. So then it put more stuff on my desk. You always had a limited number of these TPMS. And so I had spent all my time doing resource management rather than focus on people. I don't know what the right answer is. The best thing I'd found is like status reports. I think two things. One is written status reports that go out every Friday. This was again, Kim McMillen was my old boss. Who's best TPM ever. She would say, if you only report the news, when it's good news or bad news, then people see it as good news or bad news. You need to report the news every week. And then it's just news. This thing slipped or this thing launched or whatever, you want to have a cadence of, I'm getting my news today, every Friday or every Monday, I get my news. Mario Gerard: And that's across the entire organization. It's an organizational standard that every Friday news is going to come out and probably news is going to be available at this. Or there's a posted place where everybody's updating within certain guidelines of how it needs to be updated. And what's captured. Emails - the highlights and the lowlights
    Más Menos
    19 m