Hacker News Reader

Comment by igor47 | Hacker News Reader

Strong words. I wonder if the author has PTSD from poorly managed teams and has never had the fortune to work in a high performance well managed collaborative environment. I agree these are rare compared to the other kind, but they exist. Groups of people can produce more than lone wolves. One person didn't build the pyramids, the Linux kernel, or Amazon Web services. Even when responsibility for a top level domain rests with a single person, you still have to coordinate the work of people building the individual components.

View on HN

One of the features of my work, these days, is that I work alone. I worked in [pretty high-functioning] teams, for most of my career.

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.

Strong agree. When I started managing there was very little oversight. It wasn’t perfect and we went a bit astray, and we also did phenomenal work and had everyone on the team deeply engaged and moving with autonomy.

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.

Communication overhead is a quadratic function. In teams with n people it takes n^2 time to keep everyone informed.

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.

In my opinion, 4 is the best size. 7-10 is horrible - meetings and conversations use up so much time.

You want to break a team of 10 in half if you can. Not always easy. But if you can manage it, do it.

>trying to get visibility

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.

The standups are also organized around disrupting a small group of people for the convenience of one.

Standups should eliminate almost all other meetings engineers need to attend. Except to go deeper on questions that came up in standup that cannot be instantly resolved.

Otherwise yeah there’s really no point.

I would be pleased with the standup if it eliminated other meetings, but that has definitely not been my experience.

there should be only 3 regular meetings in an agile engineering team - weekly iteration planning (1-2 hours max) - daily standup (15 mins max) - weekly demo & retro (1-2 hours max)

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.

Is that three kinds of regular meetings? Because I count 8 meetings (and four kinds, as I don't think I've ever had demo and retro combined due to different groups of people being in both).

Sure, I was being loose with my terminology, you are right to correct this.

the point was in a 40 hour work week, it's reasonable for 15% of it to spent in coordination meetings, while 85% is directly related to progress.

Usually the retro is after the demo when other folks leave the room / drop from the zoom :-)

Not correcting, just clarifying for myself. I sure wish I had such a controlled environment with only 15% of time in coordination and where standup actually was 15 mins and not a segue into the everything meeting.

Be the change you want to see.

Do you mean standups as part of Scrum? Scrum dictates several other meetings.

I will allow one more meeting to start a new sprint and end the previous one. Everyone should have prepared ahead of time to report on all their sprint items and whether they were completed, if not why not, and to present the work they will be doing in the next sprint.

If the Scrum Master or whatever their title schedules any other repeating process meetings, fire them.

But what about that meeting that starts with "how do you feel today?" and "if you were a car, what car would you be? And why?".

Well obviously that’s an exception and must be allowed.

In my last company (before I left tech forever) I would tell my team that I am blocked on something or my progress is slow because of whatever reason and it would all get ignored lol.

It was almost like they required the standup as part of the process but never used it the way it should be used.

This is a really interesting point that too often goes unexamined.

I don’t know how to design and integrate systems and products, and write code, because I was born that way. I had to learn.

Likewise, later on, I had to learn project management, and product management, and the language of business so I could communicate effectively with those lacking a background in technology. Again, wasn’t born that way: had to learn.

But in a quarter of a century, the number of people on the commercial side who’ve bothered to learn enough about the technology side to have an informed conversation? Very few. Probably count them on one hand (the naive way: not using binary).

And bear in mind we’re talking about businesses that were heavily if not totally reliant on technology and the delivery of technology solutions for their continued existence.

You’d think a few more of these people would want to take a bit more responsibility for those outcomes, and maybe be a bit less disruptive to productivity, given their livelihoods have often depended on the success of said outcomes.

Like I say: interesting, isn’t it?

It's a provocative title, but I think this section better captures his scope of argument - "Collaboration-as-ideology has made ownership and responsibility feel antisocial, which is a hell of a thing, given that ownership is the only mechanism that gets anything across the finish line.", as well as "But there’s a huge difference between communication and collaboration as infrastructure to support individual, high-agency ownership, and communication and collaboration as the primary activity of an organisation".

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.

Yeah, I think the author strays a bit away from the title.

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.

It was also probably never true. The author handwaves away 'disagreement about his methods', but SLA Marshall was also simply a liar. He claimed interviews he never did and lied about his own combat experience and the circumstances of his own commission.

Agreed. I came in the comments to say something similar. I think the author raises some interesting points worth consideration but their perspective is so incredibly cynical. He mentioned a small team that made the Apollo computer program. Well it took an awful lot more than a computer program to get to the moon. I don’t think anybody would argue that there are people who don’t pull their weight out there but there is so much evidence that people working together actually works that it makes you wonder who hurt the author so much.

I fail to grasp the basis of folks knee-jerk dismissal of just about anything that strikes them as "cynical". Like, what world do you live in that cynicism isn't a signal of clear vision?

There's also a lot of evidence it doesn't work. It's not either/or.

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.

I can't say anything about how the Pyramids or AWS was build. But the Linux Kernels maintainence is full of responsibilities assigned to individual people.

yes, it seems that the author is against the typical corporate bullshit faux collab (where people are overloaded with distractions, and the whole culture is about "managing expectations", managing up, showing impact), not against delegation, supervision, review, and a few well positioned veto points

> Groups of people can produce more than lone wolves.

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.

At first, I also thought that rejecting collaboration excludes any kind of teamwork, but then I noticed the quotation marks - so they're apparently only rejecting quote-unquote-collaboration (as in "collaboration theatre": endless calls with no tangible outcome, wanting to involve everyone in decisions etc.), not actual collaboration (which is also consistent with what the article itself says).

I don’t think that the author considers collaboration bad in general, but instead how it’s done in most large corporations:

But there’s a huge difference between communication and collaboration as infrastructure to support individual, high-agency ownership, and communication and collaboration as the primary activity of an organisation. Which, if we’re honest, is what most collaboration-first cultures have actually built.

Yeah, the sheer joy I've gotten from being part of a few collaborative teams in my career was amazing. It was like we all got smarter by working together.

Especially fun when you all have a good time being with each other and still have a super high performance bar.

I’ve come to think those magic teams where the chemistry is just right are rare in a career.

I’ve been a part of two out of my dozen or so teams.

I'm 56.

That kind of full-bore magic has only happened for me once. But it was fun while it lasted!

This seems like a good time to point out something an early mentor shared with me: you can rate all jobs on 3 scales.

1. Do you enjoy the actual work? 2. Do you enjoy the people you're working with? 3. How's the pay?

If you get all 3 of those metrics over a "C", you're incredibly far ahead of most people. My golden-team job was a AAA job. My current job (where I get a taste of great teamwork, though since I'm leadership now it's different) is an B, and A, and a C+/B-. I've been here 18 years as a result.

That is great advice. Favorited that comment.

Depends on the problem being solved. And how frequently the core prob changes. Cuz nothing is static in an ever changing universe.

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.

Reply on news.ycombinator.com