Team Sizes

About this Episode

In this episode of the Acima Development Podcast, the panel, led by Mike, explores the concept of team sizes and how scaling impacts management and functionality. Using an analogy from the film Honey, I Shrunk the Kids, Mike highlights how physics, like management strategies, change with scale. The group discusses how larger teams can't be managed in the same way as smaller teams and why losing a team member in a small team is more critical than in a large one. The discussion then shifts to defining the role and purpose of a team within an organization, and how the size of the team depends on its function, specialization, and the applications they support.

As the conversation evolves, the participants debate the ideal team size, suggesting that teams larger than 10 people become difficult to manage effectively. Justin and Matt argue that team dynamics, including the experience levels of team members and the distribution of leadership responsibilities, play a crucial role in determining the optimal team size. They emphasize the importance of having a blend of senior and junior members for long-term sustainability and organizational growth. The idea of "seed corn" is introduced, highlighting the importance of nurturing junior members to eventually fill senior roles.

The panel also touches on the downsides of excessively moving team members around, which can harm team cohesion, yet acknowledges the benefits of cross-training and preventing silos from forming. Will and Dave provide examples of how large teams can succeed with strong leadership and effective management, but caution that poor management can lead to inefficiency. The episode concludes with a discussion on how cross-team communication is one of the biggest challenges in scaling and maintaining effectiveness, with the panel agreeing that the sweet spot for team size lies between 6 to 10 members.

Transcript:

 MIKE: Hello, and welcome to another episode of the Acima Development Podcast. We have a great panel here today, a large group. We've got Matt, Eddy, Will, Ramses, Justin, Dave, and Kyle all here with us. We're going to talk about team sizes. There’s kind of a carryover from a couple of weeks ago. We talked about other items of scale. But we're going to talk about team sizes.

I'm going to start by talking about the movie, “Honey, I Shrunk the Kids.” People of a certain generation watched that movie [laughs], and it's not the only one like it. You know, there's a history of movies where people shrink. There's Marvel movies, you know, people go really small and really big. And, in those movies, generally, all the laws of physics are basically exactly the same as they are when you're larger and people are smaller, and that's it [laughs]. Everything works exactly the same.

One thing that kind of blew my mind when I ran into it is not even remotely true. And you can see it by looking at ants. Like, in that movie, the ants are big, and everything's fine. All the physics work totally normal. If you look at an actual ant, when they get hit by water, it is fundamentally different than what we experience water as, as humans. Because even just at that difference of scale, water is like glue. If you look at an ant when it gets in water, it is like, you know, it touches that drop of water, that ant is stuck, and it is a huge effort to get extricated, you know, it's like running into a giant pile of tar. Because you go down in scale, it fundamentally changes the nature of physics.

You know, you can see an ant. It's very visible that, even at that scale, our physics are different. Water does not behave in the same way at all as it behaves for something larger scale. It's just different. And, you know, and you look at a microscope. It gets even crazier. I mean, you can see in a microscope with a Brownian motion, where you get small enough, and you see things just kind of randomly moving around because of quantum-type effects. And you have molecules bouncing around; stuff is just going to generally float in a way that we just don't experience at our scale.

And it breaks our intuition because our intuition is built on the scale that we normally work with. But even something you can see, and you can look at an ant, it's different. The physics are totally different for something as simple as water, you know, droplets of water, when you go down to that size. I say this is relevant because there's a lot of things like that, where scale changes things.

We're going to talk about team size today. And I'd argue pretty strongly that you can't just take a team of two people and manage it the same way when you've got 100 people [laughter], and maybe you can try. I hear laughter [chuckles]. It's different when you scale up in size. I had this conversation recently, thinking about different company sizes. If you've got an engineering team of 1000, the way that you can run that is totally different than even at 100, you know, you go a factor of 10, and that's very different. Then you take 100 versus 10 it's totally different. If you've got 10 people in your department and you lose somebody, that is a critical loss [laughs].

If you've got a team of 1000, well, you're probably losing somebody every week, and that's probably fine because you've got your systems built up to handle that. Now, on individual teams, we have a variety of team sizes, you know, beyond just department sizes, and those scales matter. This [inaudible 03:47] in a lot of ways. So, I've been talking for a bit talking about how scale matters to kind of launch the conversation. Based on that, I'm going to ask the pointed question that prompts the debate. I mean, how big should a team size be, knowing that different scales matter?

WILL: I would first ask the question of like...And I don't think this is a singular answer, but what is the role of a team in your organization? Why a team? Like, what's the role that the team is organized around doing stuff? It's a functional group, right? Sometimes people have sort of like, okay, this is a functional group, like, this is my DevOps team, and it serves this function. Sometimes it's sort of like a...I call it an administrative unit, where it's like we have interfaces with the bureaucracy, either through product, you know, leadership, or just sort of administrative management stuff. Sometimes they're areas of specialization within the codebase. They could all be different things. So, how big it is is maybe directly dependent on that.

So, let's say you have...DevOps, I think, is a good example. So, if you have a small DevOps team, maybe you only have two, you know, DevOps engineers. Then the right size is two, you know? If you have maybe six DevOps engineers, where, like, does two teams of three really make sense? Maybe it doesn't. And so, then you'd have a team of six, which could be a little heavy for a software development team, right? A team of six engineers is starting to get kind of big. And so, the size of it is definitely going to be informed by the functions of the team.

MATT: Yeah, I think there's some questions that you have to ask yourself. How big is the application they're going to be supporting? Are they supporting multiple applications or services? Can those things be broken into domains? Do we have teams that support specific domains, or do they just umbrella and support everything? I think if you can answer some of those questions, it makes it a lot easier to determine what that team size should look like.

