AA155 - Weaponizing Standardization

0:17

Welcome back to Arguing Agile. We had a podcast a while ago called weaponizing Efficiency. Yeah. And now we're doing sort of a part two with a podcast we have titled Weaponizing Standardization this podcast idea came up because I was in an interview where somebody asked me I see that you've been through mergers and acquisitions. What is your opinion on standardization? Because a lot of times when you get integrated into a larger company, there's a lot of initiatives. to standardize things and to sanitize things and I can't remember the exact language the individual used in the interview but it got me thinking I was like you know I'd I do have some experiences in in this in this arena to talk about yeah absolutely and this happens right whether you know whether it's an M& A or You know. Yeah. A divestiture or whatever. I find that word hard to pronounce. But anyway, split up . Yeah. So that this happens all the time. The company buying the other company will typically come in and say, this is how we work. Yeah. Everybody just assimilate. Right. And so this podcast is gonna delve deeper into why that's good or why that's bad. Well, Let's not make everyone guess about what side I'm on in this conversation, Because I'm going to dive into point number one, when you deal with standardization, the challenge of standardizing all of your software development teams or your processes or your processes, if you live somewhere is that you said a good chance of stifling innovation when you start laying down. Heavy, heavy processes that have to govern everything. And they had that word governance. Oh no. It's got to go through governance before we can start any new initiatives or exploring new technologies or do any cool stunts. Yeah. So the first thing I'd say here is that the acquire or. The company that acquires the other company or merges, usually there's, they're not merges of equals. They really don't bother to get the context of the working situation of the other company. They simply come in and say, this is how we've been working. This is how everyone will be working. Right? So from that perspective and from the point of view of the company that has just been acquired, you are stifling innovation because you're saying, get in line and do all of these things. That we want you to do, right? These are all maybe bureaucratic to some people, but this is how we need you to do things, right? These are the systems we need you to use, for example. So instead of coming up with a solution, right? You have to abide by what you're told, right? And that I can see how that would stifle innovation because you're, you're really not doing anything new. You're simply going along with what's been imposed upon you. But you know, I would take the other side cause we are arguing as well. That's what I heard. Yeah. So, so you could say, look, the company that is being acquired, if they fall in line and work in the way that this larger company is dictating perhaps, right? Then what's wrong with that? Right. What's wrong with, what's wrong with a proven way of working? Presumably the larger company survived. And they are the acquirer. So they're going to say, do it this way. And we're right. Well, let's, let's walk through this. Yeah. Let's walk through this theoretical conversation for a second. And, and also like, it doesn't have to be an acquirer acquiree deal. It also, like I've seen this. After IPOs, sure. For example , the company will bring in professional management and the professional managers will say, Oh, we need some standards. So we need some standardization. Well I also, I've seen it when like VP level, like C level executive type of people change the operations. COO would be a good example like COO changes and now like, well, I need to know everything is happening because I'm I'm operations. So I need to have my fingers in all the pies because operations, he's to know everything or a new CFO comes in and says I don't understand where. All of the money is coming from, so I need to standardize all the financing. Or where it's going, yeah, absolutely, absolutely where it's going, yeah. I don't understand why some teams are small and some teams are big, but on paper it seems like they're all bringing in the same amount of money. You know, we gotta, why don't all the software development teams have 4 people instead of 8 people or 12 people? Like, why are they all different numbers? I don't understand, this doesn't make sense financially to me. So, so they're saying like That something doesn't make sense. So from that perspective, it's not an acquirer or query position. It's just that something changed in the, in the, in the management of the company. That's a better way to say it. It's a less challenging way to say something changed in the management of the company. And someone's just trying to understand things. Well, you bring up a good point with finance because they will be looking for standardization from the perspective of saving money. So they might look at it and say you have five teams using this tool and you have three teams using this other tool and why don't we just have one tool and then we can negotiate a better contract with the vendor, right? From an accounting perspective, they're not wrong. But what they don't realize is You know, these teams have evolved to the point where they've chosen the tools they need. So if you're going to mandate something on them, what are you actually giving up, right? And that comes back to the innovation piece. The teams that are forced to use a different tool for the sake of saving money, they may not be happy because that tool doesn't do everything they want it to do. So they're going to go along begrudgingly. Right, and you'll have impact on motivation and all of that good stuff that happens when you tell somebody how to do their job, basically. Well, well you're steering us to talk about a topic here that is super important to me in product management, which is, hey, we've like, to go back to the acquirer acquiree conversation. We've acquired this company over here that is very successful, and we want their customers, or their line of business, or we want to break into this market or whatever. There's usually a reason to acquire a company. And let's say, for example, like Brian & Om's development software company has acquired a Brian's side business company, right? Brian Ohm's software development company uses AWS for everything, Brian's software side company is Azure cloud. So now that we bought the company, we said, okay, Brian, Brian wouldn't be there because Brian left the company because Brian's not sticking around through the acquisition ha ha ha! But, the people that left, the people that stayed with Brian's side project company, that are now part of Brian and Om's software development company, who by the way is not owned by Brian and Om anymore, that all, that got bought years ago. Like, several podcasts ago, that company got bought. Ha ha ha! Yeah. Like Well, we can't have you on Azure because now we're paying an hour. We're cutting a check every month to AWS and we're cutting the check every month to Azure. You guys need to just migrate all your stuff from Azure over to AWS. Like, so the product manager now in play, like looks up and says, I had to do what? Like so basically you just gave me a mandate to standardize for the sake of standardization. Because product wise, it's gonna be months of work to do that migration and at the end of the migration, what is, what benefit, what financial benefit will my product gain? Nothing. Right? Nothing. So, as a product manager, in that position, immediately. I feel like I'm going to get marked as the bad guy in this conversation because I'm going to say what business sense does it make to migrate us off of Azure cloud just so we don't have this line item expense of our service on Azure cloud because you realize whatever money you save from not having a second bill paying the Azure subscription, you're going to double your AWS bill. Because we're just going to move over and use bandwidth on AWS. So you're going to pay those costs. So, so really the only thing you're saying is my, my accountant that pays the bills at the end of the year has an easier time. So, so basically you've, you've gone through this whole standardization effort so that some back office accountant. Has an easier time once a year, you only have to pay one bill to pay a bill. I agree. I absolutely agree. But I also think that there's this from a product lens, right? If you have to do this. Yes It's a it's a decent size effort to say the least what could you be doing instead? Right for your product. So I mean it's chalk and cheese to me, right? Bringing in a lot of money. That's right. That's what I could be doing. Evolving the product, exactly. Or taking a vacation for a month and not working at all. That's worth a lot more than consolidating cloud platforms. I mean, to me it is. I mean literally twiddling my thumbs at my desk. Like, there's a million things I could be doing that will be better for my team than going through a big technology underhood change that gives no value to the end user, helps nobody in the company except for one accountant in the back office. Well, as a product person who's forced to do this work to consolidate CSPs, you really need to keep that resume updated. Because you're gonna get bored. I mean, at that point like, if you're a good product manager, or even if you're a Scrum Master on your team Helping product you're gonna be asking these whys you're gonna be digging you're gonna be doing five whys what? Why do we need to? migrate off of Azure to AWS You know and and if you're not giving me a list of like well These are the things that are available to you on AWS or for example Well, there's some stuff that we have available in our AWS cloud on the back end that you guys are paying extra for that We'll drop off of our expense list. So really Like our monthly expenses that you pay extra for, cause you have all these plugins or all these custom features or whatever that you've built, you don't need to deal with that code base anymore. So like if there are real gains Oh, your, your logs won't be jammed with all this garbage, all this custom stuff, because you can use our all of our modules that, that come with AWS, it's a ton of functionality that comes with it, you know what I mean? But let's pretend you're going the opposite direction and Azure cloud doesn't have like sweet queuing systems or databases or auto rollout of environments and stuff like that for you. Like they don't do that kind of stuff. And now you're going to have to inherit all that business. Like this is terrible. This is an absolute debacle. this can put a company out of business potentially if it's on a large enough scale, honestly. But to bring us back to the point and also to wrap up this category is your team has innovated to figure out how to deliver a solution. And now you're saying I understand that you have maneuvered and researched to find the solution. You don't get to discover anymore. You don't get to look for the best thing. We're just going to tell you what to use. We had we had, we did a whole podcast on different people in the company saying, I know what the customer needs. That's right. Yes. Right? An ego can't be thrown up. Like, you can't raise the shields when you hear, how do you know? You know, we can't see that as an existential challenge to your identity. You've got to roll out the evidence and say, well, this team has done a very similar thing to what you're doing and this team you know, went down your path and found these limitations and that's why as a company, we all decided if you're going to do an email solution, for example we decided that this is the most secure method and this is the way to do it. And we have tech leads can walk you through it and documentation and whatnot. Like if you're going to standardize, like there's a way to do it. But those conversations have to happen though. So oftentimes it's just an order or an edict, right? The CFO says we have to do this. Right, right. And then you go along begrudgingly with it because you don't get that opportunity. You don't get the airtime with the CFO. A dictate. Usually it's a Exactly. It's a dictate that comes down and says You must do whatever and the issue with that, the issue with that, it leads us to becoming a monoculture person or individual or individuals or panel or body or governance board or whatever other things I've seen is disguised as over the whole career that I've had it, it leads you to say, These are the approved ways of thinking and deviating from these approved ways of thinking is like not, not, yeah, not approved, not invited, and not, not, not welcome so the problem with this is it leads to like rather than a diversity of thought. With all the different people that are on our teams and all the different cultures that are on our teams, it leads to blinders in one way of thinking. And that's a big problem. It is a huge problem. You mentioned, you mentioned the word monoculture. Right. Or words. That's a real thing. That's a real thing because people start falling in line and, and echoing the same thing that everyone else is saying because you dare not utter anything different. So, we end up with The culture and the organization becoming almost like monolithic. It's uncontrolled groupthink. It is groupthink. And people say, well, that's how we do things here. Let me think about how, how I would challenge groupthink for a second. Like even, even the example, like I hate to keep going back to the exact same example of like what makes you think that this this is a solution that we need. You know, why don't we explore the problem a little more. Diversity of thought starts in the understanding the problem realm. A lot of companies like that understanding the problem phase, like they, they seek to hotwire that understanding the problem phase and cut straight to like proposing solutions phase. And then the proposing solution phase, it's super easy to co op that proposing solution phase to say like, Well, solutions can only be proposed between the hours of 3 p. m. and 3. 15 p. m. on a Tuesday in front of the angry review board. Or whatever, and you must stand on a pedestal, where we can pillory you with fruit, or whatever. Like it sounds funny, , companies have review boards like this, and steering committees that you, in order to approve things and have budget be, you know budget be reserved for new initiatives and whatnot, new ideas. Basically. Yeah. You have to go through a big process like this. You have to go to a panel and state your case and fill out a big form yeah, definitely. Groupthink is real. And standardization has a real risk of precipitating the culture into groupthink. This groupthink topic is super aggravating to me because it sort of takes on a life of its own What you end up with is you end up with a layer of bureaucracy that forms just to keep the status quo in place. It creates process to keep itself alive. Like I think of everywhere I've ever been, they had like, Governance Board, they love the term governance, I don't know why. That Governance Board or Architect. Review stage or that kind of thing. It creates a layer of bureaucracy in the organization that purely exists to justify its place. It's in the bureaucracy of the organization that sounds super confusing, but the type of architect that sits on high and comes down from the mountain with the tablet written in stone of the requirements and like you must do this and you may not deviate from these things This type of thing, I think of. Yeah, we've seen that, right? We've seen that in our lives in our previous lives, right? Where these things happen. And, yeah, to your point, I mean, oftentimes people who are innovators, they know that this is an uphill battle. They're going to have to go to these boards and defend it. Proposals and whatnot. So they tend to basically fall in line with the standardization that's there. And don't go outside of that because their chances of success are limited. If they even come to the periphery of it, stay with the guardrails. We stay right between those, the lane. Right. And that's not really fostering anything new. What you just described is like, well, now the people that succeed in this culture now are the people that. Won't challenge the status quo. That's right. The people that won't like when they see something that obviously is wrong, they're not going to be the ones that raise their head up and get smacked you raise your head up to say something's wrong. The thing will probably get corrected, but you will get smacked for. Sticking your head out of the monoculture to be like, Hey, I'm a little different. I don't think maybe that this is a smack. Like Google just got pinged with this in the news about their Gemini AI and images that they rolled. But I think they, I don't know if they rolled back or disabled their image generation. I don't remember what they did. Did you hear about this new story? I remember hearing something about it, but I don't know what the outcome was. There may or may not have been a big segment of the podcast where we played around with a certain images tool that was a lot of fun to play with and gave us some questionable images. of historical figures that we had a riot looking through. Anyway the, the point here is in the bureaucracy, there is this layer of people who are there to justify Their own jobs because they participated and perpetuated this layer of bureaucracy and the challenge here, the arguing agile challenge here is there are people out there that will say that agile coaches and scrum masters are part of the bureaucracy I'm talking about right now, especially internal ones. I tend to agree with that, but I I just want to say those people do exist to propagate their own existence, but they also exist To feed their immediate superiors what they've been used to, right? This is what the C suite wants. So your managing directors or directors, everywhere below the C suite the middle managers, they're going to continue those practices because that's the path of least resistance for them. But also I have personally seen plenty of scrum masters that do not want to challenge the status quo. They just know that coaching the organizational level is, is futile. It's futile. So, so, and they also know, again, going back to this monoculture point, new ideas outside of the status quo are just not, not accepted. You know, they're not appreciated, and you start getting labeled as a , troublemaker. Yeah. I only bring this up again because I've, I've specifically observed Scrum Masters. I look at them and I say, shouldn't you be? the person with the advanced facilitation skills the advanced interpersonal skills to highlight hey don't you think this culture is a problem but no they're hiding in the culture because they're afraid to challenge any of these issues so they'd rather be kind of safe to go along i would not bring it up and make it such a big thing if i had not seen it more than one time oh definitely it exists it's real it's out there Scrum Masters and Agile coaches, especially internal Agile coaches. And even in that segment, it's people that are coaching at the team level. Agile coaches that are primarily focused at the team level are going to just steer clear of anything that is not in the guidelines, right? The PMO usually hands them a folder and says, this is how you do things. So they're the ones that go around saying okay, look, it says so here. It's okay to have your daily stand up to go an hour long, right? That sort of thing, right? But those agile coaches that are not just at the team level, but they're also really coaching the organization. They are the ones that I would look to. To bring this up to people and say, we're stifling people here, right? This, this is not serving anything, right? Why are we continuing to do this? And to be honest, it's still going to be an uphill fight. There'll be labeled as the troublemaker, as you said, right? Not a team player. You're not a team player. Okay. Well, that's not why you brought me in. Right. You brought me in to hold up a mirror. You can get rid of me. That's fine. That's the easy thing to do, but your problems aren't going to go away. To the agile coaches out there who maybe have like, they've sort of insulated themselves and they're sort of like, well, I I know that challenging the status quo is like tough and I just don't know because it was like a lot of people getting laid off and I feel like there's security and not challenging the status quo. What tool can you give them to sort of like, to, to make progress toward challenging the status quo, but also not get fired? So here's what I'm going to say about that. If you're going to just drift along. If you're going to drift along you're getting closer and closer to that door. Right? So I would say, pick one fight that you can win, go do it, right? Be brave, go do it. And don't ask permission. That's not gonna work too well. But then again, you're not radically changing the core construct of the organizational culture, right? Pick one thing as a practice and say, I don't see why this team should be following that specific practice. Stay with you, with a team and be driven by result, by data. Yeah. And say, here's what we tried. Here's how well it worked. Right. So we're going to do it again. And then slowly over time, you can get other teams that you're coaching to kind of do that as well. You don't have to necessarily make a big deal out of it and say, we're not doing this anymore. We're doing this newfangled way of working. You don't have to do that. Just stay below the radar and do it. Right. But what we used to call gorilla coaching in the day. Yeah. If you have this monoculture where you can't challenge ideas, you can't point out problems, and you, and you, you, you're afraid of, cause that's, that's a lot of what we're talking about is you're afraid to speak up, right? Then in that kind of culture, If you're afraid to speak up and you're afraid to point out things that are not in the current pipeline, things that you're not doing right now, I feel that your whole organization will have difficulty adapting to new technologies, or new trends, or shifts in the market, or shifts in your customer preferences, and you're I feel like this whole thing we're talking about now, where it's like new ideas don't new ideas are not accepted or appreciated in our culture. Well, that's fine. I mean, I guess it's fine from the perspective of you're going to have the people running the business and the people you have working until they leave and then maybe you'll replace them, maybe you won't. Seems like it would be difficult to get people into that culture, but over time, you're going to lose market segment because you just don't have a culture who is willing to be responsive and who's willing to learn from failures. And in fact, I would, I would even go out, I would go so far as to say. Failure probably is a word that is just not, not encouraged to be spoken out loud in that culture. So that tells me you're not learning from failure. So if you're not learning from failure, and you're not learning from your own personal initiative of learning, for the sake of learning. I'm going to guess that the world, when you look at the window in a couple days, the world is going to have passed you by. That's right. Yeah, I agree. I think you lose that, that nimbleness, right? Yeah. You lose the nimbleness to, to respond to the changes that are out there because you're too mired in your own internal processes. So. What can happen here is that company is going to lose, perhaps lose customers, lose market share. I don't know, but that's not going to be appreciated by those people that are just still in the line, you know? Yeah. We lost a customer. So what? We're still doing the right thing. Cause they're just so ingrained in their current culture, the monoculture. Well, they're still checking the boxes. Exactly. Yeah. Yeah. They're checking the boxes and that's not served them well. So why keep doing it? The product management equivalent to me is when I go through an interview and I ask people, Hey, in your organization, where do the ideas come from? Right? And they'll, a lot of people, that's, that's a softball question, usually. Yeah. Okay? But depending on your responses I can dig, tell me about the last time that you picked the best signal and tell me about the detractors and I want to know about the fights, because you have evidence, you have data, there's people with their intuition, you know what I mean, that say like, well, your evidence is wrong, because I know the market. Like, tell me about that conversation. Like, I'm going to dig into the real conversations. everything I just described is not happening in this culture. No. You know, we're No. I'll tell you what is happening in this culture, though. Right. In this culture, what is happening is yeah, fill out an intake form, and then that's gonna get funneled into the product backlog, right? It's like there's no validation, right? There's no verification. The customer actually asked for that. Oh, why? Much less. Why? Right? If you're just taking the customer's word for things, for example, Verbatim. Yeah, that's this culture because you don't want to necessarily be the risky one asking customers. Why do they want something? They just told you they want something to go build it right that that's what tends to happen in monocultures and the end result Sooner or later is yeah, you're gonna have disenchanted customers and they're gonna lose you leave you. Yeah, you'll lose market share Yeah, in the culture where you're towing the party line, you're just trying to make your bosses happy because they you no idea, every idea has to be sanitized. Right. What the customer wants really is not front of mine. I mean, it's really not front of mine. I it's, it sounds absolutely bananas to say out loud, but you're not trying to impress the customers. You're trying to keep your job. You're trying to impress the bosses. You're trying to convince everyone that I think like you think. Yeah, exactly. And I've seen, this is really terrible, but I've seen this where customers coming up with certain ideas that are outside of the the day to day, how you should be working, they're labeled as trouble customers. Yeah, trouble customers, yeah. Oh yeah, that customer. Problem children, yeah, right. Exactly. What a shame. I've seen that, yeah. What a shame. But that is exactly what happens in that kind of environment. So a person who is basically, like you said, toe in the party line for a while, what happens, right? What happens is, You keep your boss happy until they leave, and then someone else comes in, and you keep them happy. Or they have different ways of working. And sooner or later they're going to say, we don't need so many people, right? Because we're prizing efficiency. Right. And you could be out. So might as well take a chance and grab the opportunity to make a real difference. now's the time where I wanna pivot us into what I really wanna talk about on this, on this podcast and what I really wanted to talk about on the weaponizing Efficiency podcast is there's some underlying need for control that is coming out. In all of this and especially in the in the point where there's a market downturn and people start getting let go right or entire teams getting let go or usually it's the offshore teams get let go first and then the contracts get let go and then you know, we we save the Internal employees for last or whatever and, and none of this is done by like who supports what revenue stream or any of that, none, none, none of that is considered. No, it's, it's all, the consideration here is which tab on the spreadsheet that person is. And even in the phases that I just pointed out, they might say, well, these offshore people, I know they align with my way of thinking. So I'll figure out a way to save them and move them over to this over here for a while. Right. Yeah. I'll consolidate some teams and get rid of basically what they're, what they're doing in this phase is they'll get rid of the problem thinkers, right? That, that's what I've seen in, in, in, in the market downturn in this. But honestly, like everything that I just described, like it all comes down to like enforcing. Micromanagement I need to be involved in your day to day work to feel like I understand what's going on. There's a feeling involved here. That I don't believe that you're working on the most important thing. That you are aligned with what I'm thinking. There's a mistrust happening. It comes down to that, really, trust. I don't trust what you're doing, therefore I'm going to tell you how to do something, right? It's not that I don't trust you because you have broken my trust. And proven that you're not trustworthy. It is I. You're in security. I am insecure. As a manager. Yeah. That is the issue. Yeah. Or I am just not educated enough to understand how to look for a team that is working appropriately on my requests or not. So I, I don't, I don't understand the metrics to look for. Right. Right. I've just not been educated. I've kind of been thrown into this leadership role and not. Nobody's helped me understand what what success looks like on paper versus not a failure or stalled progress. Nobody's helped me understand that. So I feel very insecure about it. So in order to make up for that insecurity, I'm going to micromanage this team. I'm going to take increasing control of the day to day. Yeah, that's a, that's a perception thing too. I think in a lot of times, a lot of cases, the middle managers need to have that perceived control, right? Whether they actually have control or not. And what I mean by that is the reality of this is as soon as you're not in the room, what are people saying about you, right? It's not that you're controlling them. It's, it's that you have a. Perception that you're controlling them. They're going to do things to make you happy. Right? And in turn, guess what? You're going to do those things that make your boss happy. That's what this is about. You're not prizing what really should be prized. Right? Which is delivering customer value. You're just basically, like I said, keeping your superior happy the other thing about standardization is that the idea of standardization slows down individual growth like there are less opportunities for individuals to do cool things outside of the box outside of the norm Hey, if you want to you know, if you want to get training dollars over a certain amount approved You got to go through a process Rather than just talking to your manager and then they just do it. Or if you want to get if you want to get a new technology and bring it into your work center and just play around with it or whatever Ed, what I was talking about before is like Azure cloud or AWS,, AWS is a good example because AWS has. So much stuff available to you for you to mess with so much stuff. Now, I mean, they have a AWS in house has a whole AI ML model management sort of cloud for you to play with. If you don't want to send your stuff out, out outside the chat, GPT because you don't trust chat GPT to not like steal or data. Cause I mean Hey, that's their business model. Like AWS hosts models for you. You can say, Oh, I want to use this model for this purpose. And I want to set up this thing. Right. And you can just do it all in house. If you just want to try some cool stuff. To see what you get from it. But now you've got this like, well, I mean to set up this AWS , like application, it costs like, I don't know, like 5 cents per billion transactions or whatever. Like it's super cheap. It's super, it's very cheap. But the point is like, if you don't have any. Financing. If your finances, if your financing is controlled by some other board or authority or whatever, and they only meet like once every quarter and you have to go in front of them to get a budget or whatever, approval, nonsense or whatever. How much process do I have to throw on top of this before people just say You know what? I'm just not gonna bother. I'm just not gonna bother. Absolutely correct. I think the most likely outcome out of that is people just say, I'd love to try that, but I'm not going to be successful here trying to lobby for it, so I'm not going to bother. Right. That's exactly right. Yeah. Right. Here's the way I look at it as a product manager. Brian & Om's software development company. Like Ohm is a cowboy coder he's writing scripts for all kinds of weird stuff that may never go anywhere. They might, in fact, they might never help. Anyone do anything. He just thinks the output of the scripts are cool. Ohm loves to write scripts because he thinks the output is cool. And often, Ohm will pull an engineer over to his desk and say, Look at this cool script I did. Isn't it so cool and the engineer will say, actually, not only is that cool, that is very useful, right? There is no forum for me to take Ohm's cool script and say, here's our roadmap. I'm going to drop Ohm's cool script into our just drop, just drop it into our roadmap. I should probably get a soundbite to do that. Just drop it into our roadmap because Ohm wrote something cool that now we can write into our main program. You know, our main web application or whatever, and like, everybody can take advantage of that. Like, Ohm's just like this loose cannon, just writing cool stuff all day, and sometimes he writes stuff that's like, oh my goodness, Ohm nobody needs that. Right. But sometimes you write stuff that is just absolute gold! So a company that has the heavy process that we're talking about here is unlikely to have any kind of forum where people can do that, right? As opposed to what? As opposed to maybe just dedicated time that people are given to just experiment and play, right? And go and create something in Skunkworks or whatever. You may not use most of it, you said, the one thing you use, it can be gold, right? But that's just like benefit side of it. The hidden benefit is two things. The developers are motivated because they get to try stuff, right? They don't feel like they're restricted. That's one benefit. And then the other is on their morale, right? I think maybe they're related. I don't know. But you know, I'm trying new things out, and maybe if it can be useful to the company, maybe they'll kick a little bit of money my way or something, right? Pizzas. It doesn't matter. So that kind of thinking. Is usually not going to be promoted in a company that has the heavy process, right? You just don't have the appetite for it. Yeah. Well, also you're like in a company that has a lot of process for standardization, nobody's going to do quote cool stuff development because they know that the company like it's going to be a lot of process for the company to pick it up, if you're in a company where you have like two teams or three teams and you have a product manager, one product manager, one product line, one product manager, two, three teams, right. And like a CEO, super small company. And you just have a form like, oh, well, we have a company meeting every month or every six weeks or something like that. And part of the company meeting is people just demo cool stuff. Here's cool stuff that I wrote, that I did, or whatever. It might not be code. It might just be cool, cool business processes or whatever. It could be anything. Yeah, it could be anything. Literally anything. But maybe people have cool stuff hey, here's my script that I wrote to automate this business process, or this thing that we're doing, or this Email script, like that, that's, that's, that's the thing I see a lot is oh, here's a new customer on boards. We don't have a system or whatever, but I put their name in a list and whenever the new name is in the list, the script picks it up and it sends them out an email, automated email or an automated email. Here's the other thing. It's slightly more complicated, but also equally cool. This have a script that looks at our login database and it, it knows all the users cause it has access to the user list and it looks at the login database and it says, when's the last time you logged in? If the last time you logged in is more than 30 days, 60 days, 90 days, whatever. It sends you an email. It says, Hey, we haven't seen you in a while. What's going on? You know, here's a Calendly link. You know set yourself up an appointment to talk with the product manager or with the CEO. The CEO of a tiny little company, five people company. People might be more apt to click a link and schedule time on the CEO to say like, Hey, I signed up for your application and I pay whatever dollars a month and I don't want to use it anymore because You know, you're not servicing my needs as a customer. Well, if the automated email came from, came from and response to and put time on the calendar of the CEO, when they use the form, I mean, you might retain a customer. Sure. No, you're right. You're right. Absolutely. You know, that, that, that could work in a small company and a big company, a big company, even if you wanted to write an automated script that looks at your production, even if you can get access to your production database. Yeah. To get the list, writing the automated script and running it on a regular basis against production. Big. No-no. You have to get approval for that and then. Pulling the CEO in or product manager or whoever it is like, that's another. So I guess what I'm, as what I'm saying is as an individual trying to look for different ways that you can grow different ways, you can expand and try different things, try cool things how many different layers Are you willing to punch through before you're just gonna say, you know what, it's just not right. I mean, the users that log on to the platform, log on to my website and like, they never get past the activation phase. I'm not gonna pause. It's so much work for me to get all the different approvals to talk to these people. Nevermind, they're gonna take the path to least resistance, right? They're not gonna do that. You're right. Because they may get their hand. Slapped at the, at the minimum, right? Or they will be yelled at and told to stay in the lane. That's not good. No. That's not good. Because you're not using the best thing for the job at that point. And my corporate culture never evolves. That's right. Yeah. Yep. And you get frustrated, right? Because you can not proceed the way you want to. Right. Yeah, I don't get it. I don't get it. the other thing that I don't get when you're trying to enforce these standards Usually what happens is they do not get enforced consistently across all teams. So now there's all kinds of feeling of like, even if you wanted to enforce them consistently across all teams, you'll get these feelings of favoritism and these feelings of like, Oh, those people get what they need, but I never get what I need. Also I've seen intentionally giving some teams everything they want because they're more vocal about this pushing back than other teams. Yeah. And those teams may have different relationships with those people that are holding the decisions. That's exactly right. And then you have the undercurrent of politics in there too. Right, yeah, exactly right. That's exactly right. And the last thing I want to bring up, because I think we've talked about this way more than I wanted to talk about this category of standardization is. Your relationships with vendors. I heard a story once, somebody told me a story once where they said my procurement department requires three equal vendors. Three equal choices to be submitted to them before they will allow me to access procurement funds. Even if the acquisition of a software package or a third party package or something, even if that acquisition is approved by whatever manager, whoever in the organization, the acquisition, like the acquisition department, the people actually like sign contracts on behalf of the company. They, they require. Three different quotes, basically. So, even if I know that this one software fits all my needs, and I've researched all the different types of software, maybe I've signed up for free trials and I've tried them, even if I did all the legwork, the procurement people still want three choices. And I'm saying three choices because I know there's companies out there that want more than three choices. I've, I've heard as high as six choices, which I think is ludicrous. So, so the reason that the procurement department wants multiple choices is because they want to be able to note the cost of all the different choices that that we're choosing between. And at the end of the year. They want to say, here's the highest cost choice and here's the choice that we went with, which assuming it's not the highest cost choice. They want to be able to say, we saved the company a potential amount of money by the difference of the highest choice and the choice that we went with. So they're trying to justify the procurement department's existence by saying, well, we, if we weren't around, we. Maybe could have gone with the highest dollar figure. But in reality, usually the requirements and the decisions that go into the purchase. are done before any of the purchase recs are even submitted and the, the sad part of this is like, if we're interviewing like five software vendors to figure out what cloud solution we have to go for Oh, like I'm engaging five different sales departments to do the whole song and dance and to come in and do demos. And I'm wasting a lot of time. Like I'm going to invite our tech lead. I'm going to invite our product person. I'm going to invite the procurement person. I'm invite a whole bunch of people on our company when I know, because I've already vetted the solutions. I want to go with this one. And I wrote the requirements to highly favor this one, in case the procurement people mess it up for me, by the way. And also, I'm only going through the song and dance because I'm trying to check off checklists on the procurement people's checklist, basically. This, this situation you just outlined is real. I've seen this at multiple locations, right? I've seen this. When you mentioned that at the end of the year, they can say this is the amount of money we saved through a prudent vendor diligence. I bet you they're incented based on that in some way, shape or form. If they're incented that way, then that's the behavior that you'll get. Right. And the irony of it is, as you said the diligence has already been done at a different level. You've decided vendor X is the right vendor. You may even have finance for that. You may have financial approval to go spend the money, but procurement is a different department and. They have, they usually have long lead times too, for some reason. I don't know why, because I guess I know why, because they have to go through and look at the company and all of that. Right? The vendor company and all of that. That's fine. So all that time that you're wasting, and at the end of it, they will come back and say. Either if you're lucky, they'll say, yeah, you can have the vendor you want, but you've lost all that time or they could say, no, this one's, this one's better because it, it meets 90 percent of what you need, but we're saving X thousand dollars. Right? Yeah. You, and usually the, the way that this will manifest is, is for the company to come down with a dictate that says the only people allowed to sign contracts on behalf of this company or as this company are the procurement department or the contracts departments, whatever it is. we go back to the the purpose of this podcast, like if you're going to weaponize it, like it's very easy to say the only people who can spend any money on behalf of the company are these people. So basically the policies they lay down, no matter how bureaucratic or ludicrous or whatever they are, or laborious they are, that's the word I use in the podcast. That's a good word. Whatever they say goes. I'd say if you're in that kind of a culture, make friends with these people. Because that's the way you're going to get ahead. You know? Right. Right. Offer something. But also again. How do you deal with that? it doesn't help with customer value, it doesn't help with value delivered, it doesn't help with speed to market, it doesn't help with a lot of other things. it'd be better if these people are lending their expertise to the decision process and I'm bringing them in as experts. The same way I'm bringing in finance people. To help me with finance decisions engineering people to help me with engineering decisions again It's just we like the normal models don't don't really help you understand how to integrate these non technical people into your decision flows and I feel that's that might be a big failing of the Certification and the kind of the whole industry here for sure. For sure. There's a lot there. Absolutely. I mean, all of those domains that you mentioned HR, legal, right. All of those play into this whole thing. Sales. Yeah, definitely. Yep. Standardization. I don't know if we gave a fair shake to both sides of every category in a standardization, like, I understand if your company says, okay, we're only going to buy laptops from Dell, for example I don't know why I'm going back to the early two thousands, like I'm only going to buy laptops from Dell because if we standardize a vendor and say, we're only buying from Dell, then we get a solid 20 percent off of all Dell hardware that we buy. And we only buy from that vendor. Like that that's, I mean, that's clearly a savings to the company. As long as the Dell hardware is competitive with other hardware on the market. But that's an interesting example because you may have, and this is again real, right, companies do this. But you may have a legit reason why a developer or some developers need Macs, for example, right? So, yeah, I mean they're expensive compared to Dell's, I imagine, even today. Give them those things because they need them to develop things on Mac OS. That's just an example. You can justify those things, though, I feel. How can I develop something on Mac OS when I don't have Mac OS? Yeah. But trying to make people that are in these other departments understand that. Right. Because they see names and they see numbers. So they look at, oh, you want a Mac? No, you can't have a Mac. They're very expensive. Right. Right. We've got this thing with Dell. You can have a Dell. I fought that fight with some companies, on behalf of my developers. They just say, oh, how do I develop without, I'm like. Right. Right. Good point. Right. And then you got to go fight the fight. But process for processes sake. Anytime when you're looking at any kind of process, look for the benefit coming out of it. Right. To those that are going through it. And if there's no benefit, then question it. Like, just feel free to say, why are we doing this? This way, but not in an not, not in an accusatory tone. I mean, just go in and say, wouldn't it be better if we did it this way? Cause it's quicker, right. Or you know, it gets us to the end result without having so many stage gates, right? Sign offs is another big one in processes. I can't believe we did this whole podcast and we did not talk about the number one weapon of choice which is handoffs or signoffs or stage gates or something like that. Like I think we implied it, but we did not specifically talk about handoffs or signoffs. I have this thing that I love to tell people as a product manager, I think handoffs are a big waste of time, and I hate them, and I don't want to do them. Well, in the lean way of thinking, handoffs are a waste of time, and we look to eliminate those as much as possible, or minimize them to the point where none are left. But this is real. Handoffs are real because, again, people have that insecurity that I must be able to see things and put my rubber stamp on it and that's the sign off. They become bottlenecks. I mean, you wait for people to sign off things. Right. And the ultimate is attending a StageGate review meeting and then defending the work that your team has done and then looking for approval from someone who has no clue, by the way, about the functionality you've built, right? This is like only things that you get at large companies because I can't, I can't, I can't even fathom as a product manager sitting in a room with an architect who doesn't know my business, doesn't know my customers, doesn't know why I'm building things. That basically has no context as to the why poking holes in my application. Let me add a little context to what I'm saying, because I will often put features out before they are ready. And I know that the features are not quite right. So I am expecting, oh Brian, you put up this new drop down. But it doesn't have the most obvious option in the drop down that most customers would expect, I want to pull a drop down and export this file to PDF. But you only allow me to export it as a PNG or whatever. How come you didn't like everybody needs P everyone needs PDF. Okay. I know everyone needs PDF and I know that if I put PDF, that would be the only option everyone shows, but I also know like on the backside of the house like in the backend, like I need a. PDF processor and I know I have to pay for it or buy one or do whatever. And, and I'm like, I'm not sure that this workflow that leads people to saving off the file is even a valid workflow. So I want to see people go to the workflow, select a thing and hit download or select the thing and then back out and not hit download again. This assumes you have good user metrics, good instrumentation in your application. I already know. That I'm not, that I am not servicing the customer for what they really need, but I want to see that they take that, that path in the application. It's really easy to push out fake door features. Like for example download PDF. Like if we're talking about PDFs, right. I don't know why we're talking about PDFs. I can add a download PDF button in my application. I can just go to developers and say add a download PDF button. But it doesn't do anything right now. Clicking it says, downloading PDFs is currently restricted, will be available in a future release. Or whatever. Perfect. Okay. Architect, or somebody says like, Why would you even, why would you allow that? Like, just hide it if it's not there because it's going to make For many reasons why. It doesn't look professional, Ohm. It doesn't look professional. Says the architect. Again, they don't know my customers. They don't. They don't know what I'm going for. They don't know and you can say, Well, I mean, that's the purpose of the stage gate. That's the purpose of the sign off, is so that you can inform them as to the yes, yes, and also, why do I need Why are they not assigned to my program? Well, you're in a large matrixed organization and they just were told to go do this particular stage gate review. They just show up unarmed, unprepared. I mean, this is what I've seen. And they will be blocking you by the way, because they have huge egos. They're not going to let anything slide by. Well, yeah. They decide that it shouldn't, right? Yeah. When I bring it up like that to them, of course, they're definitely going to be blocking me when I say like, you're not even involved in my program. You have no idea how I measure metrics. You don't know professional Brian. Putting something out there that doesn't work. Like I've heard your opinion and I think your opinion is hot garbage we could be in completely different segments of the technology adoption curve I'm dealing with. Early adopters, you're dealing with laggards, and you're trying to apply a philosophy, that works with laggards, arguably works with laggards, to the early adopters. The early adopters are so happy, or even the let's even back up to the innovators. The innovators in the technology adoption curve are so happy to have thing that helps them with their problem. They, they could care less that it doesn't crash every time, let alone that they don't get another export option or whatever even in the early majority like the fact that they have two options in the dropdown that work for saving their thing off and then the main option, which they really prefer, which is PDF doesn't work. They don't really care. They're still happy. That won't be a showstopper. But at least you can validate that then. You sure can. Which the architect doesn't think about it that way. You know, they don't think about it that way. We're validating this based on real customer journey through the product. They don't think of it that way. I'm with you on the thinking that they don't think of it that way. And by that way, my, my context is from the perspective of what helps user the most rather than their own ego or their own views. Or their own opinions. When you build bureaucracy for the sake of bureaucracy, and it has to justify its own sake in their bureaucracy, it can't get out of its own way. That's just not, it's not possible. It's horrible. It's, it's a spiral actually. So taking this. This example of the architect at the review, chances are they need to be able to go to their superiors and say, I did four reviews today and you know, none of them passed or one passed or whatever. And here's why aren't I doing a great job, right? By the same token, they can come to you in your, in your review, they can say. PDF. Oh, wow. We're not going to spend money on a PDF processor. We can build that in house. We're going to build that. And I know how to do it. I'm an architect. Now you're solutioning for things you don't even know the customer actually needs. I've seen that happen. Yes. I've seen exactly the case you're talking about. Oh, I can build that. Yeah, you don't need to spend money for that. Well, I mean, you can build it, but also how many sprints are you going to dedicate yourself? To my program and who can I talk to to make sure that that happens on paper and that you don't get stopped and interrupted Because my program is about delivering value and I would be willing to pay to have an uninterrupted stream of value as opposed to trying to You know jockey for position with all the things that you're involved in like i'm just not interested in that I feel this isn't It is and is not a great example because now I'm, I'm like conflicting two worlds. I'm conflicting the Brian product management world of. I want to move fast, I want to execute on things, I want to try things and let the customer be the judge and to, to, to, to follow where the customer is leading me. And the other world with this solution architect or whatever is, I want to justify my place in the bureaucracy and I want everyone to subjugate their demands to, to, to me trying to justify my role and to make me happy. Hey, it takes very little to make me happy. Just tick the box, subjugate my ego, make me happy, and then I won't be a big blocker for you. But my challenge to that is, I don't, none of that adds value to the customer. That's right. So really, just get rid of it. Maybe in our next big you know, corporate drawdown, like maybe we can get rid of that layer. And we can be a bit more lean. Yeah. Yeah. I mean, look, good luck with that. So definitely handoffs and sign offs are a big, big drain. They're a big waste. They are. They're a complete waste, actually. To all the product managers out there, or maybe scrum managers that are living in this environment the customer value would be the way to cut through this layer. I have like my customer value and my direct customers. Like we have a process and it works for us and the customers are happy with it and let the customers speak on your behalf and try to cut through this and segment yourself off of the bureaucracy and I even realize when I'm saying this, nobody's going to like that. Nobody's going to be happy with it. You're going to be, you're going to be the black sheep out here by yourself who's carved an exception for yourself in the process and everyone will hate you for it. You're right. That is the right thing to do, right? So the scrum masters, you're there to coach the organization. That is the right thing to do. So do it. Right. Feel empowered and do it. And also Keep that resume updated. Definitely keep that resume updated. And also, like and subscribe to the Arguing Agile Podcast because as a small channel, every like and subscribe helps us. It helps us a lot.