“Collaboration” is bullshit

Sure. I trust people follow this to its logical end, which is how bad our mental model of "work" is. The more I think about it, this may get to the heart of all of our (bad) economic theory. Which is that, in a simple survival sense, there is no requirement whatsoever that "everybody works," or even contributes, but to have a functioning society, we do whatever it is we're doing now.

Something like UBI with extra steps.

And perhaps the bigger issue to get over, there perhaps ought not be a moral component to this, in a world where technology + a small number of people can easily take care of ALL actual needs.

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.

When this article opened with a World War II story, I thought that the “collaboration” being discussed was people aiding the occupying forces. Sadly, it turned out to be less interesting than that.

It's interesting that the author does not even consider the impact of incentives on performance. As Charlie Munger famously said, "Show me the incentives, and I'll show you the outcomes." It is true that collaboration becomes increasingly difficult as the team grows in size, but collaboration is not the fundamental problem. To manage a large team, the real challenge is to design incentives that properly reward those who produce and perform, and penalize those who don't. People respond to incentives (yes, it is a tautology, and that is precisely the point).

I think the Author might have a lot of bad collaboration experience from working with teams that have low level of competence and agency, and especially in corporate, this highlights and accidentally resonates with me ( as of few months ago)

Laid off from a startup and moved fo corpos did gave me perspective,the first year working with the team works really well, we managed to get a lot of stuff really done and business were very happy.