JUSTIN: I would suggest that there's a maximum team size that exists that you don't want to go larger than X, no matter what application you're supporting. Because it suddenly becomes a case of people don't know what other people are working on. It becomes hard to coordinate. There's not interconnectedness. All the manager is doing is managing people and losing technical insights. So, yeah, I think there may be an upper limit there that you can't cross.

MATT: Totally agree. Another thing that you need to think about is, are we talking team size from an HR management perspective so for, like, an engineering manager, or are we talking about teams from a team lead perspective? Because you may have 10 engineers that are technically part of the same team but broken into, say, sub-teams because we have a lead to support those engineers, right? So, they can work on different things, have a different person leading projects instead of the manager trying to lead all of them at the same time on multiple projects.

WILL: Justin, I saw your face, Justin. You're like, no, no, no. No, that's two different teams. You just got two different teams in the same bucket, you know what I mean? It's like a duplex. We don't live together. We just live in the same building, you know [laughter].

MATT: So, semantics are important.

WILL: But I am really interested in sort of what Justin brought up, which is like, okay, you're right; there's a ceiling for team size. Is it determined by a bunch of really specific things, right? You can't say, like, “No more than 10,” although that's a pretty good limit, you know [laughter]?

JUSTIN: I agree.

WILL: But how do I know, like, okay, like, you got to split it up; you got to split the team up; this is not working anymore? And then, like, more of, like, things that you'll see happening rather than, you know, a number.

MATT: Yeah, what if...let's say six people is this example team size. What if all six of those people are all subject matter experts and senior-level people versus a team of six people that has one subject matter expert and senior-level person and five entry-level or junior-level engineers? I think then that changes things. That dynamic is different.

WILL: Well, you may actually just want to spread them around [laughs].

JUSTIN: Yeah, exactly. That's not using your resources correctly.

MATT: Well, it may be the case that those are the only resources we have. So, do you keep them together, or do you split it into two teams of three and have a junior engineer as your lead for one of those teams? I mean, those are the kind of questions we need to think about.

JUSTIN: I think maybe a better way to look at this is like, what ingredients do you need in a team? You need probably at least one senior person or a tech lead. What else do you need?

EDDY: You need a junior on your team [laughter].

WILL: Maybe. Maybe.

MIKE: Yes, you do. I made this argument emphatically sometime in the last week or two. If you don't have a junior developer, what I said is that you're eating your seed corn. Because if you don't have somebody growing in experience to become the next subject matter expert, then your senior engineers, when they move on, leave a hole that you are not going to be able to fill. I think you absolutely need, if not a junior, you know, somebody who is learning the ropes and growing into that position.

DAVE: It's almost like a long-term, short-term sustainability, right? Because I mean, you can have a small, tightly focused tiger team that goes in, takes care of the business, and gets out, but that's not a long-term sustainable...right? That's like a task function. And you don't need a junior for that. That's fine. You can have an operating theater full of brain surgeons, but if you want long-term sustainability, you need to view...

I think we talked about this a long time ago, Mike, that when you give a programmer a problem, we don't take problem in and solution out. You actually take a problem and a programmer in, and what you get out is a solution and a smarter programmer. And if you start viewing it that way, as, you know, you are part of the output of this unit, you do, you need new people to step up because someday you're going to be gone, and that team will be gone if you weren't eating your seed corn, yeah.

MATT: Teach a man to fish, give a man a fish, right?

DAVE: Yeah, light a man on fire, you keep him warm for the rest of his life, yeah [laughter].

WILL: You know, I don't know; I mean, on one hand, I get what you're saying. But, I mean, one of my persistently more controversial software management beliefs is that we should be moving people around a lot more. So, this sort of like, you know what I mean, this thing you said where it's like, it's bad to have task-oriented teams. Like, I love task-oriented teams. I love getting together a team to do the thing, and then they go away. Dude, I like it because by enforcing that sort of procedural process discipline, you don't let people put together the little fiefdoms, and you don't let people evade accountability for corners that they may have cut, you know what I mean?

Like, you make sure that people are cross-trained around stuff, and you can have little domain expertise areas of stuff that's going on there. But I find that one of the real sort of long-term rots that gets into a software engineering organization is people get into their little...they carve out a comfortable little niche, and then they just sort of sit there. And they don't necessarily, I don't know, I hate to use the word rot, but there's definitely a lower level of operational intensity once you really have your little flow within the organization.

MIKE: They talk a lot about silos. They talk a lot about silos, right? And you know what a silo is for? Sometimes people think, who are unfamiliar with farming, that a silo is for storing grain, and that's not true. A silo is for storing wet grain so that it will rot. The purpose of it is to ferment it because that's a different way of preserving it.

DAVE: Oh wow.

MIKE: So, you take, like, green corn, and you throw the whole thing in, or you maybe throw your corn in there. But yeah, silo is different from a grain elevator. A grain elevator to keep dry. A silo is for keeping wet so that it will ferment so you can feed that fermented food to the animals.

DAVE: I didn’t know that.

MIKE: And [laughs] it's a great image because once you build a silo, it's going to ferment [chuckles]. And we talk about silos a lot. I don't know that we always think about the implications of that, that when you silo something off, that's going to start to go rotten by design.

[laughter]

DAVE: Can I offer a counterargument to both of those ideas, though? I agree with both of what you said, 100%, but it's not something to be taken completely without a qualification. There's a...oh, I'm blanking on the author. There's a book called “The One Thing You Need to Know.” And it's a book on basically what makes people happy at work. And, basically, they interviewed a bunch of people and say, “How happy are you at work and how are...?” And then, they started looking for clusters of things that were true, you know, random things that happened to be true about these people.

