 Okay, I'm gonna take advantage of the 30 seconds or so and start a little bit early, only cause I've got about an hour it's worth the material to fit into 40 minutes. So, see how we do here. So the title of today's talk is Tuckman Was Wrong. Just real quick, if you don't know me, I'm Doc Norton. I am with a consultancy called Anbole and I am Doc on Dev everywhere. All the things whack Doc on Dev. Twitter, Facebook, LinkedIn, all of them. So if you wanna follow me or tweet about me or whatever, that's how to find me. All right, so Tuckman Was Wrong. Let's start off, this talk actually came out of some research that I was doing a couple of years ago on a completely different topic. And I stumbled across this information, started digging more into it and a talk emerged. But let's start off talking about stable teams. So, stable teams have been, for a long time, a given and agile. We have to have stable teams. All right, it's one of the things we need to do. We gotta get the team set up and make sure that that team stays together so they can get to a high-performing state. And there's all kinds of mantras around this. We wanna bring the work to the team, not the team to the work, et cetera, et cetera. And it's pretty much everywhere you look. Here is a quote taken out of Scrum Plop, stable teams pattern, where we talk about keeping the team stable and avoid shuffling people between teams. And if I ask people, why stable teams? Why do we need to have them? The number one answer that I get in some form or another is because Tuckmans. Now, how many of you are familiar with Tuckmans' theory on team development? So, Tuckmans' theory, we'll do it quick. Sounds like several folks are familiar with it. There are various forms of this. I'm gonna basically talk about kind of the original form, if you will. But in Tuckmans' theory, all teams go through a set of stages. You start in one state and you move through a series of stages. And those stages are fundamentally forming, storming, norming and performing. Now, how many more of you realize you're familiar with Tuckmans' stages? Yeah, okay. Now, according to the theory, all teams start off in forming. In forming, we're pretty polite with each other. Everyone's kind of figuring out where everybody else is coming from. We're not really showing necessarily our true selves. At least some of us aren't, depending on personalities. And everyone's kind of trying to get along. And then eventually what happens is there's little things that just agitate you. You can't stand the fact that all of her commit messages are past tense and not active tense. And how dare she? And he keeps putting curly brackets on the wrong line. And this person thinks that we're supposed to look at the board during standup instead of talk about the work that we were doing or whatever it is, right? There's things that these people are doing that just kind of doesn't seem right. And we start to raise these issues. And the next thing you know, we're in this storming stage. And the storming stage now is where we're not really getting along. Our performance goes down. And eventually, hopefully, we move into a norming stage where we recognize that this behavior is not particularly healthy. What we should probably do is figure out how we want to work together as a team. We come up with our norms. We begin to acclimate to those norms. And then we move into a performing stage. According to Tuckman, all teams move through these stages in this exact sequence. If something happens, you add someone to the team, you will likely revert. If you are in norming and someone new comes in, you will revert to storming. Well, performance standpoint, Tuckman's looks something like this. This is the typical graph that we might see. Performance over time, as the teams kind of progressed through these various stages. Looks beautiful. Very simple, easy to understand. Now, you might, if you have studied Tuckman's over the long term, you might be familiar with some other stages that either been suggested or added, adjoining, transforming, mourning, reforming. I recently heard of another suggested stage of stagnating. But let's just stick with the original phases for this talk. And storming ends up being the number one reason that we want to keep teams stable. When you adjust the composition of the team, they regress back into storming. Their performance goes down. And they've got to go back through norming and get back up to high performing. And that's a real problem for us, right? So I've got a question for you. How many of you have actually experienced this on a team that you've joined? Yeah, almost everyone has experienced this on a team that they've joined. And almost everyone says, yep, that's exactly how it went. We went exactly through those stages and then we became a high performing team. And then when you start to dig in and you start to really look at it, it turns out that many, many more of us have slightly different experiences. Maybe if we hadn't been told about the model and then said, hmm, yeah, my experience matches that model, we might have told different story if asked. And sometimes instead of looking like this, it looks something like this where we spend an awful lot of time in storming. And for some teams, it feels more like this where we never get out of it. Some teams experience something more along these lines. They seem to keep going back into storming over and over and over again, right? Which is actually realistically on a timeline looks more like this. And sometimes it's a little questionable as to whether or not we actually ever hit performing. So when you actually talk with folks, while they say yes, I've had this experience and then you start asking more detailed questions, it turns out they're like, well, I've had a similar experience. I've had something that was kind of like that, not exactly like that, but it was close enough. So I was talking about having done research and this talk came out of that. While I was doing this research, one of the things that I found was some interesting stuff on Tuckman's and the science afterwards. And it turns out that there has been study after study after study. And none of them have really been able to definitively produce results that match with Tuckman's model. There's always something wrong. Now it's a theory, it's a model, that's okay. But then in 2007, the US government published a study that they had done across all of the armed forces over a significant number of years with many, many people, hundreds of thousands of people, tens of thousands of teams. And what they did was they took the behaviors associated with forming and storming and norming and performing and they evaluated teams and when did they exhibit these behaviors and what did that actually look like on a graph? And this is Tuckman's stages for real. This is how it actually happens. It turns out that teams don't go through all of the stages necessarily. Some teams entirely skip early stages or mid-staging. Some teams never regress. Some teams go through the stages in order you wouldn't expect. The stages, the behaviors of the stages cross over each other. So you may be showing forming behaviors long after you've begun norming and even long after you've begun performing. And here's the most significant one for me. Storming right here is the dark brown. Look at storming on this graph. It's happening all of the time. In fact, in teams that show performing behavior, storming happens more, not less. It turns out that a high-performing team, a truly healthy high-performing team is constantly having good, healthy, rich debate. They're constantly looking at is what we're doing the right thing or not and they're having some really hard discussions about that. That's actually an element of performance. High-performing teams are storming. It's not a thing that we can avoid. We don't regress into storming. It's happening all of the time. So if this is the case, then the problem that we've been trying to solve all along, making sure that teams stay stable so that they don't go through these cycles so that they don't regress into storming, must not be valid. So if the problem wasn't because Tuckmans, even though that's our most common answer, what was it? Because stable teams did make things better. How many of you have experienced this? You've been in an organization where people get moved around all the time, teams get stabilized and things actually do get better. So if it wasn't Tuckmans, if that wasn't the problem, what was it? And I think what it was, it is in many organizations, is because of resources. It's because we treat humans as fungible assets, as cogs that can be inserted into different types of work. When we move them into stable teams, some of these elements go away. So because of resources. Here's our resources, some of you may call them humans, if you're all hippy-dippy like that. But here's our pool of resources and here is our massive stack of work that needs to be done. We got lots of projects and they're all kind of big and fat. And by the way, they're all funded so they all gotta happen. If you do the headcount and look at the skills necessary, we don't have enough people to get all these projects done. What is an organization to do? Well, we could cut a couple of the projects or maybe defer them, but that's a hard decision. It turns out there's another way we can solve this problem, right? All we need to do is take those projects, just spread them across all these people. Hey, look, now all the projects are gonna get done, aren't they? So we just assign people to multiple projects because why not? Because we don't wanna make the hard decisions. What happens when we do this? Well, there's a couple of things that happen when we do this. First, you'll notice none of these people are assigned to one single project. Some of them are assigned to two, some of them are assigned to as many as four. What happens when we assign people to multiple projects? All with the same basic priority, all of them having separate project managers who are confident theirs is the most important and the things need to be done. You end up with a problem. So if you were my workshop earlier this week, you've seen this. Let's imagine that you have four tasks of eight hours each. Now how you know they're eight hours, I don't know. Maybe you're the one person who can actually estimate the size of work. It doesn't matter. Let's just say we have four tasks and they're eight hours each. And you are assigned to all four of these tasks and they all have to get done. How long will it take you to finish those four tasks? Anyone? Four tasks, eight hours? 32, thank you. Four times eight is 32. So I'm just gonna go ahead and slice those suckers right up. Boom, boom, boom, boom, boom, boom. I'm gonna work a little bit on each one to make sure that they all get done. 32 hours later, all of them are gonna be done, right? It doesn't happen, does it? What happens? Well what happens is we have context switching. I'm on this task. I've got a bunch of stuff about this thing in my head. What's the history behind it? What am I doing right now? What's the problem we're trying to solve? Who cares about this? Blah, blah, blah, right? I gotta move to the next task. What do I gotta do? I gotta dump all that stuff. I gotta think about this task. I gotta load all that stuff into memory. Now I'm thinking about this task. Well that switch is a context switch. That context switch on average costs 20%. 20% compounded for each task that you add. So what happens is that 32 hours turns into 48.75 hours. That's how long it takes you to get those four tasks done. You spend more time task switching than you do on any one of the tasks. You'll also notice, this is our first task. When does it completed? More than, it gets completed basically at 40 hours. It takes longer to complete the first task than it should have taken to complete all of the tasks when we do this. Now of course if we actually start one and then finish it and start the next one and then finish it, we only have one transfer in terms of what was I doing? Okay, load up the new thing into memory. That's accounted for in the task. So at least theoretically it would be 32 hours. It might be 34, but it's certainly better than 48.75. So this is one of the challenges that stable teams I think actually solved was that we stopped splitting these people across multiple projects. So I wanna look at this just from a slightly different perspective. What does this look like? On a graph, here's eight hours worth of work and for every task that you have, how long does that one chunk of work take you? Just different representation of this same thing. But also because resources. So what else happened here? So one, we got you split across multiple projects. What else have we done? Well, okay, so we may have looked at the skills. Let's hope that we did. Let's hope that somehow this designer is needed on all four of these projects, right? How much of this person is allocated to work? They are fully booked. They are 100% utilized. That's great, isn't it? That's perfect. That's what we want. We need to 100% utilize all of our people because they cost us money. What actually happens when we 100% utilize a resource? This is what happens. Our productivity goes down precipitously once we cross basically 70 to 80%. The task time actually starts to double when any resource, be this a queue or a human or whatever else gets to actual 80% utilization. And then it doubles again from 90 to 95. And then it doubles again. So it's exponential. And basically at 100% utilization, nothing's getting done. Now it turns out that a 40 hour work week isn't really 100% utilization for most humans. We are capable of working more than that. And that's often how we try and solve this problem. Is when we're 100% utilized at a capacity assumption of 40 hours a week, we all just work 50 or 60 and we kind of make up for that gap a little bit, right? So similar graph, utilization, task time. Down here, the task time takes a little longer when you're at like 10% utilized. But for the most part, it takes eight hours up till about 80, 85% and then it starts taking a lot longer. And of course, as we add projects on the amount of time it takes you to get any particular task done gets longer and longer and longer. So I posit that stable teams solve because resources. It didn't solve Tuckmans. Tuckmans wasn't the problem. Storming always happens and high performing teams storm more than low performing teams. At least they exhibit storming behaviors more than low performing teams. They also happen to do it better than a low performing team. But something happened. So we created these stable teams and we solved a bunch of problems. But then something new emerged. We created boxes. We made a new style of silo. This team operates together all of the time. They become a little too homogenous. They become a little bit too much like one another. And we start to get these subcultures in the environment. And sometimes those subcultures are toxic and the environment grows. And we decompose the monolith into microservices and every microservice has its own team. And so we have smaller and smaller and more and more tiny little atomic boxes creating more and more subcultures in our environment. And what we learn in front-end development on one team doesn't spread to the other teams. What we learn in back-end development on one team doesn't spread to the other teams. Every team is becoming its own little thing and now we've got a whole new set of problems, don't we? So we solved one set by making stable teams and now we've got a new set. There's a lot of words in this slide and I apologize for that, but it's an excellent statement from Michael Feathers. Different areas of code are gonna need different skill sets at different times. And for that reason, we need people to go and work on those particular areas at different times. None of this is basically status. It's very fluid. If you have the ability to redeem, then you're able to do this sort of thing consistently. You go from early-stage startup and you grow. And as you grow, the needs of the code change. In the beginning, it was sling stuff, figure out market. Then it starts to become stabilized, the flat platform. But we still need innovation in different areas. And so code that once needed innovation now needs stabilization. Those are different people with different skills. That's what Feathers is talking about. None of this is static. It's very fluid. And if you have the ability to redeem, then you're able to do this sort of thing consistently. So redeeming. So here we go from we have to have stable teams because Tuckmans, which turns out to be, well, maybe not so much. And now we've got a new problem. We've got these silos. We've got these cults of personality. And we've got teams working on a code base that now has a different need than their skillset provides. So what do we do? We redeem. Now to get started with redeeming, there's a couple of things that have to happen. There are fundamentally four factors in any environment that lead to better team performance and collective satisfaction. And I've got a whole another series of talk on this, but let's go through these very quickly. What are the things you need in any given environment in order for teams to be able to start redeeming healthily? The first thing you need to do is foster autonomy. The teams still need to be able to define for themselves the way that they do the work. But you also need connection. So you need connection between these teams. You need them talking to each other. You need them sharing information so that organizationally we're coalescing on these standards and figuring out what is the leading way for us to do this work versus keeping them all isolated. So now they start to work together on what is the right kind of thing to do. We need excellence. Excellence encompasses a number of things. When I'm talking about it here, what we're talking about fundamentally is a way for teams and individuals to clearly understand the goal and to be able to see progress towards that goal in a consistent manner and the autonomy and connection to work together towards that goal. And then you've got to have diversity. And what I'm talking about here is diversity of thought, different backgrounds, different perspectives, different mindsets coming together, different expertise in specific areas. Most of the work that we do today is emergent. Most of the software that we're building, we don't actually know what the thing is supposed to be. It is in the building of the thing that we learn what the thing was supposed to be in the first place. We're not replacing accounting systems anymore. We're not writing docketing systems for law firms or any of that stuff where we know exactly what the manual process is and we're just automating it. Today, we're inventing new ways of working and we don't know what they are until we invent them. And in order to do that, you've got to have diversity. There is no one person that can make the decisions. The team's got to be able to work together and they've got to be able to bring different perspectives to make that happen. So if you've got these things in your environment, then you've got a much better chance of re-teaming successfully. So here are a couple of examples of some places that do re-teaming fairly well. Valve. So Valve has this thing that they call cabals. I don't know if it's actually still around. When I first did this talk, first did this research, I know that they were operating this way. Basically at Valve, there's a bunch of different things that are happening. I don't know, a few years ago, they released their employee handbook. How many of you saw that? All right, pretty cutting edge stuff. It was very interesting. One of the things at Valve, so I'm a developer, I'm on team A. I like it over here on team A. I happen to go out to the bar with a couple of folks on team B. One of them starts telling me about what's happening on team B. That stuff sounds pretty cool. I kind of like what they're doing over there. So the next day I come in and I go to my desk and I pull my main plug and I roll my desk over to team B and I plug it in and I'm now on team B. That's it, done. That is their internal transfer process. Go do what you want to do. Move and work on the thing that you think is most important. Now a lot of organizations, that sounds super scary because everybody's gonna go to the sexy work. Everyone's gonna go to the stuff that's interesting and exciting, except here's the thing. What you think is interesting and exciting, someone else does not. They think it's tedious. They think it's too risky. They think any number of things or maybe that lead engineer that rocked it when we were launching the new product, maybe she's a little tired now. Maybe her mother's taking ill and she wants to spend more time at home and the best she's got for the next few months is to come in, pick up a ticket, move it to done and go home. So she wants that work, not this work. When you let people move to the work that they want, it gets done. The other thing that Valve discovered was they had initiatives that were basically hubris-driven development. Some executives said we're supposed to do this thing and all the people said that's dumb and didn't do it and it turns out it was dumb and it was okay that it didn't get done. Now how many of you have heard of the Spotify model? All right, you may see that there are quotes around this. When I say Spotify model, I usually say Spotify model. The reason I say that is this thing that we call the model is not the model. This is an artifact that represents a moment in time. The Spotify model is constant inspection and adaption. They're constantly looking at and changing the way that they do things. They focus on autonomy, giving teams the ability to do what they need to do. Connection, hence guilds, chapters, those types of things. That is a way that they create that connection. Excellence, clarity of understanding and diversity. They focus on those four things and they've created an environment that allows people to move around relatively easily within that environment. Not quite as easy as Valve. Let's not just get up and walk over there. But it is very easy to move from team to team and Spotify as well. There's a few patterns that have emerged. Now there's a really good book on this now. Heidi Helflin has actually done a book on reteaming and she covers a lot more patterns. I'm gonna go through just a couple of them quick. So the first one that I like is socialization. So this is a team creates their own onboarding and gets good at ingesting new members. They get good at you show up and say, hey, I'd like to work in this team. And the team goes great. If you wanna work here, here's our standards. Here's how we do things. We're gonna pair you up with so-and-so. They're gonna be your mentor for the next couple of weeks to help answer any questions that you might have. And all we're gonna ask of you is get used to the way that we're doing things. We know you're gonna have questions. We respect that. But we'd like you to maybe hold off on change suggestions until you actually know how it is that we operate and then we'll have that discussion. And they get good at bringing people into the team and getting them acclimated to the way that we work around here. What's really important about socialization when you get good at it is it allows you to relatively rapidly grow a team. You can add a member within a matter of weeks they're acclimated. You can add a new member within a matter of weeks they're acclimated. You can add a new member, you get the idea. Now, the challenge here is sooner or later that team's gonna get to be a little too large, right? You wanna keep them at, what, two pizzas, whatever that means? So what do you do? You implement the next pattern, which is mitosis. The team gets to be a certain size, you split it. You now have two teams. Those two teams have normalized on the way that things work. And then they're both good at socialization so you can add members. And you can add members until they split. If you want to grow an organization's excellence, if you have a team, the way that we normally do this, you have a team that works really, really well. You guys are fantastic together. I love the way you guys work together. I don't know how you figure these things out, but it's amazing. We've got hundreds of teams in the organization that we want all to work like you. So here's what we're gonna do. You go over there, you go over there, you go over there. And what do we do? We split that team up, we spread it around. We put them in unfertil ground that isn't interested in their crazy wacky ideas and it doesn't spread. Add people to that team and split it. Keep doing it and you will spread this excellence. Another pattern is the volunteer fire department. This happens when organizations called these Tiger teams or other names form, something happens. Something terrible has gone awry and or we've got some really amazing opportunity that right away we need to have something happen. So we pull in people from other teams, we put them onto a single team for a defined brief period of time and then we go ahead and we send them back. This is one that we probably wanna exercise less often than the others, but it is an actual pattern that happens with reteaming. And then another really good one, trading places. At LinkedIn, they have this concept of tours of duty. You take a job, you sign up for six months. At the end of those six months, you may or may not be offered that same tour or you may go for a different tour. So they are deliberately moving people from team to team on a regular basis. Other organizations will do things like, I'm gonna send two developers from this team over to that team and they're gonna send two developers over here and we cross-pollinate. You get to learn a bit about how that team performs. We get to learn a little bit about how your team performs and then we come back to our own teams and we can share that new learning. Hey, you know what? It turns out that when they do their stand-ups, they've got this totally different thing that they do and it seems really effective and it kind of solves one of the problems I think we're having. Could we try that? In the words of Nayan Hajwala, reteaming is inevitable. You might as well get good at it. That's the end of the talk, thank you. Are there thoughts or questions on this? I try to get through as quickly as possible because this is usually one where people are like, whoa, wait a minute. Yeah, right, so I think there were two pieces of that question. The one was people are moving around, how do you do performance management and then you said something else in addition to performance management or was that it? Okay, all right. I guess my question is how do you do performance management now and why? If performance management is you've got a boss that determines you're doing good or not, my question to you is why is that the structure? If you had a structure where performance management was maybe real-time feedback in a more robust fashion, 360 or something along those lines, I'm not talking about necessarily formal 360 reviews, but if you had something where the network evaluates the members of the network, you would solve that problem. So in order to be able to do re-teaming, perhaps you need to reevaluate the current hierarchy and is it actually providing value to the members and to itself? So it would require a change in the way the performance management is done or at least I would encourage a change in the way performance management is done. So I think that there's an assumption in there that we're talking about super high fluidity as if people are moving every few weeks. That may not be the case. People may stay on a team for a couple of years. They may stay on a team for six months, I don't know. So when I did this at Groupon, what we ended up doing was we basically went with the tour of duty concept. Once you enlisted to work on a team, you were guaranteeing that you were gonna be there for a period of time. So you didn't come for two months and then off you went. You were there for four, six months at a time. Also, we're pairing and we're mobbing. As a result, knowledge share is extremely high. The entire team knows what's going on. So it's actually fairly easy to join these teams and to get up to speed pretty quickly on what's happening, what is the business problem that we're solving. If we are defining the work in terms of actual business problems, if we are product focused, that helps a great deal as well. When the team moves from implementing requirements to solving problems, it's actually easier for them to get a quicker understanding of what are we doing, why are we doing it, how are we doing it. So you gotta think about in your environment what makes sense. It might be that you want to say, hey, yes there's fluidity but when you join a team, you gotta be there for three months or six months or a year. It might be like Valve, you're willing to say, move when you want, however you want. I would experiment with it and I wouldn't, if I'm introducing this to any organization, I wouldn't go from no fluidity to everyone moves all the time. Take some small step, how did that work, tune, adjust. As the organization gets better at this, you can accelerate the movement. You may find that at first it's once a year, people can move and after a few years, it's once a quarter people can move and you're not noticing a difference. What else? Yeah, yeah, but productivity was the thing that we were concerned about when we 100% utilized and put people across multiple projects and when we stopped worrying about that and we took a different approach, we actually increased the productivity of the people. So I get the question, I understand it. It is looking at short-term local optimization. Oh, if we've got a couple of too many people on this team, they're not all being utilized efficiently. I'm not thinking about what's the long-term effect and impact on the overall organization. Think about the amount of time that is spent between teams arguing over how the work is supposed to be done. That team insists that they have to have everything designed up front and know exactly what the API looks like and that team wants to just kind of figure it out as they go and that lack of cohesion, that lack of connection between those teams, the lack of fluidity that keeps them stuck in both of their ways of doing things, costs the organization far more than it would to use a mycosis pattern to actually grow this thing out. Okay, I'm sorry, I'm not sure. Yeah, I think we're kind of saying the same thing there. Like it's not actually four stages that happen in sequence that, yeah, yeah. Which is what the studies have actually shown. What Tuckman had done was look at a bunch of studies up to that time and was looking for patterns across them and said, hey, it seems like in general this is the thing that happens and then we kind of adopted it as like this is the thing that exactly happens all the time. So yeah, you're right. Performing can look different on different teams. You're storming while you're performing, et cetera. So I know you had a hand up earlier. I think you're good. More of a controlled one than a democratic one. Good meeting. What do you mean? It could, right? So I think part of your point is that sometimes we need these folks on a team and if they opt to move, then we lose a certain amount of knowledge that then ends up becoming a real problem for the organization. So what is the demand? I think there's different ways that that can be addressed. One is that maybe you could do internal job fair type thing so that people know that there is, what are the opportunities that are open? Then when I opt into, I want to join this team, the discussion is not a matter of if, but a matter of when. In order for me to move from my team to that team, what needs to happen? My knowledge needs to be transferred. When my knowledge is transferred, then I can move. The other thing that we gotta be careful of, because I saw this at Groupon, they wanted to keep people on teams because they had certain level of expertise so they refused to let them move. What did those people do? They moved. They left the organization altogether. So now you've lost that knowledge entirely. So we gotta be careful that we don't try and control humans in that way. We gotta think about what is the real impact here, not just to the organization's need in the short term, but what is the risk? So we were losing good talent because we wouldn't let them move internally so they moved externally. It actually made more sense for us to say, all right, fine, you can go to a different team. At least you're still in the organization. I can now come to you and ask you questions. So we gotta keep that balance between those things. Yeah, there's one back here and then one over here. So you're saying that in some teams, people would be performing and other people are still norming within the team itself? So I think if I'm hearing you, you might be looking at evaluating individual performance on Tuckman's model and that it just, those two things don't go together. So we may have people who are more experienced, more adept at a particular thing and people who are learning and coming up in that particular technology or that domain. That's gonna happen on every team. And in fact, I think it's really, I think it's healthy for a team to have that kind of that type of diversity on it as well. It's amazing how often the really interesting ideas come from the folks that don't know any better. You had one over here. One of you two? You both look confused. All right. How do I view a team? What's my definition of a team? I don't know. Yeah, I should have a better formal definition of that. And I probably have one written down somewhere. Yeah. I don't know. I don't know is there's once, once you've got a organization that is constantly evaluating, constantly growing and sharing knowledge across it, when you pull any group of people together, it almost instantaneously becomes a team of people. They've got a defined purpose, right? Some kind of a mission, some problem they're trying to solve. They have a way of knowing that they are moving positively in that direction. And they are working together, not that each of them has an assignment, but that they are actually sharing the work together. And I think there we have a team, be it for a week, a year, a decade. Yeah, they're cross functional. Yes, thank you. So that's kind of what I meant, better statement of the working together. So I think we're actually a little bit over time. We do have two minutes. Okay, all right. So I don't know, that's interesting question. The first thing that came to mind for me was, how does the existing structure address any of that? It doesn't, hierarchy does not respond well to that type of change, whereas a resilient dynamic organization would be better structured to respond well to that type of change. So in my, I mean, from my estimation, having an organization that's structured like this would actually be able to do better when direction at a high level, when strategy is changing every couple of years. When it's hierarchy, watch this over and over again, the new leader comes in and says, from henceforth thou shalt's yeck and ye smack. And then slowly but surely, that makes its way through the organization with lots of resistance at every layer because my job as a middle manager is to protect status quo, not to allow change. And by the time it finally gets to where it's like we're almost functioning, the new leader comes in, right? Yes, that is absolutely correct. So when we were talking about dynamic redeeming and that type of stuff, we were also talking about organizations that are flattening out, right? That we have fewer of those layers, we have more, it is much more of a network than it is a hierarchy, yeah. All right, thank you again. I'll be around.