AA131 - EVERYTHING IS PRIORITY ONE!!!

Anyway. All right, here at Brian and Om's software development company, everything is priority one. Everything all the time is priority one. Of course. Who wants to prioritize when we can have everything right now? Everything is a burning must have right now scenario. Priority one. Keep listening to the podcast. If this sounds like your organization, I'm sure people can relate to this. I'm sure everybody's come across this where people just say. Yeah, that's priority one. So is this, so is that, right? Everything's priority one. So, that's this podcast. That's right. Alright, hit the music. Oh, there's not. There's still no music. Musicians didn't turn up today. We should have music. If we're going down the road of everything is priority one all the time, the first thing I expect people to have real world experience in is being in a company where people leave And they don't replace them and the people that stay with the company, as they don't replace employees, they do more and more and more work. Yeah, they just get more hats to wear. That's often what I hear. I got another hat I'm gonna wear tomorrow. I'm trying hard to recall a time when, everybody had only one thing, right? I can always remember everybody had more than one thing to do. I know I did in my early career as doing multiple things and not necessarily doing any of them all that well. But that's just the nature of it. You pay for, you pay for, distributed attention spans and time slicing and all of that good stuff. Um, but I, I want to go back to what you just said. Um, sometimes it's not the culture, but most times it is the culture because people flourish under a certain culture. It's like having a very strong tide coming in. You can fight against it. You feel like you're making some headway, but you really not, it's just a momentary, gratification. For the purpose of this podcast, because again, we could, we could talk the whole podcast, on the topic of companies trying to squeeze every ounce of quote resource. You know, every, every human resource that they can just trying to wring that rag out and try to get every drop out. this before though, right? Utilization and all that. Yeah, yeah. You got to be over 80%. Yeah, I don't want to, I don't want to talk about that. No, that's not this podcast. I don't want that to be this podcast. Let's talk about you feeling like everything is priority one. Because of the most common reason. What I think the most common reason why everything is priority one is because product is not setting a clear expectation of prioritization. Product is not stepping in, or maybe you don't have product. And that's why it's not clear, but, but, but their product is not giving clear expectations. Absolutely. Yeah. I mean, so certainly if you have no product, yeah, I mean, there's other issues you have there, but yeah, product not setting. Proper expectations, and also, even if, even if they did, you have a culture where people higher up can feel free to come in. These are seagull stakeholders. They come in, they hover over your team, they poop everywhere, steal their lunch and disappear. These are the people that say. What are you working on? Oh, that's great. They don't really want to hear about what you're working on. Uh, however, this is really important. I need you to work on this, Jim. I need, I need you to work on this, Janet. And then they disappear, right? And before you've even had a chance to kind of mull through what they're talking about. But in comes another senior leader and they do the same thing. So every leader is dumping on you by saying, this is priority one, you better do this now. That is a cultural thing. I've seen that in several organizations where this happens, right? And in that case, what is the team member, whoever your role is, what are you supposed to do when someone says, this is priority one? And another person says this is priority one, sometimes it's the same person, which is absolutely ridiculous. How can the same person say, two things are priority one or multiple things are priority one, but it does happen. So when that happens, what is, what is a person to do? Because you think about how you're organizing things work wise, let's say you have an ALM tool. Doesn't doesn't even even have to be a tool. I mean, let's say you have a bunch of stickies in a column. That's your that's your backlog. You have a sticky above another, and that stickies above another is a ranked order that you've prioritized based on whatever. Right? But there's only one at the top and ALM tools enforce this by nature, right? The backlog only has one Or a one mm-hmm. item. Right? And it's a sequence and there's a reason for that, right? However, in many companies, many organizations, you are asked to work on multiple ones. I've even seen organizations that, or teams even, right? These are, these are bad practices, but teams will say, this is priority one A, this is priority one B, this is one C. To me, that's 1, 2, 3. Yeah. Right. Yeah. Yeah, I don't, I can't really make an excuse for why people would do that. I mean, like the the people actually carrying out the work clearly understand like, okay, when now we're playing games with priority ones the point that you had made earlier, before we started the podcast was when you, when product is not defining the priorities or product is defined, literally everything is priority one, then, then basically product is delegating to the development team. To say what the priorities are because now the development team is going to choose the order in which they pick things up and you may or may not have a choice in that and you may or may not be happy about their choice and what they pick up to work on next because again, as, as like when I was on development teams and I, I, and I was Uh, how can I say this? I was fed work by other teams. You know, other teams would send me work and say, Hey, this is priority one. I don't know what was going on in our world where we allowed other people to set our priorities. However, we would receive several priority ones at once. Um, we would look through them and say which of these do we think is, if, that we can get through more quickly? Or which of these do we suspect that we already know what's happening and that isn't really a problem that we can, resolve it quickly? People might hear what I just said and say, oh, that sounds like you're doing some kind of like weighted shortest job type of deal, right? You know what I mean? Like, the quickest resolution gets resolved first. No, no, no, it really wasn't that way because we would look at things and say, oh, I think I have that test environment set up to handle. And I think I can replicate that just, just because it just happens. Just coincidence that I think I might be able to do that, or it might be intriguing. And I just decided I want to work on that one first because it's more intriguing than the other ones, when, yeah. So to your point about. The team deciding what to work on because really nobody's giving them priority, which is exactly what happens when everybody says everything's priority one. Human nature is basically like this, right? They're gonna say, a team member would say, let's pick up something that is either interesting or intriguing to me, individually, or Something that I can be assured I will finish so that people aren't asking me about it later, right? I'm coloring now with my interests as opposed to a customer value or business priority or whatever. It's time to resolution. Any, any other, any other type of thing? And the, the issue here, there's also another issue here. I don't know if this is the right time to, I dunno if this is the right time to call out this issue, but, you, you, you brought it up. You just brought up like, I'm picking this up because I think I can get this resolved fairly quickly. the subtext of what you just said is very real from when I used to be a manager. What you just said is a very real thing because it's somebody in the, in the organization would go pull stats that says how many items that were assigned to Brian in the past six months got marked as resolved as opposed to marked as whatever, something else. And then, not resolved or had to, had to go through iteration loops to get resolved or basically, the underlying assumption of that metric is how good is Brian at resolving tickets? But, but, you know what, the funny thing about that is if you had control of what tickets you picked up and you only picked up the easiest ones and you resolved them. You would have a better metric than anyone else. You would. And if an organization is, is valuing that metric to reward you, then why wouldn't you pick up the easy ones? Yeah. Right. Yeah. Uh, but that just simply says your entire prioritization framework just went out the window. Because you've let the team do things their way, and it's really just anarchy at that stage. we're getting a little bit off topic, but I think where this is relevant is the culture where everything's a P1 probably also has these games at play. I will tell you, let me say that in a different way. Where I worked, that, where they were guilty of this problem, where this problem was completely apparent, they had these other games that I'm talking about at play. They had people that would pick things. To say, Oh, I'm working on these support tickets and they would grab the easiest ones as fast as possible for, before anyone else got to them. I, I, I distinctly remember because I, I, like being a manager in that organization, I remember I didn't have to take any, uh, work items on myself. I could delegate all the work items a hundred percent of the work items. In fact, I would get feedback often that was like, why? Why are you working on that? Like, you got, you got managerial stuff you could be working on. I would take the worst, the worst work items because I knew that nobody was looking at my, I was not judged on time to resolve or percentage of resolved or anything. Anything like that. I was not judged on any of that. Any of those metrics, I was judged on managerial metrics, which were much, much, much different. So it didn't, so I would take the worst work items and I would, take them into my queue and, and I, like I had the worst, time to resolve. but I would take the most complicated, most technical, work items, so that my team didn't, didn't have to deal with this, this game basically, because this metrics game. At that company was not perpetuated by me. It wasn't perpetuated by my level of management. It was perpetuated far, far, far above in the hierarchy. Um, all these games, you know. Yeah, that's, that's what I was saying earlier, what is the organization prize, right? Um, so it, let's, let's just go with this, right? Let's just say the team decides whatever they want to do in terms of priority because everything is priority one. So it doesn't matter what they pick to work on. They've met. Criteria. They're working on the top priority because they're all top priorities. So when that happens, how do you deliver value to your customer at the end of a sprint when that is happening, right? Um, how, so, so kind of where I'm heading with that is, is your team using sprint goals, first of all, and if they are, what does that look like when everybody's picking their own work anyway, right? Uh, and and then extend that out to what value are you actually delivering in the customer's hands. Everything is priority one. So it doesn't matter what you do. You've met, you met the ask from management, senior management. I would argue in this case if everything in a culture where everything is priority one, nothing is priority one. So I, I would argue that who, who, Whomever, whomever, should be responsible for prioritization has completely abdicated that responsibility and has passed it to the next level down in the hierarchy. Whoever that is, whether it's a mid-manager or whether that's the product team or whether that's the development manager development the development manager, yeah. Some, somebody, so somebody else is taking it on. I, I mean, I would, I would. I would encourage the team to, to look at this in a positive light and take prioritization on at a team level and, and make, make, come to a consensus between all the team members together. Come, come, and you could do this with your working agreement. You could say, we're going to come to a unanimous. Decision on every, on every, uh, decision and, and you might hear that you might in management, you might hear that and be like, Oh my God, a unanimous decision. What's that going to take forever to decide? I mean, yeah, maybe the first one or two, but quickly after, but yeah, after a while, your team's going to learn quickly and, and you're going to start coming to unanimous decisions very quickly because some things are just not worth fighting about and, and the things that are worth fighting about the team again, they worked assuming they work together every day. And they're a reasonable sized team. They're not a team of 30, 50 people. You know, some ridiculous team like that. Um. They should be able to say, Oh, this seems really important to you. Okay, well, let's, let's, there must be a reason. Let's sit down and talk about it. Talk about it for 15, 20 minutes. And then you make a decision between you all and then you move on. Yeah, so I agree, first of all. And secondly, I want to say this. I want to repeat what I just said. You know, you're probably not utilizing sprint goals. Effectively, if the team is just picking on whatever they want to work on, if that is happening, then you look at the upstream impact of that, right? So sprint goals aren't really very effective if they're being used at all. How do they align with your Organizational strategy, to your objectives. How do the strategies then in turn, upstream again, align to the strategies, sorry, align to the objectives, right? and then the objectives probably fall under mission, vision, etc. So this thing is, has a far reaching impact than just simply saying work on this, now work on this, now work on this. Let's argue on sprint goals for a second. So. Sure. So if you set a sprint goal and then your product manager rise off into the sunset and is not accessible to the team for the rest of the sprint, like that basically is like you didn't set a sprint goal in the first place. Like you, you need to be there again. Like this, the, the scrum guide is where I sort of like a disagree with the scrum guide where it's like, Oh, the product owner is optional. You don't really need to, but you, you shouldn't need to be at the daily scrum because it's for the developers or whatever. that's great, but also, let me figure out a way to, to, to, to make the statement I'm about to make in the form of a question. The Daily Scrum. It's for the developers, right? It's, it's a, it's a planning session for the developers. However, understanding that the product manager is optional, doesn't really need to be there. Doesn't really serve a core function there. They're really just there in case people want to ask them clarifying questions, right? Right. However, there's nothing stopping the product manager from saying, Hey, I see you guys are not concentrating on the sprint goal today. Uh, like you're making a plan to not concentrate on the sprinkle today. are you sure? Like, How many days are we going to do this? Like, are you going to get back to this print goal? Like, I mean, the, the, the, the, the checking function, the balancing function that, that, product manager would might play like that can get out of hand real quick. That's why I'm bringing it up as a, like a, kind of walking on, I'm walking on eggshells right here, bringing it up. But the point is like, if nobody in the team saying, Hey, everything we're doing is not. Not part of the sprinkle. Like, this is not important. Like, at the end of the stand up, the product manager, I would expect, if they are there, to say, you guys, what are you guys doing to advance the Sprint Goal today? Yeah, I, I, well, yeah, absolutely. So a product manager, listen, if you're out there and you're saying the product manager should not be, or product owner should not be in your, daily stand up team sync, et cetera, let me tell you, you're wrong because they're part and parcel of the development team. Now I'm not saying they must be mandatory, right? They don't necessarily have to attend every meeting, but they can, they are invited and they can be there. So in the scenario that you just outlined, where the team is working on stuff that is not directly aligned with the sprint goal. They're perfectly, within their rights to say at the 16th minute, at the end of the daily stand up, I have a question, I'll wait, and then at the 16th minute, they can ask this question. How is this particular work item, how is this work aligned with the sprint goal? I think it's, it's well within their rights to ask the question, and then the team can say whatever, whatever the rationale is, right? If the rationale is... Well, I don't know. Or, I thought I'd get this done and then I'll work on something that's closely aligned. These are all excuses at the end of the day. Uh, well, I mean, they might be excuses, but also, if you're going to, the reality of day to day development, that I, again, I understand as a product manager only because I work on development teams for years and years and years, is that sometimes you say, well, we're taking this, we're taking this little side path. And we're going to, we're going down the side path for a couple of days, day two, three days, whatever. Assuming you have a two week sprint, we're going on the side path for a day or two because we think when we knock this out, there won't be all these garbage error messages in the logs anymore. It'll be a lot easier for our day to day life with all this stuff that you're not involved in that you don't see. And it's, and, and we know that we can completely knock it out and have it done. And we'll be back to your sprint goal and we can get it done by the end of the sprint. It shouldn't cause any issue. And if it does, we're going to pause all this stuff, but don't worry about it. Well, in that case, it's still somehow related to the spring goal, right? Oh, well, well, it may be tangentially related. Well, it may be, it may be completely unrelated. If it's completely unrelated, then the product. One person should be assured that that sprint goal is not jeopardized by taking on this one or two day journey. That's what I'm saying. That's what I'm saying. Where I have encountered that before, like I've been on teams before where they do, they do feature development, but also they support a product that is running in production. So when the product that is running in production has issues, they have to stop and address the issues. And that may be unplanned work. Right? But a lot of times the issues are just like, Hey, I got this message or I saw this thing in the log and I want to go chase it, okay, well, like the more advanced teams will chase that via time boxes. They won't even write work items. They'll just say, okay, we're going to, we're going to take this person off of task and spend a half a day. See what you can learn, after lunch, we'll get on a call, you can debrief us, you can walk us through what you learned, right, that kind of stuff. That's not a, to me, that's not a huge pivot away from your sprint goal. I don't think it's a pivot at all. That's just, I think that's just business as usual. Um, what is a, what is a pivot away from the sprint goal is when they say, We're doing this this sprint. I know we agreed on all this other stuff, but we're doing this this sprint, and then the next sprint, we'll go back to whatever that we agreed with, right? That is wrong. I bring all this up because we started with sprint goals. Yeah. And, I bring all this up to say... If you have a solid goal in mind, when you begin the sprint, you stated that clear goal and everyone on the team has agreed. And that's how you launch your sprint. The, the, the, the issue here is when you're, you're sprinted, you not have sprint goals when you start them, complete all the work items is not. It's not a sprint goal. No. Okay. And, if I'm going to hammer on product, like I work in product, so I can do that. Uh, that's, that's, that's the way it works on the podcast. You didn't know that. Um, it's, it's to say, if you don't have clear sprint goals, it's probably because you don't have clear business goals or strategies. And if you don't have clear business goals or strategies, if your goals are not very well defined, it's You know, oh, we want to increase, uh, user views of this new page we put in production. We want to, we want 10 percent more views. We get, we get, we get 100 views a week on this page. We want to get 110 views this week. What are we doing to promote this page? Whatever your goal is. It can be measured, clearly. You need to give that to the team and let them figure out how they're gonna, move forward with it. But if you don't have, well defined goals like that, maybe it's time to slow down and talk with your team and talk with the business. Talk with the executives, talk with sales, marketing, whoever you need to get in the room. Talk with the customer, whoever you get in the room, whomever you need to get in the room. Yes, whomever. That's right. I don't think that's the appropriate use of whom. You get the grammar reward there. Not sure. Um, but, to get, to write better goals, to get over this problem, you know. If you have something to point to, if you have a, people call this a North Star metric, right? If you have a... If you have something to point to, to keep everyone on the right track, it really, really helps in product, you know. And again, anybody listening to this, if you're not in product, you can help product by re emphasizing, Hey, we don't seem to have real solid goals. Our goals seem to be real squishy. Very ambiguous. Do whatever I say. Yeah, and only what I say and oh, oh and goals are not get it done by October 1st, that's not a goal That's not a goal. Yeah, that's not a goal Yeah, yeah, that's not a goal. So two things I want to say here First of all, we and this probably is the last thing with on spring goes before we move on to the next thing Sprint goals aren't handed down to the team by anybody. The sprint goals are steered by product, discussed, debated and agreed upon by the team that this is a goal that we can actually hit in the sprint. So product could say, well, here's this north star and I need you to go, go do that. I need you to go solve world hunger in 10 days. That's a sprint goal, right? And the team could say, well, I don't know about that, right? Well, I mean, I mean, to be fair to the To the, to the example, the North star would be, there are no hungry children on earth. That'd be, that'd be the North star, no hungry. So, so if I'm going to, if I'm going to publish that as a North star, then we have to have the ability to measure the number of hungry children on earth. Right, we, we have to have that. Otherwise I can say, how am I going to know that we've achieved our goal? You're not going to know if you've met the goal or not. So that's our North Star. My goal will be in line with that. Yeah, and steal food from all the adults and just feed it to the hungry children. That's right. Steal food from, uh. I don't know. That was the first thing I wanted to say. Sprint Go is not something that's handed down to your dictated down to the down to the team level. Right. Um, so that I forgot what the other thing was that I was trying to say now. Oh, yeah. North Star. That term is interesting. So we use it all the time in the U. S. And in Europe, I suspect. But if you're south of the equator, is this still a North Star? I don't know. Don't they see me? Need more coffee. I'm pretty sure they need, yeah, yeah, that's true. Need more coffee. Yeah. I also need more coffee. Anyway, that was a meaningless, like, no, no, it was, it was, that was a good section, because it brings us back to something we come back to a lot on this podcast, which is, your goals are not well defined. Oh, why am I goals not defined? Because the business is not really defined a good strategy, like the, the, the, the business doesn't really know. where they're going. If you ask a business leader, one of your executives, Where do you think my department and the company overall will be three years from now? What does that picture look like? Paint that picture for me, you know? And if they say they don't know or if they say, sold We're gonna sell the business three years from now. I won't be here. You can just, you can just, yeah You can just be, you can just be like John Cena. Like, you can just walk away. Yeah. We focus a lot on the business's like responsibility to bring to the team We have not like I want to turn the mirror around to look back on the team because teams over committing to things, teams over committing to things. I've seen this a bunch of times of, a senior developer on the team or just a, just a people pleaser on the team saying, yeah, we can get that done. We can come in though. You know what, you know what else I think of? I think of teams. That constantly the scrum master and the product owner are both saying, Oh, like the last two sprints, the last three sprints, you've, you've, you've turned in six points of work and you've committed to 12 points of work. And now you're committing to 20 points of work. You guys really, you want to think about that for a minute and the team members are like, No, we got this! It's great! We can do it! I have encountered this quite a bit. You know, everything being, I don't know about everything being, everything being priority one meaning the team members feel the urgency. So they feel the need to overcommit. They feel the need to overcommit. And that is also again, going back, I'm beating the same drum, but it's a cultural thing, right? This is, this is what the organization basically, prizes. If you prize that you're looking at your team members going, well, you're only committing to 65, 70 percent of your capacity. What's wrong with you? What are you going to do with the other 30%? You need to build in some slack. And so those kinds of cultures lead the team members to overcommit. And when you overcommit, seldom do you actually meet that commitment, right? Typically, or more often than not, I should say, you don't meet that. So if you don't meet that the first time... Maybe the second or third time. You should really look at that and say, how is this helping us? Right. It's, it's not helping you. Uh, I want to go back just really quickly to this idea of the, organizational goals, business goals, not being well defined. Okay. If they're not well defined. Then, looking at it from that level down, the downstream impact is, none of the stuff underneath that is really crisply defined. So you end up with ambiguous sprint goals if you have them at all. So what should the team members do here in this case, right? If you're a team member listening to this and watching this podcast, what should you do? Are you within your, are you in your grounds when you say, Hey listen, I'm not clear on the objective. I, I see what you're saying, I need to work on this and I need to work on this also because everything's priority one. But why? We have these things that were discussed for fiscal year 24, let's say. And these things don't necessarily cleanly line up to that. Should they be empowered to question those things with whoever mid managers, senior managers, whoever, leadership, right product, whoever it is, that's actually telling them everything's priority one. I would say yes, they should feel very safe in saying, I'm not so sure about this, right? Because we say we're doing these things higher up, up here, but all these things don't really add up to us going in that direction. It's like saying, well, we want to, we want to navigate to, Tahiti from here. And you have a compass, you have a map. But your map isn't really taking you in that direction, it's taking you the other way around the world. So, so, if you're one of those sailors on that ship, you're well within your rights to say... Wait, right, why are we doing this? If you're not doing that, you're simply at a point where you succumb to whatever people tell you, is priority one, then we basically have failed or we will fail very quickly. I don't know if I've experienced that. I kind of like it. Have you experienced team members feeling empowered to question leadership on the objectives? That's awesome. Yes, that's awesome. I've seen that one or two times. Not all at all. Yeah, but also I've also seen and I have also seen entire teams get washed out and, like cut. Yeah, I've also seen like the leadership, wanting to, well, let's be honest with management, like cutting the mouthy teams. Mouthy teams, not team players. Oh, Fred or Mary, they're not team players. The people that say, these, these goals, really, do any customers care about these? Or are these just like your pet project? Or, yeah, I've also seen a team who connects with end users and, starts getting viewed as a threat through the organization. Through all the channels that normally talk directly to end users. Marketing, sales, account management. People like people that are, that who should be helping the development teams understand, customer problems and, and, and when what, what, customer issues, are pain points, people who really should be enabling the teams, but they start viewing as those teams start talking directly to customers, they view them as. Threats now in the organization. Yeah. Yeah. I've seen that too. I've seen a lot of bad stuff. Oh yeah. I agree. I mean, your customer support team is prime for, identifying what the pain points are because you talk to them every day, look back and look at all the calls that have come in and say, this is where we're weak. Right? Even if it's not specific to a specific call, you know the area and you can kind of bolster that up. But yeah, I think all of this just goes back to organizational culture, which is a function of the structure, how it's structured. Yeah, but we're not gonna go there. That's a different part. Well, let's let's let's talk about culture for a second because the organizational culture that you're describing I feel the the career experience that I've had is In a similar organization that you're describing was a very reactive one. They never really did anything proactive. You know, they, they, they sort of were in this late, late majority type of market segment. You know what I mean? The, the, the, the, the people who've kind of cornered the market and they're, they're, innovation is not really a big cornerstone of their development strategy. They'll develop new features, but really only so far as they can sell them to their existing customers and kind of cross sell them to other customers that don't have them yet. And, and it's a really lazy kind of sales model. It's a complacency model, right? Yeah. I mean, yeah, we're, we're a customer going to go. They love us, right? And then reality hits one day. Well, it's all, it's also, we talked about before, about the, we, we talked about on a previous podcast, I can't remember which podcast it was about this, this black box of, inputs go into the black box and outputs come out of the black box, but the environment affects what, how things are produced out of the, out of the black box and the environment. Meaning the business environment around your customers. So, as the market changes, as environmental issues, different technologies, different regulatory type of things, different trends in the market, customer preferences, user preferences, as things in the environment affect your, quote, black box, it could impact the normal outputs that you're expecting. So, you're doing the same thing you're doing year over year. Not changing anything again, because you have a very reactive culture where you really don't, you're not on the, you're not surfing the edge of the wave here. You know, you're really just reacting when things, hit your bottom line numbers and, and that reactive culture is sort of what you're describing. This isn't like everything you're describing. I do not, some, some of the cultures and some of the companies that I've been in, especially the real, real early startup companies, they're not, they don't fall foul of this because they, they, they just don't, if they, if they fell into a reactive mindset, they'd be gone like in months, they'd be gone. Yeah, I agree. I've seen some of these companies where the startups specifically, right, they don't fall foul of that initially. And then they grow and then they grow. Oh, yeah. And you know, and then they start to succumb a little at a time. You've seen that behavior, I'm sure. But yeah, absolutely. So, I think it's important for anybody who has any role, whether you're a development team member, you're in product, whatever, to feel empowered to question Anytime you're given direction on prioritization, right? These are priority ones or whatever it is to say, how does it align with what we said we would do? Yeah. Um, if it doesn't feel free to ask the question, how does this align? Help me understand. Help me help you. You know, speaking, asking questions, I kind of pivoted us in this podcast to ask about like, things that were, the team is kind of causing everything to be a P one. Communication, is another one where it, when you don't have good, I'm trying, I'm, I'm, I'm fighting very hard to not say scaled when you have a lot of development teams that work together that are interdependent. Mm-hmm., oh boy, that's a terrible word. That are dependent on each other. Yeah, they got dependencies. See what I did. Oh, this is not getting any better. Oh, no When you have a lot of teams that work together on a regular basis Mm hmm The the way in which they interact and talk to each other and the way they plan work can cause this Like if somebody is planning something I think of all the scaled Sessions that I've ever gone to and there's always a team that is like we're we want to start this work But we don't have this one thing from this other team. We need you to get it done as fast as possible Yeah, oh we're blocked. Yeah, I think of like a scale daily scrum We're blocked on this item. We need you to finish it. Well, we're working on this other thing. It's a higher priority. Well, we can't start unless, now we have a, a situation. You know, somebody from leadership in that session is, is like, what's the takeaway from the, what's the action item that has to be resolved before the next time we meet? I mean, you're taking off the table for a second that why don't we just both go talk to the stakeholders in in both of the activities that we're engaged in? Well, the thing that's blocked and the thing that we're doing is a top priority. And then why don't we involve the end users, the customers, and maybe management or other teams or whoever we need to product right product. but, this, this, without a, a good, because again, most people don't have Scrum Masters in this, so without a good facilitator, and without a good framework, so, so, double trouble. You don't have a good framework to handle this. Because maybe you're trying to scale things, and maybe you don't have a framework, and maybe some teams use Scrum, some teams use Kanban, some teams use Chaos, some teams use, do whatever I say, Mr. Manager. And then, maybe you don't have Scrum Masters, because your company can't afford it, or whatever. And then maybe some teams use a product, and some teams don't, and some teams do., because different teams operate differently, the communication method now gets all muddled. So what should be, if it was a bunch of teams using Scrum who all plan together, who all talk together every day, who went through the scale daily Scrums type of questions, like Are you about to do something that's gonna block me? Are you doing anything Now it's blocking me. Am I about to do something that blocks you? You know, if they were walking through some basic questions like that, they would identify it quickly and they'd know, oh, we gotta take this offline, we gotta talk about it. But they don't have that structure. So communication, like an ineffective method of communication because the way their teams, organization, whatever it is, is designed, is kind of sabotaging them. Absolutely. Right. Uh, it, but you know, I would just say that it isn't just, that all of these teams need to follow scrum in order to do this synchronization, right? They can, they can do whatever your point, though. You need an effective communication system in place where people feel empowered to speak up and ask questions and then say, you're blocked, so we can't proceed. But this other team's already working on something else. The question is, at that point, what do you do, right? Who is the, who is the arbiter? Who's gonna say, do this, do that, instead? And, if you don't have a system in place, what's gonna happen is, the loudest voice, you've seen these people, they're gonna say, Oh, I think we need to do this. And then, when... That doesn't work out as it often doesn't. they are not in the room when, questions are asked. Well, you did this. She told me to do it. Yeah, I wanted you to consider everything. You didn't do it. It's, it's, it's basically a blame culture at that point, right? So how do you avoid that? That's one question. The other question is, what do you learn from this so that you don't repeat this again in the next print, next PI, whatever you're using? The next increment. How do you make sure you don't repeat this? Is there a system in place where you can look back and say, Oh, wow, this happened? How could we have avoided that? How can we avoid in the future? So I think overall, when you have again, I'm not gonna use the s word when you have multiple teams working together. It is important to have This discussion, this dialogue at specific points and not get hung up on a it's not a scrum event. So we shouldn't waste time on this meeting. I've seen that, too. These are what I call scrum guardians, right? These people that say it's not in the scrum guy. Yeah, well, I mean, I think The more important thing here is to have a, is to be lightweight enough to have an ad hoc. I don't even want to call it a system because it's not a system. If it's ad hoc, to have an ad hoc process to say, whenever we have. Disagreement or whenever we whenever we agree that we're out of alignment we need to go get the stakeholders bring them into the room, and and Drive through to a decision. Yeah, talk it out. Exactly. Right? Yeah, that's the arbiter role that I mentioned, right? Yeah It's not a person that's doing that. It's not a person that said do don't do this do this. It's Mutual consensus. No discussion. It's not, well, it will, I mean, like where I want to, where I want to crowbar this apart is it's not an arbiter. Because you probably have product people on each team to make a decision. Hopefully, hopefully you do. Even if you don't have product people on each team. You have team members. They can come to a conclusion. They will hear the right solution when they're talking to it. So I assume the team can make this distinction and figure it out. However... It's the facilitation of the session that someone has to drive for someone has to own to drive forward like I Will facilitate this through to conclusion to to to decision to conclusion to something, right? Yeah, and in that scenario Uh, where you have multiple teams working together. Who is that facilitator? Most scrum masters aren't really, feeling like they can, go beyond their team to say, let me step in and I'll facilitate a true facilitator. It wouldn't have an agenda going into it. I mean, that, that, that is a problem. The scrum, like the scrum master is the perfect person to do that. And most people don't have the benefit. Of having a Scrum Master to go out and do that kind of stuff. Which would be fantastic if everyone had that. I mean, in lieu of having a dedicated Scrum Master. It's gonna fall on a team member most likely, or a product person or a, engineering lead or somebody like that to do, to do that, to, to play that role basically. Yeah. Yeah. You know, but y yeah, you need an advanced facilitator to say, I obviously see there's a little bit that you guys have to decide. There's a little bit that you guys have to decide. We're all, we're all trying to be on the same page. Let me figure out all the stakeholders that need to be in the room and let me just get everybody in the room At our first opportunity to figure it out and the trade off is now we've delayed this decision You know, again, assuming product can't just pick, yeah, because if I, if I was, I will tell you now, not to like, now that we've gone all around the world, I'll tell you how I feel about this is I will pick a decision and if I made a bad decision, it'll be cheaper to make a bad decision and then correct it than the cost of delay of waiting whatever we can have to get the stakeholders because all these people are in different time zones and my team and then that team and then they got to stop work and then I got to stop work. I'm not doing all that. I'm gonna, I'm gonna make a decision and then that's what we're gonna do. So you feel empowered to basically put your neck on the, in the noose, right? And that's great because that's how it should be. A culture that penalizes that will propagate the other side of it, which is nobody's gonna make a decision because they're too afraid to be fired. I understand. Well, again, the organization that you're describing now probably does not have strong product practices and probably won't. Probably will never. Yeah, it's just not in their org culture. Yeah, it's probably not within their organizational DNA. You know, the other thing that we didn't talk about is constant crushing pressure from leadership. Everything is priority one all the time. I had a CTO one time that used to be a developer and he would constantly second guess the teams. You said, it's going to take you a whole sprint to do that. And the sprint is two weeks. He's like, I could get that done in three days. What's going to take you so long? Why is it taking so long? You can commit to both of these. You can commit 60 points of velocity when you normally could do 40. You can do 60. I believe you can do it. Come on, you can do it. Yeah. That overt pressure is very, very common from people that. You used to that role before, like you said, right? It's, it's, it's possible that when they did that, they were using different technologies or whatever else. I mean, it's just not the same thing. I've also had, leadership that when they set dates, uh, big conferences, or big sales opportunities or whatever, oh, I've got to get the latest and greatest into production by, the, the, the 25th of this month because that's when my big demo is the 25th. So of course if they'd set the 25th and they have a project manager works on them, the project manager sets the 25th. If they said the 25th and the project manager sets the 23rd and then The product owner to the project manager sets the 22nd and then all the built in buffers. Yeah, everyone builds in a buffer and then you get a ridiculous, Oh, it's got to be done in a day. It's got to be in today, by the end of today, right? Um, but, but look, all of this is bundled under, leadership. Puts the pressure on, and I feel inherent in this, in this question of, question. I feel inherent within this, this, this topic, topic of leadership, putting the question, putting the pressure on also is leadership not trusting that if they don't put pressure on, nothing's going to get done. That, that's, that's what I feel like. We don't, we podcast, guys, because I've had a lot of leadership team members. I referenced one just now, who was a developer, so they did understand, but most of the people that do this, do not have development backgrounds, they don't understand software development, so they, because they don't understand That's why they're micromanaging these deadlines. That's why they're putting the pressure on it, because they don't understand. What are you, what are you doing for two, three weeks? I say two, three weeks. Reality, two, three months of going off. Yeah. And saying I'm building something. And then, and then me, the end user, seeing nothing. Okay. That's why they're pushing back against that. That's, that's what I think. That lack of trust. And the reason that leadership is riding the team. Is because they have that lack of trust and there isn't communication. There's a lot of stuff we've already talked about on this podcast. This is a lose lose because there's really no, no trust from leadership. And then they, the teams feel pressured because of these artificial deadlines that are imposed upon them, right? So, two things will happen. One of two things will happen. Teams will just say, some team members that really kind of care about the quality of the work they put out, they'll say, it just can't be done, right? And they'll get yelled at and then they'll leave. Or, the other thing that'll happen is, people will just say, you want it done by then? I'll just get it done by then. To hell with the quality, right? I'll just check the box, right? It was done. I didn't think that was where you were going. Where I thought you were going was that developer who stays up and burns a midnight oil and works on the weekends. Yeah, works on the weekends. Works on the weekends and burns a candle at both ends. I've seen both. Both situations you just described. Actually, all three. You described three situations. The person says, I'm not doing this. And then they get put on the... quote, difficult to work with list. That's right. No team player. He's not a team player. And then the, the other two situations were the, the, the person who says, okay, I'll just throw something out. Yep. And then the last person is the person who's burning the midnight oil and saying we can do that, right? I went here way way way early in the podcast that the person who just says yes to everything Like mainly it's been developers on my team But I've seen the occasional product owner who just says yes to everything and just passes all those priority ones Through to the team the backlog managers right point. They're not really product But I will tell you like a career wise I've seen developers on the team do this way more than product people, way more. And I, I, I, I will tell you, I do not understand that. I don't either. Um, but I want to say that when I've seen that for the, for the most part, these have been offshored teams where, the, the culture is different. We, we understand that. And so they just say, yes, sir. How high, right. When they're asked to jump, and they get it done. They get. They get it done, but then it won't integrate. It can't be delivered to the customer. Yeah. But hey, that's not what you ask them to do. Yeah. You ask them to get it done. So they got it done. Playing games with done now. Yeah. Done, done, done, done, done, done, done, done. Yeah. Yeah. So I've seen that, but regardless of whether it's offshore teams or not, if you are simply checking the box, Right? And, and going along with it, you're complicit in this. You really should not be doing that. You should say... If I do this, this is what will happen. I just want to tell you that, right? Are you okay with that? Mr. Manager mismanager, right? you do it and then when it falls over, you say, well, you don't say I told you so, but you say, well, it was a known consequence or an anticipated consequence, at least. The other thing we didn't touch on, is the, very real case that when the business scales from a certain point, from a startup, up to a larger business, whatever, medium or larger business that, you will go through a period of paying down tech debt where the tech debt kind of forces itself up to priority one over and above all the features and all the other things. I mean, maybe you, maybe the tech that forces itself up to priority one in the form of Big bugs that, or, or the inability to scale your system or things that you absolutely must resolve, over time, cause you didn't deal with them, but, but, but your leadership might be. It's it's not like it's a but your leadership might have been completely aware and may have been the ones to make the decision We're not gonna deal with this now, we're not gonna upgrade I remember back in the day we had like major database upgrades, you know until the point where like especially databases that are like hosted in cloud solutions or whatever and It's like, you, you just cannot run certain versions after a certain point. And it's like, you need to upgrade because after this date, we're not going to support your database anymore. So if anything happens, you're, you don't have backups. You don't call us your service provider in the middle of the night. Like don't call you're on your own. Yeah. You should be, and then the business is like, we can't stop. To back, we can't stop to back up our database and upgrade we gotta keep going and make money like at some point You're gonna you know again Rightfully, so The executives will make decision to keep going like don't stop an upgrade stop. Just keep going. We're making money. So typically I I've seen this with startups when a company starts up and they're really starting to gain traction with their customers, they go fast. They almost go too fast. And so typically what happens is the founders are still there at that stage., they're really enjoying the fact that they're getting distraction and they want more and more and more. Right. So, the, the tech debt issue, they say, we understand that we'll get to it, but for now it's important to keep delivering more features because we can get more customers. Right. Um, so that happens for a while. And then what happens? One of two things, I've seen that happen. One is, now you've got more customers using your product. And they're really feeling the effects of the tech debt. So they complain, right? And now they're forcing you, really, to fix those things. And leadership, these are the founding fathers, they're going to say, Oh, wow. If we don't fix these things, we're not going to sell anymore because our references will be wrong and all of that. So referrals won't be there. So they say, okay, team, take a couple of sprints and fix all this stuff. That's one way it can go down. The other way is they just don't care because they're going to flip the company. They're gonna be gone. I've seen that one. Yep, I've seen that one too. I've been there in living color for that one. Listen, we know the database falls over every couple months. And you guys have to work at night to recover it or whatever. Take Monday off, just do it. I mean, think of all these yachts I could buy. I've been there. Yep. As I have, I have zero yachts to show for that zero experience. Zero, zero. But I've definitely been there. I had a yacht on paper. It was a small yacht, like a, like a paper. You had a paper yacht. On paper. On paper. I had enough money to buy a 20 foot dinghy, Well, but then that, know that bubble burst, so there I was I'm sure lamenting my dinghy. You heard it here first? Yes. Oh, and his dingy me. And my dingy. That should be a podcast. Anyway, so. Coming back, coming back to what we're saying is you gotta pay the piper at some point if you're staying with the company. If you're not, okay, right, but if you're a leader, you have reasons why you're making those decisions. Those reasons have to be grounded in some sort of strategy. We want to get more customers. Customer acquisition is top priority right now, and we're not going to worry about Those people that complain about stuff, right? Cause we're just at that point where we want to keep going that. Okay, fine. I like understand it. Teams. I like the, I like the, you labeled people calling out problems as complainers. So I like that. I like that. That's a, that I usually call them whiners, but. Complainers is a better word. That tells you something about the culture that you're in. Like, yeah, yeah, yeah. So, we went kind of all around the world on this topic. We talked for a lot longer than I expected us to. But, I've certainly been in a culture where everything is priority one. I'm sure a lot of people listening to this have also been in a culture where everything is priority one all the time. Yeah. Yeah, and I know that people have heard this phrase before where... People say, well, everything's a priority one, then nothing's a priority one. Okay, fine. Here's what I would urge our listeners and, and viewers. Think about how, from all of the priority ones, you can really try and eke out what is really priority one, instead of saying, well, nothing's a priority one, and then you're just gonna sit back. No. Figure that out, right? And how do you do that? That's when you engage everyone in a dialogue and say, why is this important than this? Okay, why is that important? More important than this. And then, how does it align with that, that, that organizational strategy versus objectives and goals? And, you might be onto something. Um, but if you've liked this podcast or enjoyed it, yeah, by all means, let us know in the comments below and, give us some topics. Like and subscribe that button. Pew, pew, pew, pew, pew, pew. I'm gonna do a Brian now. Ha, ha, ha, ha, ha, ha.