And the number one non-trackable business, there's no KPR spreadsheet for this, the happiest people all had a best friend at work, which I thought was really, really interesting. And I'm a naturally gregarious, very loud person. And when I read that, I'm like, I need to double down and start making actual friends at work, and I did that. When I was at CoverMyMeds, I did this. And they had a transition. They got acquired, and they brought in some senior management whose job was just to fluff the grain and just screw everybody up just to prove that we'd been acquired.

And we had a manager who the very first thing he wanted to do was separate everyone, so he just took all the teams and just sliced them up. So, you were on teams with complete strangers. And I think he had the idea of cross-pollinating, right? But if you take, and I'm going to mix my metaphors badly, if you take your sourdough starter and you spread it so thin that you kill the culture, it's not sourdough anymore. You haven't spread the culture or homogenized it. You've just wrecked it and ruined it.

And it broke me because I went to the next team we were on. I started forming friendships. We got really, really close. And they did it again. And the third time through, I'm like, I think you guys are actively trying to demoralize us. Because they were cutting us off, like, every three months. There was no chance to form any kind of a personal relationship with people. So, I suggest that as a counterpoint. I 100% agree that the professional objectives, absolutely, they should be changed, or you get bored.

MIKE: So, I talked about the silos because that's what silos do, but I actually was going to push back some as well. Have any of you read “Team Topologies?” I'm seeing a couple of nods here. It's a book worth reading. One of the things it says is that teams become more effective over time because it takes a while to learn to work with each other.

So, there's two kind of competing principles here. One of them is that if you’re isolated from everybody else, you tend to become very insular, and stale, stagnant, right? The other is that teams that have worked together know how each other work, and they're just going to work better. In general, a long-running team is a more effective team. And so, an effective approach needs to somehow combine those.

The idea of sub-teams got brought up. I don't know that sub-teams...they may just be separate teams. But one thing that can happen is, on a team, you can have rotating assignments, such that you still have a...you have a persistent team that takes on different kinds of work, and you may have different groupings within that team also. But you still have strong cohesion because you have your group of six, or whatever it is. You know each other, [inaudible 16:49] each other really well.

You may be grouped together on different projects, and you may be bringing in projects that are very different than the ones you did. Having a team work on different projects can help break the silos without necessarily disrupting the team for no reason. And I think that disrupting a team just to reorganize is a really bad idea.

WILL: You know what? Any virtue taken in excess is vice, right? You can screw it up in both directions, right? But, like, persistently, what I would say, like, the cancer eating away at software organizations, there's two things, cross-collaboration among engineering teams and organizations is just a bag of hurt. It's sucked everywhere, and some people suck more; some people suck less. But it is the number one bogeyman of everybody, everywhere, all the time, forever. Like, I've never seen an exception to this, and second only to crappy managers.

And those are two things that must be hunted down and eliminated constantly and mercilessly. And it's just sort of like, if you're not stirring the pot, those two things are going to creep in. It's a constant bailing out of water to keep those two things from sinking you. It's inevitable, you know; you have to have an answer to it.

And I think moving people around, you know what I mean, like, I agree, you can do it too much. But moving people around has a lot of really strong positive effects in letting your organization thrive, you know what I mean? It's like, oh man, this manager is always getting it done. But like, oh man, everybody hates working with this guy. Like, oh man, this junior engineer is really good. We don't have a senior seat for him, but like, man, he's really ready to go, ready to move up.

Or, like, oh man, this senior engineer has kind of lost the plot. And they're smart, but they're just not working well with people. Like, all of these things are stories that I'm sure a name popped up into each and every one of you guys’ heads as I was saying each and every one of these things. And if you're stirring the pot, if you're rotating through, if you're giving people opportunities to do good or to do bad, then that kind of stuff is going to surface itself, and you could do something about it.

MIKE: Do you know all of these people, that is --

WILL: Every last one of them. Every last one of them.

MIKE: My question is, do you personally know these people within the broader organization today? And if so, that means that you're not talking about moving somebody somewhere where they don't know anybody. You're talking about a subunit of the company that's cohesive enough that you actually know all these people.

WILL: It would be stupid to just drop somebody, just airdrop somebody in by a parachute in some situation where they could do no...you know what I mean? I mean, I'm not dumb. I understand that you can't just be like, “Hey, you're doing Haskell today.” Like, yeah, yeah [laughter], you're DevOps this quarter. Get to work.” You know [chuckles], that's not how it works.

DAVE: I've seen it work, and I've also seen it fail spectacularly, where we had a system recently where we swapped an engineer out to help another team. And that other team's process was very, very different, and it was very rigid. And they were under the gun. They could not stop and say, “We need you to do this, do this. Everything you're doing, we need you to do it sideways because we will do layer cake instead of,” whatever, that kind of thing. At the same time --

WILL: Oh, you have a bad manager. What a wonderful thing to know about.

DAVE: Right? And I understood, like, why. Like, all the intentions were good, right? It's like we had a problem. We need to throw more bodies at it, right? Conversely, when I was at CMM, and they were still a unicorn, we came up with a thing that...I called it hostage exchange program, where we would go to your team and say, “Give us a developer. We'll give you one. You give us one.”

And so, we would swap with another team, like, all the way across the building, completely different project, different vertical of the company, different profit centers. And we would swap out one person for two weeks. And very importantly, it was seed corn. It was, we're here to cross-pollinate you, to make friends, and show you how we work. We are not here to sweat you and try to get you to scream everything over the line. Because when you go to a new thing, you're going to be useless, right? But after the exchange, because we had one of yours, you had one of ours.

