The Technical Program Management Podcast is for TPMs and aspiring TPMs to learn and know all the latest techniques, skills and trends in the TPM space.
Seattle, Washington
Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part three, the final part of how to run a large-scale program. Our conversation with Rhea, if you have in third part one and two, definitely check that out before you go ahead and listen to this part. I hope you enjoy it. Continue listening. Talking about that trend. What are the most common pitfalls you see people make, or, or people need to watch out for? Rhea Frondozo: So, as a breath TPM, one of the things that I know that has happened to not only me, but the TPMS that I manage is when you work on a large-scale program, you're working with a lot of different functional area owners, and it's your job to hold them accountable for getting their work done. But a lot of times when you come in as the TPM and you come in as such a strong lead, they want to be able to rely on you instead to get the work done and for you to solve their problem. The issue with this is when you're at breath TPM, you have so many different areas that you are managing, that if you were to do the work for everyone, instead of holding them accountable, ultimately you will fail. And so, it's really important as a breath TPM, to make sure that you understand your scope, your responsibility, your accountability, and figure out who it is that you need to rely on to do what work and hold them to that. Mario Gerard: Yeah. And sometimes you don't have the right people, what I've done in those kind of situations and say, Hey, talk to your senior leadership within your organization, and if you want, I will recommend somebody within that larger organization who I think can go ahead and do this for you, but you don't step in and help fix somebody else's problem, because then it becomes your problem. And then they kind of walk away. So, you want your pocs or your functional area owners to kind of own their space and to work on the problem and then get back to you on the milestones on how they're doing on it rather than you are running those smaller programs. Rhea Frondozo: Right. And this is where that judgment call is really necessary. Like how much you step in to help them get them on the right track versus you continue ensuring that they keep on track versus you doing it yourself. Mario Gerard: And where you step into help sometimes. Because sometimes they don't have a very strong lead and then you might go in to reactivate that program or put it on the right track and then ensure that you're monitoring it to some degree, but you're not actually going and doing all the work. Rhea Frondozo: And this is where trying to figure out kind of that line between how much you go in and try and help yourself versus how much you invest instead in making an escalation to leadership to ask for the help that you need. And so again, this comes down to a judgment call of where you spend your time as a TPM to make sure that your program as a whole is successful. Mario Gerard: Yeah. I think, I think one of the key things which I've learned, I am working at OCI was to always reevaluate where I'm spending my time. This is on literally on a daily basis or on a weekly basis. Like where am I spending most of my time? And is it the right place I'm spending that time, is this what I'm required to do? And is this for the necessity of the program? And is it good at help the long-term success of the program? Rhea Frondozo: Right. Because I think goes to a second point to make about a potential pit fall that a breath TPM may have. It's knowing when, when to rely on an SME versus is doing something yourself. Right? So it's important to, for us as TPMS to understand a problem at hand, but knowing how deep do you need to go in that problem and how deep you need to go in the solution versus making sure that you're pulling in the right people to do it, or just being the person that vets, are we solving it in the right way or solving the right problem. Because at the end of the day,
Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the second series with Rhea, where we are talking about how you run L scale programs. If you haven't listened to part one of how you run large scale programs, definitely check it out before you start this particular podcast, because this is a continuation of that. Hope you enjoy it. See you on the other side. Bye. One of the things to keep in mind when we design how we communicate in a log scale program. So, we spoke a lot about communication. But how do you design a communication plan for a large-scale program. Rhea Frondozo: So, you know, I think what it comes down to is making sure that you understand who you need to communicate with at what frequency at what level of communication, for what purpose and using what mechanism. So that's a lot of things I just said, right? But let's break that down. You're going to have a variety of different stakeholders who are going to need different levels of communication at different frequencies. So, if you, for example, are communicating with executives, you're going to need to be able to produce, you know, very concise executive summaries. Maybe it's going to be in a report or maybe it's going to be an executive status meeting, and it's going to be at whatever frequency that they feel that they need to be informed at, versus when you are actually managing the program with people who are say, POCs, the point of context, you're going to be wanting to have maybe status meetings where you're working through issues that they bring up. Maybe you're going to have a program tracking page where you're tracking the different, you know, initiatives that teams are working on. And you have a way that you can gather the variety of statuses that they bring to the table and risks that they bring to the table that you can discuss as a team. Or maybe there are people who just need to be informed, and they're not maybe working on the project, but maybe you want something like a newsletter where you're keeping people informed on a regular basis of what's happening with your program. Should they, you know, have an ask that comes to them later, they're not in the dark about why this is coming. So, there's definitely a lot of different potential for communication mechanisms, through emails, newsletters, status meetings, Wiki pages. It really just comes down to making an assessment of, like I said, who needs to know what, when and how do you deliver that. Mario Gerard: Yeah, I think it's a very complex, you know, we've tried to do it with some, some kind of confluence pages, which has the objective, the mission, the risks that we are going through right now and all the deliverables and milestones and the people who are responsible. So, it's kind of a table which shows who has what milestones hit when they're going to hit those milestones. Are they red, green, or yellow for those milestones? So, somebody can take a look at it at one view and see like, you know, where we are in those plans. And I think cadence is really important in all of these things. So, you have executor level meetings where you're just giving them status or you're sending it to them via email. Then you have different levels of meetings with different types of stakeholders across the board. So, it's kind of important for you to design that and to recalibrate it. Rhea Frondozo: Right, right. Mario Gerard: You have to recalibrate. Rhea Frondozo: Right. Cause I think one of the things to mention is that depending on what stage you are in a program, the frequency of communication to your stakeholders can change. In the beginning you may spend a lot of time talking to your executive sponsors or the leadership to try and get buy-in. And at that point, maybe you're, haven't even engaged with POCs yet, but once the project goes into execution mode, maybe you're working, you know, on a weekly or even biweekly basis with the POCs workin...
Mario Gerard: Hello, and welcome to the TPM podcast with your post Mario Gerard. This is going be a podcast with Rhea. Rhea and I worked together at OCI running large scale programs. We've split this into a three-part series, and we're primarily focusing on how we run large scale programs at tech organizations. So, stay tuned and listen in and definitely check out all the three parts to the series. And so, this is Rhea's co expertise, and this is what I've been doing as well for the last four years at the Oracle cloud infrastructure team. It's definitely a very unique type of a role, unique type of people who get involved in running large scale programs. And generally, there aren't many large-scale programs which are run within organizations, right? So, I'm going to ask Rhea some questions and I'll probably add to that as well. So, the first primary question for our listeners Rhea, what is a large-scale program? How do you define a large-scale program? Rhea Frondozo: So typically, I'd say that a large-scale program is a program that spans multiple organizations. So, you're looking at a program that maybe ranges from hundreds to thousands of developers or engineers, all working towards a very complex goal. Mario Gerard: Yeah. I just feel that that needs to kind of sink in, right? So, the programs they've run, like we've had to move like 200 teams, which takes two years. If you calculate the manpower that's required to do some of these initiatives. There are literally thousands or tens of thousands of manners of work. And so that's like so complex. Do you think about it? Rhea Frondozo: Yeah, I would say when you frame it that way, and you think about the complexity that comes with a large program, it may be the case that as a TPM, you're interacting with a core set of stakeholders. Maybe it's like 20 to 30 core stakeholders, but the multiplier under that for how many people that they are working with, how much direction that they are giving to an entire organization, it can be pretty mind blowing to know that you're trying to move a ship that has so many people all trying to row in the same direction. It's pretty incredible. Once you see the amount of effort that that takes. Mario Gerard: And this is I think, where we also differentiate depth TPMS versus breadth TPMS, you want to speak of little bit about that? Rhea Frondozo: Yeah. So, you know, as you mentioned, these large-scale programs are often run by a breadth TPM because these are going to be the TPMS who work across multiple organizations. They're going to have maybe pocs that point of context that they interact with across maybe functional different organizations and teams. Whereas a depth TPM, they're going to go deep in a particular organization or team scope of ownership. And so, they're going to maybe work more directly with the engineers on a single team and understand their problem space much more closely. Whereas the breadth TPM is going to rely on functional area owners to be the subject matter experts in that space. But they're the ones pulling these different functions together to solve a much larger, bigger picture problem. Mario Gerard: Yeah. And if you want to read more about the depth versus breadth TPMS, I've written a good blog post about it with my experience working at OCI. So, you should definitely go check that out. So, coming back to the skills required as a TPM, what do you think are the main skills that a TPM needs to have to run this kind of large-scale initiatives? Because I feel like the breadth TPMS definitely have a different type of problem that they're dealing with than a depth TPM, right? Rhea Frondozo: Yes. So, I would say first and foremost, when you're dealing with these large skill programs, a breath TPM absolutely must have excellent communication skills. They must be crisp. They must be clear. They must be concise. If you think about the levels of communication that are required for a breath TPM.
Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Rhea Frondozo. She and I have worked together at Oracle cloud infrastructure team OCI. Rhea has been a tech industry for the last 20 years. She's worked at IBM for eight years, Microsoft for fours, EMC square. And then at OCI for six years, she's had a variety of different roles as well. She's been a developer, a program manager, a test manager, engineering manager, a director of TPM, and right now, is working at Salesforce as a senior director of TPMS. Her specialty is to run large scheme programs. Rhea, thank you for joining us today. And why don't you introduce yourself to our audience to our audience? Rhea Frondozo: Thanks Mario. As you mentioned, I have had a 20-year run in the tech industry working for several of the top tech companies in a variety of different roles. But what I found is that I've always been most interested in working on large scale complex programs and products after trying out so many different roles at different companies. What I now know is that my passion tends to be working on projects that aren't so much consumer facing in terms of features or products or services, but more on, so solving enterprise level infrastructure challenges. I find that the problem solving I enjoy most applies to cross-functional technical challenges that typically span multiple products, services, or even processes. Mario Gerard: Fantastic. Rhea and I actually have worked together at OCI. As I mentioned, we've been on the same team I've reported to Rhea where it was so much fun. We've actually solved so many large-scale programs or problems, which turned in programs and I've learned so much from her. So, I think this is going to be a very interesting podcast. So how we have designed today's podcast is the first section. We are going to just go over some very fundamental TPM questions with Rhea. And the second half of the podcast, we're going to go very much into the details of how you've run a large-scale program. So, let's start with the first section, right? So, Rhea, how would you describe the TPM function? Rhea Frondozo: So, the TPM function I have to say is not a very easy one to describe because it typically is something that varies from company to company and organization, to organization, team, to team. It's a newer function I think that has a blended role within many organizations. So, if you can imagine at the base, you have the project management or program management responsibilities, then you apply that to some kind of technical project, program process that needs to be solved for. And so, it also can vary tremendously depending on seniority level. And so, the scale at which you operate can be very small and narrow, more depth focused If you are a depth TPM, or it can be very large and crosscutting across entire organizations or entire companies, if you're looking more at the breadth TPM role. Mario Gerard: And what would you say are the core skills TPM should generally have? Rhea Frondozo: So, at the most basic, you know, skill that I would expect TPMS to have been first and foremost, project management skills. These are just your basic project management skills around being able to define scope, a problem space, understand business impact, being able to identify key stakeholders and goals that you want to solve for as well as, you know, creating schedules and tracking execution. But outside of just your project management basic skills, the expectation would be that you have to have very solid communication skills. The ability to communicate both up down and laterally, whether it's your having conversations with Lee leadership, having conversations with team members, who you are giving direction to, or maybe peers or TPMS that you are trying to get to work on your project, who are maybe peers. Outside of communication Some other soft skills that I think are important are...
Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us, Priyanka Shinde. She has extensive experience as a TPM. She's worked as a TPM, a TPM manager, several organizations like cruise autonomous, Facebook and Meta. And she has over like 20 years of experience in the tech industry. She's also launched TPMify, which is a coaching and consulting organization with a mission to help TPMs and TPM organizations reach their goals faster. If you haven't checked out our blog www.TPMify.com, that's www.TPMify.com. You should definitely go check that out. It's got a lot of interesting content. She's been publishing a lot of great resources for TPMs. So do go and show some love. There aren't many TPM bloggers and people are contributing back into the community. So, the few of us who are there, I would love for all of you to go and show some love and check out her blog and all the other workshops she's trying to conduct. Priyanka and I are today going to try to discuss the various types of product manager technical and TPM product type of roles. I'm sure you've seen a lot of these roles coming up in job boards recently. And so, we're going to like try to decipher what the product manager technical role is and what the TPM product role is and how they kind of coexist. Welcome Priyanka, Welcome to the TM podcast. Could you give our listeners a quick introduction of what you've done, where you've been and your journey so far? Priyanka Shinde: Sure. Thank you, Mario, for having me on the podcast. It's great to be here. Yeah, and thank you for the introduction. Like Mario said, I have over 20 years of experience in the software tech industry across, you know, various type of technologies, AI, machine learning, AP tech, education tech. And so, it's been a really journey. I did start out as a software engineer and then transitioned to the TPM role because I really enjoyed kind of getting involved from like start to finish as well as just seeing kind of things come to life. And so that was my primary motivation of transitioning to TPM. And then once I became a TPM, I worked at startups. I worked at, you know, like big companies, like Facebook as well as companies like Cruise. And I really enjoyed kind of like the different aspects of what was being offered by these companies. But throughout these times, I kind of became more and more passionate about the TM role. So, you'll see me, that's why I write a lot. That's why I try to, you know, kind of really help back because I really feel very close to the TPM community. And I feel very passionate about building this strong TPM community because I truly feel that TPMS when leveraged correctly can make big impact on organizations. And I want TPMS to realize their own power, but I also want organizations to understand that that's my aspirational goal for us TPMS. What is TPM's role and why does the industry need a TPM? Mario Gerard: That's so well put, and you could probably do an entire podcast with Priyanka's journey of becoming a TPM because all of us have different journeys and different paths that we take it to get to where we are. So that's kind of a real interesting journey to, you know, maybe decipher one day. But okay. Let's start with, today's like first question to Priyanka. Like Priyanka what do you think the TPM role is like decipher that in your own words, like what the TPM role is and why does the industry need a TPM? Priyanka Shinde: Sure. Yeah. So, the TPM role or the technical program management role, I feel is a very special role in the sense that it has so much of that technical focus while leveraging your core program management skills and leadership skills. Sometimes I'd say, you know, TPMS drive holistic execution strategy by leveraging their deep domain expertise to basically meet the goals or deliver results, right? That's the end goal. And so, I feel like, you know,
Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very interesting guest with us, David Glick. A lot of you might know him. He's been a mentor. He does a lot of linkedin posts and he's a cool person to follow, so do follow him. He's worked at Amazon For 19 years and was a VP of Amazon fulfillment technologies. And then Amazon tickets. He left Amazon to go join as a CTO of flex. He has incredible, incredible experience in building high performing teams and building high performing organizations, some very excited to have today with us and share his thoughts. 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. 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.
Hello, and welcome to the TPM podcast with your host Mario Gerard. This is part two of the second episode on burnout with Arjun Subramaniam. I hope you caught the first one. If you haven't definitely listen to that first before you listen to this. It's going to be super interesting. As we continue to discuss how burnout affects all of us. Episode I – Part I (TPM Fundamentals) Episode I – Part II (TPM Fundamentals Continued)Episode II – Part I (Burnout) Mario Gerard: how do you combat burnout? You feel that you are in the burnout phase. Maybe if you are, what are the things that you tell people to go and try to do. Arjun Subramaniam: So I'll share a little bit about my own life at the base of all these core skills that we talk about, like in Latin podcast and this one, I think there's some skills here too. I think that there's a kind of a set of fairly textbook advice Someone will give you and they're all good advice. You should just do them. Okay. Eat right. Don't drink too much exercise. Learn to get some rest. Don't use electronics too late at night. This is all really good advice. You should just do that. Like no beef with any of it, you should just do it. And all of them will reduce the likelihood that you will burn out. I think that for a lot of people, this advice can never actually come true in their life because there's something else, there is something else got to deal with. Right. It's a lot like if someone just came and told you and you are an alcoholic or whatever, it's like, well, that's easy. Just stop drinking alcohol. And you're like, well, clearly I'm not able to do that. And so I think the conceptual frameworks of some of the stuff is helpful only to the extent that you're able to execute on it. And most people who are already at that stage, they don't need to be told [01:42 inaudible] framework. They can just be like, oh yeah, I get it. I'm going to go do those things. So if you're not one of those people, what should you do? Right. And I think this is where it gets really interesting. You got to figure out what's bothering you. What's a miss in your life. And no one can answer that except for you. You got to figure out what your story is and just own it. And you got to figure out why you're feeling the way you are. You basically have to claim authorship of your story. Whatever that story is, you got to just claim authorship of it. In order to do that, It's a sizable investment of time and energy, and you've got to have a willingness to go and do that. Yeah. So that can be at a place where the conceptual frameworks of wellbeing can actually work in your favor. And that stuff is really hard. There are two things that really helped me. And one of them was cognitive behavioral therapy. I was in behavioral therapy for about seven years and it made me a better person, a better professional. It helped me understand my own story. I grew up in a very difficult family. It helped me understand some of the causes of my stress and understand how much of it was still things that I had to work through. That was very helpful. And I highly recommend it for anyone that wants to understand themselves better. I can tell you that it dramatically improved my ability to function as a person. And that showed up at work a hundred percent, a hundred percent. Mario Gerard: It shows up in your entire wellbeing. Arjun Subramaniam: It shows up in my entire life. Mario Gerard: And wellbeing. Right. Gender wellbeing, which translates to facets of your life. Could be personal, Work. Everything changes. Arjun Subramaniam: My relationships were better. Everything in my life got better, but I will say it was a sizeable investment of time and of time and energy. It was like, you know, three times a week for seven years. So it was a long time. The reason why I had earlier alluded to the importance of having a diverse source of information, I think a lot of what it takes to live a good life has actually...
Check out the podcast with Arjun Subramanian, he has worked at Appian, Amazon, Qualtrics and is now the Director of Product Management at Axon. Over the years he has been a Program Manager, Product Manager, and TPM. In Part I of Episode I, we discuss the very fundamentals of what it takes to be a TPM, where a TPM would be most beneficial and so much more. Episode I - Part I (TPM Fundamentals) Episode I - Part II (TPM Fundamentals Continued) - Coming Soon Episode II - Part I (Burnout) - Coming Soon Episode II - Part II (Burnout) - Coming Soon Here is the transcript of the Podcast. Mario Gerard: Hello and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very special guest with us Arjun Subramaniam. He's worked at Amazon, Qualtrics and is currently working as a product management, a director of product management at Axon. He's also been in a variety of different roles from being a program manager, a product manager, and a TPM. Arjun why don't you introduce yourself. Arjun Subramaniam: Hey, Mario. Thanks for having me on. My name is Arjun. I'm the director of product for axon foundation services. Axon is a software and connected devices company focused on the criminal justice system. We build software and most popularly known for body-worn cameras and tasers, it is a connected device. And the idea of. For us to be able to modernize the justice system with the best technology. Axon foundation services AFS is the team I own. They are a platform team. We built all the primitives that you need in order to build cloud apps for the justice system. So, you can imagine how much Storage you would need full body worn camera footage. Cloud storage is a primitive. So, we specialize in being able to store evidentiary media for really long periods of time, in a way that's safe and recoverable. We own cartography and maps, which is another primitive for 911 dispatch and lots of other building blocks. We call them Lego blocks for building cloud apps. Mario Gerard: Cool. The company has significantly grown over the last, like four or five years, I think. Right? Arjun Subramaniam: Yeah. Yeah. So initially the idea was just tasers. Small product company. The idea was to protect life and displace firearm uses. So, if you think about harm reduction as a strategy, you have all these different firearm uses by law enforcement or, or really anyone. And the idea is to obsolete firearms and provide a non-lethal or less lethal alternatives for firearms in dangerous situations. From that one product, which became really, really successful we invented the body-worn camera which became then internet connected. And then if you ever watch footage of this stuff on TV you know you'll see the Axon little golden triangle imprinted on the body-worn camera footage and that's largely credited to the internet connected body-worn camera. And then now there are a fleet camera, and we have a suite of applications, cloud apps that are for different purposes and different actors in the justice system. So, everything from like the patrol officers, to public prosecutors, public defenders, juries being able to orchestrate the flow of information for the entire justice system, not just the United States, but all over the world. Mario Gerard: Well, that's fantastic. I think it's a very interesting space and there's a lot of good, interesting use cases there. That's really interesting. So, I think today's podcast is going to be really interesting because also because Arjun's kind of worked as, as I said earlier, as a program manager, product manager and TPM, you've been a TPM at Amazon, probably for like 10 plus 12 years. And then now you're kind of in the product role. So, I think we are going to talk about the differences between the two roles. We're also going to talk about how he switched between those two roles. And that's going to be the first half of the podcast or the second half of the podcast,
Nacho Gomez a Sr Technical Program Manager from Amazon, contacted me to do a 'Fireside Chat with TPMs from Amazon'. The goal was to debate and share ideas on different topics about the TPM role and career. Nacho joined Amazon as a TPM in 2017. He has around 20 years of experience with different technical management roles over the last 15 years in various industries. He is working now on Kindle in Amazon’s Madrid TechHub where he is an active member of the TPM community. Fireside Chat With Nacho Gomez & The TPMs at Amazon Madrid Nacho found this blog nearly 4 years ago when he looked for information about the TPM role and we were in conversations since last year to have this call with an audience of both, new hired and long-tenured TPMs. Fireside Chat With Nacho Gomez & The TPMs at Amazon Madrid Hope you enjoy this episode of the 'TPM Podcast'. Thank you, Mario Gerard Podcast Transcript Nacho: Please everyone, help me welcoming Mario. Mario is a well-known member of the TPM community with 15 years plus experience working, currently as principal TPM at Oracle and owner and host of the TPM blog and the TPM podcast, helping people to either start or grow on their TPM career. Mario agreed to have this QA session with us. So over the next, let's say 40 minutes I will be asking him about those interesting questions that we have been gathering from our local community of TPMs at Amazon in Madrid. And if you have any follow-up questions, please use the chat. I will try to accommodate times, or we can speak about them together either during the interview or at the very end. And as I mentioned, I am recording the session in order to capture the transcript later [00:58 inaudible] and check internally with Mario that we can distribute the video itself. Mario, Thank you again. It's a pleasure having you here. Why don't you briefly introduce yourself before we start with the questions? Mario: Sure, sure. Thank you so much for having me. It's really nice to meet TPMs, not only in another organization, but it's also another country. So I think this is the first time I'm actually talking to a group of TPMs outside the United States. So that's really cool. So a little bit background of how my career has transpired and how this all started. It starting off. It was a, I did my engineering in India and then I went on to do my MBA in UK, United Kingdom. Worked there for some time. Then I came back to India. I worked at Oracle sales for nearly three years selling Oracle products in the United States. Then I got married, came to the United States and then, this was in 2009 and I could not find a job because of the economic troubles. And, you know, I was trying to move from India to United States. So I had to find myself a new job. And that's when I started, I probably was jobless for nearly a year trying to figure out what I was supposed to be doing and all that. And then I started in quality assurance and testing. I started doing automated tests, became a test manager, a program manager, a TPM, and then the rest is like senior TPM in principle. So it's been kind of an interesting journey to have been in different roles for the last 15, 20 years or so. So that's been very interesting. So like seven, eight years ago, what happened was I started hearing a lot about the cloud in Seattle, probably more than eight years ago. It was seven, eight years ago. Approximately seven, eight years ago. And then I was like, okay, how do I learn more about the cloud and all of these things? So I like, okay, let me just, you know, host WordPress site on AWS. That's going to be my goal. And so I bought a domain and I stood up a WordPress site and I started slowly writing on the WordPress site, which was hosted on AWS. And that's how my blog basically was born. And in this time when I'm writing, when I'm just starting the blog, I realized in Seattle, especially there was this new role, I was a project manager at that point of time, I was implementing ERP projects,
This is the Technical Program Management Podcast with the author of the popular blog Engineer Seeking FIRE. He has been a Technical Program Manager at Microsoft, Amazon, and is currently working as a TPM at Google. In this podcast, with Mr.ESF a TPM from Google we focus on the FIRE movement & the impact of COVID Check out some of his best posts:- Google TPM Podcast: FIRE & COVID How To Plan For Your Financial Independence What Does A Technical Program Manager (TPM) Do? In this podcast series, we talk about :- The speaker’s Blog and the FIRE Movement. The Impact of Covid on our current work environment The TPM role at Google How the TPM roles compare across - Amazon, Microsoft, Google Interview prep for TPMs ? The podcast series is divided into three parts. TPM at Google: FIRE & COVID Part I TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google - Part II TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google - Part III This is Part -I of the series, and we discuss the speaker's blog, how it all started, we talk about FIRE, and the importance of financial planning and close this episode with the impacts of covid on our work as TPMs. Thank you, Mario Gerard Podcast Transcript Mario Gerard: Hello and welcome to the TPM podcast with your host Mario Gerard. Today we have a very interesting guest with us. He is the author of the popular blog engineers seeking fire. He has over 15 years of experience working in various tech organizations in a variety of roles from being a software engineer, a program manager, a product manager and a TPM. He has been a TPM at Microsoft, at Amazon. And now he's a TPM at Google. In this podcast, we will cover the essence, the core essence of the blog, which is “Engineer Seeking FIRE” and what FIRE means and why the author started the blog. We'll maybe go into a little bit of impact we've had of COVID. And then we'll dive really deep into the TPM role at Google, and how the author of the blog compares the TPM role at Amazon versus Microsoft versus Google. And maybe we'll go a little bit into some discussion about how to prep for interviews at these various organizations. So one thing to note here is the author of the blog, engineer seeking fire is anonymous. I'm not going to name who he is, throughout this podcast, I might refer to him as Mr. ESF engineer seeking fire. So why don't you tell us how this whole journey began, how you started this blog, and what your blog is all about? Mr. ESF: Hey Mario. So first of all, thank you so much for inviting me to your podcast, I’ve been listening to it for quite some time now. I've learned a lot. So I'm really happy for your content, I'm really happy that you're doing this. So thank you so much for organizing the podcast and for inviting me. A few things about my story. So I love the tech space. So I studied computer engineering and I have been always passionate about software engineering and writing codes. And after graduation, I got a great job, at a lot high tech company I was very proud, accomplished, you know, I lost my job as a software engineer. At the same time, though, as I was going through my finances, it felt as if I was getting by paycheck by paycheck. So you know, having a great salary doesn't mean that you're living a very fancy life, especially as a new grad. So it felt like one paycheck was paying for my rent, the other biweekly paycheck was paying for my expenses and then that's it. And then at some point, I was thinking about it, somebody pointed me to the book, Rich Dad Poor Dad, I'm sure you've read it probably or learned about it. And that changed my mindset, I thought that I learned that, you know, having a great income is not the solution for everything. What I understood is that my goal should be to become financially independent. So it must finding ways for my money to work for me. So you know, I can spend X amount of hours every day working and make some money there.
Technical Program Management Podcast with the author of the popular blog Engineer Seeking FIRE. He has been a Technical Program Manager at Microsoft, Amazon, and is currently working as a TPM at Google. Comparing The TPM Roles At Amazon Microsoft Google Check out some of his best posts:- How to Prepare for Technical Program Manager (TPM) Interviews Salaries for Software Engineers are On FIRE! In this podcast series, we talk about:- The speaker’s blog -> Engineer Seeking FIRE The Impact of Covid on our current work environment The TPM role at Google. How the TPM roles compare across - Amazon, Microsoft, Google Interview prep for TPMs ? This is Part -II of the series, and we discuss how the TPM role differs across Amazon, Microsoft vs Google. The podcast series is divided into three parts. TPM at Google: FIRE & COVID Part I TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google - Part II TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google - Part III Thank you, Mario Gerard Podcast Transcript Hello and welcome to the TPM podcast with your host Mario Gerard. This is part two of the podcast with the author of the blog engineer seeking fire. He has worked as a TPM or program manager at Amazon, Microsoft and is currently a TPM at Google. We discuss how the TPM role varies across these three tech organizations, and the various nuances between them. So stay tuned. Mario Gerard: So let's move into the TPM world. So can you describe for me like what the TPM role at Google looks like? Mr. ESF: Sure so there are lots of different things that the TPM covers at Google. So from a very high-level perspective, a TPM focuses on execution. So we want to deliver products on time, while at the same time making sure that people don't get burned out. So we want to have realistic timelines, we want to have reliable timelines. And we are responsible to make sure that things land on time. So that's from a very high-level perspective Mario Gerard: Pretty much very standard right? across the industry. Google follows the industry standard of the general rule definition of what a TPM is across all the tech companies in general. Mr. ESF: That is correct. And I can go into an example afterwards, if you want. Mario Gerard: Sure. Yeah, let's do that a little later. What are the biggest challenges you think, you know, a TPM would face starting at Google? Mr. ESF: And so one of the important things to know about Google is that Google is engineering driven. So there is lots of feedback by the engineer. So the engineers are kings of Google. if you want to call them like that. And so what you need to do as a TPM is to prove value to the engineering team. And each engineering team might be different. So one team might be doing Agile, other team might be doing more waterfall, another team might be have different tools to track things. So it's very, as a TPM, the most important thing is that we need to adapt to whatever the TPM, whatever the engineering team needs, and also at the same time, we need to prove our value. So it's not that okay. And you guys follow me, there's no such thing. It's I need to prove my value and gain more credibility within the team. And that's how the team will trust me and that's how we can move from there. TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google So I think it's very, the most important thing is proving value. I think that's how I see my job proving value and making sure that people see why I have an important position in the table. So that's one thing. another thing is that there is no standardization. So there's no, there are no standard set of tools that, there is no guidance saying, Okay, this is the tool that you need to do to create your project plans or this is a tool to send email. So this is the template or whatever. So every TPM has to, First of all, there are multiple tools, it's not that there are no tools, there are multiple tools,
Technical Program Management Podcast with the author of the popular blog Engineer Seeking FIRE. He has been a Technical Program Manager at Microsoft, Amazon, and is currently working as a TPM at Google.TPM at Google: Interviewing at Amazon Google Microsoft Check out some of his best posts:- Career Advice for Software Engineers Salaries for Software Engineers are On FIRE! Inside the Culture of the Top Tech Companies In this podcast series, we talk about :- The speaker’s Blog. Google TPM Podcast The Impact of Covid on our current work environment The TPM role at Google How the TPM roles compare across - Amazon, Microsoft, Google Interview prep for TPMs ? The podcast series is divided into three parts. TPM at Google: FIRE & COVID Part I TPM at Google: Comparing TPM Roles at Amazon, Microsoft & Google - Part II TPM at Google: Preparing for TPM Interviews at Amazon, Microsoft & Google - Part III This is Part -II of the series, and we discuss the speaker's blog, how it all started, we talk about FIRE, and the importance of financial planning and close this episode with the impacts of covid on our work as TPMs. TPM at Google: Interviewing at Amazon Google Microsoft Thank you, Mario Gerard Podcast Transcript Hello and welcome to the TPM podcast with your host Mario Gerard. This is part three of the podcast with the author of the blog engineer seeking fire. He has worked as a TPM at Amazon, Microsoft and is currently a TPM at Google. We discussed the author's take on how to prepare for interviews, and what are the types of various interview questions you could hear at any one of these tech organizations. So do stay tuned. Mario Gerard: Now, why don't we take a little different route and I'm going to ask you about how I saw a blog and how you said how to prepare for interviews. So let's move into a topic where we're going to talk about, in your opinion, how should a TPM prepare for TPM interviews for any of the tech companies in the United States or anywhere else in the world? How would you approach this? And maybe you could go down into a lot more detail about that. Mr. ESF: Sure. So the way that they say about this is that there are three types of questions and kind of six main areas where a TPM needs to know how to answer in interviews. So the three types of questions are factual, behavioral, and hypothetical. So a factual question is something that requires prior knowledge. For example, if the technical question like what's the difference between a struct in C and C++ that might be, for example, a factual question, you might you need to know the answer in order to answer this. Then there is a behavioral question, which is, tell me about a time when you did this. Tell me about a time when you managed a very complicated project, for example. And then there's a hypothetical question, which is, okay, what would happen if you had a project plan and suddenly two of your developers left, for example that's a hypothetical question. So these are the types of questions, the factual, the behavioral, the hypothetical, and then we have the areas, so the topic of those questions, if you want to call them. So one is the project management area. So that's probably one of the top areas. So that's the core part of the project of the TPM. So how can they plan, organize, execute the project? How can they create, manage, and improve business processes? So how can they function as a TPM? And again, in order to look at the project management knowledge, you can ask all three questions like a factual for example, what is agile? Behavioral, tell me about the time when you were organizing a project using the Agile methodology, or a hypothetical, if you had to structure a project using the Agile methodology, what do you do? Mario Gerard: Wow, super cool. I just love the way how you map that out and categorize that, that's really cool. Mr. ESF: Yeah, that's the way that I see these. And then, because many people say, okay,
Welcome to this edition of the TPM podcast with Visva Mohanakrishnan a Sr. TPM from Amazon. She's been in the industry for the last 10+ years and has worked at Microsoft, Expedia, and several other organizations. We cover what a TPM needs to be mindful of when they join a new tech organization. We talk about How Amazon is different as an organization? What makes it nimble and truly agile ? How is the TPM role at Amazon different from other organizations? How is the scale factor a big difference in technical orginizations? What is 'day one culture' ? And a long discussion on the Leadership principles that guide the soul of the organization. The uniqueness of the TPM role ? How the TPM role is different from the SDM role. What have you learned as a TPM in the last 1 year ? I really hope you enjoy it ! Mario Gerard Podcast Transcript.. Coming Soon. ..
Welcome to this edition of the TPM podcast with Visva Mohanakrishnan a Sr. TPM from Amazon. She's been in the industry for the last 10+ years and has worked at Microsoft, Expedia, and several other organizations. We cover what a TPM needs to be mindful of when they join a new tech organization. We talk about How Amazon is different as an organization? What makes it nimble and truly agile ? How is the TPM role at Amazon different from other organizations? How is the scale factor a big difference in technical orginizations? What is 'day one culture' ? And a long discussion on the Leadership principles that guide the soul of the organization. The uniqueness of the TPM role ? How the TPM role is different from the SDM role. What have you learned as a TPM in the last 1 year ? I really hope you enjoy it ! Mario Gerard Podcast Transcript.. Coming Soon. ..
This is a podcast with your host Mario Gerard and with guest 'Ethan Evans'. Ethan has been with Amazon for 15 years and is the VP of Twitch Prime. Ethan humbly says “I consider myself to be a TPM....” though he has been a VP for over 8 years. TPM Podcast with Ethan Evans We talk about the role of a TPM at Amazon, resumes, leadership principles, gaining influence, TPM competencies, executive communication, career transitioning from a Program Manager to a Technical Program Manager and so much more. It’s one of those episodes that has an incredible wealth of information and Ethan articulates so very well. Ethan Evans is active on: LinkedIn Website Twitch YouTube Mario: Hello and welcome to the TPM podcast with your host, Mario Gerard. Today, we have a very important and interesting guest with us, Ethan Evans. Ethan's been at Amazon for 15 years, he's led several teams from Twitch, Prime, Digital Content. He's currently the VP at Amazon and I'll let him introduce himself. Ethan: Hi Mario, thank you for having me on and everyone listening, I'm really excited to get the chance to share some of my experiences. I have been a VP at Amazon for the last seven years, been there for 15 years. Prior to that, I worked mainly in startups and then coming into Amazon, I had the chance to kick off and be the first engineering leader on Prime Video. Since then I've worked in games, I built the Amazon app store where I lead a global team of about 800. Then I went on to work in Twitch, the gaming subsidiary, when we bought Twitch and now, I lead Twitch Prime, the gaming pillar of Amazon Prime. Mario: Oh, that's fantastic, 15 years at Amazon, that's something to say. You also have a second life, you are also a coach, you coach a lot of people on Twitch and on YouTube as well, right? Ethan: Yeah, that's right. I was looking for how I could use our product and Twitch, of course, is normally used to stream video games. I thought, well, I'm not a good enough gamer to be interesting that way, but what could I use the platform for that I'm passionate about and I could really lean into. I do a lot of one on one coaching and it wasn't scaling anymore, I had so many people asking me for coaching that I couldn't take them all on, so I thought, well, let me do it in this live, interactive format. So, yeah, I have a Twitch channel under my name, Ethan Evans, and I generally stream once to twice a week. It turns out my specialty, that my audience loves, has become resume and LinkedIn reviews, helping people represent themselves and explaining how to attract the eye of a hiring manager. Mario: I've seen some of those, it's fantastic. If you haven't seen Ethan's Twitch channel you should definitely check it out, it's very sharp, it's very pointed and very precise advice on what you need to do. Then you also almost do it in 10 to 15 seconds, which is what I always feel a hiring manager takes to look at a resume, he's not going to look at it for more than 10 to 15 seconds, at least at first glance. Ethan: That's right. If you don't do something to hold the attention, the way I explain it is on a resume, every line has to earn the person reading the next line and you have to capture them in the first few lines on a resume. Hiring managers see so many resumes, I think in my career, I've reviewed over 10,000 and you just get very quick on skimming them. If your resume skims badly, on to the next one because there is, unfortunately, an unlimited supply of competitors for any given role. Mario: Yeah. So, in this podcast, we'll dive into what a TPM, a technical program manager role looks like at Amazon and that's probably the first topic which we probably hit at. So, Ethan, can you explain to us what's the culture at Amazon and how a TPM role fits into that culture? Ethan: Yeah, I can do my best. The first thing I have to say in fairness is Amazon is approaching a million employees.
TPM Podcast with Ivan Santa Maria. A fantastic conversation with Ivan Santa Maria who has worked at Google, Facebook and Microsoft as a TPM. I cannot thank him enough for sitting down with us to do this. While editing this podcast I had myself to pause in several places, to just sit and digest quite a few things Ivan said. So many snippets of great anecdotes! tpm-podcast-with-ivan-santa-maria We talk about so many interesting things :) Why TPMs need to be aware of organizational microcultures. Why it is important to understand the value system of your organization. Why the role of the TPM is nebulous. Working on a V1 vs a Vx product as a TPM and the difference. How would one define the Role of a TPM? Moving from a TPM role to SDM role. Ivan’s Secrets to getting promoted as a TPM How do you build trust ? Part II can be found here. Thanks ! Mario Gerard tpm-podcast-with-ivan-santa-maria
TPM Podcast with Ivan Santa Maria. A fantastic conversation with Ivan Santa Maria who has worked at Google, Facebook and Microsoft as a TPM. I cannot thank him enough for sitting down with us to do this. While editing this podcast I had myself to pause in several places, to just sit and digest quite a few things Ivan said. So many snippets of great anecdotes! tpm-podcast-with-ivan-santa-maria We talk about so many interesting things :) Why TPMs need to be aware of organizational microcultures. Why it is important to understand the value system of your organization. Why the role of the TPM is nebulous. Working on a V1 vs a Vx product as a TPM and the difference. How would one define the Role of a TPM? Moving from a TPM role to SDM role. Ivan’s Secrets to getting promoted as a TPM How do you build trust ? Part II can be found here. Thanks ! Mario Gerard tpm-podcast-with-ivan-santa-maria
A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices. We talk about large enterprises moving from a monolithic application patterns on to microservices what that entails. We go on to talk about various microservices best practices. TPM Podcast with Vidya Vrat Agarwal on Microservices. TPM Podcast with Vidya Vrat Agarwal on Microservices This has been split into three eposodes:- Part I: Lives here. Part II: Lives here. Part III: Lives here. Vidya’s LinkedIn Profile - https://www.linkedin.com/in/vidyavrat/ Also, read my previous post on microservices here - https://www.mariogerard.com/microservices/ We talk about :- TPM Podcast with Vidya Vrat Agarwal on Microservices. What is a microservice? TPM Podcast with Vidya Vrat Agarwal on Microservices. Advantages of microservices Monolithic applications vs microservices ? Why is there is renewed uptick in organizations using Microservices ? Pain points of microservices How do you break down monolithic applications into microservices Microservices Advanced Topics Vidya's Interesting LinkedIn Posts TPM Podcast with Vidya Vrat Agarwal on Microservices. Microservices Architecture Single Team Owned Service Architecture Building A CI/CD Pipeline Thank you ! Hope you enjoed it ! ------------****************----------- Vidya's Linkedin Post (Extract) TPM Podcast with Vidya Vrat Agarwal on Microservices. Abstract The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve. TPM Podcast with Vidya Vrat Agarwal on Microservices. Monolith Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together. Monolith Pros: • Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging. TPM Podcast with Vidya Vrat Agarwal on Microservices. • Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize. • Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC). Monolith Cons: • Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability. • Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand. • Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly. • Scale all or none: Scale up/out/down, it’s for entire functionality. Microservice Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component. “ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.
A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices. We talk about large enterprises moving from a monolithic application patterns on to microservices what that entails. We go on to talk about various microservices best practices. TPM Podcast with Vidya Vrat Agarwal on Microservices. TPM Podcast with Vidya Vrat Agarwal on Microservices This has been split into three eposodes:- Part I: Lives here. Part II: Lives here. Part III: Lives here. Vidya’s LinkedIn Profile - https://www.linkedin.com/in/vidyavrat/ Also, read my previous post on microservices here - https://www.mariogerard.com/microservices/ We talk about :- TPM Podcast with Vidya Vrat Agarwal on Microservices. What is a microservice? TPM Podcast with Vidya Vrat Agarwal on Microservices. Advantages of microservices Monolithic applications vs microservices ? Why is there is renewed uptick in organizations using Microservices ? Pain points of microservices How do you break down monolithic applications into microservices Microservices Advanced Topics Vidya's Interesting LinkedIn Posts TPM Podcast with Vidya Vrat Agarwal on Microservices. Microservices Architecture Single Team Owned Service Architecture Building A CI/CD Pipeline Thank you ! Hope you enjoed it ! ------------****************----------- Vidya's Linkedin Post (Extract) TPM Podcast with Vidya Vrat Agarwal on Microservices. Abstract The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve. TPM Podcast with Vidya Vrat Agarwal on Microservices. Monolith Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together. Monolith Pros: • Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging. TPM Podcast with Vidya Vrat Agarwal on Microservices. • Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize. • Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC). Monolith Cons: • Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability. • Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand. • Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly. • Scale all or none: Scale up/out/down, it’s for entire functionality. Microservice Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component.
A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices. We talk about large enterprises moving from a monolithic application patterns on to microservices what that entails. We go on to talk about various microservices best practices. TPM Podcast with Vidya Vrat Agarwal on Microservices. TPM Podcast with Vidya Vrat Agarwal on Microservices This has been split into three eposodes:- Part I: Lives here. Part II: Lives here. Part III: Lives here. Vidya’s LinkedIn Profile - https://www.linkedin.com/in/vidyavrat/ Also, read my previous post on microservices here :- https://www.mariogerard.com/microservices/ https://www.mariogerard.com/building-resilient-microservices/ We talk about :- TPM Podcast with Vidya Vrat Agarwal on Microservices. What is a microservice? TPM Podcast with Vidya Vrat Agarwal on Microservices. Advantages of microservices Monolithic applications vs microservices ? Why is there is renewed uptick in organizations using Microservices ? Pain points of microservices How do you break down monolithic applications into microservices Microservices Advanced Topics Vidya's Interesting LinkedIn Posts TPM Podcast with Vidya Vrat Agarwal on Microservices. Microservices Architecture Single Team Owned Service Architecture Building A CI/CD Pipeline Thank you ! Hope you enjoed it ! ------------****************----------- Vidya's Linkedin Post (Extract) TPM Podcast with Vidya Vrat Agarwal on Microservices. Abstract The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve. TPM Podcast with Vidya Vrat Agarwal on Microservices. Monolith Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together. Monolith Pros: • Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging. TPM Podcast with Vidya Vrat Agarwal on Microservices. • Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize. • Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC). Monolith Cons: • Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability. • Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand. • Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly. • Scale all or none: Scale up/out/down, it’s for entire functionality. Microservice Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable,
Technical Product Management Interview: With Dhananjay Mahajan Listen in to a fantastic chat with Dhananjay Mahajan! He has over 25+ years of experience in working in tech. He has had a long career at Microsoft for 20 years. He worked as a lead engineer for 5 years and as a Program Manager 15 year. And over the last five years has been focused on program and product management areas. Technical Product Management Interview: With Dhananjay Mahajan Part I Part II Part III We discuss :- What is product management? How does Product Management differ In an agile vs a traditional organization? What the core fundamental skills a Product Manager should have? What does it take to be a product manager driving a technical product? How is it different being a B2C Product Manager vs a B2B product manager? What are the primary difficulties or challenges for most Product managers? How the Product management role is evolving in the near future? As a product manager, how do we look for product - market fit? How can you promote a culture of innovation? General Product Manager advice and tips ? Dhananjay goes into great details and explains with great anecdotal stories. Feel free to add your comments below and also tell of other topics you might want to hear about. Thank you, Mario Gerard
Technical Product Management Interview: With Dhananjay Mahajan Listen in to a fantastic chat with Dhananjay Mahajan! He has over 25+ years of experience in working in tech. He has had a long career at Microsoft for 20 years. He worked as a lead engineer for 5 years and as a Program Manager 15 year. And over the last five years has been focused on program and product management areas. Technical Product Management Interview: With Dhananjay Mahajan Part I Part II Part III We discuss :- What is product management? How does Product Management differ In an agile vs a traditional organization? What the core fundamental skills a Product Manager should have? What does it take to be a product manager driving a technical product? How is it different being a B2C Product Manager vs a B2B product manager? What are the primary difficulties or challenges for most Product managers? How the Product management role is evolving in the near future? As a product manager, how do we look for product - market fit? How can you promote a culture of innovation? General Product Manager advice and tips ? Dhananjay goes into great details and explains with great anecdotal stories. Feel free to add your comments below and also tell of other topics you might want to hear about. Thank you, Mario Gerard
Listen in to a fantastic chat with Dhananjay Mahajan! He has over 25+ years of experience in working in tech
Technical Program Manager Interview: With Alessandro Catorcini A fabulous interview with Alessandro Catorcini! He has over 20 years of experience in tech. He spent over 15 years at Microsoft in various roles from being a software architect, a Principal Group Program Manager. He’s worked at Amazon and now he and I work at Oracle’s Cloud Infrastructure Team also known as OIC. He is one of those people I see who are solving problems that are large at scale. And another very interesting tit-bit is that he has done over 200 Interviews in the last 2 years at OCI. Technical Program Manager Interview: With Alessandro Catorcini We talk about:- TPM interviewing tips. technical-program-manager-interview Five core traits of Technical Program Managers. TPM leveling. What are the things to watch out for during an Interview in General. Compare the role across various organizations. Eg: Microsoft vs Oracle. What are some of the most understated qualities a TPM candidate must have? How do you evaluate a candidate's technical aptitude? Listen and enjoy ! technical-program-manager-interview Mario Gerard ps: You can find more podcasts here.
Technical Program Manager Interview: With Alessandro Catorcini A fabulous interview with Alessandro Catorcini! He has over 20 years of experience in tech. He spent over 15 years at Microsoft in various roles from being a software architect, a Principal Group Program Manager. He’s worked at Amazon and now he and I work at Oracle’s Cloud Infrastructure Team also known as OIC. He is one of those people I see who are solving problems that are large at scale. And another very interesting tit-bit is that he has done over 200 Interviews in the last 2 years at OCI. Technical Program Manager Interview: With Alessandro Catorcini PART II of this interview lives here :) We talk about:- TPM interviewing tips. Five core traits of Technical Program Managers. TPM leveling. What are the things to watch out for during an Interview in General. Compare the role across various organizations. Eg: Microsoft vs Oracle. What are some of the most understated qualities a TPM candidate must have? How do you evaluate a candidate's technical aptitude? Listen and enjoy ! Mario Gerard ps: You can find more podcasts here. And the next episode here. Transcript of the podcast;- Interview with Alessandro Catorcini Mario: Hello and welcome to the TPM podcast with Mario Gerard. I plan on doing a series of interviews with fellow TPM's and PM's, with top leaders and invite them to share their ideas with the TPM community. So, if you're interested in sharing your ideas, do reach out to me. Today, I have with me a very special guest, Alessandro Catorcini, and we're going to chat about a couple of things, primarily revolving around the fundamental characteristics of TPMS, how we level TPMS and what the TPM journey looks like. Alessandro has over 20 years of experience. He spent nearly 15 years at Microsoft doing various roles from being a software architect to a group principal program manager. He then worked at Amazon and now he's at Oracle's Cloud Infrastructure team where he and I are colleagues. He's one of those people I see who take and solve large skilled problems. Another very interesting tidbit about Alessandro is he's done over 200 interviews in the last two years at OCI. Alessandro, why don't you introduce yourself. Alessandro: Hi everyone, and thank you, Mario, for the introduction, it's kind of large-scale problems. Yeah, well more than large-scale problems, I've solved a lot of problems of every size, some of which happened to be larger than others. Mario: Yeah, today and that's when I saw your tagline, 'I solve problems' or something to that context. Alessandro: Yeah, that came out of a joke actually. When I was working with a networking team, they started calling me behind my back you Mr. Wolf, like Winston Wolf of Pulp Fiction. Mario: Cool. So, you have also done a lot of interviews for us. Alessandro: I did, yes. Mario: Approximately over the last two years what do you think the count is? Alessandro: Actually, I was looking at the scoreboard, there is a keyboard of the interviews which is actually funny. I was at 263, I think, since January 2017. Mario: Wow! That's a lot of interviews. And you do them for TPMs, PMs, and Ms. Alessandro: Yes, pretty much anything. Mario: Across the board. Alessandro: I have done engineers, PMs, TPMs, even admins, solution architects, some have been really interesting stories, guys that came for one job and got something completely different. Mario: Let's start with, like from your perspective, how do you define the TPM rule? Alessandro: There's a story that I remember hearing at a symposium of PMs at Microsoft probably a decade-plus ago. Yes, and it stuck with me because it captures the essence. If you think of a team like a big cake, you can start slicing it and you could slice a very clean slice that would be engineering, a very clean slice that would be product management, a very clean slice that is QA. When you're done cutting slices,