Teams considered harmful
Teams considered harmful
How's that for a clickbait title?
A friend recently asked me to explain in a bit more detail my radical claim that the best team size is ONE. And truly, I should. Because it is not at all obvious, so I’ve found, just what I could mean by that.
Let me begin by saying that I’m talking about software development teams, not sports teams. I’m not a huge fan of sports teams either, but that will have to wait for another post in which I trash competition in general.
So … software development teams.
Why are there teams?
The biggest problem with suggesting that teams are actually harmful to software development is that the pro-team folks have cleverly slid the Overton Window to where “no teams” is not even conceivable.
When the team advocates argue about teams, they argue about “high performing teams” vs. all other teams. It is never about teams vs. no teams. It’s about how to do teams better. That we must have teams is a given.
So let’s take a moment to examine the real, unspoken reasons for creating software development teams.
Hiring more overpaid managers
The first and most important reason for having teams is to group the workers who do all the adding of value into numbers of “reports”.
There is a management theory somewhere (Taylorism?) that claims that there is a limit on how many “reports” (read: humans) that a single manager can, er, manage. Weirdly, the maturity of said “reports” doesn’t appear to have been a factor. It’s usually an arbitrary number, ignored whenever convenient.
So we need to divide our organization into divisions, groups, projects, etc. This provides us with a hierarchy of group sizes, which then permits a matching hierarchy of managers. Ergo, more reports equals more teams equals more overpaid managers.
One might think that managers are motivated to help the company to achieve its objectives more efficiently. Ha, ha. What planet are you from? Can I go there?
Managers exist a) to justify their jobs, usually by actually interfering with others who are trying to get work done, b) to accumulate more power, prestige, and pay – what Erik Dietrich calls “carnival cash” – and c) to make themselves “indispensable”, usually by hoarding information instead of sharing it.
You can argue with me, but the evidence is all on my side. Are there exceptions? Of course. Some managers didn’t get the memo, and they are actually trying to do good things. They won’t last long.
Hierarchies – all hierarchies – exist for one purpose and one purpose only: to blame shift. Why else would we infallibly appoint incompetent, self-involved, and insecure infants to “lead” us? It’s simple: if the leaders are shit, then we think we’re off the hook for our own stupidity and sloth.
For the small minority of humans who are actually competent and caring, this “feature” of humanity is effectively killing us.
But let’s be frank: the real reason for teams is to make life better for managers. Who cares about productivity? Who cares about the peons? We are not real people to them. You know it’s true.
Compensating for infantilism
Ouch! This one is going to hurt. But the sad fact of modern life is that most humans, and I mean most “grown ups”, remain infantile. Grown up infants. Not adults.
An adult, simply put, is a mature member of the species that always does the right thing. Why? Duh. Because it’s the right thing. Even asking that question marks one as an infant.
The adult does the right thing for the same reason that the adult does not pick up their fork when eating and stab themselves in the eye with it. They don’t have to exercise some kind of steely will to avoid stabbing themselves. It never even occurs to them to stab themselves. And if you asked why, they would, rightly, look at you as if you were insane.
After all, insane is defined as the inability to tell right from wrong. I might add: the irresistible impulse to engage in self-destructive acts.
Adults manage themselves. Infants need mommies and daddies. They need to be watched at all times to ensure that they don’t get themselves in trouble. Or hurt themselves or others.
Hence, a primary function of teams is to compensate for the immaturity of the team members by keeping an eye on them. Telling them what to do because they can’t (or won’t) figure it out for themselves.
Compensating for insecurity
Another feature of grown up infants (of all infants, really) is a deep sense of insecurity. Maturity is about power: power over the self. That’s it. The adult is in control. Infants are powerless, and they know it.
True adults then are, by definition, secure in themselves. Heh. Good luck finding one. Most people are desperately insecure. And insecure people need the safety and support of the tribe. They are not truly individuals.
Unsure of themselves, they need to watch carefully what the other tribal members are doing so that they can make sure they don’t step out of line. Monkey see, monkey do. It’s those mirror neurons.
Mimesis isn’t always negative, but it needs intellect and wisdom to intervene between that mimesis and acting upon it. Just copying the crowd leads to ugly disasters. Think mob.
Teams at work provide team members with emotional and psychological support to compensate for their insecurity. Think about it. You are there to get work done. So why all this time wasted on bonding bullshit? Why the games and the silly team names and the sausage rolls and all that nonsense?
It’s because like it or not most software development teams are effectively nurseries. The team members are not adult enough to support themselves — to be self-sufficient. Of course, we are never allowed to admit this! Infants always want to be told that they are “big kids” now.
Adults on these teams do their best to work around all this nonsense. The most infantile members of the team do nothing but socialize and goof off. And that’s the purpose of a team: to compensate for and somewhat control this behavior.
The lies team advocates tell
The biggest lie that advocates for software development teams tell is that it is all about collaboration. If they’re clever enough, they inject some bullshit about the “wisdom of crowds” and other pithy nonsense.
Hint: the “wisdom of the crowd” is directly proportional to the number of members in the crowd. How much wisdom do you think you’ll get from half a dozen immature kids?
Collaboration has nothing to do with teams. Nothing. Yesterday, I went to the best coffee house in town and had a superb coffee. The barista and I collaborated in the ordering, preparation, and consumption of that coffee. So are we on the same “team” now?
Is my doctor on a “team” with all his patients? If so, how come I don’t know any of them? But every visit my doctor and I collaborate on my health. In fact, I collaborate every day with friends, acquaintances, waiters, chefs, checkout clerks, salespersons, bus drivers, even lawyers. But none of them has ever suggested that we form a team.
Collaboration and teams are orthogonal. They have nothing to do with one another. Team members may collaborate, or they may not. My experience shows that teams most often inhibit collaboration.
Standups are a sick joke
Take the standup. Please.
A common belief is that in the standup we each get a chance to speak, and when we do we explain a) what we’ve done last, b) what we’re doing next, and c) what blockers we have, if any. There are, of course, variations.
But I can simply post this information to an accessible page and others can access them as they see fit. Asynchronously! Something like this:
Yesterday: Worked on the fucking Death Star.
Today: Still working on the fucking Death Star.
Blockers: Darth Vader keeps choking me with his mind. What’s his fucking deal, anyway?
Look! No standup necessary. How inefficient are standups? Well, consider that probably half of your “team” doesn’t give a rat’s ass what you’re doing. It doesn’t concern them. But they have to stand there (literally) and pretend to listen.
And blockers? Are you for real? If I’m blocked on something then I should wait for the next standup to do something about it? Why don’t I just go find the person or persons who can unblock me and talk to them?
Originally, if I remember correctly, standups were supposed to be very brief discussions between the concerned individuals only and held exactly when they became necessary. Ten a day if needed, or none for a week or two. That was efficient.
Now they’ve morphed into a way for the product owner (or more often a BA) to keep an eye on the kids. Maybe you have a Kanban board or equivalent and it’s all about moving bits of paper (or pixels) across the board. It’s a big game! But that’s another thing that could be posted online (isn’t that what monstrosities such as Jira are for?) and accessed as needed. So why the standup?
The last job I had (I’m gainfully unemployed, finally), I was on three different “teams” over an eighteen month contract. And in all three instances, what I was doing had nothing whatsoever to do with what the rest of the “team” was doing.
I was bored shitless (not literally) as they rambled on and on about things for which I gave not the tiniest zipless fuck. And then as I rushed through my own standup, I could see their eyes rolling back and their heads beginning to nod. I had to make regular bad jokes just to keep them from becoming comatose.
So why was I even on these teams? I collaborated every day with the key participants: the enterprise architect, the designer, and an expeditor.
I was on the each team because the idea that a developer might not be on any team was literally inconceivable. I had to be on some team. So I was simply randomly assigned to one.
But I also noticed that the other team members weren’t getting anything actually work-related out of the team either.
The same can be said for retros, post-mortems, and all the rest. The process is there to reassure management that they are in control, not to move the work forward. The truth is that all this process actually impedes work.
Children don’t need teams; they need supervision
So what to do? Well, the first step is to hire some fucking adults. Yeah, good luck with that. Adults are thin on the ground and they probably don’t want to work in your zoo anyway. I sure don’t. (Whether I’m an adult or not remains to be seen, but at least I know what one is and I’m trying.)
Once you have a significant number of adults (a majority would be nice), then pair them up with the children so they can coach, teach, and mentor them. (These are three very different activities.)
Your immature workers should be maturing up very rapidly. If they are not, figure out why. If it’s you, fix it. If it’s them, fire them.
This doesn’t mean that these pairs must spend all their time together, although occasional pair programming (or tester/BA/designer equivalent) might be good. It means that the immature developer has a specific adult to whom they can turn for help. Kind of like a mom or dad! And it means that a specific adult is responsible for keeping an eye on the immature worker.
But what about collaboration?
Just as I can collaborate with the electrician who comes to install new light fixtures (or the plumber to fix that drain) to ensure that the correct work gets done efficiently, I can collaborate with the key stakeholders for whatever work I’m doing.
We don’t need to be on the same “team” to do so. I know who I need to talk to and when. So I just arrange a time to do so. And that chat lasts precisely as long as it needs to, not some arbitrary multiple of half an hour.
And I know who needs to be informed of any decisions coming out of that chat.
So say I realize that some design feature isn’t going to work out. I message the designer and set up a quick chat, typically immediately unless some worthless meeting is preventing her from doing her actual job.
We hash it out quickly. She tells me that she’ll get me a fix ASAP. I then contact the expeditor or product owner or whomever and tell her about the impending change. Perhaps she then checks in with the designer (who has probably talked to her own design lead by then).
Soon after (my designer was incredibly wonderful), I get an update. A quick chat to make sure we’re on the same page. I contact my expeditor again and explain the change quickly so she’s aware. Then I implement it.
If some significant change is coming down the pike, the expeditor or equivalent will inform me. Some general changes can be put out in a post or an email — the benefit of this is that there is a written record. When things are discussed in person, the information is ephemeral. I might be distracted for a moment. I might not hear correctly (I’m half deaf). Whatever the reason, I might leave with the wrong impression.
So why the fuck do we keep doing things this stupid way? Are tech workers functionally illiterate? Keep the damn memos brief. Bullet points. Solicit comments. Make quick updates. Done. No need for a meeting! And we have a record.
That is how collaboration works. No team necessary.
How to tell if your team is bullshit
Teams can work, but they need to be ad hoc. That means established for a specific purpose. And I mean specific. Working on a particular product or project is not nearly specific enough.
Ideally, there is a specific objective, and team members come and go as needed. That means that each team member is there for a specific (ad hoc) purpose. They show up when it’s time to complete that work and leave the moment it is done.
They do not show up early. They have things to do. They do not stick around when no longer needed while you try to find something else for them to do.
If there is a block and they are stuck waiting on someone else, then they go off and do other work until the blocker is removed. They don’t stick around and do busywork (or nothing at all but distract the other team members) while they wait.
So at all times the “team” is simply the people currently working on a specific objective. Members come and go and sometimes return.
So how do you tell if your team is bullshit? Well, first, is it people working on specific tasks and no one not doing so? No? Then bullshit.
But here are some other big hints:
Your team has a name. Typically something stupid. What is it with tech workers and really bad puns? The best name for any team I was on was the Wu-Tang Clan. That, at least, showed some imagination. And it was funny. As we also had stupid avatars, I promptly chose the Ol’ Dirty Bastard as mine. Sadly, most of the team were too young (or white maybe) to know what any of it meant.
The size of your team is an arbitrary number. The ad hoc groups I mention above have a precise non-arbitrary number: as many as needed and not one more. If there is an artificial limit on team size, then that is your biggest clue: it’s about “reports”, which means its about management, not getting work done.
There are people on your team who don’t belong there. This is the classic situation where someone is working on something unique, but despite this they must be assigned to a team. Why? BECAUSE. Weren’t you listening?
There are key stakeholders who should be there, but are on some other team. This is a sure sign that your team is not ad hoc. It’s purpose is unclear, which means its real purpose is one or more of the three I explained above: inflate management, compensate for immaturity, compensate for insecurity.
Your team is clearly not ad hoc. It persists even though everything you’re doing changes. You’ve finished some feature, or a PI (heaven forbid), or a sprint. And yet the same team carries on with the same members. Why? Certainly not because it is necessary to get the work done.
Members are added or removed with no thought to the gestalt of the team. If you’re really serious about a “high-performing team”, then I’ve got news for you. It’s not about process and procedures. It’s about synergy.
The number one clue that your team is bullshit
Ha, ha. What is it? What is it?
It’s the last bulleted item above. Team members are added or subtracted arbitrarily, with no thought for how they will fit with the team.
It’s not just about skills! It’s about maturity. It’s about work ethic. It’s about personality and character.
Some examples might make it clearer.
I once worked on a remote team composed of several Poles, a couple of Slovenians, a German, and me. (I used to be an American, but even then I was living in Argentina.)
The Poles and Slovenians hated – hated – the German. And they tormented him continually until he finally quit. And they were just vicious about it.
They didn’t like me much, either, and eventually they fired me, which made me jump for joy. Literally. (Friends watching were shocked … but you were fired! Best. Thing. Ever.)
A BA I know was running two teams as “acting” product owner (i.e., doing the work but not getting the pay or prestige … or power).
She had some great folks on those teams. But one of her devs did nothing at all. Worse, actually. What little work he did was so bad that another dev would have to redo it. And when he wasn’t working, which was most of the time, he interfered with the devs who were getting work done.
She complained bitterly to management and to HR. And they did … wait for it … nothing at all. Because management doesn’t give a flying fuck about you or your team.
Another team I was on brought on a very insecure dev. He quickly decided that he hated me. But he was an abject coward, so instead of being up front about it and working it out with me, he was utterly passive aggressive.
For months he pushed my buttons every chance he got, cleverly convincing the rest of the team that he was some superstar (his code was mediocre at best and he was quite lazy) while undercutting me. No one noticed. I was ready to quit even though I liked the work when he suddenly quit and left the country. Whew!
It was like I’d died an gone to heaven. I pity the people on whatever new team he ended up on. People like that do not belong in any job that requires working with human beings. Or monkeys, frankly.
I could go on and on (and on), but if you’ve worked on software development teams for any length of time then you have your own horror stories (feel free to share).
But how do such people get on teams? They get there because the people assigning others to these arbitrary teams do so capriciously. They simply don’t give a fuck about whether that person will be a good fit, or even deserves to be employed at all.
It’s so much easier to just keep moving some asshole around rather than go through the process of documenting his assholity and firing the fucker.
So to hell with teams. Value mature workers and adult collaboration. Let the workers collaborate as needed in fluid, dynamic, ad hoc groupings, coming and going as required. If you must hire grown up children, pair them with a mature worker as “buddy” and do your best to encourage them to mature rapidly. If they cannot or will not, let them go. Structure your contracts to make this possible.
Will we ever see this? It’s doubtful. Enterprises are run by managers for the benefit of managers, namely themselves. Not for the benefit of the shareholders, the employees, or the customers. Don’t kid yourself.
All over the world CEOs are destroying their companies, screwing the shareholders, laying off workers by the score (or more), harming their customers, and generally making a mess of things. And yet they are regularly rewarded with bonuses in the tens or hundreds of millions of dollars. You just can’t make this shit up.
Ergo, don’t hold your breath. But you heard it here first: the ideal team size is ONE.
There is so much more, but this has gotten long enough. Example? “There is no I in TEAM”. What does that mean? It means the destruction of the individual and independent, critical thought. Hmm. Why would an exploitative corporation want that?
Cogs in a wheel. Theirs not to reason why / theirs but to do and die.