And then when you swap back, this amazing thing happens because it's like, “Oh, man, we need to cycle the pods on the Jenkins thing. And how are we going to do that?” I don't know. That team doesn't like to talk to us. And the one guy who was in hostage exchange goes, “Oh, hang on. I'll just ask Justin,” right? And all of a sudden, there's a personal relationship formed. And that was like, if you forgot everything you learned while you were on that team and you just remembered who you met, it's a victory, hands down.

WILL: Exactly. No, absolutely.

EDDY: Or better yet, Dave, you can just be like, “Oh, I've done that before. Let me go [laughs] and do it.”

DAVE: Yeah, yeah, hands down. Mike, we were talking about this on the team the day we had a deploy issue. And we have this really convenient, for those people listening out there, we have a really convenient way of deploying. There's a little thing that we click, and we get a notification that says, “If you want to deploy this, click here to deploy it,” and it's great. And you don't have to go into Jenkins and fiddle with the drop boxes and find your image and all that stuff. And I kind of forgot how to do it manually.

And so, we had an incident last week where we were like, you need to roll this back. And it wasn't me, thank goodness. But I'm just kind of on the sideline eating popcorn going, you know, if that had been me, I would have been stuck because I have forgotten how to do it the hard way. And I’m like, we need to get the team together, and we need to review how to do it the hard way. So, like you said, so if something happens, you don't have to call somebody who knows how to do it. Just, like, everyone is just like, “Oh, wait a minute, I know this.” And if you've got a process to document, you're like, I know where to look for it in the wiki, and then all my notes will be there, and yeah.

WILL: Absolutely. At the large retailer that I work for, you know, they have an unofficial tradition, 52 [inaudible 23:14] pickup, Q1 of every year, where they just, like, completely demolish the org chart, and it's anarchy. And I don't think they do it on any kind of, like, high-minded management, you know, theory principles. They just do it.

But one of the nice things, like, having been here for a couple of years and gone through several purges, is I've got people all over the company. Anything I need done, like, I've got a person. I’m like, oh, I'll take Dave, or I'll take Reed, or I'll take Max, or I'll take whoever. And I have somebody to ask to get a thing done, and it makes me really effective.

DAVE: There are people in your organization who will try to shut that down, thinking they're doing a good thing because once a team starts...like, when IT starts getting overloaded, they start saying, “We need everyone to fill out a ticket on Jira because we can't manage our workload,” right? And if you know somebody and you pick up and you...I'm just going to call Corey. He'll take care of this for me. And, like, Corey has to say, “I need you to fill out a ticket, man.” But you don't have to kill either of those, right? You can still do the, “Hey, I need this,” and your friend in IT can go, “Oh yeah, just check the PRAM, just reboot it, do the thing, you know.” “Oh yeah, I remember that.”

And then if it's going to be more, it's like, you know what? You're right. That's serious. Fill out a ticket, and I'll jump on it. So, you can still get the best of both worlds, but you can have people that are simple-minded of, like, just do it this way. And like you said, a virtue taken to an extreme can turn into a vice.

MIKE: So, we've talked a lot about swapping people around and getting them into different experiences. And I heard a couple of numbers thrown out. Somebody said 10. Oh, you shouldn't have more than 10. Somebody said 6. There may not be a clear line there. But what is that number X? And maybe, more importantly, why is there a maximum team size? Why does it stop working?

DAVE: In the pre-call, Mike, you posted a link to Dunbar's number on the wiki. Real quickly, for people listening, the size of the frontal cortex of a primate's brain determines how many meaningful relationships that primate can have at any one time in their life, and, for humans, it's about 150. I wanted to throw that one out there because I recently learned of another one called optimal tribe or optimal primal group...I don't know if it has a clear name, but the way they calculate it is fantastic. Anthropologists have determined that when you have this tribe of, like, 150 people, you're spread out over the valley, and you actually have subgroups within it.

You might be in a group of, like, 500 people, but you're spread out over about...150 of those are your relationships. But the people that you rub shoulders with every single day of your life is more like 30 to 35. And this number self-balances because among humans, somewhere between 30 and 35, the murder rate balances the birth rate. I love that number, that it's, literally, I will kill you if you add one more person to this team is how we dealt with this 10,000 years ago, and I think that's fantastic. I think it's brilliant.

[laughter]

JUSTIN: So, I don't want to be on David's team [laughter].

DAVE: Yeah, because we've got 34 right now.

WILL: I don't think we're going to see deaths necessarily.

DAVE: No, no, no, not where you can see ‘em.

MIKE: [laughs]

WILL: I think what you do see is you run into the bureaucracy associated with creating and processing and assigning work, you know what I mean, like, breaks down. That's what happens. You can't effectively utilize your people because you have this sort of, like, feast or famine, these wild swings and the amount of work you've got to do. Like, I'm getting ready. I'm warming up for a giant work hangover next week because we've got a big thing we're shipping out.

And all of our leadership management capacity has been dedicated to getting this thing over the line. And it's a big fella, so I forgive them. But we're going to have a giant night hangover, where there's just nothing in the pipeline, and then they're like, “Oh, uh, do this.” So, that's where you break down, like, the ability to assign and manage and, like, hey, provide feedback. All that stuff it breaks down. You just can't [inaudible 27:44]

JUSTIN: So, can you have a larger team if you have people helping lead it? And by this I mean you have project managers who are tracking the projects that are out there. You have your tech lead. You have your engineering manager. So, how does that all fit together? And then, you actually have the people doing the work of which, hopefully, your tech lead is one. And then, you got the other, you know, senior, regular, and junior engineers.

