AA109 - 3 Types of Teams (from Post-Capitalist Society by Peter Drucker)

Oh, welcome back to Arguing Agile it's the podcast where I, product manager Brian Orlando and Enterprise Agility Coach Mr. Om Patel! We get together and argue all things agile so you don't have to That's right. You ain't got it. Well, I mean, you can still do it. You can still do it. We're not taking that away from you. That's true. Not, not this one. If, if that's what you enjoy. We've been doing a lot of product topics recently. And I wanted to have a team specific topic to, to break up the monotony. To be fair, that's what I, to be fair, I wanted to have to be fair, a team specific topic. And, I found this Peter Drucker book, don't Be Scared of the title Post Capitalist Society by Peter Drucker. because it's not really about overthrowing the hierarchy and, instituting a, a new, anarchic. Anarch anarchist. Anarchist. Anarchist. An anarchist instituting an, an anarchist society. Yeah, that, I mean, that sounds fun. That sounds like a fun thing to do on the weekend, but that's not what this is about. I did read this once to you. But like very quickly as the elevator pitch for this podcast. Cuz I'm very bad at elevator pitches and my elevator pitches are 90 seconds long as you see here., but, , I want to read you this and get your reaction as our expert on teams. Let's do it. What he's saying is the knowledge workers, in the future of society. the business won't really know what the knowledge workers do, and the knowledge workers are the experts at the work . So you need a different way to manage. And, he says that like, although they did have teams in the capitalist society in the, the, the Society of Taylorism, right? They were different teams, and he gives some examples to illustrate. So I'm gonna walk through those examples now. Okay, so here we go. On page 86, he talks about three different types of teams. There's a second major difference between the productivity of making and moving things and the productivity of knowledge work and service work. That's what I, where I was leading in, right? In knowledge and service work, we have to decide how the work should be organized, what kind of human team is appropriate. I like human team 1993. What kind of there? We weren't considered humans in 1993. I dunno if you know that that's true. Uh, what, what kind of human team is appropriate for this kind of work and its flow? Most human work is carried out in teams. Hermits are exceedingly rare. Even the most solitary artists, writers or painters depend on others for their work to become effective. The writer on an editor, the printer. A bookstore, the painter on a gallery to sell his or her work and so on. Most of us work in far closer relationship to our teammates. There's a great deal of talk today about quote, creating teamwork. This is largely a misunderstanding. It assumes that the existing organization is not a team organization and that is demonstrably false. It secondly assumes that there is only one kind of team, but in effect, there are three major kinds of teams for all human work and for work to be productive, it has to be organized into a team that is appropriate for the work itself and its flow. Let me stop there for a second. Wow. He's covered a lot of ground, uh, right there. Yeah. For way back in paragraph. Yeah. Right. While, while you're processing, while you're spinning, I see your CPU spinning up. Yeah, definitely is overheating. Yeah. The cycles are spinning out the I'd like to take a second to step back and talk about Why I pulled this one off the bookshelf. Uh, yes. Better to talk about it. Thank you. It's amazing that this book was written in the early nineties, 1994. It, it's funny to me that he's, he's pointing these things out and he's kind of outlining these things, uh, that kind of make us say, oh, yeah, yeah, yeah. Makes sense. It's something that a lot of people don't think about or whatever because, where he was and the research he did, it's like the business world, just kind of like saw it and read it and was like, that's interesting. That's a really interesting concept. And then they ignored it and said, but we know we can figure out how to do things better. We don't need this. It really makes you wonder why nothing's moved since that time. You know, until recently, this hasn't really been talked about much. Right. Now, I guess, or, or even now. Now there's, there's different models out there for, teamwork and teaming and team structures, et cetera. But yeah, he was, uh, he was definitely ahead at that time. Well, there's, there's different models out there, but, kind of my challenge very quickly is, the model of I'm the manager and you do what I say is still, in my experience, in product development, The do what I say, manager is pretty much, I would say the majority of the team structures. You have a team, it's hierarchical, you work for somebody, there's a lead, they have team members under them. And that, like, that org structure is basically the prevailing org structure. And that org structure basically traces its roots all the way back to Taylorism. And it, and quite honestly, doesn't really do much for the knowledge worker in the modern, you know, software development team. Yeah, yeah, absolutely Concur with that. I think what's happened is between then and now, we've, if anything we've seen. The ascent of matrixed organizations, right? And that's just made matters worse when it comes to hierarchy. Now you have a hierarchy of hierarchies and people aren't really neatly into a given hierarchy cuz big still and borrow right, quote unquote resources. Right? I, you know, I think to your point, are the models today any good? We have a lot of them, right? So today the, I guess the devil in me wants to say, try one. But if you really examine those and, and you look at that against the backdrop, the type of work that people are doing today mm-hmm. I think there's a misfit there. this idea of a, of a hierarchical manager, cuz in our leader, basically saying, do this, do this by this date. Mm-hmm. Do it the way I say you should do it. Mm-hmm. That's still, to your point, it's very prevalent today and I think we're suffering as a result of that. especially in, in knowledge work. Right? Right. Not just software development, but pretty much any type of knowledge work. Let's step back for a second and talk about a, like a, a podcast series that we, would like to do, but uh, like are kind of afraid to, cuz everyone, moans and groans when you bring up the topic of an agile transformation. But the, I I, I feel the agile community specifically have been undermined by what we're talking about here is the organization and the people running the organization do not fully grasp or understand teams and team concepts. The concept of teams and what teams are for, and how the different types of teams, they don't grasp this and they don't understand what it takes to make a good team. but the thing they know is what they were taught in their MBA, there's a org hierarchy and you gotta move resources from one resource manager to another and that's the way they view it. Yeah. And, and the other thing that, uh, is pushed and I,, I would say HR is not helping with this either, but Yeah. No, they're, they're the drivers in many cases. But the other thing is this, this overwhelming, emphasis on keeping people busy, utilization. Right. People must be utilized, otherwise they're underutilized, we're losing money. Unfortunately, that, again, is way too prevalent out there. Well, that's, you know, I, I, I actually, uh, I had a discussion today about this exact subject we were talking about the book 4,000 Weeks. So many people were kind of shocked after they read the book. a new world has opened up because I, I've been taught and I've been trained, and I've been conditioned, conditioned. That's what I'm looking for. I've been conditioned to feel like I have to pack. Every single day with as much being as productive as possible. And the book basically is like, well, but why? You know? And I, I, as a product manager, I'm like, well, yeah, of course. Like that, like that. That's just the way that I think, like, this is something I say a lot in product management's, like prioritization the outcome of prioritization is in no way, shape, or form, a signal for value. Just because you've decided are you, this is your number one priority Om! You've gotta get this done. And it also has absolutely no value. That's why like online, like on LinkedIn, you see people, uh, especially the the growth product manager people, they're making a real killing off of, uh, slamming on Agile cuz they're like, you can have the greatest agile team following the greatest agile processes and the product you put out at the end, nobody wants, nobody wants to use and it's all garbage, which I like. That's, they're doing that to, you know, start a fight on LinkedIn and get engagement and stuff like that. But because we all know, like if you actually are getting customer feedback and you're actually listening to them, not just saying, yep, the customer was at the meeting, check the box, you're basically doing what they are claiming is a completely different discipline with a completely different skillset. Yeah. But this is not the podcast of that. That might be an upcoming podcast, I think. I think it might be, yeah. Yeah. I think they'd have something to say about that. They like hot takes... Yeah. I think what we've seen, um, since 1994 was it, different models evolve and honestly my experience has been none of the models really headed out of the park. Most of them have their pros and cons, like any model really. But the, the important thing is nobody really implements any of these by the book. So they dabble and then they say, this doesn't work here. Right. So we're gonna change it up. Now you've already gone away from the model, right? And, and then what you have is a hybridized version of that model. are there actual team models out there? Like I don't think I've ever seen a, like, this is the way you should structure your teams other than, other than the early scrum guides that, like when we tried last podcast to say, like, where, where's the thing that says your team ever should be dedicated to the Scrum team? And we couldn't find it cuz it, it had been rolled out of the scrum guide. But, are there team models? Other than Team Topologies, which we covered on another podcast, I see the team topologies guys out there on the internet. Man, Manuel Pias and uh, uh, Skelton and yeah, Matthew Skelton. I, I see them out there trying to help people, trying to say, Hey, this is a better way, you know, catch onto it. And then I see like the, the, the Spotify, you know, the people trying to copy Spotify and stuff like that. Sure. And it always fails cuz they, they try to copy Spotify until an actual decision needs to be made and then they revert back to command and control. But, but, but like, I, so I guess there, there are a few models that are floating out there. well, scrum, scrum itself is a model, right? I mean, you know, guess five to seven people, et cetera. That's a model. and then there are other models which are different than that, right? Like, uh, holocracies, these are more organizational models. Mm-hmm. But you could, you could extend the argument. They, you can extend the argument that they could be applied at a team level. Yeah, but again, not really seeing that done well anywhere. Yeah. Kanban, I guess, could be implemented as a team. Like a, like a concentric teams that work with other teams, that work with other teams. And in fact, you could run a whole organization off Kanban if you wanted a process to, to layer down to, to give your business a bit of process to, to, to, to help with prioritization, to help with breaking stuff down larger rocks in the small rocks or whatever, kanban kind of helps you all the way, all the way from the executive level, all the way down at l levels of the organization and, and can. Quote scale, I guess. But that's a great example of another model that hasn't been really implemented very well. It's kaban, yeah, right, it's easy to explain, but it requires some discipline, uh, yeah. To actually practice. Yeah. And you've seen all kinds of malpractices out there. Yeah. Also, uh, is this the time to bring up Nobody's making money off a Kanban? Is this, is this time for that? I don't think, I don't think this is the podcast. No, this is not the podcast for that. Just checking. There are a few people that are doing Kanban Cert. Why the, why the Kanban certification so expensive. I'd like to know that too. They're ridiculously expensive. Somebody's making a ton of money out of these things. Oh man.

