#80: From Struggling to Success: Reviving Agile Teams with Mike Cohn

Spela upp

Are you part of a struggling Agile team? Join Mike Cohn and Brian Milner in this episode as they uncover the primary signs of a team in distress. Listen in as they share the common causes of underperforming teams, and what to do to boost morale, enhance collaboration, and transform your Agile team from struggling to thriving! Overview What is the primary sign of a struggling Agile team? It's when the energy in the room feels like a deflated balloon, and laughter is a distant memory. In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software help listeners identify the signs of a struggling Agile team and the common culprits. Listen in as they unveil the key principles of cultivating a positive work environment and the vital importance of addressing CYA behavior. Plus, they share their top-notch tips on boosting team morale and enhancing collaboration, all while preventing unfinished projects and ensuring consistent delivery. Tune in to transform your Agile team from struggling to thriving! Listen Now to Discover: [01:23] - Brian welcomes back Mike Cohn to the show to discuss how to identify the signs that your team is struggling and what to do about it. [01:54] - Common causes of unfinished work. [04:45] - Do developers use Scrum as an excuse to be lazy? No—that’s rare but can be easily corrected. [07:36] - How to manage underperforming teams. [09:04] - Teams that lack excitement and laughter may be struggling. Work should be fun and enjoyable. How to create a positive work environment. [10:32] - How to break the habit of rolling unfinished work forward. [12:44] - The power of small wins to improve job satisfaction. [14:12] - How to boost morale and deliver small wins that create a sense of accomplishment. [14:30] - The Agile Mentors Podcast is brought to you by Mountain Goat Software and their Certified Scrum Training Classes. Whether you want to be a Scrum Master, Product Owner, or even take an advanced certification, all courses are designed to give you the skills that agile teams and organizations value so you’ll stand out in the market. For more information click on the Mountain Goat Software Certified Scrum and Agile Training Schedule. [15:35] - What CYA is really telling you about your team. [16:59] - The role of managers in creating an environment of openness and collaboration [19:03] - How individualistic behavior—working in isolation, not collaborating—hinders teamwork. [21:08] - Introducing Swarming—a horrible way to work, you’ll get less done—but a great drill to help teams discover new ways to collaborate. [27:54] - Thank you to Mike Cohn for joining us on the show. [28:18] - Please share this episode with others if you found it useful. Send feedback and suggestions for future episodes to podcast@mountaingoatsoftware.com. And don’t forget to subscribe to the Agile Mentors Podcast on Apple Podcasts so you never miss an episode. [27:54] - If this topic was impactful to you and you want to continue the discussion, join the Agile Mentors Community, where we have a topic discussion for each podcast episode. References and resources mentioned in the show: #70: The Role of a Leader in Agile with Mike Cohn #39: The Art of Writing User Stories with Mike Cohn Subscribe to the Agile Mentors Podcast on Apple Podcasts Certified ScrumMaster Training and Scrum Certification Certified Scrum Product Owner Training Advanced Certified Scrum Product Owner® Advanced Certified ScrumMaster® Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian (00:00) Welcome back Agile Mentors. Very glad to be with you again. My name is Brian Milner as always. And today I have my good friend back with me, Mike Konis here. Welcome back, Mike. Mike (00:11) Hey Brian, thanks for having me back. Brian (00:13) Really, really excited that Mike could join us again. And wanted to talk about something that I think is, maybe it can hit on multiple fronts. And that's really signs that your team is struggling. What are some things that could be going on with your team? And what do they mean? What does it kind of symbolize? What do we do about it? There's lots of common issues I think that teams face. I know Mike, you probably, You do classes all the time as well, and I'm sure you hear kind of the same questions over and over in classes. Yeah. So there's kind of a set of the same issues that seem to rear their head again and again. So we thought we'd maybe make our way through a few of those and just talk through them, and maybe we can find some things here that would help you if one of these things happens to be something you're experiencing. Mike (00:45) Mm-hmm. Brian (01:06) So the first thing, if we're kind of working along in our team and we find out that they're kind of frequently reaching the end of their sprint and stuff's just not done. I know I had this a lot in teams I've worked with where we had carryover, we had stuff that just wasn't finished. I remember even one team early on I had that just kind of told me, hey, it doesn't matter. It doesn't matter we don't finish it. We'll just do it next sprint. So what do you think is kind of at the core of something like that, Mike? Mike (01:40) I think there's two common causes for a team not finishing work. And one's kind of an obvious one, which is excess pressure from management, right? Management's pushing them on how much to do. Management is not letting the team have full authority over how much work they bring into a sprint. And that could be a misguided scrum master, misguided product owner, or management outside the team, but somebody is putting some excess pressure on the team. And then the second one, I'm going to call it a second one, but it's, it's pretty related. is over optimism from the team. And the team just thinks they can get that much done. And they have a really hard time learning the lesson that they can't. And I'm thinking of a team I worked with outside of Sacramento, California. Absolutely phenomenal team. Phenomenal team. One of the best I've worked with in my entire career. But I don't know that they ever finished what they said they would. Literally, I don't know if they ever finished. And a lot of it boiled down to the optimism kind of their weed guy. And he was great, phenomenal guy. I've stayed in touch with him for many years. But he just always had the attitude of, yeah, we can do it. We can do the one more thing. And always bringing that in. And so the product owner and I would talk after a planning meeting going, I wonder how many they won't make. It's like, you think it'll be two or you think it'll be three. And after a while, the product owner just had to kind of take an attitude of like, okay, you committed to these many things, but you know, let's not work on this one until all the others are done. We'll kind of keep this one. Brian (02:46) Ha ha. Hahaha. Mike (03:06) kind of on deck or ready to go in next. And that worked better, but it was just their overoptimism. And now the reason I said, I think both of those go together, that somebody's putting pressure on the team or the overoptimism, somebody's putting pressure on the team and I cited management, Scrum Master, product owners, could be the team itself, right? The team is putting more pressure on itself. That's why I think they're related. So I think that's the, those are the two most common reasons for this to happen. Brian (03:24) Yeah. Yeah, it's funny, you know, I get questions a lot of times in classes or when I talk to leaders where they, there seems to be a concern, which I think is completely unfounded, that the developers are going to just goof off. And that, you know, somehow this whole Scrum setup is just a shell game to kind of give developers a chance to just fool around and do whatever they want to do. Mike (03:53) the Brian (03:58) I don't know, I mean, I'll share my personal experience. What I tell those leaders is that, you know, it's actually just the opposite has been my experience. You know, developers want to please the others in the organization. And so when someone comes to them and says, hey, you know, can't you do a little bit more in the sprint than, you know, they're usually not gonna say no. They wanna make people happy. So they'll say yes, you know, so it's over optimism, but like you said, the pressure too, Mike (04:22) Mm-hmm. Brian (04:27) could contribute to that to say, hey, you know, I don't wanna make anyone mad. I don't wanna tell them, no, I can't do this. So I'll make them happy for today. They'll be mad, you know, at the end of the sprint, but for right now, you know, they'll be happy for a few days. Mike (04:41) Yeah, I'd rather have people mad later instead of mad today. I think we have to be careful though. There are some small percentage of teams that will use it as an excuse to be lazy. And I've worked with thousands of teams at this point. I have worked with a few of those right there. They were using scrum as an excuse to be lazy. Like, you mean we get to pick how much we do? Okay. We'll do that little. Right. Um, and normally that's fairly easily corrected. Brian (04:51) Sure. Right. Mike (05:07) because it normally boils down to one or two people on the team that are kind of creating that mindset. And I'll go back to the guy I talked about on the amazing team, right? His name was Todd. And he had an outsized influence on the team, just kind of by his seniority and by his personality. You're kind of a big personality, people liked him. He was the one that would occasionally have like parties at his house and things like that. I was referred to him as the glue that held that team together. And again, an amazing team. But his personality, had an outsized influence, right? And so his optimism drove that team to picking too much. If you had somebody, his evil twin, it's like, oh, let's commit to a little, right? That could have the same influence there. And so when we have that problem, it's often fairly easily fixed. You need to talk to the one person or you move the person onto a different project or out of the company if you have to. Other times the problem is caused when we have two people together, right? It's the combination of these two that make it happen. So... It hasn't ever been a really hard problem to fix, but I do want to acknowledge that is a, it's a, it's a concern. It could happen. Right. But I think what we tell, we would tell leaders is it's pretty rare. Right. And if you have a team using Scrum to, to deliberately go slow, deliberately take it easy, not do a lot of work. Pretty easy to notice. And it's pretty easy to fix, right? You know, fire somebody if you have to. Right. I mean, I hate saying that, but I mean, that's an option. And if we have people that are just, you know, deliberately. Brian (06:15) Yeah. Mike (06:33) underperforming and it's a valid option. So I don't think it happens off but I do want to be fair there that it can happen. Brian (06:41) Yeah, I'm glad you pointed that out because I do agree it's kind of a you know, the percentage of it I don't know I don't have any studies to say this but the percentage of it is probably so small that you know It's kind of one of those things again. Are we managing towards the majority? Are we managing towards the small minority? Are we making all our policies around the small minority? Are we making around what the majority would actually do? Mike (07:05) I love that point because I get some criticisms on my blog or YouTube videos or stuff sometimes where people will tell me, yes, but this advice doesn't work for such and such a team. And they're always describing some horrible team, right? You know, this is some totally, you know, where you've got the total command and control manager or the architect that's also the scrub master and abusing their power. It's always just some horrible messed up situation. And somebody will tell me my advice doesn't work for those teams. Brian (07:10) Hehehe Mike (07:32) I'm totally okay with that. I made the decision many, many years ago that I want to offer advice that will help good teams become great. I don't really want, I don't care if they do, but I don't really wanna focus my life on helping really poor performing teams become mediocre. Right? This doesn't motivate me. That doesn't get me excited. I wanna help the good team become world-class, right? And so I'm gonna write things with the assumption that we're... Brian (07:39) Yeah. Mike (07:57) We all have positive intent. We are trying to get better for making a mistake. We're going to own it. We're going to, we're going to go from there, but I don't want to, I don't want to give advice for all the horrible teams to get mediocre. That's it. That just doesn't get me excited. Brian (08:10) Yeah, completely agree to that. It's, you know, there will be other signs. It's not like it's gonna be hidden if you do have a team that's trying to abuse it in that way. It's gonna be fairly obvious that that's happening. Mike (08:23) Yeah, I'll get it asked. You know, leaders will say, how will I know if the team is underperforming? And, um, one of my, um, professors back in graduate school has got him, Peter Drucker, who's often, um, considered like the, you know, the management guru of the 20th century. And, um, he had a term management by walking around, right? You just walk around and you will notice. Right. And, um, you know, we started out, you're talking about, um, struggling agile teams and one of the things I was thinking there, like, what is, like, what is the like primary sign of a struggling? Brian (08:34) Yeah. Hmm. Mike (08:52) agile team. I think one of them for me is they're not having any fun. Um, I love, I love building stuff, right? I love creating products and, um, it should be fun. Um, you've heard me before say that I hate work is called work, right? You know, I get it. We got to call it work, but work should be fun. We spend most, you know, not most, but you know, half a third of our day working, it should be fun. And if you go into a company and nobody's having any fun, you're not hearing any excited voices or laughing ever. That's a sign that the team is struggling. So. Brian (09:25) Yeah, that's a great point. And I completely agree. You know, I get it, right? I mean, it's not recess. Like, there's a limit. There's work, and we're trying to make money in what we're doing. But you're right. If there's no need for our workplaces to be overbearing and just stuffy, I can't stand being in this. I can't wait to get out of it. Mike (09:50) Yeah, yeah. I mean, we all have days like that, but work should be fun, right? And that should be one of our goals, to make it fun. I mean, people are gonna get more done when they're having fun. Brian (09:54) Yeah. I don't know that we've addressed this, but I just want to throw it out there in case you have anything else you put in there. So if we do have a team that's sort of missing delivery, and they're not really being able to complete things by the end sprint, any kind of quick tips you would give teams like that to try to turn that around? Mike (10:19) The biggest one for me has to do with this being one of the worst habits that an agile team can fall into. I think it's a horrible habit to get into the mode where we don't finish things. And I'm a user of a phrase you used a moment ago, you were kind of quoting teams. It's okay. We'll just roll it forward. Right. I think the attitude of roll it forward is horrible because it implies that the iteration or sprint boundaries are meaningless and we're just going to roll things forward and I don't want that. I want the thing to go, the unfinished thing to kind of back on their product backlog. and we make a decision, do we still want them? We probably do, but not always. And so I try to get teams to stop using that phrase. I know you weren't using it. You were referencing a team calling it that. But I think it's just a really bad habit and I wanna break that habit. The way I do that is I ask the team in their new sprint, whatever we're planning, the new sprinter iteration, to under commit. They know what it feels like to not finish everything. Brian (10:57) Yeah. Yeah. Mike (11:14) I want them to see what it feels like to finish everything, right? To get everything done. And we do that by getting them to go deliberately light in the, in the next sprint and then add work hopefully at the end of the sprint, right? And so being able to add work is going to feel very different to them. It should be a positive experience. They should be excited about it when they, when they get to work that way. Brian (11:39) Yeah, that's a great tip. I completely agree. If we can, don't, you know, there's oftentimes lots of stress about just the idea of, oh, but you know, my managers are gonna be mad at me that the team didn't really commit to. Yeah, but what we're looking for is consistency. And if they're consistent, then we can forecast and we can start to look ahead. But if they're inconsistent, we can't do that. And what... Mike (12:00) So you would point, we want to be clear though, that we don't want a team to make it every time, right? You don't want a team to, I'll call it succeed. You don't want a team to succeed a hundred percent of the time at finishing what they said in a sprint. If you see a team making it every time, they're playing it safe, right? They're under committing. They're like, oh, let's not grab that extra one item. Let's play it safe. And I always use sports analogies for this and pick a sport. It doesn't matter what sport this can map to any sport, but you know, let's go with football, soccer. Brian (12:04) Right. Mike (12:29) Right. Um, I don't want a player who scores every time they kick the ball. Right. That, that sounds awesome. Right. Who wouldn't want that? Except what it means is the guys, the player is only kicking. They're only trying to score when they can. Right. They're not like, Oh, I think I can make it. Let me give it a try. They're playing it safe. They're only going to kick when they're assured of making a goal. Basketball player, baseball player, hitting the ball, anything, um, quarterback throwing the ball in American football. Brian (12:33) Yeah. Yeah. Yeah. Mike (12:54) And you don't want them to make it 100% of the time. And managers have to embrace that with teams that it is success when we can make it. I kind of target 60 to 80% of the time, the team finishes what they said they would. And so I like to reduce the commitment, get the team to feel what it's like to add instead of remove. There's a Harvard professor, Theresa Imabile, who's written one of my favorite papers, it's called The Power of Small Wins. And what she did is study what improves job satisfaction. And her research led to the idea that the number one determinant of job satisfaction was the frequency of small wins. And I consider finishing or mostly finishing what we said we'd do in an iteration, a small win. And if we can do that, have a team make it most of the time, every two weeks, you're getting a small win under their belt. That's gonna feel good. It's gonna feel a whole lot better than the team I described in Sacramento at the beginning that never finished anything. Brian (13:51) Right, right. Mike (13:52) never finished everything. They finished lots of things and they never finished everything. Brian (13:55) eah, and it goes to Dan Pink's, one of Dan Pink's big threes, mastery there, that if we start to see progress, we're saying, oh, we're getting better. We're actually improving as we go along. Great tips. Okay, let's talk about another one. Let's see if we can get another one in here. And this is one that kind of, to me, I think is a team dynamic issue that I've seen quite a bit. Not a ton, but I have been on teams that have had this. And that is when a team starts to develop kind of more of a... Mike (14:06) Mm-hmm. Brian (14:25) um, shall we say a CYA, uh, kind of approach, uh, cover your, um, the, the backside, uh, put it that way. Um, yeah, yes, CYB. Yeah. Uh, yeah. Um, but, you know, kind of, kind of when the team sort of feels like, you know, I'm, I'm being really scrutinized here and I better deliver or. Mike (14:35) That's a CYB behavior. Cover your backside. Brian (14:54) I'm gonna be in trouble, or if there's gonna be someone who's in trouble, it's not gonna be me, I'm gonna make sure it's somebody else. What is that kind of indicative of on a team? What is the most important thing Mike (15:04) the biggest thing is just kind of a lack of respect for your co-workers, right? You know, if you're really working as peers and you have this shared goal of deliver an amazing product, then you're looking out for your team members. You're not making sure they're the one that gets in trouble if there's a problem, right? And I remember early in my career, and I don't remember if this project was Agile or not. I don't remember if we'd gone to Agile on this project, but I remember it very much being a case of what I called project deadline chicken. Nobody wanted to be the one to admit that they weren't gonna make the deadline, right? So we had a software group, we had the database group, we had the testers, probably another group or two. And everybody knew they weren't gonna make the deadline, but nobody wanted to be the one that was gonna admit it, right? Because if they're the one that admits it, they're gonna get all the heat from the boss, and that was a yelling boss, he'd yell at somebody. Brian (15:37) Yeah. Mike (15:57) And the other teams would just go, oh yeah, okay. We, you know, relax today. That's fine with us, but we would have made it. Right. And, um, we need that type of openness, transparency and trust in teams. And when I don't have respect for my teammates and I don't feel like we're in it together, um, or that they don't have my back, I think that's where the CYA behavior comes from in many cases. Brian (16:21) Yeah, there's a, you know, I tell this in classes sometimes, there's an old boss of mine who had this phrase I thought was really good. He said, you know, bad news is not like wine, it doesn't get better with age. And I completely agree, right? I mean, if something is not going well, there's no good that comes from just pretending that it actually is going well. And let's not find out about the issue until now it's too late for us to actually adjust or do anything about it. Mike (16:32) That's good. Brian (16:49) The earlier we find out about it, the more runway we have that we could say, all right, well, let's make sure that people are aware. Let's make sure the dependent parties know and that if we need to, we can, you know, change staffing, we can do whatever we need to do when there's runway. But when there's none, it's done, right? It's history. Mike (17:09) Yeah, it's too late to alter behavior. Brian (17:11) Yeah, I've been a part of some teams that are kind of finger pointing and backstabbing a little bit. And there is sort of a CYA approach in that. And I think that is, there's a trust issue there obviously as well. It does come down to a little bit of just not. We got kind of a cancer as a team. We're not really working together as a team then, yeah. Mike (17:29) Mm-hmm. I think managers are doing better at this. I'm not, you know, cause this, the manager has to create an environment where we're going to listen to people and root out the truth, not just blame one group for something and not let a team or a team member get away with this type of behavior. And I think managers have gotten better at this in terms of knowing that, you know, well, it's not listening to the first guy that blames the other person, right? Let's go check into it. So I think managers have gotten better at this over the years, at least what I've seen. Brian (18:00) Yeah. What about like, this is one that I know I encountered multiple times, but you get the scenario where you have that team that say, hey, we're kind of more independent. We like to work on our own and kind of the frequent. mode is, hey, we're gonna decide in sprint planning, but then you see everybody go off in their own corners and put their headphones on, and they're kind of in the zone for like eight of the 10 days of the sprint. They're just all on their own doing their own coding, and they're not really working together as a team. What do you think is kind of at the root of that kind of behavior? Mike (18:34) Mm-hmm. Lack of teamwork. One of my favorite movie scenes is Robert De Niro in the movie Untouchables. And he gives a speech about, basically about baseball players and how the baseball player stands at the plate and you make this your cricket player if that's your sport, but you know, they stand at the plate, it's just them, right? They're the only player from their team on the field. And he talks about that being a very individual thing. And he makes the point to his mafia associates, whatever they were, that he needs teamwork. Brian (18:40) Mm. Mike (19:07) right? And he makes it in a very interesting way. It's worth, go watch this little three minute snippet on YouTube. But he uses it to make the point that he needs teamwork. And I think when we see this, when you know, you grab your thing, I grab my thing, and, you know, I'll see you in 10 days at the end of the sprint, we're not a team, right? We're just this loose collection of individuals doing things. And that's often the result of not breaking up work very well. It's often the result of defining our roles in very specific ways. You only do the front end or I only do the back end. That can happen or you grab one user story and it's yours front back end all the way through. And I grab another one. It's just not a good way to work. I want people collaborating on things because one of the things that we're after with Agile is kind of a faster turnaround time on each item that we work on. So that, you know, we grab an item and three or four of us might work on it. we get it done very quickly. And then we grab the next item. We get it done very quickly. One of my early agile transition efforts was a company that was transitioning a few hundred people, which was big at the time. And they were very much in this mode. Each person would grab a thing to work on. They would work on it for three or four months, or six months even. And then they would hand it over to a tester. And the testers have to verify everything. But it'd be done over three, four, six months. Not an agile way of working. Brian (20:29) Yeah, well, we should also probably define a term here because I know there's a term that gets used a lot when we talk about this kind of thing, and that's swarming. It's another one of those kind of agile words that we hear sometimes and think, ah, swarming, what's swarming? What's your experience with that? What does swarming mean to you? Mike (20:46) To my knowledge, I was the one that first used that. And I used it a little bit differently than people use it today. When I talked about it, I said swarming would be the entire team working on one item. And this is a horrible way to work. It's an absolutely horrible way to work. But it's a worthwhile exercise to do. It's a good drill. And I think when I first wrote about it, I was a swimmer. And I was comparing it to a drill that Brian (20:52) Hmm. Mike (21:14) my swim coach had me do, which was called closed fist swimming. So you swim through the water with your fists, right? Picture doing that. It's not a good way to swim, but what it does is it really helps you get good arm position in the water. And then when you open your hand up and make kind of a palm, you're much faster because you've learned proper arm position. So a good drill. And so swarming have the whole team work on one thing's good drill and you'll get less done that sprint velocity is not going to go up with people working this way. Absolutely not. But when you. Brian (21:23) Yeah. Mike (21:43) open your fists when you let the team work in a more normal way. Um, all of a sudden they're going to have found ways to collaborate that they would not have found. So it's basically an over collaboration technique because you're going to have six or seven people work on one item. Right. And today people will use swarming to mean, you know, we're kind of batch mode, right? You know, we'll have two or three things in process at a time. And you know, maybe that's okay if the team's pushing good team size boundaries, but I legitimately met it as. one item and we all work on it. And that is gonna be very inefficient, but we're gonna have to find ways to break it up into smaller pieces, find ways to collaborate on it. And those skills, what we learned from doing that will be handy when we go back to working on now, two, three or four items in process at a time. Brian (22:31) See, this is why it's so great to have Mike Cohn on, because terms like this that I've heard my entire career in this area, I had no idea that came from you. So I'm glad I got some of the history of it. See? Mike (22:44) Well, I'm pretty sure it did. I'd have to look up when I first wrote about it, but I do know when I wrote about it, I hadn't heard it from anybody else. Doesn't mean somebody else hadn't, you know, done it on a blog I'd never seen 20 years before me, but that's, that was where I started with it. Brian (22:56) Sure. Yeah, and I think it's a great concept. And yeah, I mean, that sounds a little like what we would call mob programming today. If you're going to take everyone and work together at the same time on the same thing, that might be a little bit more like the original concept that you had when you were doing that. Mike (23:16) Yep. Except we'd also have the testers, the designers, everybody, right? The whole team on one thing. Brian (23:21) Ah, okay, yeah. Yeah, and it's just, you know, when we think about how teams work today, you know, I think one of the things I try to help the team understand is that we don't want everyone to just grab their own thing and then go off and work on their own, you know, because then, you know, you use a sports analogy, sometimes I apologize in class and just say, hey, look, I apologize that there's gonna be sports analogies, but hey, Scrum is a sports analogy, right? I mean, it comes from a sport. But yeah, I mean, when you think about any team sport and how a team works together, they have different jobs, but they have a same goal, and their goal is to win the game. I can't just say... Mike (23:50) Yeah. Mm? Brian (24:11) You know, if I, if I play, you used soccer earlier or football to the, you know, 90% of the rest of the world, you know, 10% of us here, yeah, we call it soccer, everyone else is football. But yeah, just, just kind of the, the concept that if, if I know my position, let's say, you know, I'm a midfielder, well, I can't just stay right, you know, on the left midfield and never move. You know, I'm not touching anything unless it comes in this little square box. Well, I'm not a very good player. Mike (24:17) Right. Brian (24:39) And am I doing kind of what I'm in charge of? Sure. But am I being a teammate and am I helping my team to achieve our goal of succeeding? No. Mike (24:49) Yeah, you've got to, it's not my job, man, right? Mind telling you, you're doing that. I think the analogy that I find that works really well is a restaurant, right? Let's suppose you go to, it doesn't have to be a fast food. You're gonna go to some Italian restaurant, low end, high end, doesn't matter. You go to this Italian restaurant and you got one guy gonna make your meal, right? He's gonna make the salad, he's gonna bake the croutons, he's gonna make the dressing, he's gonna put all that together, then he's gonna bring it to you, then he's gonna start making your main dish. Your dinner's gonna be three hours, right? Because you've all got to bake the termissu. Brian (24:52) Right, right. Yeah, yeah. Mike (25:19) Right. I don't want one guy, one person, just a guy, but I want one person making my whole dinner. Right. I'm hoping that a dozen people worked on my dinner, right, including the dessert or whatever back there. So that's where we'd have a team in it. One of the things, I'm gonna stick with the restaurant thing. One of the things I talked about with my wife is I get mad at bad service at times. And I've said, if I were owned a restaurant, I would make sure that servers helped tables that weren't their own. Right. Because I love that at restaurants, right. Because I drink a lot of water when I'm out or iced tea, whatever I'm drinking. And I'm always empty. Right. And I always wish I like it when I'm at a restaurant where somebody is not my weight, my server fills it up. Right. And it's just a little touch. Right. Just a little touch. But it's like I'd probably want to train my staff like, look, 20 percent of the tables you touch shouldn't be your own. If everybody's doing that, we're all going to be happier. Right. And, you know, I'm sitting there parched with no water and Brian (25:49) Hmm, yeah. Yeah. Mike (26:18) three waiters walk by going to other tables. I'm like, please. Brian (26:23) Yeah. Yeah, yeah, it's water, please. Yeah, I've heard our friend Lance Dacey use this analogy as well as far as the kitchen. And I like what he says. He kind of talks about how if you have people back in the kitchen, just talking about cross functionality of a team, if you have a team back in the kitchen, they all have different specialties and you have the grill master, and you got the pastry chef and all this other kind of stuff. Yeah, they all have their own specialities, but. Mike (26:25) Yeah. Yep. I think they helped. Brian (26:48) You know, if there's a table of 20 that all want a steak, you know, the pastry chef doesn't just sit in the corner and say, wow, it sucks to be the grill chef tonight, you know, they all come over and say, how can I help? Yeah. So yeah, the restaurant's a good analogy. I like that. That's a good one. Well, this has been good. I think we're probably. Mike (27:00) help. Yeah, yeah, absolutely. Brian (27:10) pushing up on our time and I want to be respectful of your time Mike and also respectful of our listeners time so thank you once again for coming on I know you've got a lot of stuff to do and I just really appreciate you making time out for the show Mike (27:22) Thanks, Brian, it's always a pleasure.