WILL: I think there's a finite amount of leadership and, like, I don't know, man. I mean, sometimes that's the project managers. Sometimes that's them but not all that often.

MIKE: If you have really good leadership of the kind you describe in sufficient quantity, I think you can push above maybe that 10 limit. Maybe you can get close to 15, pushing 20, but it is continuous work. And those leaders are going to be just incredibly busy. I mean, that's going to take a finely oiled machine, and it's really hard to replicate. They talk about this in “Team Topologies,” yeah, you can maybe go over 10. And you might be able to pull it off for a while, but if anything goes wrong, the whole thing falls apart.

JUSTIN: Wasn't it the two-pizza rule? You can only have a team that you can use two pizzas to feed. That’s your team limit.

DAVE: That's right. So, 200 people if we really sweat them and give them the [inaudible 29:11]

EDDY: What if I eat a whole pizza, Justin? Like that’s -- [laughs]

DAVE: Then the other nine people split the other one, yeah [laughter].

MIKE: When I was in high school, I was running cross country and growing like a weed. I could down two extra-large pizzas myself [laughs].

DAVE: I grew up in Ranch Country, and there was a phrase that people would say that, “I have teenage boys. I'd rather clothe them than feed them [laughter] because it's cheaper.” So, the number with the group size, the thing that they found out of this was...because humans, we've obviously gone past the point where we can be around 35 people without committing a murder. And they see anthropologically, in the records from about 15 to 10,000 years ago, three things started happening. We started dancing. We started singing, and we started worshiping together as groups.

And what this does is it gives you the ability to walk into a room and meet a stranger, you know, stranger danger, we're afraid. Like, you know, primates, we're just like, [vocalization], you know, do I need to worry about you? But we've got this thing that we're all looking at, and I’m like, oh, wait a minute, we're all here to worship at the same time. Or here, we're all here to sing and dance and experience this pleasant experience in a safe environment. I can call you my tribe. I can call you my friend. And from there, we then get scaled all the way up to, you know, patriotism for a country.

I used to hate, hate with a passion, town hall meetings where the CEO comes down and tells you about the corporate vision. And now I realize it's absolutely essential. You can have 25 people on a team if you all are looking...like, the interpersonal team communication is going to go exponential, right? It's a triangle number like n times n plus 1 divided by 2, something like that.

The links between the number of nodes goes up exponentially, and that will fry and become exponentially difficult to manage. But for a short time, you can exceed that number if all of you are looking in the same direction, if you're trying to pursue, you know, common gods, common goals, common enemies, that sort of thing. You're like, okay, yeah, I can pick up and pull in the traces next to you without knowing your life story.

WILL: You must be going to different town hall meetings than I am.

MIKE: [laughs]

DAVE: I am a different person in town hall meetings than I was two years ago. And I would say I'm going to different town hall meetings than I was two years ago. And, yes, I've been at Acima for more than two years. So, what I'm saying is I have changed, and the experience of the meetings is different now, yeah.

WILL: I actually see most of the corporate town hall meetings that I have witnessed are actually like a case study in, like, this isn't working anymore. This is no longer anything. Because my experience with the meetings has been, typically, that we're not on the same team, like, anymore, like, the C-level executive that I'm meeting and me as like a, you know, a skilled worker, certainly, and somebody who's like, you know, I punch above my weight in terms of impact. But we can't have an honest conversation. They're not doing that with me anymore.

I am a resource to be managed and not really dealt with forthrightly. It's too big. We're too far away. Our interests have also rather sharply diverged. And so, there's a lot of, like, I don't know, man. They're lying, and they know they're lying. I know they're lying. We're all sort of like going through this theatrical display, you know what I mean?

DAVE: 100%. 100%.

WILL: I'm just like, all right, guys. We're not that. We're not that. We're not on the same tribe anymore. Don't put my face in it, okay? Like, I could listen to the investor call if I want to know what you're doing to justify your share price. If we need to do that, that's okay.

DAVE: The corollary that I take from that is that there's times when I sit in church, and I'm like, we are all here to do the same thing. And then, there's times when I remember a...my dad had nothing to do with church or religion for most of his life. And it was because he would sit, and his experience was, you'll shake my hand on Sunday and stab me in the back on Monday.

And if you've ever had that experience of sitting in church-going, you SOBs are all miserable jerks, and not one of you believes in what we're doing, that's a horrible town hall to be in, right? It's like, oh, yeah, yeah, you're not trying to incentivize us. You're trying to sucker us into doing work now in exchange for a promise for something you're never going to deliver, right? When there's no faith in that, it's brutal, right? It's the opposite of it.

WILL: Well, I mean, I don't have a problem with working for Corporate America. It's fine. I'm not some guy who's [inaudible 34:02] is communist, you know what I mean? Let's all get paid. Let's all make really cool stuff for our customers and delight them. And then, they will give, you know, us some of our money, and then I will get my piece of that. You'll get your piece of that. We're all going to be good. But that's not a forthright conversation that we're having.

DAVE: No, it's not.

WILL: It's like big meetings, right? Big meetings, big companies. Like, it just gets so big that you're not really...the gap's too wide.

MIKE: Well, we're talking, I mean, this is germane to the conversation because we're talking about ways to maintain group cohesion. And you're saying, as you get large, you get to town hall size, it is really hard, that getting everybody on the same page and making them happy about it may just utterly fail. So, if those tactics are challenging with a large group, it says something about the team size, right? And if you look at hierarchy of organizations, there usually is a hierarchy.

WILL: Sure.

MIKE: And at any level of the hierarchy, you have, you know, probably that six to, you know, 12 or something people at that level so that everybody is within a similarly sized team because it's really hard. It's really, really hard when you try to scale that up.

