AA94 - Don't Say Collaboration

So I had a interesting exchange on LinkedIn and not, not interesting in the way of, fighting with people over the internet. Interesting. In the way of somebody said something that I thought was particularly thoughtful and I felt the need to respond to it to say, Hey, that was particularly thoughtful, and I will show the message here on the screen next to me, and for the people that are listening to the audio version, I will read it. He's talking about , what his biggest struggle as a technical leader is. He says, the biggest struggle is to get the team to work synchronously in real time, dealing with one issue at a time, and striving to make that issue as small as possible. I thought that was a great response and I felt compelled to reply with this is the true leadership answer. Getting people to focus on the top problem and make larger progress. I don't know I don't know what I larger, that makes no sense. And getting people to focus on the top problem, make larger progress on fewer items is the way to make real progress as opposed to having a million things in progress and being really busy. I'm a really busy person Om cuz I have a million things in progress. Yeah. If you if business is how you're, you're measured, then that's what you want. But yeah, this is a good topic. I like this topic. I feel if we're gonna talk about leadership challenges, this is a leadership challenge. I feel this podcast probably applies to product people as much as it applies to maybe senior developers or team leads or people in that kind of position. Scrum Masters, I feel it would strongly apply to like you're trying to communicate to your team, Hey, it's more important to get together and finish the highest priority item first. And even if we're a little slower, because there's many people working on it, that's better because we're turning in consistently done work. Yeah, I agree. I also think that maybe some product owners could benefit from this as well, because I've known some product owners that just say yes to everything that comes their way and, and stick it in top of the backlog so this idea of. Leadership really saying, work on this, work on this, work on this. And the teams are just subservient and say, yes. That idea, I think we can kind of explore a bit. What is the team working on at a given point in time? If you're sprinting in the sprint what are they working on, right? Uh, they're working on the highest priority items that they believe can be finished in the sprint, then they should just be working on that. But along come somebody leadership perhaps says, work on this now, right now, because this is priority one. And how many priority ones can you have? the, Hey, I'm gonna stop working on what I'm working on just because you asked me is a little bit like that. The order taker team and team members is a little bit different than the organization where everything's always priority one all the time. A little bit different, but it is different. It is different. Yeah. So let's just take the other angle, the opposite angle. Why not? I mean, after all leadership saying, do this, let's do that. If the developer manager says, now do this, let's do that. And if we don't finish, it doesn't matter because they told us to change. So we could say, well, we're working on that, and then you change direction on us. Yeah. So that's why we're delayed, not finished, et cetera. But is that really helping the organization as a whole? Right. If you imagine that behavior happening on multiple teams, what does that look like at the, uh at the org level, right? People have always got the irons in the fire, right? So they've always got things they started, but not a lot of those are finished cuz they keep starting. Yeah. Yeah. Well that, that right there is the, the crux of many, many problems is your organizational culture values the people being busy all the time and having no, no breaks, no whatever. You know what I mean? the people who are working on the weekends and, you know what I mean?, they're on at whatever, 11 o'clock at night or whatever. They're the most valued people in the organization they're not necessarily the most productive. No, that's right. You know, but they have, they have the most balls in the air. Yeah, I agree. So how would , how would the Egyptians built the pyramids if they just kept starting? They wouldn't have finished anything but they did, and they, they did some amazing things by finishing one task that was at hand bring the stones and establish a flow. They had worked it out, basically, you couldn't get the stones into the, onto the site too quickly because they get in the way. Mm-hmm., it's that inventory issue excess inventory as we know it today. Yeah. They'd figured that out by making sure that people finish what they're on yeah. So those that are rolling the stones in, finish that before they do something else, right? Those that are moving the stones up up on the next level, so to speak. They finish that why is this a problem though? Have we seen any glaring symptoms, why this is a problem? I just wanna tackle the problem statement and then kind of break it down a bit. What I think that's a, oh boy. Like, that's a very difficult question to answer. Like why, why do you get a culture that is obsessed with starting things and not obsessed with finishing things like that, you would think, and you would think that like corporate structures would actually be better at this than anyone else. They should be obsessed with finishing things rather than saying, oh, look at all the things I've started. You know? I don't know. Like I feel, I feel there, there are a couple sides to this. The obvious one for me is to point out incentives, right? That's the obvious one is the person who says like, oh, I need to start all these things and every single different initiative I need a new team for, and my incentives are all based on how many people work for me. Go government gets this way. The number of people you manage means that you, you must be a good manager cause you're managing so many people. Yeah. And it's an indicator or even a measur in some companies of seniority, right? Right. The, the higher up the ladder you go, the more people you manage, right? So that, that's part of the issue as well. I agree. The, the other thing is the structure itself. So if you have a matrix structure where people are basically working. For certain individuals, but they're working on a team that's that they're not reporting to that individual for necessarily. Yeah. Then they have divided loyalty, right? Are, their loyalty is split between the team and also between the manager, hierarchical manager, who is likely to say to them, what are you working on? Drop that work on this next because I feel the pressure for, for moving this along so I think the structure also encourages this, right? Mm-hmm., this idea of starting and not finishing. Well, let's dissect that for a second. Oh, geez. I'm so shiny. Like, let, let's dissect the, hang on, let me try not to be shiny . So, sorry. Since we're talking about leadership here for a second. we're, we're focusing on this stuff being a leadership problem. Let's talk about the. Shifting priorities. Like sometimes when I talk about like scrum teams that wanna move toban because things are too chaotic, they can't oh, two weeks is too long of an increment for me. I don't know. Like I, I get pulled every couple days or whatever to do a radically different thing and my backlog gets thrown out of whatever. Like, oh, well your environment is just really chaotic because your leadership just can't decide what the priorities are. That's a whole different symptom. Let's talk about that symptom for a second, because like, kind of what we're talking about is like, oh, well my development lead interrupts me, or my CTO interrupts me, or whoever, somebody in the organization interrupts you and says, Hey, stop, drop everything you're working on and go fix this, or go implement this, or go solve this, or whatever this customer's screaming. that I'll call it what it is just so we can start on the right foot. That leadership problem has to do with a certain set of things happening in the organization. If you're listening to this podcast and that is your problem first of all, no there's very little you're gonna be able to do with it. Like leadership is the issue you gotta move the prioritization up to the leadership level. Product managers normally are the people that should be dealing with it at that level. I agree with you, right? That that's where it belongs. They have to prioritize. We can help though, right? We can help them understand the impact of dropping something and picking something else up. Yeah I feel like teams don't do that enough. They, they simply. Yeah. Okay. Throw it out. I'll work on this. I guess you're telling me this. Yeah. What if we said to the requester, yeah, we can do that, but here's the opportunity cost of dropping what we're doing. We can pick it up again. But because of context switching, et cetera, this will not now get done in the time we originally said or thought it would get done. And it would take longer. And if that's okay, then fine. so I think that we can help move that conversation along with leadership so they understand fully. It's not gonna go anywhere if you've got multiple leaders making multiple asks of the team Right. Saying work on my stuff. Yeah and somebody else doing the same thing. Yeah. Along comes somebody even higher and says, Hey we gotta get ready for this conference work on that stuff. Yeah. That gets difficult I think if it's happening frequent enough, one of the things you could think about is maybe. Just have a team that works on that, a small team that just does that, putting out fires and things like that. Yeah. And then you have your the quintessential development team can be heads down focused on doing development work. Yeah. But that, that requires at some point again, requires leadership to step in tos to segment things so that a certain amount, a certain amount of flow or certain type of flow can happen. Basically just to separate the chaos from the rest of your team. So like you have your chaos team over here, and you have your stable teams over here. Like it depends on the environment, it depends on the technology. There's a lot of stuff it depends on, so like, I, I hate to say it depends. And just like, I'll write you a check and the check says it depends. And that's the end of my help. For anyone listening that may have found this podcast the helpful thing there is that everyone's work becomes transparent and the backlog that is getting shifted in priorities becomes transparent. Okay. So if, if you, I was once in an organization where the product managers, the, the PMs, their, they, they had a very finite list of things that they wanted to get done in I think we were using Azure DevOps in that shop. But anyway, that doesn't matter what the tool was, but they had a very finite list, like maybe like two sprints ahead in the tool. Mm-hmm. of like stories and epics and stuff. But then they had a spreadsheet that went out, like months of stuff that they knew that they were gonna bring in. They knew there, it wasn't even like a spreadsheet of like, my discovery work is kept outside of the system and when I'm talking to customers and about things I can do or whatever, I keep that separate. And then when we get to a certain point in the funnel, I bring it into the system. It was like, no, no, no. They knew they were gonna do that. I mean, they had stuff staged, it wasn't quite a Gant chart. It really was like a list with priorities and they'd move stuff around or whatever. But the point was they weren't using the tool that the development teams and stuff were using, they were using just a spreadsheet on their, on their laptop. Right. It wasn't even a shared spreadsheet between PMs that they talked about when the PMs met or whatever. It truly was as bad as I'm describing it so, so what I'm, what I'm saying is it it, you could go a long way. Toward easing the, the churn, I don't know a better way to a better term, toward easing the churn of like, oh, stop working on this work on this. Oh, oh, that, that's not the top priority anymore. This is a new priority, you can go a long way towards that if you just make the things that are in the pipeline transparent to everyone, right? Yeah. Especially transparent to the people who are about to work on it. But, but to be fair, transparent to anyone who wants to come look at it, right? If anyone wanders into your dashboard, there it is. I mean, that, that's the stuff we're working on. I'm not trying to hide anything, make it transparent. I think that's step one. I fully agree with that. And as some teams will say, well these wild ideas that people have, we put 'em all in our backlog. Yeah. Our backlog's gonna be very, very deep and we don't want that like hundreds or hundreds and hundreds of items. Well, that problem's easy to solve too, right? Don't put 'em directly in the backlog, like you said, put on a dashboard, put in a different, area, right? Microsoft uses area paths. There's other ways to do this, but yes, the bottom line is it should be visible because who knows? maybe somebody on the team when they're looking at this stuff could say, wait, we can't do this cuz we need this other thing done first before it comes up. Well, vice versa we're doing this. If we changed it in a way that allows us to , get to a point we deliver this something else that's down there. Right? So communication obviously becomes important at that stage cuz they could raise that concern, right? But they can't do any of that if they don't see it. So it has to be visible the other thing that happens when it's visible is everything's in one place. Yeah. You have one certain visible radiator where everything is displayed, so you're not left thinking, well, I understand this person who has the loudest voice. They have their spreadsheet. What about these other people? Higher ranked? Maybe they may have their own spreadsheets. You don't have any of that going on. Mm-hmm., it's in one place. Mm-hmm. That is step number one. If I had an organization that was transforming or doing whatever or whatever merge or what you mean, whatever. Let's say for example that we we, we owned like Brian and Om's software development company and we were the most, like all of our processes were all streamlined or whatever, and we were like a a hundred person company and then we bought another a hundred person company, merge it with ours. Like I, I would want, I, as leadership, I would say I want to deploy my enterprise Agile coach to the other environment to help them understand like, this is the way that we work. Okay. And, and the way, and, and I'm doing that to help them be more productive now. And now I'm going to use those terms, which I normally will steer away from using right to, to be more. Efficient and that like the terms that I will try not to talk about, cuz they they could be dirty words and a lot of people in as a community be like, oh, you're talk about being efficient when you're not if you're effective or whatever. But the point is like, I want their development teams to be as efficient as my development teams I wanna be assured as the leader in, in the organization that when I, when I hand an initiative down and I say, I want to increase usage of my mobile app by 20% by the users. I hand that down as a business goal, right. From the business goal. Developers pull down and say, oh, we might do this, we might do this, we might do this my product managers pull it in. Yeah. Decide what they wanna do talk to the development teams, try different things, figure out what they're gonna do so I think of what the topic we're talking about, this leadership problem of you gotta stop starting things and start finishing things. The idea is, well maybe these guys have a couple development teams, maybe have two, three development teams, so the idea is, oh, they get the thing and they're like, okay, well there's, we have three development teams. Each team is whatever, five, eight people. We're taking your business initiative and we're just gonna give it to developer Bob, one guy, oh, he's working on it. We don't know what's happening with that. We can't do anything until he's done. Yeah. Like a, as leadership In that example, I would be super frustrated. I'd be like, I, I told you this is my number one priority. I want more eyeballs in my mobile app. And out of the 15 people, across the three team, three development teams, only one person is working on this. It seems like you. Are not taking my request seriously. Seems like you're not taking the goals that I'm setting as leadership. Seriously, and . First of all, I have been in shops where leadership addresses the team that way as leadership, I would never address the team that way. But my point being is as leadership, that's, that's the way I would feel if I found out that, oh, we just handed it off this one person and now it's his or her responsibility to figure it out. Yeah, I mean, there, there are so many things there, right? So not only is the team not really abiding by the urgency, I guess, or the relevancy of, of that request, right? You've got one person working on it, right? One person who may or may. Work the whole sprint if you're sprinting. Yeah. And maybe they're, they're off for a bit, they get sick or whatever. So you're not really I guess what it boils down to is you're not really taking the, the the direction for priority on that piece of work seriously enough and consequently what's gonna happen is things won't get done when the person making the request wants 'em done. Right so that is something I'm sure we've seen everybody who's listening to this and watching this have seen before. Right we've described some of the, the issues that happen to sort of segue into what can be done mm-hmm. next. Mm-hmm. Mm-hmm. around those things if you've got direction from leadership to work on something instead of just simply taking. Direction and running with it. I would encourage teams to say, okay, but at what expense? Right? So we understand this is more important. Here's the bucket at the moment that we're working on. Yeah and so if maybe it's not leadership necessarily, it could be within the teams, it could be the product owner, the conversation needs to be had, what are we dropping, right? And what is the impact of that? It was a quick conversation drop this, drop that, whatever it is, make sure that's recorded somewhere. Maybe it's in the, in the feature, user story, whatever before you move on, that way you've done something, you've, you've made the decision to switch work, current work for something else that is deemed higher priority. Yeah. So the reason why I harp on this is because when you pick up the work you've. You need to know where to pick it up. Yeah. And with the passage of time, you'll probably start over. Yeah. At least with the discussions, et cetera, getting your mind around it. The developers they work on that urgent thing for let's say a few days, and then they come back to the other thing. Now they have to go back and learn all about that. Like, where were we again? Right. I'm gonna cut in here because I want to reframe what you're talking about, not from the perspective of this came up as a surprise and now we gotta drop what we're working on. I wanna reframe it from the perspective of like, leadership has come down and says this is my, this, this is my top priority. Let's say that coincided with your sprint planning. So now you you just. You, you haven't started a sprint yet, so they're not interrupting any of your work. Okay. You're, they're basically from the start out. Yeah. So, so I'm thinking, I'm thinking from every, every member of a Scrum team, I'm thinking from the product manager's perspective, it's probably the easiest cuz a product manager could be the person at every daily Scrum being being like, Hey, I see us working on things that are not number one priority. What, what, what are we doing? Scrum Master could say the same thing Hey, our sprint goal is, the number one priority. Theoretically they should be related. If it's a sprint goal and it's the number one priority, they should be the same, right? Because otherwise there is a. So put that off to the side for a second. Maybe we'll get back to that. Maybe we won't but then also I feel your developers also could say Hey I see developer, Bob, I see you working on this thing that's a top priority. Would you mind if I hung around and watched just so I can see how that works or whatever, or, okay, can I take this little piece or whatever Right. Pitch in. Exactly. And, and if you're a developer, Bob, and you are the senior developer, as a senior person on the team, you should, any way you should be doing this, you should be saying, why don't you help me with this piece and you help me with this piece, and you should already be breaking up your work. And then to take a step back from Scrum teams to go into the larger organization. If you're development leadership and you see that they've moved all the difficult stuff or all the whatever platform stuff to one person, or all the infrastructure stuff to one person and, maybe you're not on the team, but you're senior, senior development leadership in that organization. Yeah. You should at least have a conversation with your either your lead on that team or with somebody on the developers on your team or somebody to say do you think this I understand you guys are stressing and you're working fast or whatever, but this strategy you're using of just throwing everything on the whatever. Like this is a kind of a self-defeating strategy. For everybody on the team. There is room, there is an entry point for them to step in to assert themselves and say, Hey, we could be working together, we could be swarming to knock out the highest priority and we could be using, doing something to make sure we're knocking out the highest priority together, you know? Yeah, I agree. Absolutely. So one of the things that really helps teams do that is if they have somebody who can say every day, whatever we're doing, is that contributing to our spring goal, right? Yeah. So we won't go there. That's not the focus of this podcast. But I wanted to say something about the how piece now, right? So how do, how do you do that? How do you focus on the highest priority thing and then also keep your eye on something that's late breaking something new which is now of a higher priority than before, right? If, if teams are using a board that's, Obviously make it easier, but it's not the only way to do it. If you're using a board, you could have a lane right at the top for high priority work right. So normally it's empty if the priority doesn't get changed on the team, but if something new comes up, then before bringing it into that, or as you're doing that, again, just to repeat myself, the conversation is what are we taking out? Right. And seeing it on a, on a board with whip limit helps you meter that, right? Yeah but if you're not using a kanban board of sorts, how do you do that then, then? I think that comes down to religiously, making sure that your backlog is ordered. Yeah. So something new comes in as higher priority has to go. Whatever you're working on, when that happens, what you're working on presumably has a status or a state of active or in progress or something like that. Mm-hmm., something new comes in that's higher priority goes above that and it's, it's sitting there in a state of new that visually says to the whole team and anybody looking at that backlog, that this thing is more important. We haven't started on it yet. So it's the onus is then on the team. Typically it's, it's a product owner or somebody like that to make sure that the states or statuses are kept current as well as the order is kept current. As things get done, move 'em away from where they were on the board towards the bottom, whether it's the sprint backlog or the product backlog. So making sure that is kept current is, I think, key in facilitating the conversations. Yeah. You know, I I recently went through this like we were talking before the podcast. I recently went through this and I found that I needed to. I needed to display leadership's initiatives, business level initiatives, business goals. I was talking about before, you can call'em goals, you can call 'em initiatives, you can call 'em whatever you want. Yeah. Objectives, whatever you wanna call it. Mm-hmm., you can, OKRs, you can do the same thing I needed to display them at a high level so that when the individual product managers on individual teams with individual products of their own came in later, they could say, well, I'm servicing this okr, this organizational okr, this organizational objective. I'm servicing it this way. And they can basically pull into their backlog, small pieces of that larger initiative that the business is taking on. But, but, but I like the business only knows, Hey, I like I'm, I'm, this, this is something I wanna do that I'm kind of vetting it against the rest of the things that we could do where no one's really working on it yet. Versus a development team actually is taking pieces of it and implementing it. Like I, I need clear delineations. And, and then, and then the last column is, so it's, it's to do in progress. And the last column obviously is done. Done. Which done might mean I've put enough money into this. I'm not willing to spend more money on this initiative, no matter what product or whatever I'm not willing to spend more money on it. It's cut off, it's done. So you still might have things that you could do that are sitting in different backlogs or whatever, but because the initiative, the high business initiative has closed either the items that are left open, Either migrate to other initiatives where it makes sense to move them to, or they just close because like the businesses decided we don't wanna put any more money into this. I think, I think of a lot of legacy products that I worked on at companies where like, Hey, that's a great idea and we probably can make a little, like 10% more money or whatever, but like, the business is not willing to spend another dime on this product. Yeah. You got what you got as far as money goes and that's it. Yeah. The the accountants use a a metric for that Mai or ROCE return on capital employed. So where is this chunk of money going to go next? Right and, and it helps them, it, it helps them certainly prioritize what they're putting the funding toward I think from a team's perspective, if you're always looking at the boards, your backlogs, et cetera, That can, that can make things visible. Right? So somebody puts something that's a higher priority at the top of the Sure. The chart. And you're working on something that's lower. You are working on it yesterday, maybe the day before, but today you suddenly notice that should be asking the question, Hey, this has come up. Do I need to drop what I'm doing? Yeah yeah. And do not wait for a sprint event for that. Don't wait for the next day. Stand up for that. Ask the question. You have a team chat or you know, some other way that you can communicate with the rest of your team. Yeah, yeah yeah. So that would be, that would be the thing to do is talk about it so you can take action early and then communicate what the decision is and the actions that are being taken to everyone. That's more critical now, cuz you're not actually in a room every day. You can see, see the board, but you could still see the board, right. If you're doing remote in sprint.. Yeah. Yeah, that's true. I mean, if something pops like theoretically, like the, the higher level business objective business goal board that I was talking about things shouldn't, it shouldn't be surprise, it shouldn't be a surprise when things pop up onto that board. Hopefully No, that's right. There shouldn't be too many changes on that cuz otherwise the organization's flip flopping. Well, especially since it's it's cross product. Yeah. It truly is what the organization wants to do and, and, and where it wants to go and stuff like that. So yeah, you can't I hope that your organization is not flip flopping faster than your development teams can move over to, to whatever priority that the organization has set. You're in quite turbulent waters, if that is true. Yeah. I mean there are obviously exceptions, right? Like for example, on that business objective board, you have something that the teams are working on. And maybe the organizational decision is now made to not fund that anymore. Right. So we're sun setting this, there's no more money on that. Right, right. Stop work because any work that you do isn't gonna pay back. Yeah that kind of thing happens, but it's rare, you know? Hopefully. Yeah, I, I could see that. I, I've been, I mean, I've been in projects that have been sunset before and it's, it's basically like there are customers locked into contracts. You have no guarantee they're gonna renew, but, until they do renew, you know how much cash you have. And for the customers that do renew and whatever the cycle is, maybe they have staggered renewals you have X amount of cash and, and they're locked into the product as is with no new features promised or whatever. That's what happens when you, you sunset systems and you have clients that basically like they're trying to move off the system. It's difficult to get I was gonna say, get unmarried , once you're married to a system, it's difficult to not be married. It's not really getting divorced, it's No, that's right. I don't know what I'm trying to say. Like, I don't know. I don't know. I'll tell you what I've seen this thing happen also is when there's mergers, because oftentimes a company takes over another company cuz they want their client base or their product or whatever than their products just being shut down. It's effectively, so I've seen it happen. That environment, that's, that's a much bigger step because now the teams are asked to completely stop work across the board Right. On the product that they've been developing , or enhancing and learn about this new one. Yeah that's a bit of a, that's a bigger jump, but it happens. Yeah. And I would also add, like I, I, I was through that on the Acquire Ring side actually, or we acquired a company that had a mobile app. And uh, I, I remember we like, say like end, when you end a life apps in the mobile app store, you can when people go to open the app, you can give 'em a link that says, Hey, this app is no longer working. Go get this other app. And you know that that's the one you gotta use from now on. And of course, people who are happily using the app that's being decommissioned, they're not like users. They're not happy . That's right, that's right. So they'll, they'll beat you up in the app store. But yeah, some, sometimes, yeah, sometimes you have a, a perfectly working, in this case, the mobile app I'm talking about, it was a perfectly working product. It's just a company who was like, why would I keep two mobile apps? Yeah, I'll, I'll take all your users, I'll roll 'em over into my other u And you know, they actually, that company was super sloppy by the way, the way they did it too. They didn't even automatically. The mobile users over, they, they said, Hey, go register for this app. Here's a link to the app store. And they basically made them act like they were brand new clients. Real, real yeah. Not like customer loyalty was not top of their mind. Yeah. Yeah dollar signs was top of their mind oh boy, where have we seen that before? Yikes you mentioned something before that I, I didn't bring it up when you mentioned it, but I wanna bring it up now. You, you said something about work being blocked. Yeah. Before. Yeah. Yeah. What, what? Like I went through this recently with a team where they were talking about work being blocked and I think what, what I, when I confronted them, I'm like, you guys are using blocked really, really liberally because I like, I think of blocked. I think of blocked like a locked door. You physically cannot walk through like a truly blocked I'm trying to even think of an appropriate usage of the word blocked means. I'm developing a web front end that does functionality y but in order for the web front end to work doing functionality I have to have backend API X developed that functionality y triggers to get its response. Now I could develop front end y webpage with stubbed out nonsense responses, but I can only get so far you can't put it in production. Yeah, right. I mean, I, I might be able to put it in production. You might with like, hey whatever, like I around it, whatever, whatever color of car that you order, it's gonna turn out black. Cuz that's what gets, I don't have the production list of colors. So you're gonna get black, whatever it is. If you wanna order a car with a black paint job, that's the only color that I'm sure that our Brian and Om's auto manufacturing can produce. We are all a hundred percent sure we can do black. So I, as a front end developer, without an API that responds with the proper set of colors. I'm just gonna, everything's black. So we can go to production if leadership's like, you know what, fine on the initial splash page, just say, Hey, just to let you know, Mr. User, before you step through this car order form, you can only choose black as a color. As we're cool with that, like great. But the majority like that. That's a very simplistic Yeah. Yeah. Example. So a, a true blocker is like, well, this thing doesn't even exist and I can't, I can't truly fake it. I think of like a, when I worked on the data warehouse you would pick up data and you'd ship it somewhere else. So like if somebody didn't create the platform you were shipping it to well, the platform doesn't exist, so like you could do things locally or you can create a test environment or whatever, like an in-house. But like if you're proving that you're gonna ship data somewhere and the platform doesn't exist, you're shipping it to, you truly are blocked in that instance yeah. So blocked it doesn't just mean an impediment, it truly means cannot move forward. Yeah. So in that example though, right? Maybe you just change your definition of done to say we're gonna build it, test it, but not, there isn't a final destination for it yet. That might be another story or a bunch of other stories what about something really, really stark, like a developer working remotely? Their laptop crash, they're blocked, they can't work, right? Yeah but I agree with you. Blocked is way too often used to mean, not really blocked, but yeah. Something, right I went through this recently, this week as a matter of fact a, a team had a column on their kanban board called on hold. Mm-hmm., that's just another way of saying blocked. Yeah and there were multiple things over almost two dozen things in that column. Oh boy. And I'm looking at that, that stood out from all the other columns by a long way. I, I mean, I mean, I, I have to say like, I not cool to cut in, but like one thing in the block column should. Like immediately in your daily setup, you should all zone into the one thing in the block column. Absolutely. Whoa, whoa, whoa. There's something blocked. Hang on, let's all stop and see what we can, you know? Right. Let's all roll past sleeve and unblock that thing. So I, one of the things I do as a matter of course now, is to change the color of the cards. not in the on hold or block column. I don't like the column approach at all. Yeah so I, I eliminate the column, but for me, something can be blocked anywhere it can, yeah, it can be blocked and still be in the backlog. So it's new but blocked. Sure can. So I change the color of that card so that, to your point, every day the, the team can see that. Yeah. If it's in the news, it's less of a consequence, but it's just there for, for knowledge. But if it's not in the new call and the team can look at that and say, This is blocked. Why is this blocked? Yeah. Right having almost 21 items in the block column is, or on hold, whatever, same thing that is just an abuse of the, of the actual board. I think. So that's, that's a classic example of a team that keeps starting and you have a bottle bottleneck forming in the on hold column. That can also happen with the active column. They just don't bother blocking it. They just say, oh, well I can't progress that. I'll just pull something else in to work on. Yeah. And that's what obviously we should all be striving to eliminate. So we have flow across from left to right. And the flow should be like water, not like, like molasses. Yeah. You know? The other thing for blocked that I've dealt with as well is the team will say something's blocked because another developer's working, like another developer on the team is working on another piece kind of what I was talking about before is like, well, that developer's working on the backend api and until they're completely done with all the endpoints of the backend api, we're not even gonna start on the front end. And, and like my response, my product response is like, like getting the site launched is the top priority. even if the form to order the car only lets you order a black car because you're faking out the response for that. I, I need the webpage up because the users don't care about the api. The user not ordering a car by pulling up Postman and . We should be hilarious. That'd be hilarious. But like, they're not doing that. Like they're going to the web front end. The development team equivalent of this like kind of what we're talking about here, the, the leadership problem of starting things. Not, not not finishing things, but starting a million things. The development team equivalent here of what we're talking about. Would be I would never even put up the, the first bit of a webpage until the entire backend API for every bit of ordering the car is up and running and, and, and can be exercised via backend test or whatever. And then I wouldn't even start on the front end like, ah, no, no, no, that's not good enough. That's not good at all. Like, I, I would rather you fake me through the demo, right? The whole demo than working this way. So if you're saying like, oh, well the, the, the front end deploying the front end website is blocked because every bit of the backend API that serves it is not ready yet. Again, that's not blocked to me. It's not, now you can, you can call in an impediment. I, I would argue that like, it's probably, I'm not probably using a great example that's probably not even really an impediment now impediment here would be this stuff is only available until we get someone to open a firewall, port production so external users can see it. That'd be like an impediment, you know what I mean? Like somebody that we don't control, somebody we don't control on our team doing something for us. You know, that kind of stuff. Right, right. Yeah, I agree with that. You know, I think people need to get their mindset around not waiting to finish everything. Yeah. Um before progressing and this, this is that old discussion we've had before on a podcast. Slicing the work vertically. So to your point, get the website up. If it has one thing on it, fine. Get it up, put one thing on, and then over time put more and more things on actually, and, and I just thought of the real, a real impediment, like an impeded versus a blocker. A real impediment. A real impediment. Like I, I was talking about the data platform before I just remembered. We were trying to get access to a different data system to pull data into. And we had to get approval to pull data in, but even like there were forms and people that gave approval and stuff like that. Sure but even if we didn't get the approval, we knew what the response from that system looked like so we could fake it but even if we didn't, even after we got the approval, we still had to get credentials. And so, so we cleared the blocker the blocker of, we don't have approval to work in that system. And then we got the approval to work in the system, but then, Another blocker. Another blocker was we had to wait till we got credentials to actually pull from the, the, whatever the, I don't remember if it was a production version or test system. I don't remember what they had. I think they had a test system. Maybe a staging. Yeah. Like something like that but anyway, but like until we got the correct credentials, we couldn't, so it was like, oh, we can do all of our work in stage. I was like, well, I don't care about stage until it's in prod, until people actually pull fields in, in the global catalog. Like I, as a product person, I got nothing to show so I I don't care about stage. So like, are we blocked or is that just an impediment? Cuz again, we can, we can do a demo, we can fake that data. Mm-hmm. We can fake the data. It doesn't, I think there's nothing wrong with that as long as you're up front and say, look, this is not. You know, authentication or whatever, right? This is fake data in the expert. We'll get there and that's fine. That's a great example. Like fake data is a great example of, when I say fake, I'm, I mean, I don't mean fake as in like we just made all the columns and all the data up. I mean fake as in we're using stage data and we're representing it as it would be prod. Yeah. Because we don't have pro credentials yet. But assuming the stage and pro systems have the same fields, credentials, whatever, you know what I mean? Uh, data, basically the data structure looks the same like it's, I guess we're, it's an impediment to moving to production that we have yet to resolve. But we can do a demo. Yeah. I'd say maybe reframe that so to say this is not impediment cuz we know what to do we just haven't done it. We know what to do. We need to do X, y, Z. So it is really a dependency that's at the end of the day Yeah. I, I think this, this word blocker impediment, they, they raise way too often by teams. Yeah. And, and a lot of times team members aren't even doing anything about the said blocker or impediment. They just say I, I don't know what to do here. So I'll call it a blocker and say over to use scrum master. Yeah. Right so I think if you're a scrum master listening to this or watching this, when a team member says they have an impediment, the first question you should ask them is, what have you done to solve that? Right and then come to me, don't say I sent an email to Bob or Mary that that's not taking action. Yeah. I'm blocked on this item and and so I'm just gonna pick up the next one over to you. Om, now, now on your, on for your status. Om That's the norm. Exactly. That's the normal one. That drives me crazy. I'm like, wait a minute, wait a minute, wait a minute. If you're blocking, I'm blocked. If you're blocked on moving an item forward, but whatever, like some people might be like, Hey, dislike this video because impediment blocker, they mean the same to me. It doesn't really matter. Like, take ownership of it home and go figure it out. I'm with you. I, I am on your side. I believe basically the same thing. If you have a blocker impediment, something, basically a work item that cannot move to the next status mm-hmm., you should stop and say, Hey, I have a problem. Can anyone on the team help me out? Okay. No. Okay. No. Mr. ScrumMaster, Mr. Scrum Master, nobody on the team can help me out. So you and I, when the meeting's over, let's put our head together. When the daily stamp's over, let's put our head together, figure out where we go from here, right? Make a plan. Somebody do something, right? Something happens. Scrum, master continual follow up. You know what I mean? Uh until something happens or it doesn't happen, eventually 24 hours will pass. You'll be back in the same spot tomorrow. Same question's gonna ask. If the same question gets asked and the same problems for persisting and the scrum master developer puts our heads together and it's like, oh, we try to do whatever. Like now you need to be thinking about like, okay, who else can we ring into this? Who else can we roll into this discussion if we can't figure it out now? Like that circle needs to keep expanding and expanding and expanding Escalation time. Basically like your full-time job now, between now and when that impediment is resolved Yeah. Is resolving the impediment. That's, that's your number one task now, is to focus on de blocking that. Yeah. Unblocking, unblocking. That I like. I like de blocking. De blocking. I don't where where that came from, but yeah. So I agree with you. Don't, don't neglect it and keep saying unblocked still. Yeah. Don't move on to something else like the minute you move on to something you like, oh, this is difficult, I'm gonna move on to something less difficult. Like you've take an easy way out. Yeah. You're never gonna get back to it, man. It's not gonna get resolved without constant effort from you and or your team, or team members or scrum master, whoever. Like, why? It's not, why would you think it's gonna get like That's, that's, that's, that's this culture of throwing things over the fence and hoping somebody else is gonna fix them. That Scrum tries to get around. That's why we have principles, that's why we have values and stuff. Exactly. And by, by doing what a lot of people do, which is I'm still blocked, so I'm gonna pick up something else. That's how you end up with those blocked columns populating, right, yeah. And, and getting piled on. So yeah, just avoid that. What do you think about the concept of. Streams of work for a development team. So the development team will start a sprint and they'll say, Hey I got, we we wanna implement story X and Y and Z. And so om will take story X and Brian will take story y and developer. Bob will take story Z and we'll all be working on separate streams of work, which, which, which may be contributing to the same feature, but also maybe not even related to each other. So basically the idea is rather than all looking at one story one, one, like rather than swarming or peer programming, swarming, whatever you wanna call it, rather than all working on one thing at the same time we're all going off our separate areas, working individually on separate sets of code. Yeah. So I think what we need to do here is distinguish between the two things you, you just said. You know, if you are working on, if multiple people are working on pieces of the product that will come together and it's a focused effort for at the team level. That is one scenario. That's, yeah the other scenario is everybody's working on different things. You're not even a team at that point. Yeah, right. You should not be a team in that case. You're gang. You're a gang. Yeah, yeah, yeah. Scrum gang . Ah, every, every podcast I get that into is a win. That is a win. Scrum gang. Scrum gang. But if it's the former, one of the things you really need to be mindful of is will all the pieces fit? It's like saying, Brian, you take the corner of this puzzle. We don't know what the end thing's gonna look like, but you go start putting the pieces together of this jigsaw over there. Just do the bottom right corner. Yeah bob does the top left corner and I do the the bottom left corner or whatever, and the other corner. We're just gonna say, whoever has time, just go ahead and do that in your own time by yourself. Yeah whoever finishes first. Yeah. That's your, that's your reward. More work. That's more, but, but how is that puzzle gonna look? Right. That's the question I have. So you have to collaborate to use that word. I'm gonna use it only once today. Only once, but you have to work with one another. You have to understand that, because then collectively, the thing that is kind of not quantifiable, un quantifiable is the knowledge that everybody gets. Mm-hmm. about what we're trying to build. Right. Learnings from one person. Are immediately available to somebody else if you're continuously speaking with another. Yeah. So yeah, you really have to do that. Otherwise you're gonna suffer silos. Yeah, right. You'll build something that looks different. You'll end up with a a square hole in a round bag, square hole, square. That makes sense the other way. No, that does make sense actually no, I had it right. a square hole. It's all about, it's all about size. When you have a square hole Yeah. Around, around peg will fit. If it's small enough . So that, or if the hammer's big enough. So, so you have to, I mean, otherwise you, you're not gonna end up with a product. You're gonna end up with a Franken product that doesn't even look like what you want it to look like. But it's something that's not what you want. Because now guess what? Now you have huge tech debt. this stream's work thing is that's, that's the weirdest thing across my career that I've seen because it's so common among development teams is the think it is. You know what really doesn't help though? Most of the ALM tools propagate this stupid idea. They, by having this thing called, assigned to, yeah, you're right so it's assigned to Bob. Well, okay, Bob, it's all yours. That's all you. It's assigned to home. It's all me. Yeah. Yeah, yeah. It's almost as if your role on and to the team should determine your visibility. To the assignee statuses. So like think about this for a second. If like, I'm using Jira and in Jira you have stories and you have subtasks, right? So subtasks can, and usually are broken up by developer, but they can still swarm on the subtasks, okay? Right but the stories, the stories are assigned to the entire team to complete, cuz because the team commits to a story. So really the assignee on a story should just be your team and your current sprint. Yeah. If you think about it, right? Yeah. That's the assignee, the team in your current sprint first of all, if you're not on the team, you really shouldn't see any of the subtask. maybe if we have to give somebody something, you just get like a little, a little bar that, as you know, if you have seven subtasks, the bar moves in little ticks. You know what I mean? As straight line, right? Yeah, yeah. Subtask get closed, right? The little bar becomes more blue or whatever, as the subtask role wants, right? But if you're not on that team, first of all, if you're not on the team, you, you don't see anything except the blue bar moving for subtest. If you're on the team, then I guess you could split subtests up by team members. And, but, but only for the purpose of, only for the purpose of who is the main developer who's kind of leading the, you know what I mean, getting things together. Cause usually it's one person and everyone else can kinda contribute but even that, I'm, I'm willing to be flexible on even that, to say maybe you don't need that. The point is the point. The higher you are up in leadership, the less names that you will see on individual work items. because it doesn't matter to you. You should say, Hey, I want to hand off this epic. Well, who do you hand off the epic to to get broken down and broken into stories? Well, you hand it off to a product manager. So basically at the leadership level, at the high level board where you see epics, all you need is the name of the product manager. Product managers are on teams, so you should know the team by the product manager. So you assign you leadership delegate epics to product managers to run with. Right. The product managers bring it to teams and they bring, the what that gets broken down into stories, which they are still involved in. So they get to see a high level what in the form of all the stories that contribute up to their epic that they're assigned to. So they're accountable. It's all this, so they're assigned to all the stories cuz it's their stories leading to their epic. So now their name's on it all. Yeah. But then how it's being delivered, if the product manager is also the product owner who sits in the team, then they can see the names on all the stories. But anybody else in the organization who is not on that team can't see anything. That's the way the tool should work. It should, I've seen it work a different way, but I like that a lot because in organizations where the product manager is the product owner, then on the Epic, they have their name. So they can look up at leadership and go, that's mine I've got three teams working on that or whatever. Yeah. At the teams level, if they're the PO they can own the features, they would be assigned to them perhaps but I haven't seen that play out in practice. What I have seen on, on one team is every. User story was assigned to the tech lead on that team. Mm. It's, it's their name and then the tasks are assigned to individual, well own by, I should say. Sure. The creators of the tasks which is anybody on the team to create a task and then they put it, usually they put it against their name. The why this team did that is pretty interesting. So every day the tech lead would be the go to person by anybody who is working on the tasks for that story. Yeah and where you have an active involved tech lead, that works quite well it's not that every story is gonna need their input necessarily, or every task, let's say, but when it, when it is, they're there. So I've seen that, but that is just one. So I'd be more okay with that if you had some high level categories that things broke down into where people were accountable to those high level categories. And I'll give you an example because this is, I'm getting super meta now. So if I had a work item that was a technical enabler type of work item, so, hey, if you wanna go implement this functionality, we're gonna have to upgrade our version of this system to nine x or whatever. Okay, well, the actual upgrade of the system, that is a technical enabler. In order for us to do a functionality later on down the road, that is my tech lead is answerable to that item. So I know who to call when I want to know about that item. I call my tech lead, assuming I don't hand, assuming I don't have product managers. Cause some, some, some businesses., they don't hand technical things off to their product managers. They hand it off to some engineering leader. Yeah. And the engineering leader kind of subs in and out as a product manager, but like a technical version of a product manager, but not the job title product manager. And, and I think of the same thing as like a customer request that's been funneled directly through a customer that says, oh, well maybe like, I've been in companies where like 50% or more of the company's revenue comes from a single customer. So whenever the customer says, Hey, you guys really need to add a checkbox on this screen. Normally you do some discovery work and figure out exactly what the customer needs, but sometimes it's quicker to just implement exactly what they ask for. Yeah. So sometimes you have customer requests and then sometimes you're like, leadership comes down and decides like, oh, this is we want to, we wanna break into this market. We wanna do this strategic thing. We wanna create this analytic product, or these reports out of our database or whatever stuff like that. That they think is gonna strategically position the company. So there's some categories so the strategic things I definitely think should be handed down to product managers Yes. To run with for the next level, the customer things. Maybe you have a subject matter expert, maybe have somebody who works in support, or maybe you have somebody who's like a, a customer advocate type of role who can stand in when questions come up about that kind of stuff. There are different people in the organization that maybe yeah, but obviously my first recommendation would be like, just get your product manager. They, they're supposed to do it all right. But maybe if you're a bit more nuanced than that, or maybe you don't have enough product managers to go around or whatever you mean, maybe there's a, a, some other strategies you can use. I'm doing like the scrum trainer thing of like, just use Scrum the way it's supposed to be used and you'll have no problems. Like, okay. Yeah. But like in the real world, like , other strategies, other, other tactics. I look forward to your angry tweets. I, I was just gonna say, somebody's gonna say something on LinkedIn or something. Oh, no. I hope it's no one who has a day job, but that's what I hope right. But no like these are other things that maybe you can do and it doesn't cost you a lot. I mean, just put the person's name in there that deals with the certain category or whatever, there was ways you could do this to, to kind of help you along. I honestly, I forgot what, what we even talking about, we were talking about this whole assignment, concept. Assignment, yeah so the, just because something is assigned to someone doesn't mean as a team, you simply just say it's on that person. Right. It's them, it's not Right. That piece of work is still for the team to deliver in the sprint. So the team, anybody on the team owns it just as much as the person whose name is on there. It's just that that person might be. The most suited person who knows the most about it, perhaps cuz he is done or she's done that kind of work before. Yeah so I think that attitude change takes a little bit of time to get used to where in the daily standup, for example, team members aren't saying here's what I did yesterday is what I'm doing today, kind of thing, yesterday I stood a standup and gave my status and, and sat down. I'm gonna do the same today. That's right. Right that's where a team member might say, well, I'm working on this thing and I, I kind have a question on this. And another team member immediately could say, well how about we get together right after we can swarm on this peer program or take your mob program. That kind of approach is very beneficial in my experience, but it's also difficult to get a team to to implement that especially if they're a team that hasn't been around a long time , they've had a lot of churn. You don't really know the other person. You know, you don't know if someone's gonna challenge your expertise or you're afraid of being made out to be incompetent or whatever it is. Whatever the insecurities are, they need to be put aside. Let's go down that road. Cuz I mean that's, I feel that's the one thing that is probably most beneficial that we haven't talked about, on today's podcast like how, what are some tactics to kind of get your team or some ideas, I don't wanna say tactics, like dirty tactics. What are some things that you could do to prompt your team? Toward working together, you know what I mean? Swarming on things, basically. That's what, that's what I'm saying. Swarming on things that's what I'm saying because I'm trying not to use the word collaborate, because I, I I feel the, the title of this podcast is gonna be Col Col. Like, we Won't, we don't use the word Collaborate. That's gonna be the title of this podcast, talking about collaboration without using the word collaboration. That's gonna be the title of this podcast. It's gonna have collaboration twice in the title . All right. So as far as tactics go short of buying cattle pros and heating them up That's right. And they grow red. That's right. They're too expensive. That's the only reason. Okay. Very expensive. And the team members tend to not like it. So one of the things you could do is when you're standing up on your daily standup, switch up the routine and say, do you know what Mary's working on? Mary, do you know what Fred's working on? Fred? Do you? Right. Can you talk about that topic that this other person's working on? Yeah. And if they just have completely no idea, it tells you you're not. working well together, almost use the C word. Right so I, so that's just a symptom, right? How do you make that happen? I think every time you point to a task, you could ask the question that I know it's got Fred's name on it, but who can help Fred with this? Yeah fred may say, well, I'm gonna finish you in the next hour. I don't need help. Yeah, that's fine. But otherwise somebody needs to say something. Yeah. So you could ask that question, who has these skill sets who can help this person? Yeah. And, and when that task is wrapped up, he in term can help somebody else. Right. And try and instill that culture of swarming it. It isn't easy especially if the team members don't trust one another. I think that's the, that's at the center of all this. Yeah. Yeah yeah. Like we were saying earlier, before the podcast showing your code to someone else. Oh man. That, that's gotta be tough. Terrifying, right? Yeah, terrifying. So you gotta get that fear out of them and say, it's not your code. This is our code. This girl is gonna speak for all of us when it's out there. Yeah so can we all look at this with the aim to not necessarily say, oh, you're terrible at coding. The aim is, how can we get this done the right way, obviously Yeah. But get it done right collectively. Yeah. That, that mentality, that kind of an approach, I think will foster this behavior of swarming together. I'm already compiling my agenda for round two of this podcast because we didn't even talk about like sitting testers with your developers. Oh yeah. When, when they start writing line one of code sitting, sitting down and saying like, Hey, hey like the first thing, what is this? What is this function supposed to do? What, what is this piece of the code? What is this new module we're writing supposed to do? Oh, it's supposed to display a webpage for login. Okay. Well let's make sure that you're not logged in first. Oh. Oh. I guess that should be the wrapper of my right. You know, if, if, as long as you're not logged in, let me check that first and then now let me check now, now let me prompt the login page. Yeah cuz if you're logged in, like you don't need a login page. If your first story is create a login page, that's not going to be the first thing that I would think to code. If my first story is create a login page and my test is behind me, you don't need this page if you're logged in. When you. Working together, you're going to identify things that maybe you won't think of on your own. Absolutely because testers think slightly differently, right? Yeah. I agree. I, I think if you, if you had a magic wand, you could put your testers with your developers day one, like first hour of the sprint and work out some tests that can be written first and small ones. Yeah and then just write enough, go to fail the test and then move on. Right, right. If you do that, if you do that well, when that story is. And the tester does their they do their automation or whatever they, whether they do a manual quick check, whatever it is, that's gonna go super fast. Because by definition you've gone through all, all of that. Yeah but to get to that point requires a mindset change, right. Because nine times out of 10, if not 10 times out of 10, testers aren't sitting with developers. Day one, they're just simply saying, when can I get something to test? Right. Yeah. And we've gotta get away from that. Yeah. and that is kind of why we titled this podcast as a leadership problems, because I feel there are, there are organizations where you will never even get to having that conversation because they'll, they'll, they will say like, why would I pay a tester to sit with a developer and not do anything? Air quotes? Yeah. Not, I mean, I know, I know it sounds ridiculous, but not do anything while my like theoretically if you have no. Automation testing at all, and you're only a manual test shop. Your developer, your developer and your testers still are sitting together while the codes being written. And theoretically your tester is still testing it at, at the end of the line, inspecting for quality that everything we, everything demoing said not to do, assuming you're still doing that. But the point is now they see how the code is written. Mm-hmm. and they were involved though during the whole time. So they're still doing the test at the end but the point is now they can be assured that things have been thought of at the very, very beginning of the production. Yeah. So in that scenario, in that model, right, the tests that they're doing at the end are more likely the pre inspection when you pick up a vehicle. Yeah you wouldn't want to pick one up without. Things happen, things get missed out, but that's a minimal thing at the end because they were there involved from the beginning right. Any pivots that needed to happen, et cetera already happened. Yeah so just we know we know what to do. Right. Then why isn't it being done? Mm-hmm., it, it's, it all comes down to the mindset, we need to break this, this paradigm that people have in their heads about testers testing things once things have been chucked over the wall from developers that has to go. And some of the ways you can do that you've just touched on one, right? Get together with the developer day one, but you don't have enough testers to do that for every developer necessarily say you have five developers, you don't have five testers who can do all of that. So there is that mm-hmm.. Now, as far as changing the attitudes and can do is have your tester do things like. run your product demo. They, they're actually doing the demonstration. Yeah and then when they get feedback, that feedback is translated not by a BA. So change up the roles is what I'm saying. Yeah. Right 10 rules. So the 10 rules to me is when somebody writes 10 lines of code, the tester needs to be there to look at that. Mm-hmm., right? This is different from TDD. This is writing the code first, but still the tester there. And they could say, what about this? What about that? Yeah. Yeah. It's not as good as tdd. Sure. But it is a step toward it these are little things you can do to get there in the not too distant future. I wanna keep going cuz we're talking about testing. So I'm excited. But to cap this off the streams a work thing is always weird for me cuz I'm like, why, why do you care about everyone going off and working on individual things that may or may not be the priority? Just, just to keep everyone busy. Like, I I Oh yeah. I mean, I get that project management mindset. I, I understand it's, it's, it's pretty natural for people depending on their background to fall into that control type of mindset. And I, so I understand. Like, I don't, I don't get too upset about it being that prevalent out there, but also you gotta know at some point this doesn't really do anything. Yeah. You know, it's hard to divorce yourself from that mindset if you come from that. That that domain, that background as one who was living in those, in those spheres, I can say that, but cuz the focus was on utilization. Keep people busy utilization right. And yeah, they could just write please turn over on a piece of paper on both sides and keep doing that every day. Right. That doesn't really get you the value you looking for. Yeah but again, if one's come from that environment, that's all you know. Mm-hmm., right. And yeah, and, and like, just to, just to cap this podcast off like that, there was a, there was a discussion we had before the podcast that I think encapsulates CIS really well. Is, is there's, there's two management teams in two different organizations. And one management team says, oh, you need to show us a, a, a work breakdown that proves that over the duration of the project everyone is utilized to X percentage of their eight hours per day. And I mean, show me that everyone's working 7.25 hours per day or whatever, and show me what, what activities are gonna be involved in along the way. And then the other management team says show me that everyone is working on what I declare as the top priority until the top priority is done. And then moving on to the next priority show. Show me that people are working together to make sure that the business' top priorities are knocked out in the order in which the business. sets of priorities, right? Until we are done, done with the list, basically. Which, I mean, you're never, you're never done with the list obviously in either, either in either methodology. You're never done with the list of work. No but the point is in the second example that I, that I used, not, not the one that is concerned with utilization it, it's so much more mature of a way to run a business to say, I'm gonna give you the employees in my business, my number one goal. And I want you all to put your heads together to figure out how to accomplish my number one goal. And when my number one goal is accomplished, and I feel this is the star next to this, when my number one goal is accomplished, star, or accomplished enough where I decide, I leadership decide I will accept this. This is enough. Move on to number two okay, so, so you finish your work. You keep showing me the work until I say, okay, enough. Enough. I know there's other things we can do. Yes, the product would be better with more things, but this is enough. Goal number two is creeping up. We gotta get to it. Let's pivot. Cut off goal number one. That is a lot different than just saying, oh, what are you doing to make sure that everyone has their butts and seats for 7.5 hours per day? hands on keyboard. Yeah. Yeah, I agree. It's a completely different mentality, right? Even one's gonna get you the actual value, the result that you want. The other one's going to get you good numbers. That's it. Yeah. Eventually, good numbers that are meaningless. Meaningless, right? Exactly. So it. Yeah, everybody's working great. Everybody's working, right? Yeah. But what are they producing? Yeah, yeah. Yeah. So it's pretty clear to me that a lot of organizations are still in that camp where they're looking at keeping people busy. Yeah. You know, we're paying them, they gotta be busy, right. All right. Well that's is that a wrap? That's a wrap. That's, that's this podcast all right. Well make sure everybody you sure you like our podcast. Give us your comments down below and let us know what else you'd like to hear about and let us know what shorts you wanna see. yes, that too