The ideal team size is ONE

Teams? We don't need no stinkin' teams!

I would never want to belong to any club that would have me for a member.

(Groucho Marx via Woody Allen)

There’s a rumor that Gödel, upon hearing this joke, choked on his bratwurst. Then quietly, and shortly thereafter, published his first incompleteness theorem.

[Editor’s note: the author occasionally just makes shit up.]

Teams are pure overhead

To be clear, I’m talking about teams in tech work, not sports teams. Is this true for other kinds of teams? I have no idea, but maybe…

There is an enormous amount of talk out there about teams. Teams, teams, teams! Teams, we’re told, are the answer to everything.

Teams are the secret to fast, efficient, high quality delivery of value to the customer. Or so the story goes.

Homie ain’t buying it.

Show me the money

I’ve spent years working in enterprise on numerous teams and I’ve yet to find even one “high-performing” team. Unless by “high-performing” one means “creating tech debt at an astronomical rate”.

At one such organization, I was lucky enough to be on one of the higher performing teams, with four devs, three testers, a BA, and someone else whose job description I never managed to understand.

I won’t guess as to my own capability, but of the other three devs, one was quite good, one was mediocre, and one was worthless. One tester was quite good and the other two were pretty mediocre. As for the remaining team members, the best I can say is that they mostly stayed out of the way.

In order to keep this rather large team functioning, we spent probably 30+ percent of our time dealing with “process”. By this I mean standups, huddles, retros, refining sessions, post-mortems, and general socializing/fucking off. Probably closer to 50%.

We used feature branches and pull requests with required code reviews, which further degraded our effectiveness. My guess? Our efficiency was probably no better than 20%. I’d even go so far as to say that if we’d cloned our best dev, the two of them working alone could have produced more and better output than the whole team.

And we were one of the higher performing teams.

Trivial pursuits

We worked, as was popular then, in a large, open-plan office where we were all expected to sit together. Working from home was tolerated occasionally, but frowned upon. We were one big happy team. Pre-pandemic, of course.

This meant that all around us there were other teams. I never found this proximity to be anything other than a continual distraction.

Immediately next to us was a boisterous team who seemed to do nothing but play games and pull pranks on each other. Every day they would do the daily trivia contest in the paper. Loudly. I found them incredibly rude and obnoxious. And I wondered, do they ever actually do any work?

So I couldn’t help but laugh one day when their BA came in late (early afternoon, in fact) to find them essentially having a frat party (minus the kegs). Clearly very annoyed, she asked in a loud voice, “Has any of you actually done any work at all today?” The team looked chagrinned and remained silent.

And that was when I realized that my suspicion had been correct. It was not that they somehow managed to appear to be goofing off while getting great work done: they were goofing off. And getting paid pretty much the same pay I was getting.

Enter the Wu-Tang

Most places I’ve worked, teams have been permitted to choose their own names. Bad puns abound.

One large enterprise at which I worked sent me to work with the “Wu-Tang Clan” team. I shit you not. And the irony of it was that the team had been given that name by a BA and not one other member of the team (except me) even knew who the Wu-Tang Clan were. Or cared.

As we were also expected to pick “avatars” (good lord, why?), I chose for my own the Ol’ Dirty Bastard, the humor of which was utterly lost on my fellow teammates despite my having two decades on the next closest member. Maybe I should have chosen Method Man. Things didn’t end well for the ODB.

The real Wu-Tang Clan

But the real questions is, who chose these teams anyway? And why?

More often than not, the division into teams had to do with arbitrary “boundaries” in the software or hardware on which they were assigned to work. Often, this meant that there were separate teams for front-end apps, back-end apps, cloud infrastructure, etc. Or for individual features within those apps.

Coordination within each team was poor; coordination between teams was nearly non-existent. So you can imagine what a great idea it was to have your front-end work, for example, depend on changes to an API handled by a completely different team.

I still remember one occasion where my team requested a new endpoint from an API team and were simply told, no. We ended up having to do a substantial rewrite to fit how they thought that our API interface should work.

Frankly, I lost track of the number of times we were blocked, sometimes for days or even weeks, because we were waiting for another team to get around to our priorities instead of their own.

And don’t even get me started on how often we finished a complex component only to have it blocked from deployment for weeks or months by the lawyers who were in another city. You might think that getting legal approval was something you’d do before you began work, but you’d be wrong.

In one instance — a real eye-opener for me — I built a feature in a few hours, then was told that I should have taken at least three days to do it. I was going too quickly, it seems, and would make the rest of the team look bad. Then my feature was held back for legal approval.