JUSTIN: So, going back to your talk, I mean, your chat about, you know, getting everybody aligned in the same direction, I can't help but think about the example of Twitter, X. And say what you will about Elon Musk. He forced his way to everybody be in the same direction, and I am very curious to know what impact that had on their team sizes. Because I'm like [laughs], did they...

EDDY: Correct me if I'm wrong; it might be inflated, but I think over half of the team left when he forced his way.

JUSTIN: I think so.

WILL: 70%, yeah.

EDDY: It was quite significant.

JUSTIN: And so, do they have smaller teams, or do they have larger teams with fewer managers? I bet that's what happened. My theory is that Musk got rid of most of the middle management, and they have the engineers left who are interested in working for Musk and are probably well-compensated as well.

WILL: [laughs]

JUSTIN: And so, they're all aligned somehow. But, I don't know, that is going to be an interesting case study in some future, you know, business school or engineering school.

WILL: I’d imagine you're right. I’d bet you any sum of money the team sizes are larger. And I think probably you got a lot of people on a visa who aren't empowered to just go anywhere. And I think they're probably making less money and working harder, and maybe just didn't have the option to hop over to Amazon, or Microsoft, or Google, or whatever. We'll see. We'll see.

I think there are a lot of people who are leveraging tech winter right now. And whether that remains to be a sustainable management practice or not is going to be told, you know, when tech starts to boom again because nobody got off their phones, man.

MIKE: [laughs]

WILL: And then, the market for talent becomes a little more competitive. I think there's a lot of people who, you know, it's your way in this, like, rather sharp and prolonged economic downturn for our slice of the economy but long term, I don't know, man. I don't know. Is it good management? We'll see, you know. Sorry, that's a little bit of a tangent, I think.

MIKE: Yeah, no, it still comes down to, you know, how do you work with the group? How do you keep the group cohesive, and the challenges with that? So, is 10 a reasonable cap? Like, if you got a team bigger than ten, you better look at cutting it?

JUSTIN: I don't think I've ever been on a team that large. I think the most I've been on is...well, I guess it depends on how you define it because I've been on front-end teams where we have the product owner and then the designer. And then, I was a full-stack engineer, so I helped the frontend and the backend, and the database [laughs], but there were also people on each of those. And so, I guess we were, you know, if you include the designer and maybe a database guy, I don't know, it's like, you know, hey, we're together for a project. But I don't think it ever got up to 10 in our standups. I think the max number of people in our standup was, like, seven or eight.

DAVE: I'm hesitant to say a number. I worked at Evans & Sutherland around the turn of the millennium, and I was on a team of 50, 25 software engineers, 25 hardware engineers. Basically, we'd come up with the same idea that NVIDIA had, that you could do 3D in hardware and do it very, very fast. You could do stuff in real time that couldn't be done at that point, and, it worked really, really well.

The 25 people, the status meetings got [inaudible 39:00], but those went on and on and on and on, right? It took forever to get through the status stuff. And, yeah, subdivided, and, like, I was literally...my sub-team was in the middle of a cube farm, but, like, my job was 2D-bit blit block image transfer. My job was to move rectangles from one place in memory to another. And there was somebody else whose job was to handle 3D and somebody's for curves. Literally, we had a triangle team, like, literally. But at 25 people, it functioned.

But what I will also say is I was on version 3. They had built the entire graphics card for real image 1, real image 2. I was on the Real Image 3,000 team for making version 3. And we also did largely waterfall because there was hardware coming through the pipe that had to be anticipated 18 months in advance. And the rule for waterfall is don't do it unless you've built the exact same thing twice before, which they had. And so, there were a lot of stuff that, you know, that had happened in that.

WILL: Right now, like, my daily standup has 18 people in it.

DAVE: How long are your stand-up meetings?

WILL: 30 minutes.

DAVE: 30 minutes? That's a status meeting, yeah.

WILL: Eh, it's okay. Thirty minutes is fine. They're pretty efficient. They tend to go over fairly regularly, but not because of the status meeting being bad, just because we're just getting ready for a big release, so there's a lot of nuts and bolts to make sure everything goes right.

And I would say that the team is functional. And it is really kind of one team, but there's a manager, and then there's sort of an assistant manager. And there are some, you know, pretty senior, you know, sort of shadow management. Like, we have at least three people that could and do act as managers, like de facto managers. And so, it's big, and it works. And it works as, like, a single team, but there's a lot. It isn't just a guy. There's a lot of support.

MIKE: So, proof. There's an example case of all the support you can push up close to 20 and make it work.

DAVE: For a while.

WILL: But there's like, well, yeah, but there's also at least three people who are acting, like, two named and one unnamed people who are doing that job. And if you took any one of them out, the whole system would collapse. And so, you think like, oh, we've got 18 people on one team. But it's like, yeah, but you've got three managers, so that's, like, three six-person teams kind of in one thing. It would be hard to make that a sustainable thing other than just sort of a special case where it's like, if you have the right mix of people, you can make it go.

DAVE: There's something going on right now where I live and work. And, Eddy, I think, Eddy, you're in Michael's team, right? I think I see you in the standups. Maybe not. I'm on a team of 28. Well, I'm on 4 teams that total 28 people. And shout out to Michael McMullin. I don't know what he's done behind the scenes, but our standups are three minutes long. Like, I'm not kidding. Like, we walk in --

WILL: Three minutes long?

DAVE: Yeah, literally just long enough to...is everybody here? Does anybody have any blockers? And, like, we don't even do the here's what I'm working on, and here's what I need to. And part of that is because we have a channel for that. Mike, you'll be happy to hear this. I have made some impassioned pleas against using a Slack channel for standups. And there's times when that has been completely opaque to me. And when I first started, it was very transparent what everybody was working on, and it's back to that.

