AA162 - 5 Things to Analyze Before Shuffling Your Teams

0:01

welcome to the arguing the Agile podcast where enterprise business agility coach Om Patel and me product manager Brian Orlando debate the real world challenges Agile professionals will face. We are not here to sell you anything. We are here to argue about Agile so that you don't have to. Om, I wanted to ask you a question. Have you ever been on a team that management comes in and shuffles all the team members amongst all the teams and gives you new teams and new team sizes and tells you, all right, go. Oh my God. Yes, absolutely. I have been in that situation. We're starting well. Yeah, because you know, there's this this is the illusion of doing something to fix the problem from the management perspective, shuffle teams around because you know, what we have isn't good enough to, it's not meeting performance to our standards. So shift things around, right? I don't know how tightly we're going to be stuck to the format of arguing agile on this one, because who makes these calls to shuffle people, usually it's either the quote, the Resource managers. That's right. Sometimes it's the PMO. If the PMO has budget for all this, they'll shuffle people or whatever. I feel the root under all that, what we're about to talk about behind the root of all this is somebody who holds the purse strings. Somebody who has the budget feels like they're not getting what they're paying for. Feels like that. That's, yeah. And those people, that's an emotional, by the way, not, not a, not a logical on numbers. We're not seeing on paper, on my spreadsheet. That's a, I feel we're not, it's a gut feel thing. And sometimes that is fed also to those folks by other people. It's like, we feel like these teams are slacking again. There's, there's nothing underlying that in terms of data, but these teams are slacking and they can maybe this one or two, these, we have two people that are really good and we have four people that are meh take these two people and we can put one of them over there and one of them over there and they can bring everybody up. And these other ones, well, we'll see where they fit in. If they don't, well, we can just dispense with it. Yeah. What about the case where it is legitimate, where management is seeing problems and they're saying, look, these teams are just not working the way the way they're organized or whatever. I guess we'll get into that on this podcast. I guess we will yeah, we will, there's no spoilers here, but by the time we get into that, we'll figure out like, how do they know that? Yeah, you're right. Yeah, I think that would be helpful to people listening is that how do they know that like what are the indicators of each? I want to start with what Anybody listening to this podcast is going to point out that says, Hey, anytime you change a team in any way, shape or form, whether it's management doing it or whether it's the, the, the team asking for the change or whatever. And you've decided to add somebody or take someone away from the team for whatever, whatever the reasons are, you're disrupting the current team dynamic. Basically that you're going. Tuckman's model. Is that what we say? You're going back to forming all the, you're taking the team out of whatever phase they're in and they're going all the way back to forming every time. So this is something that's very, very misunderstood, right? People say, well, what do you mean? It's only one little change. Teams have been around a long time. We're only changing one person. What they don't understand is. And you hit that right there, Tuckman's model, they go back, no matter where they're at, they go back to forming because you're looking at the number of communication channels, vectors, dynamics, whatever you want to call it with one team member versus six others, right? So you can do the math, as I always like to say when there's numbers involved, because I don't want to do the math. People do fall, the team falls back to forming at every stage when there's even a single change. Meaning, if you have a new person added to the team, or you have one person removed, or replaced, like for like, still, the team goes back to forming, because that's the human dynamic principles of how we work together as human beings. And, and this isn't very well understood by people that are making these decisions, because they're making them on other, based on other factors, right? Typically, on hearsay. Typically on very seldom really on performance, I would say, because by the time they look at performance, that isn't really one person's thing. It's not one developer, one tester, one you UX anybody, really one person's one person. So their contribution isn't really what's causing them, I mean, there are exceptions, of course, but isn't causing them to be the outcast here the target person that gets changed out. Let's stay on disrupting the team's dynamic for a minute. This little topic, subtopic in the podcast that we're exploring. It's really, Fairly complicated because depending on you could be replacing a very like the cornerstone of the team like a very big personality That's been there a long time has a lot of knowledge or a very stable member of your team that you know They're they're the person everyone goes back to when they need help or whatever and you when you replace that person now It's not really knowledge that you're losing. It's that, that, that centered, that very centered person who is like a very steady part of the team. And now the team has to figure out how to work without this, that, that steadying factor anymore. Like it could be something like that, that's very difficult to explain on a financial sheet on the bottom line of Oh, your, your team has six people, but this other team has four people. So we need one of your people to balance out the run rates of all the teams. Well. Who do you take like, okay, well, I'm just going to pick that person cause everyone's kind of got the same skills. So I'm just picking that person. But you pick the person who is the steadying factor I think of a team where you have one person that's very, very, very reasonable and you have many other people that are very, very opinionated on the team and you always have this one person that's very moderate and again, they're a, they're a balancing factor between extremes on the team. And now when you remove that, now the team has to learn how to de conflict. That is not easy to do. So first of all, let me go back to the point you made earlier. This, this is not a topic that is either discussed widely, understood widely, or even enacted upon. Right? So people look at that as a role and say, well, we're going to replace this developer because we got this other one. And you know, per hour, they're cheaper, but they have the same skillset. Yeah, right. And they've been in the industry longer, but the person that is the outgoing person is one that is always available to people to ask questions. They're a team player. They're always available and they're always making themselves you know they're not the center of attention. That's all I'm saying. What I'm saying is they are always willing to lend a hand, helping bring others up. Right. And the replacement has the same skill sets on paper. Maybe even cheaper, which is the allure. But this one aspect is missing. People can't go to that person anymore, right? So forget the fact that they go back to forming, even after they come out of there, they are still missing that element where they can rely on somebody who has a reasoned Voice and they're not afraid to say things, right? So how do you replace that? You don't, you don't, I think the team suffers as a result. I think whoever's making this call to do the replacing actually having gone through this experience or replacing people like that on the team is, Oh, we'll just have the dev lead who's not really part of the team. They're just like, they're like a manager level, right? We'll have them step in for a time or the dedicate them 25 percent of the time to your team. And they, they can work you through this transition or whatever. I mean, how can you, how are you gonna replace a dedicated team member with a part timer and expect them to actually make it? First of all, how's it, how's a part timer on the team going to make any difference? First of all, yeah, their, their loyalties are divided. So even beyond that, so I can share an anecdote here. I just thought about something that actually happened with one of my teams. There was a fairly junior developer. Not necessarily somebody straight out of college, a couple of years of experience, but he had the demeanor where he can talk to customers in non technical terms. We have senior people on the team, fantastic developers, right? Seasoned. They cannot talk in non technical terms to customers. So this guy, they always push this guy in front, right? While the customer's calling, you explain to them, right? And he did very, very well. This is the inevitable that happened and he got shuffled out. They let go of him, but just shuffled him outside of the team to some other team. And now they put somebody else in who had the same, roughly the same amount of experience in terms of, technical prowess capability, whatever. But they didn't have the ability to explain to customers what they're talking about in non technical terms. And it came to a head really, really quickly, really quickly where customers said, we have no idea what's going on. Yeah. Didn't so and so talk to you? You know, they just. No, they can't do it. So whoever makes the decision needs to take that into account. This is not stuff that, that finds its way on any spreadsheet. Right. I mean, you have to know people. That's what it boils down to before making decisions. I mean, you like the, at the point where I want to, I want to ask you, I want to jump into the things that find their way on the spreadsheets or not. The size of the spreadsheet that you would have the matrix of the spreadsheet by people and skills that you would need to have both technical skills, interpersonal skills. Yes. Soft skills and other categories. There are several categories. Yeah. Business skills, domain skills, the amount of categories and the amount of things on your spreadsheet that you would have to quote, manage as a quote, resource manager. Sorry. So I should say that not with, with less disdain, but I can like the Sorry, is there a. Not a way to shortcut the forming, storming, norming. Can I make shh First of all, is there a way to, to analyze my team and know what stage I'm in? And also, is there a way to limit the amount of time that it takes to go back through those phases? Maybe I can only move one person every so often, or maybe there's some checks I can do. You know, maybe it's not a time limit thing. Maybe it's just like, I have to see some things happening between the team members is there I don't know, a playbook or a checklist or something that could help me, me as a manager, me as an outsider to the team. Even it's like product sometimes. Sometimes a product manager feels like an outsider.'cause like all the developers are doing development tasks and I kind of have to sit that one out. You know how can I know that they're really jelling. Yeah. There's a lot on the periphery there. Deliver managers come to mind. Right? Yeah. Resource managers. PMO folks, whatever, but you have two questions embedded in there, right? First of all, how is there a way to know what impact a person is making? First so if you're not in the team, you don't really know, right? It's hard. So how, how do you if you're on the periphery, how do you know what somebody's worth is? Not technically, but as a team member, as a value player, right? The only way to do that is. Don't take point measurements, right? Ask people, but then observe, right? Make sure you ask the right people, not within the team necessarily. Also ask teams that are working with those teams, ask the customers that these teams are delivering to and see, don't fish for it though. Just, just ask, how's the team doing? Anybody stand out? Anybody not pulling their weight as much as they should. Open ended questions like that without saying is Fred or Mary that don't do that. That's only one side of it, right? And then the other side of it, which I almost forgot, but you know, how do you know if if you're at the forming, norming, storming, et cetera? How do you know that? That's a great question because a lot of people struggle with this, right? So the only way you know that is by be, again, you have to be in the team. So only team members know this. Outsiders can only see glimpses or. Time based things, right? Discrete values. If you're in the team, you can see who is regularly contributing, who is bringing everybody back together to work as a cohesive unit, as opposed to working in a silo, you have some people that just say very little usually, but when they do say something, it's because they want their way. And if they don't get their way, they're going to take their binky and go back to the corner. I wonder if there's. I wonder if there is a doctoral dissertation in this. I think there is honestly, I think there is a, what you just outlined is we probably could sit down on another podcast, not this one, and just talk about Tuckman's model. Cause I think that Duckman research is not, it's not really that I was going to say, it's not that deep. That's not true. It's not so broad that we cannot consume all of it in a podcast. You know, we can research it ahead of time, pull out the relevant pieces and talk about and dissect it in a podcast, at least at a high level, right. Look through the research, that kind of stuff. And then. Try to figure out if we were to give us a team a survey of like 40 questions for example, could we ascertain what stage of the model that that team is in? What a fantastic topic for a podcast. I agree with that. First of all, right? I also think that well, you're right been around a long, long time. It's been around since the sixties, largely untouched until very recently when they added a stage on the end. Well, actually they didn't even had a stage. They just renamed it. Yeah. Right. To mourning from a journey. I, yeah, but you know, how many people have been on teams that really mourn? If you haven't, you know what your team wasn't as. Well, gelled as you thought it was, it was a journey because they're like, well, we're done with this work. We're gonna go work with some other team. It's just work. Yeah, right as opposed to I really love working with this team I'm gonna miss my teammates, right? That's where the that's where the morning comes in And then when you go to another team and the moment somebody says gee It'd be nice if we had X Y and you're the first person to go I work with these people One of these people would be great, right? If you're, if you're talking things like that, you might be mourning. Otherwise, you've adjourned and you've moved on. So I agree with you. I think we should do a podcast on this topic because this is very valuable. Tuckman didn't necessarily do this for software teams. Yeah. But it applies very, very well. it's basically with anybody who is a Quote unquote, a knowledge worker, right? So yeah, let's, let's, I've noted that down. We'll do a podcast. Yeah, to move us to the next category so assuming that management actually has a plan and they have a assumption. Yeah, they have, they have a spreadsheet. Again, we're talking about management here. Well because again, if you're a company of 10 people, Like the, the, the, the rebalancing of the teams here, here's how it works. We take on so much work that we're all busy and we're all doing stuff outside of our normal job role because we're all team players or whatever. And then like we just can't take it anymore. And then we hire another person in to take off those extra responsibilities and that becomes their job role. And then we grow and divide and grow and divide and grow and divide. Until now we have a bunch of extra people on a bunch of extra teams that are doing a bunch of extra stuff that that's just natural. That's the startup, right? That's startup life. Exactly. So when, when you have enough functions where you need to split off all those functions onto a new team, you, you basically, you basically are just doing across your organization or your program. If it's if you, if you're in a big company, you have a program, you're doing skill or knowledge. Oh, slash experience, right? Rebalancing. You're saying, well, I got this team of junior devs. They really should have a senior engineer sitting over them. Or I got this team of I got this program of four teams, five teams, four or five teams, and they have no architect, they have nobody with architect experience. On any of the teams, I need to take an architect from another program and I need to put it on that team to, to basically balance I, I don't know what your ratios are in Q again, my early in my career, I was in QA. Anybody that works in QA knows at a regular basis, the company will look at the number of QA people. To the number of developers and say do we have the right ratios and what they're really saying is Why do we want to pay for all these qa people when we can buy more developers? That's what they're really saying. It's not the right discussion but but the point of this category is They might be taking people on or off of your team because they're generally rebalancing skills Or knowledge about products or services or whatever Or experience levels. They're trying to balance them among all the teams. Well, absolutely. Yes. And right. So I think there's, again, there's a lot that that's under there, that same topic skills rebalancing. When companies make decisions to rebalance skills, they're doing it because of an input. There's an impetus, right? To do that. If everything's working well, then let the status quo prevail. So something happens and then they have to look at the team and go, wow, we need to shuffle things. Right. Why? Because we've heard that our quality's bad and maybe QA is not pulling their way, or, or we're not developing things and, and in, in a timely manner and giving them to the QA people that are just sitting there twiddling their thumbs. Sure. Most of the sprint or whatever it is, there's a lot of antipas there. But that notwithstanding, there is some kind of a stimulus right. That causes people to make this change. Yeah. So the first thing to do is figure out is that a valid stimulus? Because it could be that there's a, there's a plethora of reasons why people that are in this role who can actually shuffle teams here, these things, it could be hearsay, right? It could be assumptions. It could be one offs like this one sprint QA missed a couple of things. All right. But. You know, it's a point in time kind of thing. There's a lot of different variables here. So figure out, are you looking at a point in time? Are you looking at discrete things or are you looking at a trend? You said exactly what I was thinking is management is observing management is observing a trend that maybe one particular team does not see, but they are seeing it. Across all teams. Now, now we return to what we said in the first, I don't know, two, two, three minutes of the podcast. Is it a trend they are seeing? Logically have evidence quantitatively observing or Is it qualitative just what they're hearing, making an emotional response to Oh, these teams always promise that they're going to deliver things in one sprint and they always take six sprints or whatever. And they just feel like anytime there's an important feature, the teams are dropping the ball, right? Like when you dig in, the problem is that the knee jerk response to that becomes reshuffling the teams. Oh, we need to get more senior people over here because Then I can have more control because my, Oh, the, the other thing that I've seen happen is they take their star. Their star product person or their star manager or their star architect. And they put them on the trouble teams to quote, whip them into shape or, or, or so they have, they have somebody who's there, quote, eyes and ears on that team. I haven't said that in a long time on the podcast. The point is that the leadership is trying to put someone onto the team that they trust. To figure out before they do something more drastic more dramatic. And usually that again, only in my experience, but in my experience, that usually is, that's doesn't help at all. I think when, when you said the first thing you said about hearsay and all of that, It's not like, okay, when you first hear about a team missing a target or whatever that may look like, right? Bad quality whatever it is, don't make a knee jerk reaction to use your phrase, but be data driven, figure out what is really underlying that. Right? Because they missed it doesn't mean you should just kill that team or people or person or the messenger or the messenger or the messenger figure out what did they have a dependency and the dependent team not deliver. So why was that? So that doesn't absolve the team in question, but it also doesn't make them appear directly in your crosshairs. You gotta figure this out. Maybe the customer, a customer, had reason to call somebody out and said, Well, this person. You know, didn't really help us. Right. Why was that? Right. So dig deeper. Is it, don't go on the face value of whatever you hear first. Well, in addition to, to giving the team more skills or giving the team that appropriate level of experience that maybe they're, they may, maybe you believe that they're lacking the other reason that management might make changes is because they, they, maybe they're trying to empower teams by making them more cross functional. So the, which kind of goes it kind of goes under this category as more skills, more knowledge, that kind of stuff. Like they, they want the team to have all the skills and all the knowledge that they need to perform the tasks that they're being given to actually deliver what they're being asked to deliver. I've also seen this, exactly what I just explained. I've seen this work in the reverse. Where you know, managers are incented of it on how many employees that they have under them. And architects are incented on how many teams that they have and that kind of stuff. And I, I've seen cross functionality destroyed by the same impulse. As, as what the drive to make teams cross functional. I've seen the exact opposite of that in play as well. Ditto. Absolutely. That's, that's a good call out. I think if you are in a company where you've been for a while, you should get a feel for that, right? I'm not talking about evaluations or anything. How are people perceived, right? Teams, as a whole. So when a customer has something bad to say look at the message. Are they blaming a team? Are they saying this product is bad? Are they saying the experience is bad? Or a mix of the above. So if you're new into a team, or fairly recent, and you don't have Let's say you don't have the luxury to figure all out. The best thing you can do is talk to your support people. People that are taking calls from paying customers that are experiencing the pains, right? And figure out, are they, are they calling out individuals or teams or the product or the quality whatever it is. But again, don't just make snap decisions on that as face value. Note that down, and then talk Deeper you could do a lot worse than do the five wise, but that's not the only thing you can do, right? It's a lot of different techniques. Maybe what really happened is nobody really understood the requirement well enough But they had an idea of that, right? So the we think the customer wants this therefore it must be we deliver to that and the customer says Yeah. Not quite right. Yeah. Right. So whose fault is it? It's not the development teams. It's not the support team. It's not the deployment team. It may actually not even be the team that formulates these requirements. It may not be a product team it may be that something false was promised right by your sales team. I don't know. I'm just saying, well, the figure that out the other problem that you're outlining here is working in a feature factory I will admit that it might just be the way that I listened for your example but in your, in your example, I was asking the whole time, where are the product people? How come they're not absorbing this? Like the customers are complaining. And what I've seen in feature factories is the customers are complaining the development teams. And the product owners on those development teams, they don't talk to customers, so they would never know if the customers are complaining. So the, the, the deafening like tone at which the customers are complaining, goes straight to leadership management, whatever people with budgets, it doesn't go to the developers of development team. And now. The development team is surprised that leadership is shuffling the teams and making changes based on what the customers are complaining about. Well, yeah, I agree. I look in some organizations, what happens is sales is the front line, right? So they, they are the first level of interaction with the customers and they come back and they interpret what they think they heard. It might not be what they heard. And then they say these are the things that are needed. And the product people are basically taking that as input, right? And they're going now to town and saying, well, this is what we need. Because us sales people have done the work, right? Somebody needs to validate that. So, in an ideal world, at that level, what should happen, in my opinion at least, for what it's worth, is listen to the product people, the sales people rather, and the product people will just say. You say they want this, let me go validate that where's the evidence for that? Go get that, and then you have a better chance of narrowing that cone of uncertainty. Otherwise, you're just basically throwing dice on the the craps. Well, Let's forget about product people for a second, for a second. There we go. Good. Goodbye. Product people like and let's talk about the, what management thinks that they're getting out of this reshuffling. And I think the main thing. That they think they're getting when they add the main reason for them to use this, this, this sledgehammer of a, of a solution is because they think that they're introducing fresh perspectives to the team. They're, they're I mean, that's the same reason why they would get their star architect or star developer. Or star crony. I don't, I like, I don't, sometimes they add people that have, they had no idea about how to, yeah, right. Sometimes they're just getting their friend because they trust that they can talk to that person and that they won't lie to them or whatever. Sometimes they just go get their buddy. You know, I mean, if you've ever worked with a I was gonna say CPO, I was gonna say chief product officer. Sorry, that's not fair. I was gonna if you ever work with like an executive that obviously has no clue how development is done, but they got hired in and now they're your boss and you're like, well, how did this, I don't understand how this person, well, it's because management trusts them and they don't trust you. That's which is, Very hard to hear for a lot of people. Like I, I expect I expect the downvotes to roll in by the ones, by the ones. I think you're right. People have people that they bring in because they trust them. Right. But by doing that, they're also saying something. They're saying we don't trust anybody else. Yeah, right. They're saying that So so that that is true. However You started out by asking what are they really getting by reshuffling the teams? Oh, they're getting is a sense of Hope that change will be good for that. That's It's so funny that every so everything we've gone back to in this podcast That seems to be a negative scenario has been an emotional like they what what do they get out of it? They get the feeling like they have done something when in actuality like you like they haven't done anything yet They've done something that maybe is actually harming the situation, but they don't, regardless of whether it's beneficial or not they feel like shuffling team members is going to give a fresh perspective to the team and hopefully make the team better see things their way because again, they're not good at they're not good at organizational design, communication methods in such a way where their goals are clearly expressed to the teams. Honestly, it's like the, where I've pivoted now on the podcast, I'm specifically talking about a feeling of leadership that is being inflicted on the teams. They don't know exactly how to say what they need. So they're shuffling the team members to try to make up for their lack of communication skill. Yeah, yeah, look, yes and, right? So one thing that happens as a result of this is this covert, overt, overt pressure. Sometimes covert. Too much pressure. Too much pressure. So sometimes what happens is no, not sometimes, often. What happens is when there's Change? Team members are alert okay, there's change. Right? Fred got rolled out. Mary got rolled out. Whatever. And now we have John and, and, and Jane. So, That is, I think, a deliberate ploy, whether intentional or not, mostly intentional, but on our management's part by saying, well, we're going to shuffle things up, we're going to stir things up, right? We don't want the status quo. And that puts everybody on their toes to say, Hey, look, we better watch out because we could be next. It puts you on notice. It puts you on notice. And it is a, it is a terrible way to proceed. If you're looking for the team to gel. And go on that model to the next level on the graph or whatever it is It's a terrible way, but people that are making these decisions a have never heard of tuckman and b They want to basically Reassure their superiors that they're doing something right. That's all it is. I sound like I'm being overly critical on, on these executives or these directors or whatever their position is. I am but also I mean, they should read a book or something. No, I, like so I have I have a couple steps. I have some suggestions who knew that Brian would have suggestions and identifying the root causes of some of the problems and actually just identify it, not trying to solve them, just trying to identify the root cause of before you go into the shuffling mode. Okay. And I have a few bullet points written down. I'm just going to read them out in order and see if, I'll stop afterwards to get your take. So, so if you really want to get a fresh perspective and you're seriously considering it and you're seriously considering shuffling team members in order to get that fresh perspective, for the teams involved, I want you to analyze their processes, analyze their current communication channels, analyze the leadership styles involved, analyze the The workload distribution and analyze the interpersonal team dynamics in play. So that could be in between the teams as they interact with each other. And also that could be in between leadership and the teams, both to any of those. I could say both. And third, how the teams interact with other teams. Other teams outside of their program or whatever. Okay. Well adjacent Intra team, okay. Yeah, yeah. Or inter, inter team? Intra. Intra, okay. Inter? No, intra, intra, across teams. Well, I'm confused thanks for listening to the podcast. If you're also confused, like and subscribe. We're all in the same boat and it's sinking fast. Oh, yeah, but the hole's on your side. I'm going in circles. So uh, like analyze the processes, processes between leadership and the teams and between the teams and the teams and in between an individual team. Yes. Okay. Analyze the calm channels, both inside of a team, between teams and between leadership and the teams. Analyze the leadership styles, both in and of team members. In between all the teams in the program and leadership to the teams, leadership styles, right? Cause that one right there, like that can sink you right there. The leadership style of your leaders who direct teams is strictly directive PMO project management. You're starting off failing let's just say, you're starting over the hole in your canoe. Yeah. No paddles. Workload distribution. Do you have OKRs? Do the teams get to choose how they're set? Do the teams get fed work? Do the team members on each team get assigned work? Do teams get assigned things? Interpersonal team dynamics. You know, how do teams interact with one another? What are your Do the teams even have visibility to the customer? Absolutely. The, the whole , team topologies podcast that we did is at play here. Sure. The whole do you talk to customers is that available to you and who on your team talks to customers and how often, and you know, who's at your sprint reviews you know, that, that kind of stuff. So I think between those five bullet points right there, those five indicators right there, you can make a lot of ground if you're a leadership and you, and you really, really want to know now, if you're a leadership and you're just trying to. Look like you're doing something and you just want to shuffle and make yourself look good or, put your best guy on the team and hope that your team doesn't at that point your management for me, I mean, that's a lot of, a lot of people like that they feel like that's the end of their ability is, well, I shuffled the team and I told them what I wanted. I don't understand why they're Well, you've not done the other half of leadership, which is really get in there, your part, right? So if your management you haven't done your part in the reason why you're doing all these things is because you're reacting and at the end of it, you really need to look in the mirror for a long time. But if you are leadership and you really care for the success of the organization, the teams as a whole and ergo yourself, right? One of the things you'd be doing is figuring out the impact of making a, even a small, minute change. Look at what it means to the whole, not just the individual. From a nuanced perspective, I'm going to move this person out because they're not a team player. It's like, look at the impact of that across the whole organization, right? Not just your own view, like that's probably very narrow. Look at that and say is this the right thing to do? And then weigh that up. If you're not sure, don't do it, but ask other people. You know, look, what do you think I should be doing here? Right? Be vulnerable and ask. And if three or four people say, hey, you know. Maybe it's this one person. They have something, right? And you can, you can probably go It's still not data driven at that point which I would love to, right? You're not data driven, still. Figure that out. Talk to the person. Maybe there's something going on in their life. Remember, you're not looking at the data. Resources But you're looking at knowledge workers you're looking at human beings Maybe there's something going on that specific time in their life that causes them not to give their hundred percent Right but if they've been giving their hundred percent they're not giving 20 right now Even though they they have other You know, circumstances right in their lives. So understand that, understand it because they are worth keeping, right? If you can help them in some way, that's what you should be doing as a leader, as a manager, all you're doing is looking at percentages and utilization on a spreadsheet and you're making these moves. Sorry. Can't end well. I mean, I would imagine that either a lot of people's experience is either number one. In some sort of program that is failing with their customers. So the management is just moving people around because they really are clueless. I mean, these, these are difficult, even for, even for some excellent agile coaches that I've worked with and I've worked with some excellent ones. These steps are difficult to analyze all the processes for every team, doing it for one team. Is a challenge sure and it's going to take you a while. Okay, but okay doing it for a program Interconnected teams that each have their own team problems Oh, okay. Some teams are, some teams are between three and nine people or whatever. But we don't call the specific number out anymore. Apparently in the scrum guide, whatever. Some, some of these are two pizza teams. Some of these teams are 20 plus people. I just finished the predictable success. Les McKeown's predictable success and impredictable success. Yeah. He says what you should do is you should go around and ask people to write you what the org chart looks like. And then you should say, no, no, no, no. Now write me how the orchard actually works now, how do I actually make decisions? If you could write that org chart, like to figure out communication channels and leadership styles and stuff like that, you'd be way ahead. But very few people are going to invest that amount of time into this, like pseudo theoretical organizational design exercise. The way that we treat organizational design is like, there are a few people that really study it and conduct studies across organizations. But the majority of people kind of stumble through it and figure it out. Imagine if we treated other things that way where the majority, there's really not formal education. There are experts out there, but quite honestly, we don't really seek them out to help us. Right. We all kind of just stumble through it and, and, and through our own arrogance, assume that we are doing it right. Like what other things, like imagine a software development is like that. Pretend for a second that literally everyone in your organization Had to write code in order to do their jobs. Good luck. Okay. But they couldn't access any actual software engineers to figure it out. And I was going to say they couldn't check stack overflow. I don't know. Maybe that's a little too extreme, but that would be the point is like now everyone's saying like, Oh, well, I'm a, I'm a great software engineer. I mean, are you? And then, and then based on how good I feel about my skills, I'm now gonna tell you how you should be a software engineer. I think that's where I'm going with all this have you walked through all these categories and if you have walked through all these categories like do you really understand the data that you're looking at and. Do you have the ability to gather qualitative and quantitative metrics? Put the two together in a way where you really understand what you're looking at, and then when you feel like you understand what you're looking at, do you have somebody who really understands? To check with to see if you're right about what you're looking at vulnerable to ask for help Yeah, right And at the end of the day we've now we've now piled on so many requirements that a lot of people are saying like yeah I'm out like i'm yep. I get it done. I get it. Look if this was easy anybody could do sure sure Oh my goodness, where do we go from here? Well, I mean great. I mean, I mean this points you made, you know people can Rewind through this podcast in slow motion and write those down because listen every one of those is critical Yeah, I feel, yeah well, there's two other points that are both, I feel legitimate for shuffling people on teams. Number one is career growth and career development. You've got to move people because they, I mean, people can only stay in one place for so long until they they kind of stall in their career growth, career development. So that's one thing as long as you're actually talking to these individuals involved and make sure that that's the direction they want to go in fine. Sure. But if you're just saying, well. So Fred's been in this role too long, or Mary's been in this role too long and I think they should move. That's different. I think, I think what you just pointed out is critical as well because I think of one of my development teams right now, we're really a figure out and do cool new things team. And we're constantly doing cool new things with different technologies. I've been on other teams that are maintaining products that are in sunset mode or maintain mode where it's that it's the same, exactly. It's this, it's the same kind of thing. Day in, day out, answering support tickets, doing bug fixes and enhancements, and really no. Big changes, same code base maybe an older code base. It doesn't really get updates or whatever. Like I I've been there before. if you're looking for the type of people that needs stability and are okay with that, and you're having one on one conversations and those people are telling you I don't really have a lot of like high flying career achievements. I'm happy with stability. You know what I mean? Until this program sunsets, if, if, if those are the conversations you're having as their hiring manager in the organization I mean, I guess that's fine it is, but from the York standpoint, there's something a little different, so the people that are in the support teams they may be content to be there because they like doing support work. Right. Well, from the org standpoint, what I was going to say is, there's value. And these people interacting with customers and learning about some of the pain points of the existing solution, feeding that right back into the funnel at the beginning, right? Into the intake and say, these are things that aren't working well for our customers. So you're not just supporting because you get paid for a support contract for a year you're actually trying to improve your product over time, right? And. The delicate balance there is these people need to feel empowered enough to say Let's solicit from our customers. What are those pain points knowing that if those pain points are Taken care of quote unquote. Then there'll be less to support and they may be jeopardizing their own positions That's a delicate balance. Yeah, So the org needs to look at that and say there's some skill sets here that play these people are analysts. They're analyzing All these things, the experience of the customer. Well when there's a time when there's not too many calls coming in, don't be thinking you don't need these support people. You can reuse them somewhere else, right? If you're astute to try and substitute that for talent, you buy in. Good luck. It's not easy to do. the other reason that this kind of shuffling might happen is because the manager or the, the person with the budget or leads or somebody is trying to resolve a conflict, a conflict between people. So the concept might be, well, there's a troublemaker. So we'll just put them out of the pasture by putting them into support. That kind of thing. Right. I'm, I'm guessing, but that's, that's not a good thing. Where I've seen this is we have someone that we think doesn't play well with others and we just move them to another team to see if they gel better with those people before we try to before we get rid of them from the organization. I've seen that. Right right. Yeah, I have too. It's, it's unfortunate because all you're really doing is buying time for yourself. Right. Right? And, and it's at the expense of the other person. Right. Right. So. So if you haven't talked to them and you really haven't understood what's at the, at the real heart of the issue, you're not doing your job, right? You're not, you're taking the easy way out by saying, well, I did, I did this, I did this, I did this, and then it still didn't work out. So we got rid of them. Right. So to your superiors, it looks like, well, you're taking action. You're being proactive, right? Yeah. Right. Well, You're very close to what I've also seen is making it somebody else's problem as well. Because this whole thing gets even murkier when you talk about moving people between program teams. So there's like separate programs and like a large, a very large organization. Now everyone is just taking this low performer and nobody wants to make the final call to get rid of them. The funny story about this is I see this the most in management, they take a manager who is subpar and they keep moving them around within the very large organization and all they have is really is a history of failure. Ah, yes. Agreed. And To your point these are all, of course, FTEs, right? You're, you're right. Usually when I've seen this, it's, it's that kind of situation where these people are permanent employees somehow. And essentially there are ways to get rid of them. It's just, nobody wants to spend that political capital because their culture is way too guarded to spend political capital on something you can just make go away. That's exactly right. Yeah. The status quo, that sounds terrifying. It sure is. It's terrifying, but you know what folks we're going to take this and spin it into a different podcast and talk about these different ways, how companies Maintain the status quo and those that don't and you know, compare and contrast those two. I think that's a good topic for a podcast also. Yeah, we may have a guess for that. We may not You'll have to just tune in and find out but if there's other podcasts that you would like to hear Let us know in the comments below and like and subscribe ring that bell