When that approval came — more than six months later — I was so long gone from that team that I couldn’t even remember what I’d built. I am fairly certain that they simply tossed my code in the shitcan and built the feature again from scratch, taking at least three days, no doubt.

I can’t really blame many of the devs, testers, etc. who did essentially nothing all day. I suspect that most started out wanting to do good work, but were so utterly stymied by the dysfunctional structure of the business that they finally just gave up and spent their days doing as little as possible.

You might think that I was just unlucky, but this company had a great reputation. And the same problems existed at every enterprise with which I’ve worked. No exceptions.

Forcing square pegs into round holes

Part of the problem with the “team” approach is that the enterprise believes that everyone has to be on a team, even if it makes no sense at all. Why?

In one organization I worked with, I spent more than a year on a greenfield project for which I was the primary dev. I was, of course, assigned to a team, none of whom had anything to do with my work, nor I with theirs, but we all had to pretend to care at every standup, retro, etc.

I had to get their buy in on every feature I built, despite their having no idea what I was doing (it was also beyond their skill sets), and I had to fight to get code through code reviews by devs who had no clue. Occasionally, I was forced to insert bad code just to get anything approved. Again, I shit you not.

Not only was this stressful for all involved, but it was a real drag on our performance — just an incredible waste of time. And it often left me livid with rage, especially given the apathetic response of other coders that it was “just they way things are”.

Yeah, and with attitude it will be just the way things will always be.

But what was even worse was that, repeatedly, the product owner would try to force more devs on me thinking that it would make me “go faster”, this despite that I was already the fastest coder (see above about his demand that I slow way down).

Maybe his real goal was to slow me down, because that was invariably the effect. Instead of simply getting on with the coding, I had to stop to explain myself, then teach the dev how to do it, then review their code (which was invariably not very good), then have them redo it, then review it again, etc. Not to mention hounding them to stop screwing around and get shit done.

And boy did they resent that.

When I finally turned the code base over and left the team for a new position elsewhere, they sat on it for a couple of months, then put an entire team on it to “bring it up to speed” because the main code base had changed since I’d moved on.

One of those devs was remarkably sharp and very fast — definitely faster than I am. And yet, it took the “team” a full year to do what I could have done all alone in a couple of months, tops. Even allowing time for the team to learn the code base (not that complicated) and come up to speed, a year? Really? Why?

Because of all the same reasons I’ve given above. If they’d just put that one fast coder on it and left him alone, he’d have had it done in a month or so. But they gave him a “team”, so that slowed him down by an order of magnitude.

In yet another enterprise, I worked on three (3!) different teams over the course of eighteen months, and in all three cases I was working on small, greenfield projects that had nothing whatsoever to do with anyone else on the team.

Do the math. Seventy-two weeks, give or take, five days per week, average fifteen minute standup (I’m being generous)… that’s about ninety hours of my time wasted — about $15,000 at my charge-out rate — and an equal amount of their time wasted at a somewhat lesser rate. But that doesn’t include all the other wasted time, such as waiting for a code review by someone who has no idea what I’m doing, or hours spent bikeshedding in retros for teams of which I was never really a part.

Why?

This will be an enormously unpopular answer, but the main reason is the illusion of control.

Management wants to feel like they are in control. There is a limit on the number of “reports” any individual can handle, therefore, as the enterprise grows, so, naturally, do the layers of management and the number of teams. And teams have an “ideal” size, too, so they multiply as well, although if you take that number and divide it by itself, you’ll arrive at the truly ideal size, read: ONE.

The other big reason for teams is because most humans are infants. Sorry, but someone has to say it. Without “adult” supervision — a sick joke as the supervisors are themselves infants and must also be supervised, right up to the head infant or “CEO” — they will make a mess of things.

And weirdly, a great many humans don’t seem to be very happy outside of work. I dunno, maybe television, the Internet, and, especially, (anti-)social media have left us feeling that we aren’t loved or something. But an awful lot of people seem to want to find that love at work. Or at least companionship.

Hence many enterprises are a bit like kindergartens. One enterprise I worked at, which had a big, open-plan office, required that if anyone applauded, then everyone must applaud. So if your team of eight applauded something you did, then all 100+ people on the floor joined in. Gotta love Big Brother.

At another, every day started with a “check in”. We each took turns talking about our feelings (no, really) and providing each other with emotional support. Did I mention kindergarten?