so he says, the first kind of team is exemplified by the baseball or cricket team. It is also the kind of team that operates on a patient in a hospital. In this team, all players play on the team, but they do not play as a team. So he says each, each player on a baseball or cricket team has a fixed position, which he never leaves. In baseball. The outfielders never assist each other. They will stay in their respective positions. If you're up at bat, you are totally alone. Is an old baseball saying. Similarly, the anesthesiologist will not come to the age of the surgical nurse or the surgeon. he says, this team does not enjoy good press today. In fact, when people talk about building teams, quote, building teams, they usually mean that they wanna move away from this kind of team. Yet the baseball or cricket team has great strengths that should not be discounted because all players occupy fixed positions. They can be given specific tasks of their own, can be measured by performance scores for each task can be trained for each tasks. It is by no means accidental that both baseball and cricket are, that there are stats for every player going back for decades. The surgical team and the hospital functions much in the same way. He's got a point there, right? So this is, again, look, look, the, the time where he wrote this. It was basically the time of the eye shaped individuals, right? Yeah. Everybody who was an expert in what they did. Right. And, and he's got a couple of examples there, sports as well as, the hospital setting that, that he, portrays there. Yeah. You had a skillset that you acquired over time. You paid handsomely for it probably, right? But then, and then you practice that, right? Right. So without you in as a, as an integral cog in the machine, it doesn't work. that was the prevalent model at the time. And I dare say it still is prevalent, but it's, it's getting changed, I should say, in, in quite a few areas that are sports is another example. Let's apply this to software development, but apply it in a way where it's lacking in sophistication where you say, oh, well I've hired a developer, they should be able to develop anything. Well, but which is kind of, uh, if you look at it that way, you, I could argue for the like, hello, we're arguing agile. I could argue for this from that perspective. I know I would be wrong. So I'm not even gonna try because it's ridiculous to say like, well, just hire me any developer. Like, like you gonna hire a job and developer Yeah. To work in a.net shop, or you gonna work a Yeah. A front end developer to work on backend stuff. Or I've been in shops where we take a frontend developer and ask them to do backend tasks because, just because we had a lot of backend tasks. And also because the shop, well also because development, leadership, slowly over time is trying to grow full stack engineers out of their front and backend talent. They're trying to help people develop their skills. I feel the people that would engage in this kind of view, Of saying like, I have a developer. What does it matter if they, their expertise is first base or, you know, left field or whatever. Like a right field or what, like the outfield. Yeah. It doesn't matter. That's a big, that's a big difference in position though. Of course there is. Right? So that's like saying, look, you've got a, a person who can paint a house, get them to commission them to make a portrait of me. Yeah. Paint the Mona Lisa! Yeah, paint the Mona Lisa. That's right. They're a painter. They can do it, you know, shove 'em up on a rig and say, do the Sistine chapel. Come on, you can do it. Yeah. So I, but I do have to say the other side of that, which is since then and now what we're seeing is just to use his example of sports, another sports where people can actually fill into a another position. And that's, that's not just accidental, that is deliberate. They evolve to fill in. Right. Like in soccer, like in even, I'd say even in ice hockey, you have people that will rush forward and then you have others that will fall back. To fill the void. And if you just did that because of that specific, occurrence, that wouldn't work. Cuz it's just a warm body in the right spot, but they don't have the skills. Right. So people have to train for that. And I think that's happening. Yeah, to a certain degree. Probably a lot lesser degree I would say. It's happening in software development too. So you have people that can write a script. You have developers, sorry, you have testers that can develop, they're technical. They write, they write test cases, test scenarios all the time. That's not, that's coding basically. Uh, so if they sit alongside a developer, they're acquiring these skills, they're growing those skills to the point where can they become a developer? Only if they want it to over time, but they can pinch hit for somebody. And that's the T shape that we're, we're talking about often on this podcast. the people managing the team he's talking about here, everybody has a specific spot. I think of all of the engineering leaders that I've been coupled with in my career who really were like, you could not shake their opinion that the best way to run an engineering team was to have front end developers and backend developers and keep them dedicated to just front-end work and just backend work. That the teams had no full stack developers, real tight specializations and, and, and crossing work between developers outside of their specialization was, was not, uh, taboo, yeah, yeah. It was, it was not encouraged. That's the general specialist at best. Right. So you're a specialist and if you say, well, look, so-and-so's not here today, can I lend a hand? It's not your role. Yeah. Right. That's not your job's. That's not your job. Yeah. Yeah. I, I think this shift to that from the other's perspective is to, to be a special generalist, I guess. But somebody who does really well at their core skillset, right? Yes. But they can also lend a hand. Yeah. That's different from give that person the same responsibilities, the same accountabilities as the other person who's an expert in their own field, I've seen architects do this quite a bit and, and then they become, What is now, I guess referred to as the M shape now, right? Where the M four multiple, so they become specialists in multiple technologies. You're a cloud technology expert in aws, and then you become a cloud technology expert in something else. Google or Azure. That was the core idea of, of DevOps is if you build it, you own it and, and you're going to need to understand more than just. Tiny little slice of a language that you primarily develop in, in order to, uh, operate like that. I don't even know if this is prevalent anymore, but I, like in my career, even as recently as a couple years ago, I've encountered this where they, the, the, they just don't want developers venturing outside of the, the, the, the role that they hired them in for. I encountered it all time in contracting and I would push back on it with, basically, I would see it in the tech side of the firm and I would push back on it with the business side of the firm to say, this is gonna limit you guys. You, you understand that, right? Like basically the product owner are gonna have to bring in every sprint. The product owner's gonna have to bring in a balance of front end and backend work and the product you're basically putting on the product owner to say, what's the most value you can bring into the business and what's the most value that you can bring in the business that we can work on right now? Cause I don't have the skill to work on everything at once. I don't know why this is still so prevalent, cuz it does, it just seems backwards to me. We all understand at some point you're gonna call in, you're gonna call in the calvary at some point when you want to go, you have to and have a sleek product and design. You're gonna go and you're gonna call in a a, an experienced front, front-end engineer, a ui ux person. Someone to streamline your user experience through the whole app and, and, and, and give your app that, that sleek polish that you don't care about when you're trying to rush things out. That's right. That's right. Those, those good ui ux people are like gold dust. They absolutely, you can't find them. Not, not. I've been struggling to find good people like that. Not like wwe, a pilot resumes that say ui ux. And that's how they get through the ATS screen. But when you talk to 'em, they're like, wow, use this tool. Say, all right, I don't know it. I'm out. I, I think, I think the, the best U ui, I have a really great u UIUX person who lives here in Tampa. I would like to try to get 'em on the podcast to talk specifically about uiux, but uh, again, like it's, it's its own discipline. It's, it's u uiux even though I say it, I'm being flippant when I say it, but U I U X is different than just a front end engineer, of course. Course. Right. And that's kind of what we're going with, with, with what we're like this subject of like, wow, I'll just have a team and I'll have a front end engineer and I'll just tell 'em at a checkbox. At a dropdown. Well, that's different from hiring a u UIUX person it's, it's actually the opposite. You're hiring the u i UX person to tell you what you should do to have a great user design and experience as opposed to I'm hiring this front end engineer so I can tell them what I want to do the UI ux person will be able to tell you they've already spent 15 clicks to get to this point. Do you really want 'em to do another three? Right. So they, they focus on the journey, the customer's journey. Right, right. And that's a different mindset. The front end developers really don't have that necessarily. At least that's been my experience. To cap this category, he says, for repetitive tasks and for work in which the rules are well known, the baseball team is ideal. So, so yeah, here we go. Front end, back end. Like, I feel this is, every senior developer, director, developer that tried to jam that square peg into that round hole because they were trying to like, oh, this is something familiar, a front end backend developer, I can pay this and it's familiar and it was this model on which modern mass production, the work of making and moving things was organized and to which it owes a great deal of performance capacity. so the rules are known, very little risk, and you're basically stamping out widgets is where Exactly. Right. Yeah. There, there isn't, there is, there's very little to no risk, I guess maybe something breaks or whatever, but there's very little to no risk because everyone's working on their place on the assembly line. Everyone's doing the exact same job over and over and over again. And, um, you know, there's almost no risk in that except people around if you want or somebody doesn't show up, that's fine. That's not a rare skill set, you know, it's really not. Call someone in. And, and, and honestly, if you, if you roll it back to our podcast on Taylorism, which I will link in the comments below. Below, yeah, if you roll it back to our podcast on Taylorism. Like the era where this was happening. They're like mass, public education was not even a thing. Like most of these factory workers didn't even like, oh, I remember early in our podcast, I, I think I left it in the editing. I don't know. It's been a long time since I watched our podcast on Taylorism. Like most of the workers didn't even, like, they had to, they had to, like, buying a permanent pair of shoes was a big consideration because a lot of them didn't even have shoes. For sure. I believe that you talking what, 1920s? before that. Even before, yeah. Yes, I believe that. Yeah, it was before that. Yeah. That's the era where these, these ways were invented, these ways to run teams were invented and they're still around. Most people had to walk to work and they had to decide whether they wanted to buy a really, really, really expensive pair of shoes. That would last 'em a couple years or a cheap pair of shoes that would last them, you know, just, just a, a, you know, a couple months or not have shoes at all. So the nature of work has changed, that's what's changed. Right. And the team structures are still predominantly the same. Yes. That's, that's the problem we have. It wasn't knowledge work back in the day. Now it's all knowledge work, pretty much all knowledge work. So his second type of team, he says the second type of team is the soccer team. It is also the team concept on which the symphony orchestra is organized and the model for the hospital team that rallies around the patient who goes into cardiac arrest at two in the morning. Here we go into a quote, on this team two. All players have fixed positions. The tuba player in the orchestra will not take over the parts of the double base. They stick to their tubas in the crisis team at the hospital, the respiratory technician will not make an incision in the chest of the patient to massage the heart, but on these teams, the members work as a team, each coordinates his or her part with the rest of the team. And then he says, this team requires a conductor or coach, and the word of the conductor or coach is law. It also requires a score, quote, score, and it requires endless rehearsals to work well. But unlike the baseball team, it has great flexibility if the score is clear and if the team is well led, and it can move very fast. To think that he said that back in 1995. Yeah, four and even four. Okay. Yeah. Uh, but even today, right? We don't have that model in very many places. When you think about it, you have care teams as they're called, right? So he mentioned healthcare. Yeah. With That's true. You have healthcare teams, they work in a team environment. Yeah. But you know, that's pretty much it really. I mean, you think about software development, you don't necessarily have that. Some forward-looking, forward thinking organizations do mob programming, for instance. kind of an offshoot from peer programming. So, When it was two, we called it pair, we added a third one, it's not a pair anymore. Then we started having people look over their shoulder, hence mob programming. And that is still pretty rare, overall. And why is that? Right? It's because the bean counters can't fathom how, how is it that six people are working on this one thing? Yeah. Shouldn't we have one person working on it? And that's the reason why what they don't realize is there's better quality built in, cuz six pairs of eyes are contributing to the solution here. One person knocks it out and then, oh, it's failed. It comes back again. And that's interesting because where I was going with this was I think that this is, I think this is the modern software development feature team. I think this is the majority of what we deal with. The soccer team where everyone looks the same on paper and theoretically they should get along. If we take a soccer team into consideration for a second, everybody knows there are players on the team that are more skilled than other people on the team. That's true of a software development team. Also, you have your primadonnas, right? But, if he's gonna say the second team is the soccer team, where like they, they need a coach. They need someone keeping them pointing in the right direction. They need there, there needs to be constant effort on the part of the coach to keep them pointed in the right direction to keep them. Where, where is it? It requires a score, basically. I'm gonna break his example here in a second. Actually, I'm gonna break his example right now. You have two coaches. You have one coach who is the process coach, and you have one coach who is the business coach. So basically you have a product owner and you have a team coach, team, lead, process, person, whatever. The way the work gets done and the work to be done. What you're working on and how you do it. Right? And then where it breaks down is where he says they're okay as long as they have a coach. I think the, as long as they have a coach, part of it is where we're gonna break this down and say, well, well, you know, most teams have really terrible leaders who don't know what they're doing right. And don't paint a clear direction and don't get, you know what I mean? And like, try, don't get anything, any, anything special from the team. I, I don't know a lot about soccer, but I would imagine, there are teams that are better than other teams and, and generally players that work together that are better than other players that work together and the domineering quote coach that's trying to tell you all the things to do and trying to be involved in every single play in every single like. Come on. Like, that's not gonna work for a team like this. That's too prescriptive. That dictatorial approach almost. Right? Exactly. That, that, that requires the team to simply park their brains at home. Right. Show up and do as they're told. Right. And that team's not gonna win. Right. Well, well, like, here we go here the big picture, like here we go, here, here comes a clip about, here comes a clip of what I, what I wanted to say in this podcast. So, because the management style of the organization is the first type of team, right? And the team style is the second type of team. And now we're in one organization trying to gain success. You're, you're not even like, you're, you're on different planets at that point. Yeah, absolutely. The two are ch cheese and, and you're trying to mix them. And that's a recipe for disaster. The team requires a conductor or a coach. The word of the conductor or coach is law. It requires a score. And en endless rehearsals, like in, in our line of work, I, I see this as like, a cycle of retrospectives that are just on a schedule and a, and a and, you know what I mean? And, and constant introspection of what we be doing better and stuff like that. This is classic, inspect and adapt, right? This is is where it is. You do something, you look back and see how you, did you improve, use some more rinse and repeat. Yeah, yeah, yeah. I kind of wanna move on to the next point, but I, I kind of wanna stop here and talk about, um, like why management is so outta. And what, and maybe what we can do to get management back in sync because like the team structure and team organization and, and really org design, that's kind of where we're going with this. We're gonna do a big podcast on that. At one point, your management has to be aligned with good organizational design to support good software. Cuz if, if you have bad organizational design, you're gonna get bad software. Like that's, that's Conway's law basically in a box, right? Absolutely. I concur, but you know, to your point about how, why management is not on board with this, think about who they are and how they got to where they are. They didn't get to where they are by doing it that way. They got to where they are by being directive, telling people what to do, when to get it done by. And that's, that's the reason why they can't think this way. I don't know. For the most part. Yeah. Yeah. Like if I'm looking for places to push back, like that'll be the first place I push back is, did they get there like that? Like I, I, I think of , all the directive managers I've ever worked for, they had a whole staff of good natured people that kind of took their, took their beating and, and, and took it in stride and had a positive attitude. And up until the day where they just couldn't take it anymore, and then they quit, or they were fired, went somewhere else and, and, and, and those, those, those managers taken credit for their work, uh, all along the way. People like you just described, that that's what I've seen them make their careers on. They make their careers on the back of people that, uh, they do. They do, yeah. But they, but they didn't make their career. Nurturing teams. Oh, no, no, no. Right. Creating a good organizational design. That's not how they made their careers. They got, frankly, they made their careers by stepping over people. Right, right. And, and those people that they step over are basically, I don't know, collateral damage. Right. It is what it is. They get tired and leave, or they're fired or rif'd off, whatever. Right. That's how they got to where they are. So we can't expect those people to come up with decent organizational design. It's not in their dna. Well, I mean, at the point where you're going there, at the point where you're super low on empathy. Like, you're, you're not looking out for what's best for people, and you're not trying to like, put people over the top and you're trying not, you know, you're trying to claim credit for what other people did, and you're not really trying to promote other people. And that, like, I don't know if you're in that situation we have other podcasts for this. Let me move on to the last,, point though, or his last team, while, while I'm here, Finally. There's the doubles tennis team. The team also of the jazz combo or of the four or five senior executives who together constitute the quote president's office and in the large American company or the vorstandt. Sorry, he board management. Vorstandt. Yeah. See, sorry. Gotta had to be German there for, for our listeners in Germany. You can hear me? Screw up Vorstandt. this team has to be small, seven to nine people may be the maximum. The players have a quote preferred rather than a quote fixed position. They quote, I don't know why there's so many quotes in here. No. The, the, like, the, the passage stands alone by itself, without quotes anyway, the team has to be small. Seven to nine people may be the maximum. The players have a preferred rather than a fixed position. They cover for one another, and they adjust themselves to the strength and weaknesses of each other. The player in the back of the court in doubles tennis adjusts to the strength and the weaknesses of the partner who plays the net. And the team only functions when this adjustment to the strengths and weaknesses of the partners has become condition a conditioned reflex. That is when the player in the back of the court starts running to cover for the weak backhand of the partner. At the net, the moment the ball leaves the racket of the player on the other side. A well calibrated team of this kind is the strongest team of all. Its total performance is greater than the sum of the individual performances of its members. For this team uses the strength of each member while minimizing the weaknesses of each. But this team requires enormous self-discipline. The members have to work together for a long time before they actually function as a quote team. And, and here we come to the main lane of, I feel like what, what every organization wants to have. But, fails to properly envision, understand, engage the team coaches to get to like, they, they don't understand that this is the goal. they don't understand how to get to this goal. But I think every organization understands that this is the goal. Yeah. You pretty much nailed it. I mean, a lot of times people hear about the terms self-organizing teams, right? Self-managing teams. Teams, yeah. And those people that understand those terms. They'll be like, okay, tell us how we can get there. Cuz they may not have the answers. But those that don't understand it, they misinterpret it and say, no, no, we need to control these teams, otherwise it's gonna be chaos. What self-managing, they don't know what they're doing. We need to tell 'em. And so they go back in that command and control mode. Yeah. I'm glad you, I'm glad you jumped first to the word control because it's, it's the word that most fits in this position. I was in an organization once in a scale capacity, big team, six, seven teams, right. And, I recall hearing over and over again, how do we know that everyone's, you know, pu punching out, cogs on the assembly line. How we know that everyone's working. You know, how do we know that people aren't taking advantage of us and working. Whatever, 39 hours instead of 40 hours or whatever. I'm like, is that, is that really the concern here? Is that really what you're worried about? It goes back to that utilization, right? You covet that. Keep people busy. Well, that's Instead if they're busy. I know they're working. Forget what they're producing though. Well, each of these team models I read today, management is structured to support one of these team models. I, I don't think management can be, maybe I'm wrong here. I'm willing to be challenged here. Maybe management can be structured to support multiple of these. So I'll lean in a little bit on that one, I don't think you'll get to a situation which is, you know, wherever you are, you can suddenly go from there and transition to this. Ideal world of having self-organizing teams. There is a journey between those two states. And you potentially could have teams that flex in that way. Right? So in those scenarios, you would have management possibly embracing multiple models for a period of time. They have to have the appetite, they have to have the trust in the teams. Yeah. And lastly, I think you mentioned this, they need to engage the council of somebody who can help them with it, right? Yeah. In the capacity of a coach. Right. Get help. Get help. Yeah. get Help is a great, I was gonna say it's a great movie title. Get, like, get help. Get help is, it's a great message. Like it's a great message to end with. Get help because, this would probably be a good post for LinkedIn. Not, not in the normal LinkedIn post of people trying to get attention on the internet, right, by throwing out their hot takes over the internet. But, this probably would be a good post for LinkedIn , in in this book in again. Here we go. One more time before we are done for today. Peter Drucker, post Capitalist Society. Again, don't be scared about the title. He's not talking about, the revolution. I mean, unless you're down for a revolution and then sign me up, I'm gonna speak singularly cuz I don't know if you back me on this one, but what I'm saying here is that there, there are management styles that support these types of teams. And, if you are managing to the first type of team we talked about, but you want the third type of team, working in your organization, pushing you forward, you're never gonna get that right. You, you need to adjust, , and, and you as the leader in the organization, I'm here, I go, I just switched from management to leadership. You, you as the leader in the organization, you need to make the first move because your teams are not gonna evolve, with your dated management style, going back to the first, like you, you're, everyone needs to be in their own positions. I can't have a frontend developer go learning backend stuff or go figuring out how to, you know, figuring out how to, how, how to optimize, uh, database store procedures. My, my, my front end developer, why are you doing that? Why are you working on that? Don't do that. Talk to the dba. Yeah, you should let the DBA do that. He's better at it than you. You'll never be good at anything. Like what? Like what a terrible message. If you're having problems with this at a team level, you should bring it up with, like whoever the leader of your business unit is, who, whoever that is, who whoever can make a difference? You should definitely start with yourself though. Look in the mirror and say, you know, am I enabling this organization to be self Sure. Certainly should. Managing right. And if, if I'm doing that, what are the obstacles my peers on, on, you know, on the board. Okay. Talk to them. Yeah. Right. Give people the teams enough rope to work with. Trust them to get the job done and leave 'em alone for a bit. And you'll be amazed what they come up with. I feel in the, in the first example, the baseball team where everyone plays their individual positions and everyone gets scored on their individual positions. I don't feel trust is strong in that model. It isn't. It isn't. Cuz you're trying to do the best for yourself, not for your team. Yeah. That's why. Yeah. Uncool. I think that's thoroughly uncool. Absolutely agree. Because then what, what do you, how many people on a baseball team? Uh, 38,000! I know. Let's say, I don't know, let's say 20. I don't really know, but do you really want a single baseball team with 11 people on it, or do you want 11 teams of one person each? That's the decision you have to make, because if everybody's in it for themselves, then you don't have a team. Nope. You have individual teams. I'm wrapping up. What I learned today is, uh, 26 people are on a baseball team. That's what I learned today. I'll tell you what I learned is Mr. Drucker was very talented, uh, way ahead of this time. I can't believe it. Yeah. so if you haven't read his stuff, definitely you should.