I'm back to being able to see what everybody is doing, and because of that, I walk into the meeting prepared to leave the meeting. It's like I kind of know where everybody's at, and we walk in, and then one person will go, “Actually, I’ve got...” and they’ll raise a blocker, and then we'll talk about the blocker for five minutes. I think the longest a meeting has gone is, like, 12 minutes.

I don't know if Michael has a gypsy woman prisoner in his basement, and she's just forced to hex everybody else and not him. I don't know how he's doing it, but it's amazing. It's very exciting to watch. I love it when something miraculous can happen and I'm like, how does that work? Like, I genuinely don't know. But it works --

WILL: I mean, I think it’s working by, like, not doing. I haven't been to the meeting. I can't speak to it. I won't do it. But like you said, like, oh, it's a three-minute meeting. I'm like, then why have the meeting?

DAVE: Well, because sometimes if there's...the reason it was three minutes was there were no blockers that day. Usually, the meeting is like 5, 10, 15, but not half an hour. Like, it’s scheduled for --

WILL: And how many people are in this meeting? How many people are on it?

DAVE: 28.

WILL: 28? Forget it. Like, get rid of the meeting. I’m sorry, like, you're not doing anything. And, I mean, it's great, like, I don't know, if you don't [inaudible 44:21]

DAVE: Hmm, I disagree.

WILL: With the daily standup, that’s valid. But why even have it? Why even have it? If you're not going to do it, then don't do it. Figure out another way, and that’s okay.

DAVE: We could stop having that meeting and see what breaks, and I kind of don't want to because, like I said, it's magic right now. And I genuinely don't understand it. There's a book that I highly recommend called “Read This Before Our Next Meeting.”

WILL: I have to say the only thing I’ve heard is good is, like, it’s very short. That's the only benefit that I've heard described. And I don’t know how the team runs --

DAVE: Okay. Okay. Hang on. Cool. Yeah, let me answer the question that you're really asking then, which is, what's going on? There's a book called “Read This Before Our Next Meeting,” where you basically say, “Everyone, this is the objective of the meeting. Come prepared to reach that objective,” and that's the difference. We're not wandering in going, who's doing what, and where are we? We're not looking for a status on anybody. Everybody knows everybody else's status. So, that part of the meeting doesn't need to happen. You're right, that part of the meeting doesn't happen.

But we do need to know if anybody's stuck, and we need to dogpile on something to save somebody from something. And if there's an issue, we dogpile on it, and we take care of it. And that's the point of that part of the stand up for us, yeah. So, the status part is being routed through another channel, and that's what saves us 27 minutes. Does that make sense?

WILL: I like to see people, man, like, I don't know. Like, that’s just me. I like to see people, and I like to look at their faces, and I like to look 'em in the eye and hear their voices and how things are going. And I get a lot out of that. And I don't think software engineering as a discipline is served by having more people typing into screens in isolation, generally speaking.

JUSTIN: So, Will, I think you bring up a good point, which is part of having a team is creating the culture that, you know, you want to engender within your company. And the act of meeting together and of interacting with each other is how you create that culture. Well, it's one of the aspects of creating that culture, right? Obviously, working with each other, time outside the meeting. But bringing it all in and kind of sharing a joke and doing, you know, interacting in some way, I think, is a great benefit to engendering a sense of teamwork, and so on. And so, that can be hard to do with a larger team. It's a lot easier to do with a smaller team; let me just put it that way.

WILL: I mean, if you have 28 people in a daily standup, like, I don't know how you could do it differently than Michael McMullin's doing it just because you just can't.

DAVE: You can't. It would turn into an hour-long status meeting. And to your point, though, we don't socialize. Well, we do. We all show up a couple of minutes early and then we get the water cooler stuff going on. And I don't count that as part of the official meeting, but I probably should because, yeah, there's some socialization that's essential. And it's good because it's cross-team because, like I said, there's 4 teams actually in there. And if you're going into this meeting expressly to socialize, and communicate status between people, and where are your projects, and that sort of thing, you're not going to get 28 people through in 3 minutes. Yeah, absolutely.

WILL: So, it's like 4 people in sort of a meeting. It's a four-person meeting. Well, I feel like 24 of those people don't need to be there. Like, 24 of those people are not supposed to be in that meeting.

DAVE: I'm hesitant to change the formula because it's working, and I don't know how [laughter].

WILL: You’re right. No, no, you're right. You’re right. Like, we agree, right? Like, don't do it, but at the same time, like, you've got four teams. You've got four managers who are supposed to be explicitly doing this job. And you have all these other people, what, holding their hand while they, you know what I mean?

DAVE: Yeah. See, we just came off of that. We just came off of a representational republic, and it was satan. It was the worst. The representative served as an information killer, as a communication deaddrop. And we had the team not knowing what the rest of the company was doing or why we were working on what we were doing. And our issue is we’re going up to this person and not going out...we finally started routing around them.

WILL: Oh, so you have a bad manager. What a wonderful thing to know about.

DAVE: That was said, not I, yeah. So...

WILL: Like, I don't even know who I'm dragging here, and I have no accountability whatsoever. But it sounds like somebody has a really important job, and they're blowing it.

DAVE: I won't say how recently before this team. I won't say how recently. I’ll just say that before I commit career suicide.

MIKE: Well [chuckles], you know, there's some aspects of this. We talked about some things to make a group meeting work, but still, you're talking about four teams, around seven, you know, six or seven. It just keeps on coming to that number. Yeah, you can get up to about six, and then that's it. So, you know, empirically [chuckles], this number keeps on returning [inaudible 49:18]

