AA143 - How Ego Kills Team Empowerment and Products

Om sent me an article earlier this week. I thought it was a really good article. The article is titled Ego Killed the Empowered Product Team. It was posted December 11th, 2023. The author is Jeff Gothelf, Gothelf, Mr. Gothelf. That's right. I hope I said that right. We were talking about topics for the podcast and I think I mentioned to you that I really wanted to have an episode on product Management and Ego. Yeah. Was the original idea, and then you sent me this article, and I was Well, this article is great. This is everything I want to talk about. Nearly everything I want to talk about. You know, I still want to talk a little bit about ego and experience. Because ego versus experience when it comes to like Scrum mastery or product management or organizational design or whatever, that could be a tight rope for example, in product management, there was a previous podcast that we had that said, well, if you have experience, it should be even easier to get the information, the data that you need to prove that a certain one case over another case to prove the way. Right. But At some point, wouldn't you say how many times do you have to prove the results of the experiment until the team just takes my word that this is what we need to do I think a lot of times where I developed one, one like an epic Is like a container for many, many stories, right? And the way that I work, that's the way different systems have different things. But we'll just stay with Epic and story for a minute. And Epic is more like a high level business goal and or, or an achievement of a high level business goal. And all the stories that lead the way are like little micro steps along the way to achieve that business goal. And as I go about achieving the goal. Some of it is evidence based, but some of it is just like when I cook up the stories originally in the epic to say we need to do this, and we need to do this, and we need to do this, I may have vetted the business viability of the epic, but that by no means explores all of the functionality potentially that we may develop that go along the way. And I think that's That's fine, because intuition has a role. So based on what you know, you project based on your experience to your point, right? And you say, chances are that this is where we want to go, right? But that shouldn't be cast in stone necessarily, because as you're inching toward that You're constantly validating. Yeah. Is this still correct? Yeah. And if you're doing that, there's nothing wrong. I think that when you're talking about experience, and in the light of ego, what happens oftentimes, the other side of it is, people who are experienced, over time, they manage to build up a level of ego, where, instead of explaining themselves, over and over again, if needed, To those people that are around them, they just say, well, because I said so. Yeah, yeah, yeah, I can see that. It's a two, it's a, I think it's a two way street. Because if I was on the other side, I might say, this time you might be wrong. Right. You've been right fifty times, but, right? Right, for people that listen to this, if they're not product management, if they're on the Scrum Mastery side of the house I equate that to when a new product manager or even manager or whatever, or even scrum master anyway, when someone new joins the team, that's what I'm trying to say when someone new joins the team and they try to roll out processes. That worked on their previous team and it's not working on this new team like that, that could be ego at play because if, if every team is different, the playbook for this one team and these personalities that made up that team, it doesn't automatically work. You have to explain why you want to have refinements and why a refinement is different than the sprint planning and why you're using scrum in the first place rather than doing whatever like it. You know, the, the, you have to bring people along and then like this where you were talking about, like this, the stairs that were going down, like all collapsed and turned to a slope and you slid all the way down. Like where that happens is you just don't have a desire to go through that, bringing people with you kind of step along the way. And I bring up this super long winded way of introducing this podcast to say. I like this article because it helped me understand how to pull this story out about the slide. From oh, I know what to do until over to like just do what I say because I want to do right like Saying I know what to do is not inherently Egotistical no that could be experience based. Yes, right? Yeah, and in this situation you think your experience gives you something you can apply, right? And that's fine But instead of instead of saying this is the way right to people around you say this might work We're gonna vet this out Maybe just do a little experiment, whatever, right? I think there's a nuance there that if, if you're traversing that in that way, you have a much greater chance of getting those people around you to go with you as opposed to I've done this before in my previous company, I did this and it worked. You hear that all the time. People saying that. Yeah. And just because it worked in this previous company doesn't mean it will work here. It's a completely new dynamic. I mean that, that right there. It worked at a previous company or it worked on a different team, like transferring success from team to team. That right there, I would like that to be its own podcast at some point. Agreed. Because there are some things, there are certainly some things that are transferable. Yes. You learn a skill, you learn how to have a difficult conversation, you learn how to lead teams from point A to point B. Sure, all those are transferable. But you learn a framework, you learn a tool, you learn whatever, And those may not necessarily transfer to the other team. Oh, I know a way to break down work, or I know a way to some kind of metrics what's like a, a goal, objective, kind of like OKR framework or something like that, some kind of goal framework. That may not work with the new team. A new team and a new org. I mean it's a different organization. Their culture is different. So I think you need to kind of look at that as well. Alright, let's let's dig into the article. I'll post the link to the article in the description. I'm gonna call out some highlights and just read them and the passages will kind of talk about them So I'm gonna skip around this article to the relevant points. He says That he kind of opens with the statement that feature teams are told what to do and are measured on delivering output. They're incentivized to ship products, have low levels of collaboration and almost no autonomy. Product teams, on the other hand. are empowered to solve problems, achieve outcomes, and collaborate across disciplines effectively. I mean, that's basically the, the difference between empowered teams and feature, feature factories. Yes, exactly. He calls that out real early in the article. He's also pulling this and says, hey, Marty Cagan paved this road a while ago, and it shouldn't, shouldn't be new to anyone. To end the introductory paragraph, he ends with, an empowered product team doesn't stand a chance in the face of ego. And then he opens the next paragraph with an absolute zinger of a paragraph header, which, by the way, could have been the title of this article. I'm, I'm, the jury's out whether I like the original title or this title. Oh, this one better. But it says, it says, humility is the oxygen. for empowered product teams. Fantastic line is a fantastic line. Let's think about that line for a second because spoiler alert, we're going to read the rest of the article. And there's, there's a, there's a good conclusion paragraph in this article. However, if you think about oxygen for the purpose of, I don't know, living, starting a fire, like many, many, many reasons, like the less oxygen there is, the less intense the fire can burn the less oxygen there is, the less intense you can work, you know what I mean? the less and less and less you have of it, the less functional, your team becomes. So it actually is a really great analogy for saying Hey, humility, it's like oxygen. You have less of it and things don't really work too well. Yeah, that's very true. I like this kind of this, this analogy or metaphor better than the fuel metaphor. You know, humidity is the fuel for Empower product teams. But oxygen works better, I think. Yeah. Also, I like that because also like the egotistical people who just suck all the oxygen out of the room and there's nothing left. Nothing left for anyone else. That's very true. That's right. So he says inevitably teams and organizations struggle to put this model into place. The model of empowered teams we were talking about consistently causing frustration, blame and ultimately suboptimal products and services. The team's working to help their customers are frustrated, the people who suffer the most with this failed pursuit are the end users and the customers. Yeah, I, I certainly concur with that, but I also think there's something else there. He hasn't necessarily called it out. People that suffer are, you lose good people basically, right? They get frustrated. They won't stick around. If they're frustrated, they're going to move. And so if those people are good, you're going to lose them because Yeah, I think that's, I think that's accurate and I worked for at least one organization like them, probably several teams like this before, but one organization in particular I'm thinking about that had just a giant ego near the top of the food chain. Once people rose in seniority to the level where they, like the glass ceiling they were butting up against was that person. And they realized they were never going to get above that person just because of the ego in place. That was when they usually left and some people took years to get there. Some people that caught on and were real strong hard workers and real sharp. They got there sooner but again, I remember staying in that company watching, watching just, just the churn as people realize that this is where the glass ceiling's at. And time to keep your resume updated and move. I imagine anyone listening to this who probably realizes There, there are glass ceilings at their company, like it's, it's a shame because I, I would think that like if you're a CEO or a manager of a company, a leader in a company, right, boy, you would want to, just break all those glass ceilings and be all right, that, that can't happen, that can't happen cause they were, I mean, they were career dead ends for people and as soon as they saw it, right. You know, the younger the person, the quicker they would make the decision with that. Like as soon as they saw that block, they, they, they were well, got to move. Yeah. I mean, if you're a leader and you want to make this change. You won't be able to do that if you yourself are mired in this cloud of ego, right? So let's say you brought in people that are below you, right? And so you've brought them in now for you to say, okay This isn't what we want or move them sideways is basically an admission of failure It looks bad on you because you brought them in so you're less likely to do that It kind of feeds on itself, I think the sad part about this, like what I was just describing about the the, the, the up and coming people I mean the people who are gonna carry the company forward into the future, the people with the, the, the different ideas that are gonna kind of re-energize the company over and over again. They're never gonna stay. Instead, the people that are going to stay are the the yes men. The, the yes men. Yeah. They're, they're the people that are never gonna challenge. The ego of whoever that is that's sitting there establishing that glass ceiling. And then, usually people like that will just, they'll just hire in and retain and promote the people that just say yes to everything and never challenge them on anything and, and, and back them, basically, if they were to be challenged in the organization, they'll, they'll back them. You know, I've, I've I've experienced that before. I think people that are in that position. They hire people that are just like them basically so that they can feel supported, right? And not challenged. They feel uncomfortable being challenged, especially by people below them that are younger. And so that's kind of what I was saying. You know, these young people are gonna get fed up and leave. And they may be very, very smart you don't want to lose that. Younger, they will challenge them, yes. But where I've seen it more often is they won't hire older people. They'll, they'll, they'll tend to hire people at the start of their career.' cause they don't know any better, right? They haven't worked in a bunch. I mean, they, they, they don't know that they're getting abused, basically.. . Sad but true. This is a, this is a true, true, like if you came to a place for optimism I mean, you're in the right place, but also keep their resume updated and protect yourself. I don't know what kind of statement I'm trying to make right now. The po the point was. This workplace that, that they would never hire older workers because the older workers, they wouldn't stand for this kind of stuff, you know what I'm saying? Right, right. Plus they have experience and different viewpoints that they like to put forward. So, again, this person's not going to hire them because they feel challenged. I feel like there might be, There might be people listening to this that, that are starting to realize they starting to come into focus is Oh, my team only has all junior people and it's like we make me even like I think about like a development teams I've interfaced with that are like all junior developers and I have to look around for a second and be wait a minute, this is so strange, like we're, we're the, we're the development leads, we're the architects, we're how come the team, the whole company has nobody like this. It's so odd. This is part of the problem. Chances are that company is looking to hire the maximum number of people for minimum dollars. Yeah. Right? Right. Well, again, when I climb the ladder to look, who does all the development hire? There it is. There's that glass ceiling. There's that person who doesn't want to be challenged. Who doesn't ever want to be told. It's not even be told that their ideas are bad. It's they, they, their ego is so fragile that they can't even have their ideas challenged, which is, which is difficult for me coming in as product management, because , my role professionally is being told that all my ideas suck. And I have to be prepared at any moment to defend any of my ideas against. Any challenger in the company and have it not be a challenge to my ego I it should be completely fine to say Brian I don't understand why why we are prioritizing this. I think this other things more important Can you please help me work through why we're headed in this direction not that direction and that should be okay More than that should be Welcome with open arms because whatever strategy you're following becomes truly battle tested, right? I mean it's being challenged from different directions. And so if there are any weak points, they will come out And you'd rather have them come out there then pursue the strategy and then have it fall flat later. Yeah You know that that's that's my thinking is fail up front if you're going to fail and be open to it I mean, I like to get when we're talking at the strategy level I like to get a lot of representation and a lot of voices in the room together at the same time like Physically if possible actually in the room not work best. Yeah, we're not customers get some of those in there, too I I would I would like it. I would like to yeah but I mean, again, there might be people listening that are well, that, that would not go over well in my culture or it would be seen that not even people listening, but even in my own career experience, I've worked in some workplaces where what I just said, which is, Hey, can you show me why we've chosen to go with this path? Rather than that path. I, I mean, I like you that right away Brian's not a team player. Yeah. Bri, Brian doesn't troublemaker. Yeah. Brian's a troublemaker. He wants to know why we're employing this strategy. In most companies, you don't even get to ask the question. You're just told, this is what we're doing. Yeah. Now go go play ball.'cause we're doing it this way. As I said so. Well, I, I mean, to like to like to, to actually give people a tactic like I feel like I, what I. the way that I just asked the question that that's the most softball way to bring up. Hey, I don't think we're heading in the right direction. Right? Hey, can we sit down just help me walk through our strategy of why we're going with in this direction and not doing this or whatever or why we're servicing this persona and not these personas or whatever whatever it is like if you sit down with the people that make the product decisions, even if you don't have product managers or whatever, development makes decisions, you have a CTO or maybe you work directly with a CEO. It doesn't matter who it is. It's just the decision maker at that point. Just help me understand how we made the decision. I think that that's not super threatening. It is not if you're you. Really targeting the problem rather than the person. Yeah. So don't don't attack or don't challenge the person, right? Don't say can you explain your strategy? Why did, why did you make that? Yeah, yeah, yeah. Why did you decide? Exactly. Because that, that's when people just go on the defensive. Right. Just say, I'm trying to understand the direction we're going in. Can you help me with that? Right? Like I feel like we've, we've gone way far from the article. To pick back up on the article. He says no amount of books, Ted talks and LinkedIn posts are going to take ego out of the leadership equation, empowered product teams fail because of a lack of trust. Leaders, egos buoyed by titles and salaries believe they know best. Their teams are here to execute their vision and to do it predictably. Smart people they hired to do the work aren't there to question or cast doubts on the vision. They're certainly not there to change course once a commitment has been made. Regardless of what the team learns along the way. Shots are fired in this article all over the place. The creation of the vision and, and again, going back to our previous podcast about vision, mission, mission, vision, and strategy the creation of the vision and the strategies that execute on that vision. I will tell you very rarely, is that a collaborative effort? You know, it's Hey, sales is going to tell us what the strategy was. CEO is going to tell us what the strategy or whatever operations or whoever whoever it is in your company. So there's that, that there's that I can understand why he goes involved when only like one person says look, I'm trying my best. You know, I'm the only sales guy in your company. I'm trying my best. I got these strategies. I'm trying to figure out to how to get us into certain markets or how to do whatever. I'm trying my best. Just don't beat up my work. You know, I, I have a lot of empathy. For people doing that, they don't realize that like sales is a skill. And maybe if you're the sales guy, or maybe there's like a, a small sales team in a large, like a lot of software development firms I've been in, compared to the amount of like software engineers and developers they have. Their sales team is small. Sure. So the sales team has a lot of pressure to get out there into the market, especially in B2B sales. However, wouldn't it also be helpful to, to, to help spread that sales skill throughout the company. So everyone turns into the ability to work. So, so everyone ends up having the ability. To do sales, like maybe it's not, maybe, maybe I don't want, maybe they're not front line sales people, but yeah, but, but can you add them to a call and have them understand the basics of, Hey, here's how we vet a potential client. Here's how we the whole sales cycle should be understood, right? They may not be able to practice the sales cycle, but everybody should be able to understand what that cycle is. Right, right. So I think there's a couple of things I want to pull on here, right? One is if you're the person who is creating the vision and then just simply passing it down and saying, this is how we're going to do things, tossing it over. Yeah, if you're doing that you might want to think about working on skills where you can bring people along with you as opposed to just dictate to them. Right? That's kind of going to work or creating the vision with people. Now in most companies, that's not done. Yeah, right. At least I haven't found that most companies, but imagine what it would be though, if you call people from different areas, different domains of the business together and say, this is what we're trying to do. How best can we do this and get everyone's voices heard and create a vision from there? Yeah, that's a different level of collaboration, facilitation, and. You know, skill working with others the, the skills that basically not everyone has. I think it starts with those leaders having humility to say, I'm not the right person. The only person who should be creating a vision. It should be a joint effort. If you acknowledge that, then I think it gets easier after that because you can then practice some of these things we talk about. On the product management side of the house, what I, what I can bring to this is to say, if you do, if you create the vision and the strategies that come from that vision in a collaborative manner, or even if you create strategies first and you back up into the vision, because we talked about that too. Even if you do it that way and you collaborate with all, all of the teams in your, whatever, in your, in your segment, maybe you're a really big company and, and like all the teams is not a realistic thing, but, but you're, you're a corner of the organization, right? What you'll end up with is since you have the people that do the work on the teams or representatives from those teams or leads or whatever it is, you have the ability to say how can we test the business viability of strategy? What does the MVP of this strategy look like? And also, you can do the old project management thing where you're, you don't get out of a meeting without putting someone's name down to each one. Which team, and it's, it's our world though, so we can say we're not putting names down, we're putting team names down. Right. So, I'm going to distribute. To the teams and I'm going to ask them to commit, Hey, I would like your team to test the business viability of that. Oh my goodness. Business viability that, well, we're really a development team. We don't really like talk to customers who don't adopt products or whatever, well, well, you know what? It's a great time to figure out how to do that. Like it would really help the business. If you can figure out how to test the viability of this thing before we move it into active development and start building features, like figure it out. You know, listen, you're going to figure it out or what, or who's who else is going to figure it out? No, no. So the alternative is, is What, what we see all the time, right? That's quite prevalent, which is nobody figures it out. Somebody just comes up with it in the ivory tower, and then people just keep marching. This is what I call the sheep march, right? You just jump right over the cliff. You know, we're following the leader, and the leader goes over the cliff, and everybody goes over the cliff. You can see the cliff from a mile away, but nobody says anything. Right? So that alternative, that reality sucks. The smart sheep will just go, wait a minute, I'm not going. And then they leave the company. That's that sales pipeline., sitting in your company meetings, you hear about all this, but this long pipeline, all these customers, and we're betting this and doing that. I'm like. I mean, wouldn't it be better if you, if you actually engage the teams and brought them along through your pipelines that, Oh, well, here's what I know about this customer and here's the, what I've gathered about them. I think this team would be best to be engaged with this customer. Maybe I'll bring them along and then this other team for this other customer is doing these things and you start your sales people start becoming collaborators with your teams. To bring them along and include them in the sales process. A nice benefit of that is also customers come along with you, right? So you're building trust. The customer builds trust in your company because now they've met with other people, not just people that make promises, the sales people, but people that are lower down in the organization, the development team members even, right? And they can, they can have a discussion. Yeah. You know, and believe it or not, I've, I've seen this only very, very sparingly, but where I've seen development leads. Engage with customers, eventually more businesses resulted because the customers can ask questions I wonder if we can do this. Well, we can't quite do that, but we can do this. Now that becomes a feature that they can pay for. But that wouldn't happen if that dialogue didn't happen. Sales people don't know to ask those questions necessarily. I mean, they probably do, but I feel if you're asking questions and you have the Marty Cagan trio the, the designer, the product manager and developer in addition to the person who's an expert in sales I mean, now you have, you, you, you asked the question once, You get the answer, any of those people can ask follow up questions. And now, there's not a further communication channel that needs to happen. There's not six months where the requirements to get to a delivery where the customer's I didn't want this, I wanted something else. Like you, you can find out right there in that opening, in that opening salvo you can find out. What he finishes the article saying is an empowered team threatens the viability of that initial idea, as it should, in parenthesis. Humility is in short supply and without it, empowered product teams struggle to survive. So, again, everything we just outlined about, well, sales brings this along, the easiest case to prove what he's talking about is to talk about all the companies I've been a part of where you know, sales is incented on over here and product development is incented over here. And if product development is incented on the number of features that you're putting out or hitting X number of bug fixes or whatever, whatever it is. And, and none of their incentives have. to do with talking to customers or helping other departments or customer satisfaction in any way, shape or form. There's a good likelihood that even if they were invited. To these sales calls. I mean, they're gonna be well, I'm too busy trying to knock out my incentives right to work on features. So if you draw, if you draw little circles around all little groups oh man, like that, that it says humility is in short supply, but Kind of my challenge to this sentence is I don't know, is it humility keeps you from doing that? I, I think the systemic concept of bad organizational design. I mean, maybe you could say it's humility, but, I don't know, it's, it's really not, it's really not just humility, to your point, it's, yeah, not just. It's bad org design, it's, it's bad overall system, I guess, right? The whole system of rewarding people based on X, Y, Z. That, that you need to look at and say everybody is in it as a company to survive it together. It's not just Development teams are incented on creating features, they're going to create features. But, are those features the most valuable features for customers? Yeah, and how are you proving they're the most valuable? Are they getting used? There's a whole post release measurement, like apparatus, seeking to prove our initial assumption and in the world of ego, you'll actively work to not look at features after the fact for their adoption rate and to, you know what I mean, because it might undermine Your telemetry is going to stop at delivery. It might undermine your initial assumption that says, oh we, we've got to build a button that lets a customer do operation Z. Okay, Mr. Executive, you said that we had to do that, and now we did it, and here we are two months later. And here's the measurements of how many customers actually do operations. Zed. nobody likes to do it. Nobody does it. So that's not what that leader wants to see. Yeah, yeah. Well that leader, if, if ego is in play, they only will interpret that as finger pointing. Of course. They'll be Oh no, you're just finger pointing at me to say that I made a bad call or whatever. Yeah, but you didn't implement it, right? Yeah, you didn't implement it right. That's exactly right. That's exactly this is a real conversation. Oh, yeah right now like this is this is again. This is we'll get here in a second About all the data in the world may not be able to climb the mountain of ego unless there's some checks and balances in your system. Absolutely. Absolutely. That mountain needs to be burrowed through instead of people can't climb that mountain just make a tunnel through it or something. He has a great story about joining the, the, the Tony Roberts band. And he says, and he says in a quote, he says, when you join a band with a person's name in it, you have a clear sense of your role in that group. You're an employee. Not a collaborator, and that's a, that's a little story he has here, which is a pretty, pretty good in the article you know, which is it was just the same thing we're talking about is Hey, you can bring evidence and say, Hey like we implemented features ed and the the, the, the evidence says that people really don't want this. And we went through the trouble of implementing it. Cause you know, you said, Hey, just take my word that people want it. And then we did it. So. This is just a, it should be a small stepping stone of listen, we should gather more evidence before we build stuff. Again, I, I feel if you're working at a company that's old Tony, Tony Roberts company, the Tony Roberts company. Ooh, they're there's a certain expectation right there on the name of the company that yeah, those conversations are not gonna, they're not appreciated. Yeah, folks, if you're at one of those companies, keep your resume updated, first of all. You know, I mean, somebody like myself would probably just say. Okay product lead, CEO, whomever, we did exactly what you wanted and here's the adoption rate nail that nobody wants this, right? So, okay, I'm, I'm not challenging that person necessarily. I'm evidence driven. I'm saying, look, nobody's using this feature. And then, cause I'm me, I'd say, wouldn't it have been better to do something else in that time and effort instead? Where's, this is our opportunity cost. You layer that on top and you go, we wasting money here. Yeah, it's been nice working here. That's, that's exactly right. I was sorry, Om, like you, you don't bring me problems, just bring me solutions. That's, that's the, that's the manager I'm thinking about right now is who says that you just didn't implement it right. And we, and I'm going to double, triple, quadruple down and say, we're just going to keep the development team on this feature until it gets the adoption. You know, when in the first place, the, the assumption that people needed, whatever the feature was. was flawed in the first place. Yes. So adding on to it and trying to bail it out. It's just a losing proposition that is that's just like that's trying to swim in quicksand right in the pit of quicksand. I've seen it way, way more than you. I agree. I agree. Keep polishing that. Keep polishing that and nobody uses it. I mean, there again, that glass ceiling, that glass, you run into somebody like this in an organizational position that is just not open to coaching, not open to evidence. There may be like everything we're talking about spoiler alert everything This article will conclude with it may not have an impact, you know again if you have somebody with no self awareness no Reason to change no, no, there's no spark. They're kind of pushing that person. No spark pushing the person with a terrible analogy There's no propelling the person I don't know. No arm pushing him off. This is not getting better. There's no person there with the ability to soften that executive ego. That's his next section. Softening the executive ego. You would think this section would give you some tips about softening the executive ego, but let's, let's read it to find out. So he says he quotes Vince Lombardi. He says, perfection is not attainable, but if we chase perfection. We can catch excellence. Good quote. Good, good, good little body quotes. Yeah. He says we, we, as an example of this, he says, we, we may have never spoken to customers in the past, but, but today every every quarter we talk to two customers. So listen, we know it's not great. We ideally we want to be talking to customers every day, every week. We're doing two a quarter. It's a start. It's a start. Yes, it's a start. We understand we're headed in the right direction, right? He says if you if you weren't talking to customers at all And now you're talking to customers twice in a quarter You've you've you know, you have 200 percent extra chance for learning now that you didn't have before Right? So the more you do it, the, the, the more your chances increase and improve. So, that, that's the point of that article, and then he pivots to another zinger of a statement. Which isn't necessarily related, but it's a great statement. each process change can be measured in the impact it has on the product. That's a super powerful statement. It really is. Which is, it's weird. At the beginning of a new paragraph, after quadrupling learning opportunities. It's strange. It's placement in the article is strange. I don't quite understand. But. Well, like in and of itself, like if I just stole that and posted it to LinkedIn by itself, like it'd be a zinger of a post. Each process change can be measured in the impact it has on the product. I guess the assumption here is you're measuring, you're measuring. You're the things that you roll out you're measuring in terms of impact on the product Yeah, you can you can measure your impact on the product. I guess that's the assumption because oh boy some companies don't even do that They don't they don't that's right. So assuming you're actually doing that. You should be able to see a process change Any process change you should be able to see a deviation above, you know above the the horizon is it a positive? deviation or negative deviation right and it through the The whole control theory control, closed loop control theory, right? You should be able to say, if we do more of this, we'll get more of the impact we want. We do less of this. I mean, it's common sense, but to your point, not many organizations are measuring the impact on the product of their process changes. so when you develop a feature, and you roll it out measuring the impact of that feature is, is one discipline and, companies Probably commonly can figure out how to do that. It's probably common. They get, even if you're like technical architecture is kind of evolving and you haven't quite figured out how to measure the impact of features on users when you roll them out, measuring the impact of process changes. Like that's an advanced concept. Like people think of process changes, like the, the impact on the product, meaning like velocity increase or a number of features, or maybe like reducing defect, reducing defects, right? Yeah, yeah, stuff like that. Not like impact on the product. Like I feel we could, I feel we could take this whole sentence offline and have a completely different podcast. I like that. Just exploring like. How can we, different process changes, how might we measure their impact? That's a very, very valuable broadcast, I believe. Because it would benefit a lot of people. I think it would, the thing I immediately think of with this is backlog refinements. If you're not having backlog refinements and your sprint plannings are becoming pseudo backlog refinements and pseudo sprint plannings together, or Your sprint plannings are becoming backhog refinements where you just create the work out of thin air and then The work as your team picks up work items, they start refining each work item and planning it. You know what I mean? Like you have no idea how long it's going to take something and then you get rollover from sprint to sprint process changes that lead to impact on the product. I'll give you another one here, right? So reviews and demos, why wait till the end of the sprint to show something to your customer? Right? Why not? As soon as the feature is ready to show them, show it to them. Don't wait till the end of the sprint for your sprint review or a demo. Right? So you can measure the impact to the product in terms of maybe you have a more robust product because you're getting feedback faster. Maybe your time to market is lower. I don't know. Yeah, yeah. Potentially. I mean, you could there's a lot of people out there that say don't measure NPS, but like I immediately think you could follow, like after all of your process changes, you could be tracking NPS as well to see ups and downs and you know, whether or not that's aside from the conversation, whether NPS is good or not. I mean, if you just made a process change that might be the beginning of a trend over time. I don't know. I don't know. This is a super interesting topic. We're going to pause here because, again, I think this deserves its own podcast. I don't hear about this topic in the, in the in the agile sphere, anywhere on the internet. So it's super interesting. Anyway, he says further the idea of measuring the impact on product, he says, every win we collect is evidence. We can point to earlier successes and then start implementing them as a default. So this is the old best best practices, the old best practices from the nineties. Yeah, I remember. And then he says a as we implement these, these earlier successes as defaults, step by step, we improve our ways of working. If we can connect these wins to the leadership team's goals, then the trust will increase. He's right on all of those things. I mean, I just want to point out, he says, says every win, but you know, whereas things don't work, that's a learning opportunity to trade should be. Should be, should be usually what comes along with ego is the inability to, to tear apart and really analyze failures because or even to accept them in some cases. Oh yeah, right. Yeah. Well, if you can't accept the failure, if you, if you cannot accept the failure, you cannot ever learn because tearing apart the reasons. Why you failed something like it could be something as easy as well, this was, this was our sprint goal and our sprint goal was to implement feature X at the end of the sprint. We did not implement feature X real cut and dry. We just didn't do it. Maybe we were real close, but we didn't do it. Okay. Why didn't we do it? Well, when we got into feature X, we realized that we didn't do enough refinements on feature X and the critical path that we mapped out, we had to go back to the users, get them back in the room, and talk about it. So I mean, the takeaway from that might be, maybe you didn't have the features, maybe you didn't have the users in the room when you talked about FeatureX originally. Maybe you didn't have them in the room for long enough. Maybe you didn't have the right people in the room. You know, there's a million things we can do about that, but if you never, Do five why's if you never talk about that if you're not even allowed to say fail If you have to come up with excuses and sugarcoat things or pass it off to somebody else or I've been an organization But they just blame somebody and then they get rid of that person. That's right. Exactly Yeah, they're there. They've immunized themselves from having to deal with failures So they basically never learn anything. I mean, that's I mean, I guess it's I was gonna say I guess it's good for the people that stay there But I don't even I don't know if it is because like do their skills ever really develop They just stuck in like a little static bubble. That's right. That's exactly right. These people Become lifers until they're the whole company goes under right? Yeah, right Oh, I mean or it's their turn to accept the blame You know, and throw themselves on the sword for the right into the fire. Yeah, yeah. I mean, that's more, more likely to the scenario in companies like that. So again, keep that resume updated. So he's going to close the article. The title. Of the section that closed the article. It says evidence will overcome ego. I have big problems with this title, but I'm going to read it. I'm going to read on anyway. In the same way we use evidence learned from in market experimentation, we can justify the organizational design and cultural changes we want to make. I think he's bending a little bit into cultural changes into changes in org design, changes in way teams Talk to each other and, and, and interact with each other. So he says if you can repeatedly prove that small changes in your team's ways of working yield stronger results, product results, you can expand the autonomy and empowerment of your team. And evidence will overcome some part of the ego, not all of it. He just risked himself there. Yeah. Some part of the ego. Some egos you just have no chance against. that's exactly true. And then he finishes the article, he says, and your customers will thank you for it, which I feel is just like out of everything in the, in the last paragraph if I'm going to take issue with anything in the last paragraph, it's what you just pointed out, which is like some of those egos, like no, no amount of evidence is pretty watertight. So I think, if you really kind of go the distance on this, maybe over time you can mold. Your organizational structure in such a way where a culture gets to be instilled over time again, it's just over time. Nothing's gonna happen quickly. Where when you have one individual with that watertight ego, everybody else around them can see that right and deal with it in some way. Usually it's pretty drastic. You know, it's well, we just don't agree with the way you're working here. It's not working out for you and so maybe we'll see around but that, that, again, it's rare. You don't see it very often and when you do see it, it's, it's, it's never a case of, hey, it's not working out because that person may be higher up in the organization. My experience with this is if, when you're tiptoeing around when you have this individual that like their ego is just, you're just not getting around their ego. that they're completely going to be a roadblock. No amount of wins are going to get you past this. I mean unless you're executives are, are willing to make a change or whatever management, it has to be a drastic change. It has to be addressed. Cause yeah, everything we're saying, like these are valuable skills, like building your evidence, setting your case. Connecting it to strategy, connecting it to your leadership and your manager's priorities. All valuable skills in the workplace. They'll, all these skills will transfer with you from place to place. And certain people will appreciate it rather than others. But again, once you realize this glass ceiling is here, that there's this ego you just can't deal with and overcome. No matter how much evidence or how many times they have to be wrong. You know, and, and then blame someone or reject it or deflect it or ramp up that narcissism or whatever it's going to be. I will argue against the, the, if you can repeatedly, Prove these small changes. They'll make a difference. Yes, in some cases. Yes, they will I would say probably in most cases honestly, like a reasonable people in most cases Yes, but the what he ends with and your customers will thank you for it that I feel that is the strongest way Around one of these roadblocks because the, I remember I was at a company one time where we had a really influential, really important customer. And we, the team ended up establishing a relationship with that customer. With the customer really liked the, the product person. And he really liked the team. He really, the, the cu, the customer really liked that. I mean, I I'm I'm a direct communication. I'm a direct communicator. I will speak directly to the problem, you know I don't like to kind of dance around issues or whatever. I like to jump right in. I don't mind people challenging me and I don't mind people asking Hey, how did you come to this conclusion? Like directly like that. You should really welcome that because like I said before if you have a thesis of some kind and people are challenging that and you can talk your way through that. Now that thesis has been tested, right? And the more challenges that your thesis survives. The stronger it is, the more robust it is, so you should welcome that. Otherwise, there's an element of risk there that's something that you haven't considered undermine your entire approach. So I'm with you. I don't mind people asking questions. If they're open to listening to the answers, this is why. And I'm also one of those people who'd say, Oh, I didn't think of that. Right? And maybe we need to pivot a little bit here. So that's the whole point of that that collaboration has the value of getting multiple people's insights that can be brought to bear. What he ends with and your customers will thank you for it, I feel is the strongest, most helpful. Piece of the article is to, to remember to point out to people, Hey, if you're stuck in this, like battle of egos let's kind of push the egos and all this stuff off the table and get the customers directly involved because that ego is much more difficult to maintain. In the face of real customer feedback. You know, I mean, real cus like evidence is one thing. If I have a system and I'm tracking things, like if, if I, if I'm in a, in a, in a a B, two C type of deal where yeah, I have users, end users that are using my product and I'm, I'm kind of watching their behavior through metrics. Mm-hmm. That's one indicator of evidence. Evidence of user behavior. And that should be enough to kind of level the egos, but sometimes it isn't and sometimes people throw out things that they claim are outliers Yeah Until they get to their until they funnel down to their kid I had a director had a director of development one time who was a he controlled all of the statistics So you would when you wanted statistics on the product usually had to go through him and then he would export Oh, he'd filter out stuff. He would, yes, he would filter out stuff before you get it. So yeah, you would never see these outliers to chase cases. Anyway but if you have the customer's direct input that you're starting with, I mean, once the customer gives you their input. Then you can look at numbers from that, but you're starting with a base level of understanding of this is this is the customer's experience. Let's all get together to talk about, it's not your idea, my idea, whatever, it's the customer's problem that we're all agreeing to solve. Yeah, I think that's your best hope really is to see the impact on the customer, translate that. And back that into your strategy and say, it doesn't matter who's right, wrong, but this is the impact. How do we change that? Yeah. And let's just go create another approach. Yeah. Right. It certainly helps have ways to measure customer impact. But this was a, this was a fun article. I don't see a lot. Posted in the product management Agile space about dealing with egos. I feel there could have been paragraph somewhere in here about tactics to help you approach this situation. But we, we will include those in our, we hit a few, we hit a few of those indirectly and directly as well. Great. This has been, this has been interesting for me because it's not an angle that you see being pursued elsewhere by you know, other, other podcasts or anything like that, even other blogs for that matter. So this was very useful. I think anyone who works in product management, if you're not allowed to ask. Like what, what brings you to that conclusion and, and, and if your reaction. So the question of what brings you to that conclusion or what made you prioritize this over this or whatever no matter how clunky it's worded your reaction to that, it's, it's, it's sending a message. So if you're listening to this and you never thought about ego in the past. Hey, like , let's think of, let's stop and think about your reactions to things for a second. Absolutely. No. So when, when you are challenged don't think about that question or those questions as challenges. Think about those as ways to improve your own Yeah. Idea. Your, your strategy. Well, it's, it's your communication about the strategies that the co, that the company is employed in. Because again, a lot of times. At the, at the strategy level is where I, I personally have encountered ego a lot at the strategy. This strategy or that strategy. Is the strategy working or not? What should we do if the strategy, if we all agree the strategy is not working? Because again, the people who originally proposed the strategy or backed the strategy or made the original assumption, they got a lot of ego in the game. You know what I mean? They got a lot of their confidence. Is built on that thing succeeding. So they, they're, they're not willing to say this strategy is a failing strategy. Absolutely. Even though it might be feeling right in their face, it's, it's, it's a compensation side to it. It's super tough. I mean, it's super tough to deal with failure. Maybe that, maybe that's also a separate podcast of I mean, it's how, how you like encountering failure, like. I mean, you, you should immediately pivot into what do we, what do we learn from this and what can we do to stop failing? You know, but again, once the quagmire of ego is all gumming up the process here. I mean, it's real difficult to move forward to any kind of successful path. Yeah, I agree. Again, let's, let's end by saying, hey folks, keep that resume updated. If your ego allows, please subscribe and like. And, let us know what else you'd like us to talk about.