Teams are how you do big stuff. I’m really good at what I do, but I’ve been forced to reduce my scope, working alone. I do much smaller projects, than our team used to do.
But the killer in teams, is communication overhead, and much of that, is imposed by management, trying to get visibility. If the team is good, they often communicate fine, internally.
Most of the examples he gave, are tools of management, seeking visibility.
But it’s also vital for management to have visibility. A team can’t just be a “black box,” but a really good team can have a lot of autonomy and agency.
You need good teams, and good managers. If you don’t have both, it’s likely to be less-than-optimal.
They could review PRs and commits and specs to get visibility and reduce comms overhead, if they had the skills and time.
The non-technical manager also takes great conveniences in making technical people spend their time translating things. But no one ever asks the manager to learn new skills as much as they make developers do it.
Otherwise yeah there’s really no point.
If the Scrum Master or whatever their title schedules any other repeating process meetings, fire them.
literally everything else is work off the kanban board or backlog.
in my teams everyone was told to decline all meetings unless it explicitly led to the completion of a weekly planned story/task. this way all meetings for the team have a clear agenda and end in mind.
for mandatory external meetings & running interference with external parties, there are ways to insulate the majority of the team from that.
On my second team, the visibility theater took over, upper management set and reset and reset and reset our direction, and nobody was happy. In retrospect, I should have said no immediately. Trusting and empowering your people is hard to beat.
That's why the most effective teams are wolf packs - roughly 6-10 highly performant members where communication overhead is still low enough that it barely matters, but have enough people to be way more productive than an individual.
Obviously there's a minimum level of competence you need to have for this to work. The smaller the team the less freeloaders are tolerated.
You want to break a team of 10 in half if you can. Not always easy. But if you can manage it, do it.
I think the author has identified that most organizations both fail at effective collaboration, and also use collaboration to paper over their failures.
I think the author maybe over-corrects by leaning on the idea that "only small teams actually get stuff done", and honestly I don't think anyone should be using SLA Marshall/Men Against Fire as an analogy for like... office work (if nothing else, even if you take his words at face value, then the percentage of US infantry who fired their rifles went up from 15-25% in WW2 to ~50% in Korea due to training improvements), but I can get behind the idea that a lot of organizations are setup to diffuse responsibility.
I also do think it's interesting to think about building the Pyramids. For the vast majority of people involved... I don't think modern audiences would call their work relationship or style "collaborative". Usually we use "collaborative" in opposition (at different times) to "working alone", "working with strict boundaries", and "being highly directed in what to do". Being on a work gang, or even being a team foreman is very much "no working alone", but those were also likely highly directed jobs (you must bring this specific stone to this specific location by this time) with strict boundaries.
The author says, "The collaboration industry has spent a fortune obscuring a dirty truth: most complex, high-quality work is done by individuals or very small groups operating with clear authority and sharp accountability" which means collaboration can work... in the right environment and with the right people. I work in R&D and I could not imagine not working in a collaborative environment. It's not reasonable to have expertise at everything and it's understood that things have to get done no matter whose name is on the ticket/story.
I also agree on you calling out Men against Fire example as well. That's not a collaboration issue, that's a training issue (amongst other things). And that problem went away as you said.
> By 1946, the US Army had accepted Marshall’s conclusions, and the Human Resources Research Office of the US Army subsequently pioneered a revolution in combat training which eventually replaced firing at ‘bulls eye’ targets with deeply ingrained ‘conditioning’ using realistic, man-shaped ‘pop-up’ targets that fall when hit. Psychologists know that this kind of powerful ‘operant conditioning’ is the only technique which will reliably influence the primitive, mid-brain processing of a frightened human being. Fire drills condition terrified school children to respond properly during a fire. Conditioning in flight simulators enables frightened pilots to respond reflexively to emergency situations. And similar application and perfection of basic conditioning techniques increased the rate of fire to approximately 55 percent in Korea and around 95 percent in Vietnam.
This piece is more of a whine about a certain kind of office culture, which the author - unreasonably - generalises to collaboration as a whole.
There's likely a lot of money to be made by identifying and defining good vs bad collaborative cultures.
Both are real. But a lot of "good" practices are more cargo culty than genuinely productive, and the managers who really do make it work seem to get there more by talent and innate skill than learned effort.
It's not a linear scale. A lone wolf can't produce the latest Assassin's Creed game. A committee can't produce Stardew Valley or Balatro. They're different capabilities, not a simple matter of more/less.
What organization, skills, leadership is required to explore a jungle for gold is very different from what organization, skills and leadership is required to run a gold mine.
So we get explore-exploit tradeoffs, satisficing vs optimizing choices etc.