Individual: “My cat died yesterday". Team, pretending to give a shit: “Aw… that’s so sad.” Hugs all around.

If either of my cats died unexpectedly (or even expectedly) I’d be fucking catatonic. But no way I would think that the answer was to go to work and saddle my “teammates” with that shit. Take some time off! Deal with it.

I have never understood any of this. I have a life, and it doesn’t revolve around my work or even around programming. When I go to work, I want to get shit done and go home. I want the people I work with to be adults who are there for the same reason: to get shit done and go home.

I appreciate it when my colleagues are smart and witty and kind and gregarious. Who doesn’t? But I don’t need them to be my buddies. If one of them turns out to have interests that match my own and we’re both up for it, then I am happy to meet them outside of work hours to discuss those interests.

I’ve made several of my better friendships this way. But we are not friends because we worked together. We’re friends because we share interests.

The unspeakable truth

The truth that may not be spoken aloud is simply this: it is about infantilism.

We live in a society where no one ever really grows up anymore. Or, to be more specific, people grow “up” but they don’t mature. Maturity and wisdom are remarkably scarce on the ground.

As I’ve remarked elsewhere, the definition of an adult is someone who does the right thing every single time. Because it is the right thing. Because doing the wrong thing is simply inconceivable. To suggest doing the wrong thing to an adult would provoke a shocked and astonished response: But why would anyone do that?

Adults understand that wrong things bring bad consequences. I don’t have to be told not to drink acid. I don’t have to exert willpower or discipline to avoid drinking acid. It never even occurs to me to drink acid. Imagine if every week my team leader had to check in with me and say, “Hey! Good job on not drinking acid last week! Keep it up!”

Or, “I see from that hole in your cheek that you drank a bit of acid this week. Do try to keep that to a minimum, OK?”

This is how adults see the idea of doing the wrong thing: inconceivable.

Infants are continually driven to do wrong, stupid, and foolish things that harm both others and themselves. They lie, they cheat, they steal. They do whatever they think that they can “get away with”, not understanding that no one ever “gets away” with anything. The act of doing a wrong thing is instantly and inescapably destructive to the one who does it, not the one to whom it is done. And once done, no wrong act can ever be undone.

Thus, infants require supervision — parenting — to prevent them from hurting others and, especially, themselves. And this is the secret purpose of teams: to keep infants in line.

All the reasons given for teams — organization, communication, coordination, etc. — are possible without the team structure. With adults, they happen effortlessly. Adults know what they know and, more importantly, what they don’t know. They know who is affected by their actions. They know to find out from others what they need to know, and to consult with others before taking actions that might affect those others.

They don’t need to be told to do this. They do it without hesitation or prompting because it is the right thing to do. They can continually form informal, impromptu, ad hoc groups as necessary to coordinate some activity, and then dissolve those structures instantly the moment they are no longer needed.

They don’t need silly names or avatars or feel-good events or rigid structures or “checking in” to guide their efforts. Things simply flow.

Adults can work together in groups of nearly any size efficiently and effectively because everyone looks out for everyone else and everyone ensures that they’re doing their part as well as humanly possible, without needing to be told to do so. Without needing any formal (and arbitrary) structure.

Every time you encounter a problem — no exceptions — it is because one or more participants has regressed into infant mode. No infants, no problems.

The vicious cycle

Teams might have some value if they recognized that their members were immature and if the true goal of the team was to help those members to mature. In essence, the goal of every team, as should be the goal of every parent, ought to be to make the team structure superfluous.

Every team should be working toward a near future in which the team is no longer needed because the individuals are now capable of working without parental supervision.

Unfortunately, this is the precise opposite of how teams work in modern enterprise. Rather than maturing the team members, the teams infantilize them, just as all systems of control do.

Next thing you know they are doing trivia quizzes and shooting spitballs at each other instead of working.

This is great for management! Heaven forbid that the workers should become mature enough to do the work without the expensive and useless overhead of management. And infants are unlikely to question why they are doing what they are doing, or to notice how badly they are being fucked by the organization that is pretending to care about them.

And that is the real reason that teams are so loved by organizations.

Better still, that teams are a hard brake on productivity and efficiency has spawned a lucrative enterprise of its own in the form of various consultants who will — for a price, of course — show you how you’re doing your teams “wrong”. With luck, you can get up to who knows? Maybe even 25% efficiency!

In short: don’t expect the love of “teams” in the tech industry to disappear anytime soon. Too many salaries depend on their continued existence.

So… do you think your Wu-Tang sword can defeat me?