AA172 - Review of "Transformed" by Marty Cagan

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. Welcome back to the arguing agile podcast. Ed Martin is back Ed, we need a title for you. I was gonna say Software development Sage. The czar of software development. Bienvenido, Ed. Yeah, yeah, definitely. I've had many different roles in my career. I started out as a network engineer. I became a software developer became a IT business leader. I have had multiple roles and leadership for the last 20 years so yeah, I'm a product minded leader. Right? if you're in an organization that is not product focused I tend to find myself challenged. if you're too busy doing tech work and not being focused on product. What the customer needs, what the customer is asking for and what's going to drive overall revenue. I get challenged in those environments to perform well because I'm interested in what the customer wants and needs. And how are we going to provide that? And what steps does it take us to get there? So from a Marty Cagan standpoint, let's just go with product leader! Ed and I have been talking since before this Transform book from Marty Cagan came out that we wanted to have a podcast on it and I was ready the week it came and I held off because I wanted all of the fervor, the initial Marketing and whatever. I wanted that to die down for a little bit. I wanted to read the book at least twice before I talked about it because my initial cynical take before I even read the book, I didn't want that to cloud what I was going to talk about in the podcast. Because my original super cynical take was this is just all the agile transformation stuff, different terms. You know, I agree. Right. And I didn't want that to be the, because that would be the part. I'd be well, thanks for listening to the podcast. Like a subscribe. And that would be the, that'd be it. We'd be done in. When I started seeing all the marketing and all of the initial feedback from Twitterverse and LinkedIn, et cetera, there were some people who were upset and I was Oh, what's in the book? I really, felt like there were some people who were really taken aback by what was published. So I couldn't wait to get into it myself. But as I read it, I didn't feel like I left with a new insight. there were some things where I Felt like he did a great job of clarifying what he meant and what he thinks. But I'm not so sure the people who were upset that this was their book. I think this book is more towards if an organization is looking to do a transformation, this is a great place to start to figure out what those things are. Can I get all my cynicism out of the way at the early part of the podcast? I don't think you'll get it all out, but go ahead. You'll get the majority out. I think you're right. I think if I'm an agile coach and I'm looking to rebrand for what's hot on the market. I think this is a great book because I can just call myself a product coach. If you're looking to see what's going on in business, there's quite a few podcasts out there that are futurist focused. And I think that with this book and many of those other. Thought leaders that are saying what the next 7 to 10 years look like. Oh, THOT leaders, not in my book, not unless you're Megan Thee Stallion. yeah, thought leaders. See, I figured I'd throw a trigger out there for you. But if you're looking at what might happen to the gig economy in a couple years, What's that going to look like? What is technology going to look like as automated intelligence starts taking over certain areas. So being able to understand product and what product is, is going to be very important for people who used to be very focused on process and technology. You actually have, that's a product and you can't just live in process and technology, right? Normally when we do a podcast, we kind of go over all the things we could talk about and sort of organize them down. If you've ever been on a podcast, like you know that that's kind of our system. We sort of didn't do that in this podcast because there's so many different things in this book. But one thing that I just had hanging over me has been if you're going to dismiss agile coaching in its entirety, right? And say like all these people that are over here are they're all trying to sell you certs or they're trying to do whatever, or it's heavyweight. If you're going to dismiss the entire career field and say, well, you don't need any of this. You just need what I outlined in my book, even though they're not exactly telling you how to do it anyway. Well, who takes over that responsibility in the new order of things? If we're all, if we're not agile transformation anymore, forget it. Trash that model. We're product operating model now. Like we're going to find and replace. Who does that now? So he, in the book, he calls out product leaders do that now in the product operating, well, he still has coaches. He has product coaches, right? so I questioned, if agile coaches were also just renamed. You have to go there as well. Right? So he does say that, but he kind of leaves that as an option. He says, you either have people that know product and have a product mindset in your company, bring them in. Or if you can't find those, then bring in a product coach to help you with it. I just figured out what this podcast is going to be. This is going to be the product leaders podcast. There are two roads we can walk down right now, which is what happened to all the agile coaches. And the other road is, if the people that you get that do the coaching in the future are all product coaches, where did they come from? He names the Magnificent Seven in his book, other than that, who knows? I mean, they probably will have an expanded list in the future and they'll keep it on their website or something like that Yeah. Fabulous 20. I don't know. But yeah. what does happen to all the Agile coaches? Do they not have the skill? they would probably pivot. I mean, what happens to the agile coaches up to the agile coach, right? Where do they want to go? Do they want to go into product? Do they have the product mindset, right? There are agile coaches out there that may not have the skillset to actually coach at that level, right? So when you think of coaching, you have a high skill level. You have high school coaches, college coaches, NFL coaches, right? So you have a skill levels of what level you can coach at. And so we may find that there's a focus on product based on the industry based on the skill set. And so we may find some isolated opportunities where the coaches come in and help the product leaders, right? So do you have a design coach somewhere along the way, product designer? May also need a coach, so there's opportunity there if you're design focused. I think that the opportunity is there for them to pivot their career, but it's up to them on what they do, but there's going to be a need. His definition of product leaders. I don't know if you have it, but his definition of product leaders are, they're the ones who hire the, that, that segment. He's broken up the categories by product managers. Designers and engineering. The product manager is in charge of value and viability. The designer is in charge of usability. And feasibility is up to development. Each of those has a person who hires for those roles. That person is designated as the product leader, for that segment. But now We're designating the product leaders are now in the segments of their, I guess their sub segments, the key thing that, that was, that We don't want to gloss over is the fact that the tech lead is in the product leader group, right? And so how many organizations have you been involved with where the tech lead? Cared which is also another quote in the book tech lead has to care much care as much about the product That's being built as much as how they're building it but what's your experience with the tech leads actually falling into a product mindset? In the original inspired book. He didn't make this designation about the tech lead. like all developers are just the developer, right? so the feasibility was assigned to development to tell you whether they could build things with the current team. skills we have, the current technology that we have and whatnot. And this book, it's kind of been refined to well, you need this special designation on a developer of tech lead. Who's basically like your senior kind of, I don't necessarily like that designation as much. Because it seems like number one, it seems like you're creating a new role. We don't necessarily need one, but number two, it seems oh, I can take this tech lead and they can do this special job. And then leave all the developers over here to quote, do the coding, do the real work of coding. But I think he's still saying the entire engineering team has, so I want to make sure, no, he said in one of his sideboards, he says, We prefer the whole engineering team to be involved in it. So there's a transition that the engineering teams are going to have to go through as well. And I've actually been challenged on this because when I do technical interviews, conversations, and describe my process of how we execute and deliver I tend to get the, well, you're not technical enough. I believe I'm still technical. I can still pair a program with the development team. I can still draw on the whiteboard and architect a solution. So I still feel I'm technical enough, but I use product, grammar, product terminology. The thing that I'm developing, the thing that I'm delivering is a product. I take pride in the work I do and the way it's perceived, because I see it as a product. And so I think that developers and engineers need to start realizing that, that their day to day is their product and is it represents them. And as we move on into this future economy. The thing that you do is important on how it's delivered, what it looks like. You don't just get to sit in a desk and trade time for money anymore. It's changing. The developer has to care about they can't just care about how we're solutioning something they need to care about what it is, why we're doing something. I don't know exactly the terminology he uses, but that was on page 67. Let me, let me flip it just to see what kind of terminology. there was two quotes, 67 and 68 says that's only true if the engineers care as much about what they build as how they build it. And the next quote on 68 is, if the tech lead is unable or unwilling to engage in product discovery, Then you are very likely guaranteeing that the eventual product will not achieve your goals. How many tech people do not want to be in You go to those meetings. I don't want to go there. I don't want to talk about it. Just tell me what you want me to do. I'm just an order taker. Yeah, absolutely. They have to be part of Discovery. They do. They do. But again, go back to the question you asked earlier. How many organizations have you been in where Your technical folks are actually speaking to customers to understand not only the what, but also the why, and that's the missing piece here. So what he's saying, his thesis is, I believe, correct. It's just the reality leaves a big gap there, right? And I guess that might be the challenge for organizations to get there, if they're going to go down this path. So those agile coaches that are coaching at a level above just the teams, they may be able to make the pivot easier than people that are just process coaches, right, on the teams. Because they don't have a product mindset necessarily. Of course, there are exceptions, but that's my take on it. Om, you mentioned people at the team level okay, well like the most dangerous agile coach is the people that can stretch above the team level, but they haven't quite figured out how to stretch like across to the enterprise level yet. They can do a little damage in that little corner of the organization. Do developers have coaches? Is there a model where a developer gets a coach, right? When is the organization going to invest in that style coach? That's supposed to be your team lead, but your team leader is assigned so many other things to do. Where does that developer coach come from? Where, where's that time allotted? Well, Ed, I'm glad you went there because let's take a break and talk about the product leader designation that this book makes. Now, everyone, it used to be just product managers. It used to be just product managers that hired other product managers. You were product leaders. Now everyone's a product leader. Everybody is a product leader now, Ed. That's what I'm saying. And in the world where everyone's a product leader, nobody is part of your job. And he says this in the book, part of your job as a product leader in a new style organization is coaching. It is actually a big part of your job And the people that do the hiring in this new organization where we're all product leaders said those people have skill in their particular area. So I, I am an expert in product discovery. I've come up through my career. Now I'm in, I'm in some sort of position where I can hire product managers. So I'm going to find and hire and train and coach that person. I'm going to mentor you. I'm going to coach you, whatever it is, but I have this skill. I'm an expert developer. I'm going to try to transfer some of that skill. Same thing with designer. Yep. All right. Here's my core disagreement with this whole book. All right. I'm throwing it out on you right now. I did not share this in the prep for this podcast because my experience is most of the people in those roles, meaning hiring managers for dot, dot, dot, fill in the dot let's take the tech lead out of this and discuss that by itself. Okay. But most of the people that hire chief product officer, VP of product, most of those people don't come from product. They can't do discovery work. They never been a product manager in their life. Most of the people that at the top levels of product, they came from sales or marketing or something else. They didn't come from product. He does say in the book, he does like to give him credit. He does say in the book, if that person doesn't have those experiences, Then you need to look for an external coach, bring a product coach in. So how can I square that? How can I square the reality of what I've seen with the shining example that he's telling me? So I'm gonna answer that with another quote because he talks about product leaders. He quotes Andy Grove legendary CEO of Intel the quote is what gets in the way of good work. There are only two possibilities. First is that people don't know how to do good work. And second is that they know how they just weren't motivated. Well, I would argue in today's workforce, there's a third and there's just no freaking time to do good work. But I'm going to say in today's workforce, what gets in the way of good work right now. So when we, you're talking about coaching is the reason I transitioned that quote. very few people actually have the time to coach and train and teach and develop their staff anymore. So when he goes in here, he talks about the 1 1 12 model, where there's one product manager, one product designer to 12 engineers. If I remember, that's the actual team size he recommended as being the max. In a 1 1 12 model the coaching is challenging when at the levels that are people are trying to work today. There's too much thrown at product, project, in the current models that when you try to transfer that into this new way of working, that work doesn't go anywhere else. Most product managers are managing multiple lines in many organizations. to compound that, going back to the role of the product leader, he's saying that they are also accountable for product strategy across the board, not just individual products, right, across the board. He says you can't have a different strategy for every product team in the organization. So that's part of what they're supposed to do, in addition to the coaching you mentioned. On top of that, he also says, product leadership gets involved with defining team topology. How will teams be organized? He says that. And then thirdly, the coaching piece, right? So how much are you going to Burden the product leadership with, first of all, because that's a lot, that's a lot for a leader, even if it's the one, one 12 model or whatever, that's a lot of work for a person to be doing. Right. The background, et cetera, all the skills, the coaching, the team skills and so forth. How do you find these unicorns? Where do you find them? They must exist. Either they exist or you got it. Like you said, you got to go out. Side and rent some expertise in, or they get developed over the next eight years. At some point there's this, this isn't necessarily a book for now. This is a book for how do you get there? it is about transforming, so I don't wanna completely kick it to the curb. I did enjoy the read, I did enjoy the context. I got lots of highlights. it will be a reference book. So there, there is that going, there's a certain part of it that I just look at right now. I don't know how, while we're transforming, how do we transition the current model it's, it's not with, without leadership being on board. Because when you talk about the tech lead and you talk about technology leadership, if they don't grow up with a product mindset, they're not going to buy into this because they think it's smoke and mirrors. They don't get it. just do the work. And so how do you transition the decision makers mindsets? To support the overall goal. This is not the book for that. Yeah, this is the book for what does the ideal state look like? So you can hold it up to say, Hey, we don't look like this. let me figure out a way. Let me chart a path or whatever. You know, after you've changed your title from agile coach to product coach, the cynicism shining through the point for me is holding up the example to say. Hey, this is where we want to go. Marty Cagan has given me the example and inspired. He gave me the example. This is what product discovery should look like. We need to get here. this is what a durable product team looks like. We can't have people come in and out of our team all the time. We need to get here. That's fine, but he's not giving you a path of how to get there. He's just showing you what the ideal looks like. So I guess leading from example is, it is a method, right, in one way, shape, or form. but again, where I started with this book before I read it, was I expected it to be a rehash of everything I learned while I was thinking that I wanted to be an agile coach. But back in the dark ages, that's right in the dark times before the Sith or whatever. So, the challenge for me is on the cover though, it says how to, right? And that's where I bought into the philosophies. But I also felt like a lot of it was greenfield teams. In my mind, as I was looking through this, a lot of it started with, it's fresh. In the ideal scenario with the leadership in place that's supportive with the situation that yes, we have they're either rock bottom and they want out or I'm 100 percent bought in. So, Paweł Huryn and Akash Gupta did a podcast with Marty Cagan. One of their criticisms is this is too idealistic right now and or aspirational. And 99 percent of the companies and teams don't work in anything close to the environment that Marty envisions. That's a quote directly from that podcast. So we to your point. Yeah. I mean, this is. The North Star, right? How do you get there? It's not clear. It just tells you snippets, I think, and you've got to synthesize your own. there's a quote that I learned many years ago that I think it's worth repeating here because this quote is something I find myself frequently running into, and that is, a person convinced against his will is of the opinion still, right? so if you're trying to convince a leader that we should do this and it's against their will, you haven't changed their mind. And so the mindset is the thing that's the hardest for me to get past because I've been in enough backroom conversations that there are people I can name by name that, yeah, it's not going to work there. So does that model, how do you make those headstrong, fixed minded leaders who aren't going to adopt this new way of working eight years from now? Where do they go? So let's talk about agile coaches. I think they'll pivot. They'll figure it out. They'll move. that's in their mindset. It's the leadership. That's not in their mindset. companies are going to suffer. So I think the product coaches, as we're calling them now, have to catalyze the change with those people that have fixed mindset. Unfortunately, not a lot of these product coaches, whether they're rebranded agile coaches or not, they've never done product well anywhere, some of them haven't even worked in product, period. And that's a problem. How are they going to go in and influence somebody if they haven't even worked in the field before? The other thing is, they don't necessarily believe they have the power to change. Something that Marty talks about in the book, right? Agency? So I mean, that's part of it too. So there's lots of little things, but none of them put together. Kind of says, here's the path forward. That's a used agency. And that's something that I've, when I hear the phrase, I don't have agency for that. I was why not? I just, that's something I don't understand. The idea that I don't have agency. I take agency. I've worked to find it. You gotta seize it, right? I agree. So if you don't have agency, you gotta figure out why you don't and what you're doing about it. You can't just stand in the circle and say, I don't have agency. I can't do this. Figure it out. That's your role, that's your job. Before we get too far along, it was, it was, it was on page 205. It's one, one 10, not one on 12. So it was it's written as one product manager, one product designer, and somewhere between two and 10 engineers for a platform for a development team experience, product team, but if it's an engineering platform team, nobody, nobody knows what a platform team is. So you skip that because nobody even knows what we should do a whole podcast on what is a platform team? Because everyone's going to hear platform team and be Oh, Oh, that sounds like us. We're building a platform. You're not building a platform. You build a train. We'll build a platform. Yeah. So anyways, it's on two or five. Anyone who's interested in one, look it up later, What is a platform team? Well, I have them. Yeah. I don't think you kept a backlog. Oh, I keep a backlog. It's a formal one. Yeah. I actually give him an idea. He'll get, he'll go, I'll put it in the backlog. I might actually go to my phone and actually add it to the backlog rather than just saying I'm at it. I'll put it over there. Something I wanted to point out was I think there's a big hole in this book like this book assumes that you have CEO support. It even says it's very important. And CEO, if you're in a very large organization, I guess CEO could come down to like the director or whatever. Like it could break down to like your business unit or your business segment or whatever. It could be a general manager. Yeah, something like that. But it, there's a hole in there with what if you don't have that direct support? What if the product transformation stops at a certain, like. in the ladder of your, up your corporate ladder. they don't care. You know, he doesn't go into any of that. And only in my experience, cause again, we kind of all know each other, come together through where we have worked in the past, where that, that like two seconds of my career where I thought I wanted to be an agile coach That's where you run into all your problems is you don't have leadership buy in and your teams are trying to push that rock uphill. And the minute that you leave or your contract ends or whatever, like one less person pushing that rock is all I needed to just roll over the team. And now you're all back to ground zero, but your coach is known as Sisyphus. Yeah. And the other side of that is normally you're protecting the team, right? So clearly when you're the person protecting the team and you're moving, you're pushing the rock and you move. There's no one protecting the team anymore. So what Cagan recommends there in that situation is if you're an individual contributor. Maybe try to raise your skills so you can have a better discussion, become a better partner with that leader who's not on board. That's one thing, and then slowly try to exercise some control over things, like that's easy to say. There's definitely the desire to improve your skillset in there. If he talks about being stronger at what you do, right. and from a leadership standpoint, if your team isn't strong enough, then you need to hire stronger people. So in order for the product model to work in an organization, Everyone has to step up and become stronger, or you have to hire stronger people. And to step up may require bringing a coach in, product coach to help. But, yeah, there's definitely a edict in here, whether explicitly or implicitly implied, that you have to get better. Now he does, there is a, partnerships. there is a point in the book where he's talking about Product leaders. And he is saying normally the product leaders that you have, a big part of their job is coaching and they should be able to coach the people that they hire up to speed. I think it was three months is the number that he gives you. You should have somebody up to speed and operational. But on the track of what we're saying and again, to sync it with my experience, if you're product leaders, essentially I've never done the job in the first place. They need to get product coaches from outside to come in and help them or to coach the people that are under their staff, right? Because they're not capable of coaching them. So then you get other people to coach. If I'm Gary from sales and I get a new job as a V. P. of product at Om's Development Company. Now it's mine. Right? I love it. You bought him out? Oh, no, no, no, no, no. Oh, yeah. No, no. We were both acquired, but I took mine and I left. He got his yacht. I'm not sticking around. He sailed away. What are you, crazy? Sticking around after I buy my company? Brian, I like all your software, but why don't you do this one thing? And also, why don't you change this one thing? You don't need to meet every single day. You're a smart guy. Your sprints don't need to be two weeks. You can get that done in a couple days. You don't need to release every sprint, do you? You can every couple months, maybe. He talks about release cadence. That was pretty good in his book. He talks about my customers are saying, Well, you're giving us all these changes. We need a longer release cadence because we have to have all these testing and all this type of stuff. He's no, you're giving them too much in your big bang releases. You need to release more off and you're harming them before the training impact. And yeah, that's a tough one. That's a tough one to choke down for a couple of people that I've worked with in my career. So there's real good advice in here. But where I was going was if you're Gary, the new VP of Product and you've only ever worked in sales and account management in your career. But now because you go golfing with the CEO, you're the new product person. We read a book, ed, and it said we needed a product leaders. So I've hired you, well, not you, but I've hired Gary to be our product leader. He's got a solid . Product related experience. Ohm tangentially. Trust me. It's product related. So he can't coach product discovery. He can't talk about how to find the business viability risks because he's never done any of that. I mean, he could talk about it, I guess. And he probably will talk about it in my experience. Anyway, he'll probably talk at length about it. However, he can't tell you any, he can't give you any how to's. You want me to coach those product managers, let's say. So in that case, Gary needs to invest some of his money that he takes to run his department with, and he needs to hire product coaches to help all the people that Gary hires to advance their skills in product discovery and everything else, he does say. That you need to get outside help if you don't have those skills. Oh, he does say that. Yeah, definitely. If you don't have this buy in, it's going to be much harder or something like that. But he really doesn't expand on that. Yeah, definitely. Don't waste your time on transformation. If you don't have leadership support, it's not going to, work it's not worth the effort. it's painful. And if you're trying to do a product model transformation and you're working with leaders who don't have a product mindset and they weren't agile before it became product you're not gonna make it it's been baby steps, right? We went from agility to business agility, to business transformation, to product model, right? So I'm not trying to say they're not the same thing. they're incrementally different. But it is a mindset shift. Mm-Hmm. that the leaders are gonna have to go through, but if they didn't go through the first mindset shift, they're going, gonna make it through this one. Right. Right. And that again I understand why he avoids it.'cause basically it's a dead end. I mean, he probably could write a whole book. I was gonna just say that about this dead end, that maybe the. Maybe that's going to be his next book dead ends. No, hypnotized. How do you change the mindset of people? Mind control, mind controlled or yeah. I know you have to have one, one word title, but you just said, how do you change the mind? And mindset of these people, and it, I still go back to the quote convinced against your will. You have the opinion still. You're, you, you, I, I have little to no confidence. You can change their mind. And I, I have little to no confidence. You could raise your hand and say, I need some help. That you're actually going to get help and today you're, Oh, you need help. You must not be good enough. Let's hire someone else. Not realizing that the amount of work that's been put on to you and the skill set you're being asked to execute on there is no OJT anymore in this, in this, in this world. Right? You either know it or you don't. Well, the reason that I go down this tangent is if you're working for people who've never done the job that you're doing, they didn't come up through the ranks of the job that you're doing, that includes developers it's gonna be very difficult, like everything you're saying, it's gonna be more difficult. It's going to be more difficult, but at the same time, if you're a director of engineers and you have managers underneath you and you have 50 engineers on that team that make up the engineering team, do you have to, as a director, do you have to know how to Stand up an AWS instance. you have to be able to conceptually have the conversation, but the fact that you came from the Azure cloud space, not the AWS cloud space, you have some transferable knowledge and conceptual knowledge that should be enough to say, I don't, want to be very careful to say, they've never done it. Thus, they can't hold that role. Right. There's some translational knowledge they can apply, like costing models, for example, in that scenario. I grew up an angular developer and now I'm managing a react team. Does that matter? So I do want to make sure that we don't paint with too broad of a brush to say, You haven't lived in my shoes, thus you can't lead me. I understand where you're coming from. I think about that all the time when I see developer job descriptions, Oh, you have to have experience in Elastica in the elk stack and Elastica, and that's not that difficult to pick up and learn. Very quickly if you already know about ETL data pipelines and whatnot, right? Because you've done it in the Azure Cloud to pick it up and move your technical skills over to AWS that's actually not difficult, right? I mean, there's some syntax to figure out, but I mean, like three months. I mean, how you know what I mean? Yeah. It's doable. Yeah. It's, it's doable. But that is different from some people that I've seen that were project managers that are now engineering managers. I've seen it less often of people from other non technical roles jumping into engineering management than I have product. If I'm going to put a number on product, I'm going to say 80 percent of the, quote, product. Product management, product leaders, come from non product when you get to the VP level and above. Does that inherently make them bad? Yes. No, I don't know. Uh, Well I don't know if it makes them bad. However if they're self aware enough. To know that they can't coach the people that they're hiring and they need to get help then I'm more okay with it Then i'm more understanding because I mean the current downturn in the market, right? they want people that like the market is trending towards people with More experience in product management You started slowly seeing the job say three to five years in product management, and they have started to creep up to eight plus years in product management, which I doubt anyone's had eight plus years in product management. But you're starting to see that. People want more. They're trying to grab up more experienced people in the market. So from an engineering standpoint, I think there's a natural transition from a developer engineer, from someone who grew up in the development space to transition into product. I think a developer has been doing nothing but creating in their feature factory worlds. They've been creating. A product throughout their career. So I actually see a natural transition to where I would give it to someone who was a developer for 10 years and they've only been a product manager for two years. I would give them bonus points for the development time because during their time in there, they were working with essentially product people delivering the features, developing the features, probably writing the code that did all the instrumentation to make sure that you had the metrics you needed. So I would actually give a developer. If you look at LinkedIn, I'd give someone who came up through the development space, through the QA space, that a little extra bonus because their mindset on their day to day was a little more product minded and same with marketing, right? They come up through the marketing space then, but they're not going to be managing the engineers, but they very well could have someone who does the marketing. On their team, managing engineers for them. So you're never going to see on a LinkedIn profile that someone hired a coach. So the judgment that they didn't have the experience on their LinkedIn profile, isn't going to show you their leadership experience in their time in the seat and how they did that. You may see it in the recommendations, right? You look down on LinkedIn recommendations, you may find some nice juicy stuff there, but yeah, I understand what you're saying. I'm just trying to defend the people, right? There are some folks out there that are really good at their job. they've done some great stuff. there are great product leaders out there that are aware of the, actually, You know what? I shouldn't beat up product leaders so much. And turn my attention over to agile coaches a little bit, because there are agile coaches out there that. They've never written a line of code ever. They don't know how any of those systems work. They've never had to stand up an environment or anything like that. And I think of the same thing with them trying to coach developers as I'm now thinking about with product management, Hey here's some product discovery techniques, the things you might try. Okay, well, if I've never worked as a product manager. I can't coach that. So the next best thing I can do is get somebody who is an expert to help my team members and potentially me as well to learn those things. I think like now let's transfer that discussion over to agile coaches. And now it's a very meaty discussion, which could be a whole different podcast How do you coach your team on like CICD best practices and stuff like that? If you've never done it, this is, yeah, I guess I'm sort of having the same conversation. I think that's a valid comparison. So if you're an agile coach who doesn't have a technical background, let's say you've never worked in DevOps or whatever, and you want to coach your team in CICD. You could do worse than to partner with somebody who is a DevOps person, bring them in, right? Because at the end of the day, you're trying to make the team better, right? You may not have the skills necessarily. Unfortunately, with the product leaders that haven't worked in product before, when they get engaged in transformations, that's where, I think Marty Kagan uses the term transformation theater or something like that. That's when people go through the motions, right? Many companies go through this and without really changing how their employees work. You know, actually changing the conditions, actually changing the culture. Or even org design for that matter, which plays a big part into this. I think there's so much situational nuance that goes into some of the things we say, some of the things we do about what someone should or should not have and where it fits. And I think some of the greatest agile coaches I've ran into were previous school teachers, right? So they picked up enough technical skills along the way, but they're good at running a classroom. And they're good at, they're good at running a Sprint. And so those teaching techniques play very well when you're trying to manage the team, manage the client, manage the delivery, communicate the message. Be a good storyteller. keep people happy in what they're doing on a daily basis. A school teacher may not have Kubernetes experience to help coach a team, but they're going to do a great job at communicating the needs. Right? And that was and I forget the term he used and I could probably look it up, but you know, what is it good for us for? It's good for a technology driven organization, right? This is about a company that's technology driven. Whereas sometimes we talk in a broad brush on the agile coaches and others, and they're not necessarily In a technology driven organization, Let me flip to it. But yes, in a general sense though, cause that was one of the, one of the recent questions that one of the meetups I was at was how technical should a scrum master or coach, and I think they were scrum master, not coach, but how technical should they be? If you don't, if you're not able to communicate with the stakeholders and you're not able to communicate with the team and you're just pushing messages back and forth, your value is very limited. Yeah. I'm focusing on two throwaway lines. I'm going to turn over my cards right now and show you what I have in my hand which is my problem is not with any of the audience that we've been talking about. Product leader who has no product management experience and needs to get help. The product leader who knows they need to get help and gets an external coach for their team. There was a third persona we haven't talked about yet, which is the one I've interacted with a fair bit in my career. And every agile coach has interacted with, I'm a hundred percent certain, which is the quote, product leader, business leader or department leader, whatever you want, who does not have these skills is not doesn't know that they don't have these skills. And it's just like saying, well, why don't you just do it this way? You know what I mean? And like has ways that they want it to be done. they think they understand what product discovery is that I'm going to tell you, I know what the customer needs is not doing anything that Martin Cagan describes in either inspired or this book. You know tech leads often fall into this in large programs where they have real strong opinions that are based in, I don't know, things? It's opinions, I guess? Yeah. I call them assumptions. But the school teachers, I know exactly, when you say school teacher, I know exactly, we have a question, we have a great question on the podcast. That is it's what, what makes you think dot, dot, dot. So you'll say something and it's oh, Ed, you say , you can't coach me in product discovery. Because you've never done product discovery in your career, you're not an expert at it. What makes you think that a non expert, you can't learn anything from about product discovery? They have a way of asking things that kind of dig and also kind of make you question your entire existence. Well, I'm a consumer of product in a way that I pretty much anything that's above a certain price range. I do a lot of research on and so I don't need a salesperson and I can outsell a salesperson. So I, from that standpoint as a customer I believe I've done my product discovery. I've compared your competitors, I've done my research. And so I would say that there are folks out there that. May not have professional product discovery experience, but in the right organization, sometimes the customer would make a great hire. I wanna pivot to a reference from the book that we wrote down in our prep. Page 52, the tech lead is charged with delivery, the Holy Trinity of the designer. And the product manager in this book, I think the tech lead got kind of subbed out for the random faceless developer slash engineer. I think it became a, they got an actual name to role in this book. I could be wrong about that. I have to go back to inspire to check, but he says the tech lead is charged with delivery, Which is in addition to feasibility of the four risks. Yeah, they're responsible for the feasibility risk and they're overall accountable for the product's delivery. Is that the tech lead or the developer? That's the tech lead. Okay. So of the Trinity, it's product manager, product designer, tech lead. The Triumvirate. Yeah. Ooh, Triumvirate, I like that one. I like Holy Trinity better, but Triumvirate's a strong contender. So, yes, they, somehow I have never experienced this in a way that made me successful, that the tech lead was overall accountable for product delivery. How about you? Have you ever experienced where you were successful with a tech lead and you're responsible for delivery? I have not. What I have experienced, I'm sorry. I used the wrong word. Accountable, definitely not accountable for their, their accountable for moving backlog items at the most and, and working with the teams and approving PR requests, basically, what about you? Have you come across that in your career? I'm accountable. You're accountable, product manager, one finger in the air. I, no, nobody goes and gets the tech lead and says, How come you guys missed this date or how come this didn't work? Or how come this blew up? No, no, they come get me. They don't get the, yeah. When I heard the emphasis on tech lead in this book, I was already on the fence about, well what are we doing here? Are we designating this? Special engineering manager who's not quite paid as a manager, but sort of is more responsible than a team lead. I do want to say something though. I do want to say I think it's necessary. There's been many times in my career where I felt like the development team were, was not helping. They were not helping their team. They weren't helping the company because they sat back and said, all I do is deliver code. All I do is write code. Tell me what you want and I'll do that for you. Right? The order taking, not taking ownership of what they do. Back to an earlier comment is what you do on your daily basis is your product. And there's been times I haven't done a good job. Now, I tried. I wanted to do a good job, but whatever the circumstance was, I didn't. that's a pushing back from accountability that I just heard right there in your statement. well, you told me what to do push back hard on accountability. Like you told me what to do. Not my fault that it didn't meet the yeah. Woo. Yeah. But, but now real quick though, real quick. Have you ever, have you ever been, I mean, it's a common meme, right? The, the donkey with the loaded wagon. Oh yeah. Right. Have you experienced that? Cause I, I have. Right? I could not move when that last bag of wheat was thrown on my cart. And even though I raised my hand, even though I asked for help, I was still held accountable for delivery. So there is a, back to the Andy Grove quote, right? That was the thing. There's two reasons. You're not motivated. I can't touch the ground, man. so, I guess this first quote, part of that quote, I don't know how to touch the ground at the moment. I asked for help. No one's unloading me. there are a lot of people out there, and I think HR departments right now with remote work, globalization of employees. if they get hundreds of resumes in the first day of a post and they're stuck trying to figure it out, weed through it, they become the first line of defense for hiring. Right. the hiring manager can't be the first line. the HR people don't even try to read that. they just look at the metric and then ask the hiring manager how come you haven't read all these hundreds of resumes? They don't read any of those. I don't, I don't know who. Who is out there on whatever LinkedIn or YouTube or whatever. I may be the people that run HR channels telling you that eight like recruiters screen and what, I don't know what jobs they work in. I've never worked in a job where I had a professional recruiter screening all the resumes for me, like maybe the largest of large companies that happens in, Oh, I can, I've had it happen where HR took, they took control, yeah, they took control of the role because they wanted to be the first line and I, I've always felt like that's the worst thing you could, especially from a, when you're hiring developers because your HR department is now Your first impression of the company, right? When a developer says, what tech stack do you use? Right. That's their first question. And they're I don't know. It says here, we do this. What does that mean? They should not be the face of your engineering team. Anyway, so I have experienced more than once, but then again, like I haven't worked in monster hundreds and hundreds of thousands of employees can maybe, maybe that's where I've worked in a small organization where they said, here, we'd line these three interviews up for you. I didn't ask for those times. I didn't ask for these resumes and this is the first time seeing them. So yeah, it's back to mindset. What's the mindset of the org, what's the mindset of the leaders who's in charge of HR? What's the mindset of leaders who's in charge of the organization as a whole? So, I mean it's sort of a weaving back into the, but let's get back to the tech lead being accountable for delivery. When I was a manager back in the dark times no, when I was a manager I was partnered with a few recruiters that they, they very well understood of the corporate headhunters that recruited specifically and only for highly technical development, QA engineering type of roles. And they could definitely speak the language they wouldn't get lost in a technical, or not architectural technical discussion, career wise tech skills. Could understand because they got trained in that kind of stuff. So again, it goes back to my, you just went to an external recruiter though. I did. I'm talking about also in the internal HR department. So this is my job. I'm taking it again. they've decided the internal, I assume it was a decision. I assume it was the decision because the other end of that is, you just, it sounds cynical when I say it out loud, it's they haven't intentionally made a decision we're not going to train our people. They just decided eh, it sounds bad. Right. Yeah. In actuality, that's probably what's really happening is we're not intentionally going to train our people to speak the language or whatever. I mean, I hate to say it, but those are the people I worry about that are at risk to get replaced with AI. Anyway, the point is that the headhunters in My example, they had to have better skill of than your normal corporate head like recruiter or whatever, because that's all they did day in, day out. your company could have invested in the ability to train your people to understand. And, and, and if we, we beat up on HR enough where I don't need to go deeper into this in this podcast, Om knows! If you had certain recruiters that, Only like their job was only to staff certain teams and they got familiar with the team members, team leads hiring managers on the scenes, whatever it is. Then they would get like super ultra familiar with the skill sets and the process and the operations of those teams. So when the candidate did in the first round interview or the phone screen or something, when the candidate did ask questions about those teams and their processes and the technologies. The recruiter, because they only work with those teams, would be able to answer at least at a high level. We'll be able to answer. that's the same thing conceptually, like sports related. we're in the same ballpark as if you're hiring someone to do product management and you're asking them product discovery questions, like you should at least know what the right answers are. So I don't know. All roads lead back to Rome. so to get, to get where you're going, I think, and maybe to help, I'll quote the book cause it, I think it plays into this. So product manager is explicitly responsible for ensuring the value and viability. Right. So if to your example earlier of people in charge, are they being held responsible for value and viability or are they just saying do stuff right? So how are they now value requires a deep understanding of your users. How is that leader helping understand the users and customers and from a viability standpoint requires a solid understanding of your business. Now, I will say that they probably have a solid understanding of the business. I would agree with that. Cause again, the, the people that play golf with the CEO, Gary, the salesperson who got the chief product job, because they played golf with the CEOs wife's husbands who left them whatever, here's a long story and it has to do with the GME and AMC anyway, where you won't lose them is talking about specific customers and those customers needs. Cause he probably coming from sales, he probably is an expert in that. Now where he'll come across is I don't understand why you're not building this feature in that feature. Cause I know what the customers need. A little farther down, just for those following along, we're on page 56. But a little bit farther on understanding your business means learning how your product is funded, monetized, that's the sales guy. How's it manufactured? Not your sales guy. How's it marketed? Eh, maybe. How's it sold? Definitely. Well, funded is a maybe as well. How's it delivered and serviced? Nah. no. Not in the 80 20 rule, right? So the yes, no was in the 80 20 rule. there's definitely a lot of folks out there selling the product. They're Oh, I didn't know you couldn't do that. I thought you could. Can you make it do that? Because I already sold it. Right. Yeah. Well, that's again, that's, that's Gary, the salesperson turned chief product officer. He's going to be making deals bringing it back to the product team saying you guys need to implement by this date that I picked out of the essentially a new title, but same role, right? And same bad behaviors. The other thing that Marty Cagan talks about is a high integrity commitments. I actually liked his take on high integrity commitments in this book. his high integrity commitment is anytime that you need to give a date. With a development team we're picking data out of the air. We're going to deliver it to the state. So let's quote agile again, who gives the date? Cause in the book, right? Once again, it's from a rebranding standpoint, as that's just more agile because no one should give a date. No one should give a high integrity commitment. Other than the people deliver doing the work. Mm-Hmm. the work. Yeah. Right. So that's another agile take. So I was really expected some zingers, but I didn't really see'em 'cause a lot of stuff for me. I'm oh yeah, it makes perfect, oh yeah, that's what we should do. I must have skipped all of the early hype cycle. Cause I didn't get a lot of negative feedback. I didn't see a lot of negative feedback. I just had expectations. I wanted to see what I feel about the book is I feel he named things very well. He put gracefully lifted topics and gave them a good name and categorized them very well. I really like the objections section at the end of the book. Oh yeah, that was awesome. If Marty Cagan could write an episode of Arguing Agile, it was that whole section right there. I was wow, he just nailed our podcast theme right here. Picked every role and gave an argument. That's right. He picked every role, he gave the typical objections you'll hear, and then he gave them the argument. And he gave you the response. So since you were talking about, since you're talking about hiring people, I want to read this section here. And that was look for people with a broad understanding of business and the proven ability to quickly learn other parts of the business. Look for people who are comfortable immersing in the data to understand the behavior and the trends. Look for people who want to get face to face with real users and customers. Look for people who are willing to roll up their sleeves around a whiteboard with designers and engineers. So definitely when we're talking about who belongs on the team, it's the, you're looking for those people, not necessarily who have all the things you need right now, but who have the mindset behaviors, abilities to learn something new, to come in and provide value, understand what you're selling, have some pedigree of what you're trying to accomplish. Yeah. you're not going to make your junior developer your tech lead. It makes sense from a standpoint of this is where you're going toward, right? So you won't get there now just by reading the book, but you'll have to do all of these things to try and move in the right direction. that said, how long does it take for this transformation to occur, right? Six months to two years. There's a lot happening in the business. As you're trying to move the needle and transform product mindset transformation that back to product discovery. It's going to, I believe it takes longer than six months to put in a new product discovery technique in an organization that already exists. If it's a new organization, you're starting from Greenfield. You know, you could set the processes in place from day one. But if you've been around for 5, 10, 15 years, and you've got to unlearn and keep the machine moving, it's already underway, it's going to take some time. Yeah, that is one of the things that kind of surprised me with this book, is he was even willing to give timelines for this kind of stuff, rather than saying you need to break down the, basically you need to put up scaffolding around your company, Deconstruct the pieces that are built in this old way and reconstruct them around the scaffolding of the new way and it's not a transformation It's like that's that's you're rebuilding the business and that's the way it's gonna be forever so I looked at my notes over here and and scroll a little bit further I did realize there was one one thing that I didn't hear in the book that I was let down by not hearing and that is You know to quote the the movie World War Z the devil's advocate, the 10th man. I really wanted a 10th man role to be in here somewhere from a product standpoint where no matter what the business asks you to build, there was someone out there like looking at why that's not a good idea, why that might fail, where, where's the contrarian dissenting opinion when it comes to product management, right? I love a devil's advocate and I love the 10th man role. Well, you should, I mean, if you're, it depends on how you do product discovery, like again, this should be a welcome to another feature podcast, product discovery should be its own podcast for us. Because syncing product discovery with what Marty Kagan says product discovery should be with what you can do on a real what you can really do. I mean, what is really possible in a normal organization. Or how you get there, maybe how you transition from doing nothing to actually doing it. It could be its own podcast. I could probably think of a pretty good scaffolding. Yeah, definitely. And when it comes to who should be doing product discovery, right back to his one, one 10 model how many, how many teams have you been on that actually had a product designer, right? But if you're talking about customer experience, what's the customer experience, those people are really who should be doing your discovery because they should understand the experience more than anyone else. Well, it did. Boy, there's a, treating the designer, like kind of patronizing the designer to say just make what the development team did look pretty versus getting behind the designer and saying, how can we improve the experience of the user? Boy, you hire a strong tech lead or you go through this transformation and you bring up one of your current, People into the role of tech lead. I've seen more than once at more than one place that I've been at. I've seen the tech lead really dig their heels in and resist this kind of thing. I've seen tech leads. In fact, that was one of the things we were talking about before the podcast is tech leads. I've seen tech leads who are they're just a train wreck. They're just a ball of negativity and chaos that are fighting, kicking, and screaming this whole transformation thing all along. And leadership knows it. They just, that person has too much tribal knowledge. They're not willing to make a move. I don't I almost didn't want to bring up this late. Yeah, that one's too personal for me. I'd be I can't. Yeah, that one. Oh, you have too many stories. Too many stories come to mind. Oh, you can't, oh tech Lead Horror Stories. Is that another podcast I writing there? Tech lead Horror stories? There you go. I like that one. That one's a future podcast for certain. Tech lead horror stories. Future podcasts on platform teams, future podcasts on tech lead horror stories. Product discovery. Product discovery. Which, there's a, do another, I mean, add another book to the, to the story, which is I think it's called Shape Up by the base camp group. Shape Up does a great job and it's available online for free. to read or you can buy the printed copy, which I did is it's a phenomenal book to reference, they do a great job of working with the designer, providing low fidelity drawings and ideas of what you think you want, and then allowing the designer to use that low fidelity to then use their skillset to come up with something that's a little more meaningful. Whereas if you give them something that's high fidelity, they're already working within the constraints of what you drew. So, and there's so many other great topics in there in that book that's worth reading. Oh, and there's one more future podcast in our list here, Om versus Marty Cagan subtitle product objections, product objections. we're going to read the product objections, we're going to compare Ohm's advice against Marty Cagan advice. Here, I'll tell you what, let's do a couple random ones right now, this is a teaser. Alright. These are teasers. Alright, let's do this one for Brian first. Hold on, and then we'll come back to Om. Brian, this is an objection from Line of Business Chapter 39. I have P& L responsibility for the product line, so why should I not have control over the engineering resources? And these are people, not printers, engineering people. You shouldn't have the product manager should not you should have the P& L responsibility, so I don't know why you're misaligned with finance, but you need to get with your product manager and figure out what that might be. It's not that difficult to manage finances. Figure it out. So I know that was not Marty Kagan's response, but Oh, I guess I should have. Yeah. What was Marty Kagan's? What was his response to that one? You know, the other thing I want to the other thing I would like in a short to to send over to Marty Kagan is I would like to see all of the objections from the stakeholder, the objection that the stakeholder had, and then his answer. I would like to see the list of stakeholders and objections for all the ones that are on the cutting room floor. Right. Yeah. I would like him to send me that list. Marty, send me that list and then that'll be the podcast of the objections. This could be a great game. Objections from the cutting room floor. But there's no question that a line of business manager is a critical partner in the product model in very much the same way the CEO of a startup or scale up plays a critical role. But just as a startup CEO would depend on her product and technology leaders, the line of business manager would want to do the same. In practice, just as with a startup, many of these most strategic decisions would be done collaboratively, such as product vision, product strategy, and identifying appropriate outcomes for product teams. It doesn't say anything about get your money right. So you're saying collaborate with the product people to do product things. So it sounded like. Which is basically what I said, except I, what I said was, turn over your weapons of mass destruction to the product people and then talk nicely to each other. But first you got to surrender them weapons. Give them a meaty one. I want to go right to where the pain points for enterprise agility are. I want to go straight to the legacy PMO organization who rebranded themselves as VMO program management or product management, but they're really just packed with project managers. I come from the school of thought where everything, is about predictability. We need to focus on delivering what we say, when we say. We let the business leaders worry about what gets built. And we focus on being a reliable and trustworthy machine for delivering what is requested. Classic. So this is definitely in the wheelhouse of a PMO. We've got to standardize everything, first of all, so PMOs do. And then when we have new people coming, we just hand them a book that says how you do projects. So, yeah, we need to be predictable. They're losing sight of the fact that everything you're delivering is unique. If you have multiple products how do you become an expert at becoming predictable in this sense? Well, there's only one way. And that is, plan everything out up front, So we're now squarely into the waterfall world. Plan everything out up front and tell the customer when they can have something That's classic PMO and it doesn't matter if you're rebranding yourself as a VM. Oh, it's called value management or whatever. Just these are just plays on words. But you're still basically a waterfall project management organization. That's what you are. But in a product organization, how are you going to? So how would you pivot away from that if you're a PMO, right, already? one of the things to acknowledge is you're not really in charge of when you deliver something. You're only building stuff and then letting the customers pull value whenever they're ready for it. It's a strange concept for PMOs. They're really all about delivering. Getting to that milestone on the Gantt chart. we know what we can build. We know how fast we can build it because we have X number of people, So work with the customer to say, when would you like this? And then back into it by either ramping up or ramping down the number of people you have on your dev teams. It's definitely a cultural change. definitely a huge culture change, putting the customer in the center at that point, rather than pricing predictability for the sake of predictability. The book says, because you're getting ready to be ready to respond, Brian this is a good summary of the old model, but in the product model, the focus is no longer on predictability, but rather innovation. Predictability is important only if it delivers value to the company depends on uh, I have no problem with any of that. Listen, I, I just, I can't remember who the person is on LinkedIn. They have a picture and it says a hundred percent, a hundred percent predictability, zero percent innovation. We had a whole podcast on deadlines where I said, I can hit a deadline a hundred percent of the time in agile. So don't give me any of this agile teams don't give dates, nonsense We can give a date and I can hit it. 100 percent of the time, I mean, what you're going to get in there might not be satisfactory. It might not meet anyone's user needs, but I will hit it by the deadline. That's exactly what PMO's prize. Yep. Great. We can do that. We can operate like that. No one's going to be happy. No one. That's right. If we're wrapping up, I do want to just close with I do think it's a valuable book. I do think it's a worthy read. I think it has some amazing content. It's a good collection of summary put together, sanitized in one language I mean devoid of anyone's particular scaling method or, or, or thing that they're trying to sell or whatever. Yeah, I agree. And I, in, in all of his books I think there's like 1400 pages related to product and product delivery. And, and I think that they're all great in their own, in their own right. But there's definitely some fundamental in the book. We didn't get into where he talks about the reality. you have to address your current reality. You have to understand what your reality is as you're trying to move. And I think there's certain areas in organizations that the reality is, They can't move and a book isn't enough and mindset is everything and we have to figure out how to help that and if there is a next book, maybe not hypnotized, but definitely some way of taking Carol Dweck's book on mindset and adding to it on how we can fix the mindset because the objections are one thing, but there's still a whole shift that has to happen within the technology organizations. No doubt. Yeah, absolutely correct. So, no panacea in there, right? There's no actual follow this and thou shall have it kind of thing. Oh, I don't think, I didn't see a flow. Definitely thought provoking ideas. There's frameworks that you can go to but, no, it's not the scrum guide that says do these four events and everything will be perfect. That's right. Ohm, take us away. All right. Well, thank you for the six of you that stayed with us. We're increasing our population size now. It's gone up from two to six. Let us know what you think about this podcast and let us know what other topics you want us to delve into, but don't forget and subscribe. That's right. Down below. If you're Gary. And that's not a thumbs down. Oh, that's, I was gonna say all thumbs down have been edited out of Twitter, YouTube, and this podcast. Thumbs up.