WILL: Okay, what's the smallest number? Let's go in the other direction. Wait, actually, no, hang on. We might not have time to get into this. But I am curious, like, where does the team no longer make sense? One person, you're not really a team, right?

DAVE: I mean, I have arguments with myself, but –-

WILL: Two people, why are you on your own team? Three people, have we seen a team, like, an effective functional unit with three people? It really becomes like, honestly, more, like, on an org chart level, like, does it make sense to give these people a manager, right? Are there enough workers for me to rationally advocate these people that are on manager? It's almost like can I justify the accounting line item, you know, more than anything else?

DAVE: I think it comes down to how much of your objective is explicit and static, where, an organization, you need a lot of that. You could have a team of two, just a partnership. And what direction do we want to go in? We don't need a lot of external, right? And now you can go after a goal, and that goal can change and adapt very, very quickly. If it's a much [inaudible 50:23] thing, then changing the goal is a lot more complicated. You've got to synchronize a lot more people.

WILL: I'm kind of curious to hear from Kyle. As DevOps, you guys are not necessarily always sort of as robustly staffed as, like, software engineers. What's the smallest DevOps team you've been on, like, one or two, two or three, one, just you by yourself? I feel like you feel that more than we necessarily would.

KYLE: Three was the smallest, and I thought that worked really well. Scaling up from that, there's quite a few DevOps tooling that you run into locking situations. So, I feel like you kind of start to develop sub-teams, which we kind of have as we've grown to 7, 10 people.

So, while I'm sitting here listening to you guys talk about all this, I'm just kind of thinking of team size, to me, I was thinking, well, the minimum and the maximum are kind of dependent on the pipe size, and it will depend on what pipe is coming in or what pipe’s coming out, so your work coming in, the channels that you have to get the work out. So, if you've got a build pipeline that backs up, maybe it's only six people, it makes sense. That 7th person is always just twiddling their thumbs because they're never ever actually able to deploy something, right?

Or, you know, maybe the pipe that's the smallest is the management pipe. The manager over here he can't manage 10 people. He can't manage he, she, it, can't manage eight people, right? Like, so, where's the pipe the smallest is kind of what I'm thinking of, just because I think of everything as systems and, you know, flow like that. I don't know if there is a magical number kind of like we brought up, and I'm wondering if it's more of that pipe situation, because, yeah, kind of like we've said, well, does it make sense to have a team of 1?

Well, if you've only got enough work for 1 person, it's a team of 1. That's your pipe. And, you know, if you don't have a manager, do you go past 3 people? Do you have, you know, the ability? Do you have the pipe to actually function as a team if you don't have somebody managing that fourth individual, or whatever you want to call it, to kind of scale that up [inaudible 52:44]?

DAVE: I think also it has to do with your organizational, like, you can have a team of 2 that aren't really a team because you're all just doing the same amount of work, right? The same kind of work. This is a weird quote out of nowhere, but General Schwarzkopf from Operation Desert Storm in 1991 said in the battles in Kuwait, they very quickly learned that the Kuwaitis were not capable of, how did he put it, they were not capable of putting together an attack above the brigade level. And that's very much a team organizational statement, right? And they were able to capitalize on that in that particular venue.

And I think about that in terms of team organization, right? Like, if you've just got 2 people, you don't have a brigade, right? And if you've got silos of 5-person teams in a 50-person team, you can't put together an attack above the brigade level, right? You're going to have that same problem.

MIKE: We could probably dig into cross-team communication, which is one of the most challenging things, if not the most, that we deal with. I think that came up...it was either in the pre-call or earlier because it is a huge challenge to deal with cross-team communication.

But I think that we've covered our topic pretty thoroughly. We've talked about some of these physics of scale, right? That once you get things bigger, the rules quit working, right? It quits applying. And that there's kind of a sweet spot, you know, the Goldilocks zone of somewhere around half of 10 [chuckles] that works really well and allows teams to collaborate well together.

DAVE: I like that our podcast is kind of a, well, here's the thing, and it's like, we're going talk about this, but there's all these adjacencies to it that affect and almost sometimes even govern, right? Because they become a dominant term.

MIKE: Well, we have to put maybe a pin in that one and come back to it later and talk about cross-team communication because, again, that is a challenge in [chuckles] our industry, probably not just in our industry, but universally crossing those boundaries without maybe literally killing each other [laughs] and making that work. But for here, we've kind of talked about the team size. Is there any final words people want to get out there before we end this?

WILL: I just want to apologize to all the managers that David threw under the bus.

[laughter]

DAVE: Yeah. They've got plenty of company under there. It's, yeah, it's...My mouth tastes like feet all the time, so... But --

EDDY: I would just make sure that you add a comment out loud to whoever edits and says, “Please leave my apology.” [laughter]

DAVE: Yes, please...so, I heard a great definition. The definition of a friend is somebody who listens to your BS, and then calls you on your BS, and then keeps listening to your BS. So, any time that you hear me dragging somebody, I swear to God, I'm not dragging them. Like, you'll know if I'm angry. And this is just me being happy, and sometimes stuff goes weird.

And yeah, I apologize if I'm dragging somebody inappropriately. I hope I dragged them appropriately; that's a very different thing. Because I'm going to go right back to listening to their BS because there's nobody that I want to get rid of, you know, so...some people I'd like to adjust. But I'm sure they'd like to see me pipe down and adjust as well. So, it's fair.

MIKE: [chuckles] Well, thank you, it's been a great discussion.

DAVE: Thank you…

MIKE: Until next time on the Acima Development Podcast.