AA128 - Change Management with Stormy Dickson

There are no notes to this podcast because organizational design and change management is not really taught. Nobody really is an expert. Nobody gets a degree in change management. I mean, if you do get a degree in change management, feel free to write me in the comments and tell me that your degree is in change management. And also tell me where you got it from so I can go back and get my doctorate. Yeah. So, agreed. In any kind of business degree, change management is certainly covered however, it becomes a huge part of what you are experiencing in your organization or potentially tasked with, being that change agent, with or without previous experience and really understanding what that means. What does it mean to manage change? Right. I told you at the beginning, we kind of covered this on the, previous podcast with where William was on, where we were talking about, enterprise, agility, transformations, basically agile transformations. I know it's not vogue to call them agile transformations anymore. But regardless, like all agile transformations are, is a series of change management steps. Boiled down to a team level, and then maybe like up through the organizational level, but. That's all it is, and, a good portion of the last podcast with William, were, I was kind of beating up saying, I've been in a lot of negative situations that I can reference off the top of my head way more than the positive situations where people said, you know what, Brian, we're not positioned for growth in the future. We're not positioned for success. You might be on to something. Let's fully dedicate. We're all in to this like let's figure out how to get through this change together. Mm hmm Said no one ever exactly said no one ever so, where do we start right? I would venture to say that no one is an expert in change management because there is no one, script, no, no one prescription that I can write, that I can write, or one, no one checklist that I can give to someone and say, here you go, this, this'll, this'll, this'll fix everything, right? But, it's easy to, I would say fairly easy to recognize. This is basically the entire space where, where your enterprise agility people, operate., I hear what you're saying about, the team, every team is, A special, unique, I'm going here. Now I hear what you're saying about every team is special and unique. And like every company is also a special and unique, and we're all together inside special and unique. That was, that was, that was for the people, people are listening to podcasts. I'll never see what I just did. But, trust me, you're a special and I believe in you. But also, there's a playbook, that if you generally follow the playbook, you'll generally, again, generally, quote generally, Be successful. And Agile coaches basically know what that playbook is. If you're checking off that, that like lowest of low hanging fruit, I think that's where your enterprise agile coach will start to say, well, how often do you talk to customers? They'll start with questions like that. So there, there is some easy stuff. I think we're making a big leap here though. So what you've said, so that's probably right. Yeah. So yes. I think there's some, some, there is a playbook and certainly people who have expertise in identifying that, those needs and potentially prioritizing kind of figuring out in which manner to organize those things. Uh, but that's assuming that we have an enterprise agile coach or any coach, agile coach at all, which. in and of itself assumes that we have some buy in from somebody to actually work on making change. You're absolutely right. Yes. It assumes at some level that somebody knows that there is an issue that needs to be resolved and they are seeking help. Correct. Yeah. So whether that person is a contractor or whether you've taken a leap to hire somebody permanent or whatever. Yeah, it does. So, so I guess we should back way up, way back, back, back, back up. And we did, we did a podcast, we did a podcast in episode 60, which may or may not have been before. Like I learned how to edit. In the dark times before the empire. That's my best Obi Wan Kenobi. It's not very good. Like we did a podcast episode 60 with, Curtis about John Kotter's book, leading change, he outlines the process and it's kind of positioned from people that are in leadership positions trying to roll change out in the organization, which I would, I kind of would argue if you're a product manager. You kind of are in a leadership position. So, it, it would be good to understand these, the, the, the framework in that book and the framework in that book at a super high level. I'm going to run through the framework of the book at a super high level because we're not going to retread. Arguing Agile number 60 in this podcast. His steps are, step one is establish a sense of urgency, you have the most political capital to do this when you're new. You, you come in as a new CEO or new head of a department or somebody new, you have the most capital to do this because you're seen as an outsider, right? So establish a sense of urgency. Hey, we've got to do this. We won't be around in three years. If we don't do it, we've got to kick it off now. Keep reiterating, you know what I mean? The sense of urgency. Step two is create the guiding coalition. That's getting some people that agree with you, getting some people that are on the same page, getting some people in the same situation, getting them together, getting them to guide the quote transformation of whatever the changes doesn't have to be a transformation. Step three is developing a vision and a strategy agreeing on where we're going. So this is like, I feel like we already went, like there's eight steps, spoiler alert for people who haven't read the book from the nineties, but, there are eight steps. We're on step three, and this is a tall order because most organizations they have no idea. Like, Hey, where are we gonna, where we wanna be in three to five years? Well, we wanna have a market cap of this and we wanna have X percentage more profit or whatever. Like, no, no, no, no, no, no, no. I'm not talking about that. How will we look? The teams, the people, the, reporting structures or whatever, what will we look like in three years? Oh, why are you asking that? Get back to work. Go back to the salt mines! most organizational vision, most change management, what we're talking about, breaks down at this step of, well, I don't know where we're going to be and I'm busy with the day to day. I don't have time to figure out what our teams look like, what modes of interaction between teams and stuff like that we've definitely touched on this. I don't know if you have a specific podcast. We've definitely talked a lot, a lot about vision and strategy on another podcast for products, not necessarily for the organizational design. it's been salt and peppered into a couple different podcasts, but we've not had one specifically on, what is your organizational design future? Right. Like, what is your vision? How do you craft that? How do you sell it? How do you, you know? Who even maintains that? We haven't dug in, in that, from, from that perspective. What I would say though, is we have, honed in on the importance of, our product, our product vision and goals and such, how they need to really funnel up into that strategy, which should funnel up into the actual corporate vision and the importance of everyone understanding and buying into what that is. And I think this goes back to the importance of getting that coalition together, making sure that that is communicated, is simple, is simple, right? So that's our North star. That one, the vision shouldn't change every three to five years, generally it can, but That's that, that's that really like, I actually pulled up apples just cause, there's a lot of simple ones out there, but apples is to bring the best user experience to customers through innovative hardware, software, and services period. It should be simple enough that everyone at Apple in this case, understands that whatever it is they're doing from whatever level in the company that they're doing, that they are doing something that will apply ultimately to that vision. Now, certainly there's strategy. There's, there's layers to that to get into that. If you are doing something, you should be able to ask yourself. You know, can I check the box that I am doing something that is going to align to our corporate vision, which requires number one, that I know what the hell the corporate vision is. right. Hurdle number one is it's got to be, first of all, you have to have it. Yes. Well, that's hurdle number one. Second of all, like that vision has to be expressed in terms of, goals or strategies or something. How are we going to deliver on this vision and that that's leadership's job. That's not anybody else I mean you could argue like the senior product leadership should definitely be helping with that you definitely could argue that you would not be out of sorts if I were to push back on that point, I would say depending on the size of the org, I'm with you depending on the size of your, if you're talking to an org in the thousands, now we're talking about like entire segments of the org being divisions that kind of have a different vision of their own, that kind of like you can help tie back up. To the company vision, but the company vision is so broad, So the company vision should be broad, but that North star. So I would, I would argue that, that that's not that if you have different organizations or, or different kind of siloed departments or, lines of business, whatever you want to call it, that those would have a different goals and strategies, or maybe a different vision. But would always, or excuse me, a different mission, but would always align back to the company, vision that that shouldn't change across the board regardless. And that should be, we should always be able to align to that. I think it's the other way around. I think, I think you all, I think the, the mission comes above the vision, so you might all tie back to the mission. But you might have, again, like we're talking about theoretical, so I, I kind of want to abandon ship on this one because I, I want to get out of theoreticals because if you go back to John Kotter's leading change, where he, like we were at, and you're right, I, I, so I, I, I got that wrong. I, so I'll agree with you on that one. Got it. But I mean, theoretically, even if you're a large company, you, if you really want to be a focused large company. Tying everything back to one vision, no matter how many teams or how many segments or whatever business things or whatever you have, it really shouldn't matter if you tie back to one vision and you really have focus with your whole company and then your different divisions or whatever the organization can say, we're executing the vision by launching these strategies. I think about the strategies and the goals being like a subdivision level or a sub business level or whatever. But again, I want to get over this because I want to get through the rest of the eight steps. I bring it up to say most companies, they fail at even having visions and strategies that are publicized, that people know, that people like, I had a, I had a CEO one time, who , I remember he came to a company meeting, he's like, who can say what our vision is? And. If someone could remember it off the top of their head, he would he throw 100 He literally would give him a hundred dollars. He'd go in his pocket and he'd break out a hundred dollars and be like boom There you go is a hundred dollars I need everyone to be on the same page. Everyone needs to know what our vision is because that's what should be dictating prioritization and whether we accept jobs and whether we, how we proceed. You should be thinking about how it ties back in the vision. So he wanted everyone to know what the vision is. again, now that I'm many, many, many years later in my career. I understand that, you can't have a vision that's, three paragraphs long. You need a vision that you can remember quickly. So, you know. That's, that's, that's inspiring that, that I want to be a part of, right? That, that's something that I can remember and I want to be a part of, right? And I know, so we want to get over this, but I want to say one more thing. So, just, so. We do whatever we want, yeah. So, but I want to, so I give an example and I've told, I think I've told this story actually on this podcast previously, but so my oldest daughter went to elementary school, and the elementary school is a charter school and they use the fish philosophy from the Pikes fish market. She could tell you to this day what it is. But the, fish vision and strategy, right, they had things posted everywhere throughout the school, right? Number one, it was included in orientation, but that's not what made it stick. What made it stick was in the class. All of the teachers, their lesson plans. would roll up to that, those, that, those values of that fish philosophy, if a kid needed to be, redirected, they would ask, Hey, are you living the value of this? Whatever it was in the fish philosophy. Are you, are you meeting this? And if not, how are you not meeting it? so there was education for the. Staff, there was a culture that was created with the leadership, with the staff and that filtered down to the kids. And I have a 24 year old to this day that knows those things by heart. But again, again, number one, it's gotta be there. Yes. It's gotta be there. It's gotta be publicized, it's gotta be available and it's gotta be good, meaningful, dare I say, it has to connect with people. Yes.'cause again, if, if it's two paragraphs long, like no one's gonna remember it, right. Where we're at is, companies fail, just developing a vision, a good vision, and then publicizing it and then pulling strategies from that. The next step to that is once you have a vision, you spread it around. You, you, you, the 100 bill thing, I don't know, I don't know why we're making it rain right now in the organization. But the, the, the idea is you want to incentivize people to learn your vision. You want to, to, to, to go to all your mid managers and make sure their people know it. You mean you, you want to incentivize it so that people know you want to communicate. The change vision, that's step number four. Step number five is to empower employees for broad based action. And a lot of Agile transformation people know this as removing obstacles, which is, if, or, or breaking down silos. That's the other thing that people know this as. if you're trying to empower employees and you're trying to say, Hey, Stormy in, in the course of your normal work, you figure out. What you could be doing to advance our vision. Mm-hmm., I need to break down barriers so that, so that you feel empowered to start doing that in your daily work. But Brian, I need to ask my, my leader, if that's okay. Yeah. That I get Brian. Brian is, I, I need to, I need to make sure that that's okay. Yeah, that's exactly step five. Okay. We need to get, we need to get past that because again, like innovation just. Does not happen when you're worried about like, well, if I propose something, then my manager might think I'm trying to go over his head and it might, trying to hold me back or whatever, like all that, all that needs to be cleared away. It all needs to be cleared away. Like lack of psychological safety. I mean, you think about step five. It's like, Oh, it's just a step five. It's just a, it's a hurdle. It's a bump on the road, but step five is like, it's huge to overcome. This is culture, like literally ingraining it into your culture. And it really is a huge opportunity to get creative too. So how do we ingrain this into our culture? Make it fun, literally make it fun, make it memorable. A hundred dollars. So throwing a hundred dollar bill out in a meeting to say, well, do you know The vision of our company, do you know what that did that made that, that was memorable. People went back that day and were like, what is our vision? I bet I'm going to know that next time. That person who got the a hundred dollars, I guarantee you, they will always remember what that vision was for sure. But it's getting, it's not about him about making it rain and throwing out a hundred dollars bills, but it is about, well, but it is about, being creative. And making it fun and, and really getting people to buy in and not just recite it, but believe it, believe in it, be a part of it. Yeah, I mean, that's step five. You can't be empowered when you have, component teams separate. Oh, all my development is done on this one team and all my QA is done on this one team. And then I got to send it over the wall to this other team to deploy. And then I got to send it over to this other. You can't like you're not empowered at that point, If you ever been behind a boss who refuses any suggestion To change and you've been frustrated. Like, you know what I'm talking about now, why this is difficult. Go back and read John Cotter's leading change. He's talking from the top down. He's talking sponsoring change from the top down. He's not really talking from the bottom up. That's, I, I feel a different book. I don't, I haven't seen that ever work, but maybe I would love to hear from somebody that has, I, I, maybe that could be a completely separate podcast. Step six is generating a list of short term wins. Right, so if you do have a, if, if, if you do have like a, well, we're going to step into agility, and we're not sure that we want to, go all in and transform our whole organization, so we're going to pick a, a, a group of people, or a cross functional team, we're going to do a pilot program. Okay that team will have some missteps. Every team has missteps depending on the politics at play in your organization. What you can do to get around this is you can broadcast the wins and you can treat the failures. As learnings, assuming that for each failure, you're implementing something that makes sure you won't have that failure again. So, assuming you're, you're really going into this with good faith, and, and full effort, you know what I mean, money, effort, everything behind this, You're generating short term wins with your pilot programs and you're broadcasting those short term wins. That's step six. I love that you're saying broadcasting, you know quick wins But you mentioned failure, you know being able so being allowed to fail and finding the value in that as that being an actual win a learning opportunity So I mentioned this recently to one of my, one of my leaders and saying one of the best ways in which, so the one of the best ways that we can learn and we can ultimately win is to fail because you don't know what you don't know. And if we are empowered to experiment, in the life cycle of that, we will experience failure, right? Right. From that we learn, which is a win, right? So we pull the positive out of that. But what I want to say about that is, for our, our leaders to be transparent about their failures. Where did they fail? What did they learn? So the more transparent that they can be about that, that makes it okay for that team. People become more empowered and more comfortable and more safe if their leaders are humanized, and it also makes it okay for them to fail and to say. Yeah, and to admit to failure and what they've learned from it. Let me ask you a question, like a segue on this podcast. But it's a, it's a, it's a segue that we need to take right now, which is, where or when do leaders fail? Where does a typical business leader fail? Like you were saying like, Oh, I want my leaders to represent where they fail, so we can learn from that too. Or to show me, the employee, that they are learning from their failures. What would you categorize as like a leadership failure? Well, it could be, a direction that was chosen based on a particular project. So there's a lot of assumptions that are made. It could be, it could be guidance that was given for a team to go in this direction and that was really ended up being the wrong way to go. You're you're very close. So exactly what I was thinking which is engaging us in a business strategy That is based on an assumption and I will tell you like as a product manager I have no problem going all in diving headfirst into brackish water. I can't see the bottom so I don't know if the pool is five foot deep or if the pool is Three inches deep because I can't see the bottom. I have no problem diving headfirst in Okay. Cause we're going, we're going to dive in together. I'm okay with the idea of, we have not explored this market segment. We've not explored this business. We've not explored this customer. We've not explored something. So. We're going to take a chance and try something small, so it shouldn't really be dive in headfirst. It should be like dive in with a toe or feel around with a toe. There's a million like books and everything that. You can read to double back of what I just said on the org design side, though, Oh, stormy, I'm gonna like, we'll have a whole QA team over here. We'll have three development teams over here, and they'll all feed the work to that one QA team. And then when, when they're done, we'll Then we'll sit you with the business because you're really more business focused than you are technical focused. So I don't really want you talking with the developers and like that that kind of like bad decision of like oh We're gonna build a bunch of walls and I don't want you going between all the walls because you know I'm trying to protect your time and that's what I think is important based off of nothing. Cause I've never sat with development teams and the bad assumptions on org design, that's where, I've just seen. Not the same. Learnings come from Absolutely. Yeah. And because they're siloed, so any learning is going to be within that one little, that one little like walled off section, right. If there is a learning shared. Right. So yeah, I mean absolutely. We were talking earlier about, but, creating teams or pods or really kind of trying to break down those walls so that, we have truly this cross functional, organization where we are able to learn, trust and, and grow together. Yeah. The, the issue that I've experienced, and especially in the, that segment of my career, when I thought I wanted to be an agile coach, I don't know why I thought that, was, usually what happens is that the person who made the call. To say our team should be split up like this. I want to try this. Let's try it. Let's try having all the testers over there and all the developers over there and all the requirements people over there. Let's just try it, any, Agile coach or whatever in the room will be like, oh boy, do we really have to try this? Like, do we really have to go through this? We're going to try it and it's going to be Terrible and then hoping that that leader stands up and says hey I did like I made a decision that it's not turning out the way I expected. Let's pivot hoping they make the right decision. Because even failures could be wins if you decide to pivot based off of what you learned, the problem here is by the time we've paid the money and realize that we have been had whoever paid the money is not willing to say. Listen, we've been had. Let's go. Let's go, kids. Back in the station wagon. We're leaving. Like, they're not willing to stay. They would rather just Suffer throw more in rather than say that they were wrong here. Yep. You know, we can fix this. Move on. The funny thing about this is at every company I've ever been at with product, product management. Usually when I come in, I lobby very hard for them to do user personas. Hey, you need to know who you're building the software for. Yeah. And they don't have it. They like, I've, I've been at zero companies that have it when I get there. Yeah. Right. And when I, when I get there, I'm like, Hey, you need to build personas. And, we're gonna build them based on our expertise. And this, we're just gonna get moving. And then when we build the personas, I put a little parentheses that says, assumption. And they're assumption based personas. I like to have assumption based personas and then factual personas. So, and I tell the teams, I was like, we're, we're gonna start with these assumption based personas. And then when we start talking to actual users of the software, we can start asking them the questions that are on these personas. And then we can start filling in the Our best guess is, yes, there are guesses, our best guess is we can start filling in with actual, factual, evidence that we hear from the person who that person is. So we turn, over time we turn, we turn assumption based personas into fact based, interview based personas over time. And and then you actually get to know the actual, the real user who you're building the software for. And I've reiterated that process. At every company I've ever done product for, this, this is kind of the same thing of where we're talking about, the, the short term wins, the, the failures, like you can assume that, something is a certain way, but until you, you start gathering evidence that it is that way, like you really shouldn't take it on your ego or, go all in or get defensive or whatever, cause you don't have evidence If you're a product manager and someone's trying to set your teams up in a way where you have all these silos or whatever, maybe you can sit down with them and say, hey, I'm okay with this for now. As we get some evidence along the way. Do we agree to revisit this topic and talk about the evidence that we've seen in two months, three months, whatever, like if you can get, if you can, if you can kind of just hedge that bet a little bit with them, so when you're ready, when you're ready to say, look, your strategy sucks. Yeah. Let's talk about like, Picking a good strategy, you, you've got an in where they don't feel defensive. Yeah. Cause you, at the beginning you said, hey, let's, let's agree that this is an assumption based strategy. Let's agree that we will revisit it in three months when there's evidence, next quarter, whatever. And I, that's not too hard. I, that, that, I don't think that would upset too many ego, I mean, it might upset some egos, but. So it sounds like what I'm hearing is that number one, you need to recognize that this is an assumption and that might, so, so once the, once you've agreed that this is an assumption, then admitting that, hey, once we know, and we all agree that it's an assumption, then We have that little doorway and we can back out and it's not, we, it was an assumption. So we have the opportunity to say, well, it didn't work. They can back out. The leader can back out without, without losing the manager here without losing face. Yes, absolutely. But. I think the hardest part is not, is, is not necessarily kind of setting up that process. It's recognizing from the, from the beginning, what is the assumption, right? So that's, I think maybe the hardest part. Yeah, it, it certainly requires some expertise however. Like if you listen to the podcast, if you've listened to 120 something episodes of the podcast, you should realize when, your leaders are, they're sending you down the path to the dark side and like, I feel you should like, I'm a team player. I'm going to like salute and say, yes, sir. And I'm here for the team or whatever, but can we agree X, Y, Z? but I would say like for what you're talking about, like if you've not, if you've not created a guiding coalition. Who develops a strategy and pushes the, pushes and communicates a strategy out. You're gonna fall foul here in this step, which is you're trying to generate short term wins and you got people sabotaging or fighting back or, trying, trying to, trying to, to, to shoot down your wins. Like, oh, you only won because XYZ, whatever excuses, or the worst case is someone trying to actively sabotage you winning. And, inside of generating short term wins, you also start down the road of changing the way your goals are set and changing the way your incentives are done and a lot of stuff that really is ingrained in the culture. Once you start generating wins, you start realizing like the model we're using is not working. We need to go, generate new models. Now you're, now you're headed towards real change because step seven. And eight in John Cotter's leading change. Step seven is consolidating those gains, aggregating them and bringing them into one place where they're visible. And then starting to, to, to basically point everyone back to just those gains to check out my gains, to, to, to basically your, your. You're, you're creating a snowball to increase and produce more gains towards change, towards where you're going. And then, step eight, his final, his final step in the book is to anchor the new way of working. So where, for example, if you're spinning up a new team and you're like, Oh, I want to do this with this new team and say, well, you need to do it in a way where this other team is, winning basically. This other team is. Performing, top notch and you need to do what they're doing. Well, I'd prefer to do it in an old school way or whatever, but no, no, that's not available because everything from here on, we're committing to this new way of working. This is like what you've heard in agile transformation is all like Oh, I want to create a new team, a new development team, and I don't want to use any methodology. I just want to use whatever, um. Well, that's fine. But, you still need to tell us, what is your throughput and you need to tell us, what strategies are you engaging with? You need, so if you don't use scrum, and you're not gonna use Kanban like that's fine, but we have a framework to tell us what business value we're knocking out. What, what, what business problems are you tackling? I'm not going to do any of that. I'm just going to be over here and hang out because Bob knows. What to do or Fred knows what to do like that's not gonna cut it in the new way of working in the new way of working so I would assume. So I would assume if there's a new way of working number one once we go through remember that all of these steps are building on the prior step right so So once you get to six, you've always got already gone through one through five. Right. So, and then once we get to seven, we've really kind of ingrained that into our culture. And then eight is now just making that exponential. So being able to not just it's ingrained, but we're replicating. So that means that new, the new team coming on, I would. I assume at that point, actually, because it's ingrained in our culture, we've probably developed a method in which we are onboarding that new team so that they are also becoming ingrained in our culture. I mean, this is the same way last podcast, we talked about if you're going through a transformation. And you're saying, I'm gonna have a couple different teams now and they have, the teams have developers and the teams have product managers and I'm going to start a community practice with, it's a cross team in that it's like discipline specific, all my developers across all the teams go to developer community practice where they share The different things they're doing in the architecture and the different ways they're checking in code or deploying code and the product managers talk about the different ways that they're connecting strategy down to their whatever epics and stories and how they using JIRA or whatever, or whatever ALM they're using. Or whatever good tools they're using. And maybe the scrum masters have a community practice where they talk about how they're handling collaboration between teams and scaling and and those community of practices start sharing wins and they maybe they showcase failures in a way to say, Hey, if you run into this, here's how we got around this. Maybe they showcase success to say, Hey, we did this. We didn't think anything of it, but it ended up being a really great thing. They start sharing those learning so that not all your teams have to make the same failure so that all your teams get that learning. Now you've, now you're creating a culture that where one team fails solves a problem for all your teams. This is where you should be going. This is exactly like this is the past. Yeah, that's eight. We've received we we've gotten through We've gotten to eight when we've got to that mindset where we're a team or a line of business, whatever the case may be says this is what happened. And this is how we solved it. And we're communicating this out, to make sure that everyone learns from this. This should be valuable information. And then creating a path to make sure that we can do that and that those are, celebrated. It's not just kudos and high fives for the, Hey, we've got through a go live! Woohoo! But, really high fiving the people who are vulnerable enough to come forward and say, You know what? I realized something. I, I screwed up here. But if I share this with you, it's going to help across the board anyone else from potentially making this same mistake. And that's huge, particularly in development. I think the reason that I was thinking about change management as a topic is because it's something that I have realized that I need to, that has been, become part of my job role but, in receiving the information that I need to be, kind of a champion of change management, in my role, and then having conversations one on one with leaders from all of these different teams and different lines of business, understanding that. No one person had the same understanding of what that meant. Right, right, right. Yeah, if you find yourself in this weird role, that I've, I've found myself in before as a, Product manager. Mm-hmm., who, who was a scrum master for a, who worked on technical teams for, for many, many years, and then worked as a scrum master, quote, playing the role. Now, now that I'm in that part of my career where I'm purely in product, I, I do find myself in the position where like I, I'm the person who has most, the most expertise in how teams should be, formed, how teams should work together, how teams should not work together. it's a heavy burden when I'm, I'm trying to do all this product stuff, but at the same time, like I'm seeing a lot of, teams with a lot of challenges that I know that I could easily suggest, hey, maybe you should do, two, three different things. Like I know what the future looks like for that team and I just don't have the time in the day to spend with that team to help them work through where they should be six months 12 months, 18 months from now, because like my main responsibilities to the product and, and honestly, to my teams, like I'll, I'll intersect and interact with other teams that I don't even sit on those teams. I'm not their product manager. I'm not the scrum master. I don't even interact with them. They're like stakeholder teams and I'm trying to help them because there are, they are stakeholders to me and I'm like, Hey, have you thought about maybe doing this? With your team structure or maybe interfacing this way with other teams or, the most difficult, part of a scrum as a job is when they have to urge teams to work with other teams to plan. So to say like, Hey, we want to refine this. Epic or story or whatever. And in order to do that, the best people in the organization is this other team. So what do we do? Do we just get on a call with everybody and who's going to moderate that? And, maybe they have a scrum master, we have a scrum master, or do we just get the lead of that team and then a senior developer or whatever, and they just get together and plan it like how, you know what I mean? But what is the best? I, I don't, you probably have to try, but yeah, you have to try a bunch of different things to figure out what the best is. But, the point is, I'm not a scrum master or the product manager for those teams or anyone's manager in this case. I'll bring all this up to say, if you are the de facto expert, there are two paths in front of you. This is not true. There's many paths in front of you. I told you before the podcast, I was on, I was on a program at a program on a program. I was assigned to a team one time and, the, person I work for was not on any of those teams. They were not even in that departmental structure. The person I worked for. And I remember the person I work for coming to me and saying, listen, look, we hired you as I think they hired me as a scrum master. We hired you as a scrum master and, we need you to go in and just pick people, pick a subject matter expert and be like, you're the product owner now pick a developer and, and be like, you're the, you're the. Scrum master now and then teach and coach those people have one on ones regular basis, you know once a week or whatever but you have the expertise we hired you in this position But now that you're here and you're observing these problems What we realize is what we really need is we need someone who can coach the people into the roles because we have too many teams for you to sit with any one team on a permanent basis So we really need you to spread your expertise across the entire program, instead of like one or two teams It's like seven or eight teams And we're really changing the role that we brought you in for. And I had a choice there. Instead of being an individual contributor to one team, being sort of a mentor and coach to many teams and going where I'm most critically needed. And it was a completely different role, that I kind of, found myself in. You know, I feel if you're in product and you understand, Oh boy, welcome to my monologue. Let's get the assumptions out of the way You understand the job of product owner to a team. You also understand what a product manager does that a product owner may or may not do. And also you understand the basics of agility with regard to how teams should be formed. If you understand all that, you maybe have some skills that are a lot of transferable skills that maybe they need in, in different parts of your organization and maybe you'll find your If you're an organization that the level of maturity of your teams is much lower than what you have experienced in the past, Maybe you found an opportunity to grow in your career to move yourself into a slightly different role where instead of one team You're now spread across a couple different teams and you're in a more strategic. You're more in the product manager side Of the business than you are any in any individual product owner team level side of the business and maybe that's an opportunity. So as, as long as you're not setting yourself up for failure, I would say there's some, there could be a cautionary tale there, to be very honest. That's very true. That said, if you feel confident that you've got the backup you need, from a leadership perspective, you might not even need. someone to come to you and say, Hey, I'd like you to do this. I would challenge someone who recognizes a need. So see a need, fill a need, right? So I would challenge someone who recognizes a need and sees that there's that change management opportunity and you have the skill, and, and feel like, Hey, I could do something bigger here. Yeah, I would challenge somebody to go to that leader and say, Hey, what do you think about this? I could, this is something I feel confident that I could do and that could, assist us to, on a larger scale to grow as an organization. I mean, be your own advocate. At that point, you probably could, start implementing these John Cotter Leaning Change steps. Absolutely. You know, instead, I said, the John Cotter Leaning Change book is really meant for, executives and director level people kind of, trying to, to, to sponsor change to the organization. But, where you were going, was you could do this. You can get an executive sponsor and then you can start building your own guiding coalition. You know, you can start collecting your own wild West posse to, go right out when you need to have a gunfight or whatever, I'm not saying go and get, go and get in the gunfights. Howdy partner. Okay. Yeah. It's a howdy partner. There's a fallout reference in here. That said, so just thinking about kind of the organization that we may be coming from so, if you are being that kind of self advocating champion for yourself and potentially you see an opportunity that you could, engage and build and grow yourself and the company and are advocating that to leadership, if you have these silos very, built into the company, understand that, you're going to have your work cut out for you and there's going to be people that are, are not, not going to be real happy with, the potential change that you're trying to implement. Like I say, it starts from top down. If we're recognizing the opportunity, we see leadership that, that is ready to get engaged and involved we can certainly get that ball rolling and, and advocate for ourselves to be a part of that change. Yes. Yes. And yes. That's it. Yes. And yes. Okay. I could continue talking about this for two more hours, but I'm not going to. If you have the experience slash skill and you have the ability and the desire, yes. And the desire to deal with this, like knowing that in some circumstances you might be taking on a second job of change agent, right? Assuming you're not a full time agile coach and that's not your normal job anyway. Like if you're a product manager or somebody and you just know that, Hey, we have to redesign the org, that this is not going to work. You might be taking on a second job maybe temporarily. I mean, that's a, that's the point of getting your posse together. That's a point of getting the guiding coalition. So you can distribute some of this work. To the rest of the coalition. They should be, they should be mobilizing people and they should be knocking out wins to ingrain this in the culture, so you don't have to do it alone. Well, change, change management, change management is interesting because change management, much like agile transformation in, in, in just, just the phrase. Means nothing. Exactly. Right. It really means, so it means something to everyone, but it's a different something to everyone, which if it means something different to everyone, it means nothing. Yeah, right. So if you like, if you like talking about nothing, subscribe to this podcast.