And there came the Agile Coaches telling us to "Collaborate" while disguising as a need to serve his own agenda ( as he's also a PO for another squad ). So workshops on Collaboration, Explicit Expectation on PM have all authority and controls PO, for 8 freaking months just to get a competent team to work with a junior team with no agency nor even willingness to be mentored or do anything. So somewhat this incidentally aligns perfectly.

Corporate always manage to hire incompetent people, not firing them, and let others over-compensate for their failures, so yeah, its not really obvious but its there.

I believe the good collaboration can happen, but when people actually go of their ego and start listening and actually doing the work.

This quote and the entire article could be extrapolated beyond the scope of an organization to highlight the importance of the notion of authorship in society as a whole:

> 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, then rationalized into the language of teamwork afterward. Dostoevsky wrote _The Brothers Karamazov_ alone. The Apollo Guidance Computer came from a team at MIT small enough to have real ownership, hierarchical enough that Margaret Hamilton's name could go on the error-detection routines she personally designed.

Contrast this with the claims of “democratizing knowledge” and the image of a utopia where everyone contributes original work into a black box and expects no credit and no compensation in return (in fact, happily paying for the privilege of using it).

We, humans, like to have created something worthy of kudos. We pull the rope less hard when it’s a collective effort than when the rope is just yours alone.

Individual responsibility can just become a blame culture. I remember sitting near a team that worked like this - meetings with everyone trying to prove that some screw-up was actually due to someone else.

In such scenarios nobody wants to stick their neck out at all, everyone hates everyone else.

At a higher level the usual problem is with incentives being different from one team to another. If you want something done you have to start with the incentives rather than expect people to work against them and there does have to be leadership to break deadlocks.

It's frustrating to pull more weight and take ownership when other people aren't. But what's legitimately soul-killing to an individual and deadly to an organization is the collective impulse to avoid giving those people credit when it's due. Most of those 20% out there pulling more than their weight just want some acknowledgement. Not giving them that is one way to quickly hollow out your company.

I was skeptical about the claim that 80% of soldiers refuse to fire their weapons, so I did a little reading and it seems like the original source has been pretty much debunked. This 2011 article sums it up: https://scholars.wlu.ca/cmh/vol20/iss4/4/ but it's been doubted for decades.

> Every project now seems to carry more coordination overhead than execution time, and when it fails the postmortem just recommends more collaboration...

Or it gets stuck in code review cause one colleague likes nitpicking everything endlessly, so you’re stuck changing working code for multiple days.

Or they have questions and want to spend 2-4 hours in a meeting about design and how to do development “better”, bonus points for not writing anything down for future reference, them expecting you’ll keep a bunch of rules in mind. No ADRs, no getting started guides, no docs about how to do deliveries, probably not even a proper README.md, or versioned run profiles or basic instructions on how to get a local DB working (worst case, everyone uses the same shared instance).

Even more points for not even having retrospectives and never looking at stuff critically - why people keep creating layers upon layers of abstractions and don’t care about the ideas behind YAGNI/KISS. More so, no actual tooling to check things (e.g. code style, but also tools to check architectural stuff, and also obviously no codegen to deal with the overly abstracted bs).

It all depends on the project and team a lot. Some people have only had the fortune to work in locales and environments where stuff like that isn’t commonplace but rest assured, it can get BAD out there.

Working in a good team can be better than working alone, sure!

But working in a bad team is certainly worse than working alone.

Especially so when seniority is measured in years or nepotism and you’re told to not rock the boat and shut up cause “we’ve always done things this way”. I'm exaggerating a bit here, but I’m certain that plenty of people work in conditions not far removed from that.

Somewhat recent and somewhat related:

Collaboration sucks - https://news.ycombinator.com/item?id=45892394 - Nov 2025 (248 comments)

A lot leaps from riflemen, who obviously didn’t want to die (did you expect them to rush Medal of Honor style?), to system features to model office work? Whole essay is incoherent mess written by one of those lonesome “no-bullshiter” who gets the job done but is so pulled down by modern day bureaucracy that even his clairvoyance can’t get through.

> Dostoevsky wrote _The Brothers Karamazov_ alone. The Apollo Guidance Computer came from a team at MIT small enough to have real ownership, hierarchical enough that Margaret Hamilton's name could go on the error-detection routines she personally designed

I have good news for you, my jaded friend! What is similar between those people and you? You’re an individual! Therefore you could write another masterpiece yourself, you can be next Notch, next copyparty guy, next Stardew Valley guy and a long list of creations created by an actuallly high-performing individual, not some complainer who is oh so encumbered by stupid social dancing.

This article is so true. "Collaboration" is how nothing ever gets done; we have this expression: "designed by committee"; we should also have "made by collaboration".

What's depressing is that it's like Fred Books' book never happened: most managers think the way to solve IT problems is just to trow more people / more money at it until it gets solved; and they're all surprised when it doesn't work, but try again the next time anyhow.

> 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.

that is a meaningless buzzword salad masquerading as a deep insight

I have a coworker that will take projects out from under you and do all the work themselves if you ask to collaborate with them. It happened twice, one of them he out right took all the credit and handed me peanuts. The person knows this so they try to keep you involved by having you review their work, which is usually pointless because they’ve already done all the work and there are no alternatives or caveats to consider. I will never work with them again even though they do good work and are sharp, purely because they’re a control freak and it slows everyone down.

What it misses is that the 80% of soldiers who were not firing was still required. Not everyone has the same product, and someone’s product exists at an abstraction layer above the outcome and towards the organisation that builds it, as ugly and inefficient as it may be judged in comparison to an army of perfect contributors that does not exist.

I think the author is overfitting. Collaboration and ownership are actually not in tension. _Bad process_ and ownership definitely can be. You can still have a high performance, high accountability culture that is collaborative.

Thought-provoking essay. I can see how responsibility and ownership are important to help identify, motivate and reward the high achievers (and conversely, identify and get rid of the "dead wood"). But I can also see how collaboration and the dilution of responsibility and ownership helps better integrate junior members who might otherwise stay on the sidelines for longer than they should. There's also the issue of personnel turnover: what happens if the one person who is responsible for a major piece of a project leaves the company? A collaborative setting is more resilient to churn. There are trade-offs, and possibly a middle ground to be found.

Not sure men fighting for their lives in WW2 is the best comparison point for dev teams having too many standups and retros.

i work in teams and collaborate with my AI agents,

and i feel that it's a much better way to work.

whenever i need real users feedback, i just ask my wife next to me to test out the features and give end user feedbacks

It is interesting to pick on an example like the Battle of the Bulge. To put those men, on both sides, in the field was an enormous effort of collaboration. We can say it was doomed from the beginning, in hindsight, but it was very dangerous at the time and took enormous efforts to disengage troops and redeploy them. Patton's redeployment must be one of the greatest organisational feats in history.

At the beginning of the Battle the weather was terrible, stopping the normal collaboration with the air force. When the weather cleared, collaboration restarted, and both arms could work together much more effectively than the army alone.

Can we start appreciating and respecting other people's professional experiences without dismissing and criticising them?

It's well written and brought to light a very interesting subject, e.g. "Marshall’s research showed that just 15-20% of riflemen in active combat positions ever fired their weapons".

A lot of process and management is about dealing with low performers - by which I don’t mean incompetent people but people lacking motivation, or with the wrong intuitions, etc. Our hiring process can’t reliably filter out low performers, and when they get in it’s difficult to fire them, so we invent ways to raise the bottom line through processes.

And FWIW I don’t think you can solve this by always hiring the “best” either, at least not beyond a certain team size.

> ...every unilateral decision gets read as a cultural violation and a signal that you aren’t a team player. 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.

This is definitely how it can feel sometimes, but it's simply not true. The problem really is just poor communication and big knowledge gaps.

I do understand that not all workplaces allow for enough discussion. Arrogant behavior from leadership is just them cracking under the pressure. You should know that you're never the only one noticing it.

Don't get dragged down with them. You can voice your concerns candidly with the right people who care the most about the outcomes and let the chips fall where they may, or you can suffer in silence like they expect you to. It's sad that this is the expectation because these conversations are just as much a part of "collaboration" as anything else. I expect there may be some defensive replies from certain types of people who feel threatened by this idea.

What you should never do is let this stuff get under your skin or take it personally. The fact of the matter is, teamwork is the nature of any business. When people go rogue, it only makes the problems worse. Everyone misses out on opportunities to grow and the project suffers from the lack of coordination to continue long term.

Prices law is relevant here:

50% of the work is done by the square root of the total number of people who participate in the work.

I think our processes are terrible as an industry. I have brought this up many times but we don't understand what actually works when something goes right and what failed when something went wrong. Adding to this is that engineers love tools and process so they tend to credit tools and process with success because we like the machine. Giving it credit where credit wasn't due leads to slowly growing more elaborate process and tools over time. This love of tools and process is a fundamental flaw in our culture and it is a big part of why big teams fail and small ones can get things done.

There are two fundamental truths to software, or any real organizational level problem. First, you don't know what the solution is until you have actually built it and are using it and second designing and building something is a non-polynomial growth problem.

The first part of the problem we sort of get, sometimes. The solution is iteration for the same reason it has always been. Assess, step, assess, step isn't just a good way to train a NN, it is also a great way to do pretty much anything where you don't know the optimal solution. Take the gradient of the situation and then take a right sized step in the right direction. Think you can have a perfect design before you start coding? You are basically saying you can take one big step from the start to the end. Either you have a small problem to solve or you are deluding yourself. Successful software is iterative. It always was and always will be. If your retrospective says things like 'if we had just done X from the start' be very careful because you are falling into the hindsight trap. You really couldn't have known X was the right thing. There is a reason you didn't see X. Just accept the iterative nature and own it. Try for appropriate step sizes, do good regular assessments, keep the iterations tight and you will probably be ok.

The second problem, NP growth, is where things really fall off the rails though. People get iterative, they see it work, even if they don't understand what they are really doing, but NP complexity growth is a real killer. The problem is that it actually IS true that if you took more time and put all the pieces together and solved it all as one problem you technically could eventually find the better solution. But more than likely the heat death of the universe will catch you before you do. Oh, yeah, and the total information storage needed to document the combinations tried will likely kill you too. There is only one good solution to NP growth, accept a local minimum and divide and conquer.

NP complexity growth is the foundational problem that needs to be attacked and the why things work or don't. Even more than iterative in many cases. As a problem grows its complexity, the possible number of solutions to check, grows in an NP way. The only solution is to drop the number of options to consider. You have to divide the problem and admit a local optimum is the best practical solution. People -sort of- get this by pretending to break the problem up and give it to different people or teams but then totally blow it. Jira is an example of totally blowing it. So you broke the problem down and you broke the teams into smaller pieces to address those sub problems but then you threw it all in one place again in Jira and you had all the teams in the same standup. You can't do that. That is the point of divide and conquer. You do that and you get lost because the problem just got too big again when you put all the pieces together. Also, communication scales up with people, even without problem size changing. Create too big of a team and the communication eats all the available work. Divide and conquer -requires- not communicating, or at least being exceptionally careful about how you communicate between problems.

The processes and tools we have created and love to use so much are the heart of why things don't work and we need to start admitting that. They give us a false sense that we can make a team bigger or take a bigger problem on. That is a mistake.

If you have done a good job of dividing a problem up, and correctly sized teams, then you have created problems that are clear enough not to need status boards and the like. Sure, go ahead and use them if your small team likes that. Be my guest, but you probably shouldn't. If a team is iterating on their problem and the problem is appropriately scoped then the team knows the state of their entire piece so well that the status boards slow them down. Why put in a jira ticket when you can just deal with it? Why break your internal team communications like that? Team management and project management become easy with small teams since your options are limited and the problem is small so it is all obvious. If you are saying to yourself 'well how will we know the whole thing is on track' well if you divided correctly then every level has a human sized understanding to deal with and is keeping track of their piece. That includes the team that owns teams. They should have designed the teams working for them, and the problems those teams are dealing with, in such a way that the working memory state is enough. They also designed the communication to that team in a way that they stay informed -without- joining that team and in doing so joining all teams. In other words they don't micro manage because that breaks divide and conquer. If any level is lost then the problem may not have been broken down well or has changed. A good iterative team catches this and raises the flag quickly so the divide can happen again if needed. The team leading the team has the job of monitoring to help figure this out, but monitoring in very limited ways so that they don't end up micro managing and collapsing the divisions.

A good military know this and a bad one has forgotten it. In WWII we had task forces for everything. They could stand up a TF, get it training so that it was a coherent entity, execute the mission needed and tear it apart. We were amazing at it. When WWII ended we did big things because we carried our understanding of the operational level of war, how to break apart problems and teams, into industry. We went to the moon. Now however we have standing task forces in the US military that are essentially the leftovers from WWII. We crate new task forces, badly, that are really just the existing ones renamed which means they have their old job and new job and nothing has really been broken out and isolated correctly. We suck at war and a big reason for this is that we have forgotten the operational level of war lessons from WWII.

This is a long rant to get to this final point. The author doesn't get the real reason why '20%' does the work. It is because we hire and create massive teams that can't get anything done because their communication has scaled to 1000% of their capacity. So, naturally, a small core team forms that can effectively communicate and get a job done, by ignoring he other 80%. It isn't the other 80%'s fault, it is the organizations fault for not breaking things up and creating small teams where the size of the problem is understandable and actionable and, most importantly, not re-merging the problem and the teams with stupid things like Jira boards.

The real solution is the same set of solutions that work time and time again. Create small teams. Give them clear problems to solve and the right tools and authority to solve them. Put bounds on what they should be doing so they, and you, don't get distracted. Understand that a problem is an evolving iterative thing and lean into that. If 80% of your workforce isn't doing things then your organization is broken. Start figuring out how to fix it. Collaboration isn't bullshit. It is fundamental. We just need to actually, intentionally, design that collaboration based on the actual things that shape it. NP growth and iterative understanding.

You know you can just say no right?

And if the job is ass like that just get a new job.

Or start your own company.

This article is just a complaint slop, and complainers are just as bad if not worse. Do something.

The core issue is that collaboration bullshit is fantastic for mediocre people who cannot produce anything of value and as the team grows, the share of mediocre people will inevitably grow. This is why every single large organization turns into a theatre of processes.

Laid off from a startup and moved fo corpos did gave me perspective,the first year working with the team works really well, we managed to get a lot of stuff really done and business were very happy.

Corporate always manage to hire incompetent people, not firing them, and let others over-compensate for their failures, so yeah, its not really obvious but its there.

I believe the good collaboration can happen, but when people actually go of their ego and start listening and actually doing the work.

Not sure men fighting for their lives in WW2 is the best comparison point for dev teams having too many standups and retros.

This is definitely how it can feel sometimes, but it's simply not true. The problem really is just poor communication and big knowledge gaps.

Prices law is relevant here:

50% of the work is done by the square root of the total number of people who participate in the work.

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.

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.

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.

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.

I doubt whether Marshall was referring to soldiers in logitiscal roles when he made his claim about only 20-25% of soldiers firing their weapons, but I do wonder whether other people are getting confused by those numbers. About twenty years ago I looked up what the "tooth-to-tail" ratio was for various branches of the U.S. armed forces, and found anywhere from a 1:10 ratio for the army (10 soldiers in support roles not expected to see combat, v.s. 1 soldier on the front lines who would be expected to need to fire his weapon), to a 1:25 ratio for the air force (which had, naturally, a lot more support personnel, such as mechanics and so on, who would spend their whole military career in hangars or on bases and never actually flying a single plane). That's anywhere from 10% to just 4% of military personnel, depending on branch, who would be expected to fire at the enemy; the only time support personnel would be engaged in combat is if something had gone badly wrong militarily and their supply lines were being attacked.

So while the article you linked isn't confused on the subject, and I doubt Marshall was mixing support personnel in with front-line soldiers in his numbers, I do wonder whether there are people who confuse those two numbers: the number of soldiers, sailors, coasties, airmen, or marines who would never be in combat even during times of war, vs. the number who would actually be in combat and not fire.

(The article did address "what if the battle never came near where those particular soldiers were standing?", which was the other question I wondered about).

that is a meaningless buzzword salad masquerading as a deep insight

I think it's just explaining the difference between comms/collab being a supporting thing vs the only thing? It doesn't seem intended to be deep to me, but it's a little verbose.