All of the collaboration artifice that the author is referring to seems to me to always be a futile attempt to meet "the date". That software development might itself be _inherently_ unpredictable is never even considered, even though there are a lot of reasons to suggest that it is: by definition, the software you're developing has never been developed before, or else you could just use the thing that already exists.

I had a glimmer of hope in the late 90's when the agile manifesto was published - everything about it seemed to me to read "software development activities can't be coordinated like a wedding banquet can, but you can at least make sure that everything is tracking toward a shared understanding". I guess I shouldn't have been surprised when "Agile" became "tell me exactly what you're going to do and how long each step will take" almost the instant of its inception.

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.

In short, he proved that even AI agents exhibit all the dysfunctions one would normally attribute to human shortcomings / politics / laziness etc.

Either way, I think the point is strong: if the organization is bad, you end up doing mostly work about work which is exhausting.

Small, effective teams with super high accountability are more fun, but don't look "reproducible" or "repeatable".

Shameless plug on my take: https://www.menge.io/blog/where-to-cut/

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

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

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.

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.

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.

Collaboration isn't a process or a management technique -- it is a communication style. If you want collaboration, you can't take random people and use process to "make them collaborate" -- you need to build your team out of people who are collaborators.

Furthermore, collaboration is not at odds with accountability. Most of the highest performing collaborative teams I've ever worked on have people who are each individually highly accountable for their own contributions, and that's a critical part of what makes them a valuable collaborator.

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.

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

that is a meaningless buzzword salad masquerading as a deep insight

If folks don't clearly define the finish line, than a project will run out of budget eventually as scope creep turns it back into the same useless mess.

Proper restructuring usually means firing people that do not recognize they are in a business setting. The Big Brain fallacy is a common bias with people too blind to recognize what other professions bring to the table, and ultimately are unproductive in a large project.

Every manager should read Moneyball before building operational teams with HR, and avoid the trap of the costly Big Brain =3

"Moneyball: The Art of Winning an Unfair Game" (2003, Michael Lewis)

https://www.amazon.com/Moneyball-Art-Winning-Unfair-Game/dp/...

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

My current employment is the first time I haven’t see this, the Pareto Principle.

The reason for this in biology is two fold:

1. Growth is distributed evenly as necessary to fill the containing system whether it is employment numbers or peas in a pod.

2. Resources are distributed to where they are demanded. Higher productivity individuals will consume a disproportionate number of tasks to complete as well as available resources. This difference is often statistically insignificant as a base difference but after compounding 20% of individuals account for 80% outputs and inputs.

Human behavior accounts for the same compounding because numerically growth distinction is similar enough.

And LLMs is about to make sure that the structural support people are 99% of the team and the people who do most of the work are 1%, orchestrating a team of agents...

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.

* I believe these workflows aren't entirely invented yet; it currently seems to be mostly token-burning with the illusion of productivity, measuring inputs rather than outputs.

The problem with this is conflating *output* for *impact*. A team of lone wolves writing 1k LOC by the hour is good output but not necessarily good impact.

A team with higher coordination overhead and "structural support" will probably have lower output, but if it focuses on significantly higher leverage activities might just have a better impact. The key question is whether that impact is visible and understood (often not) and lots of businesses are bad at understanding leverage.

I see this lone wolf BS from lots of founder types who mistake their own grind for real performance, often missing their own blind spots. I don't disagree that the 80-20% rule comes up and that some people have an outsized contribution overall compared to others, but to say that collaboration is dead as a result is throwing the baby out with the bath water.

Im not saying teamwork is not needed, but it for sure should not be #1 indicator for teams.

Vetting for character to skip dycks is till fine in my eyes.

Shoot rounds from your m16/ak47 all you want while sitting in a ditch — it’s mostly pointless

https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...

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

The point of collaboration is to put people together that when combined are greater than the sum of their parts. You take person A individually and they may to X, you take person B individually and they may do Y. But individually X and Y might not be that valuable, it's their combination and the glue that combines them that is valuable.

What the article misses is that yes, 20% do 80% of the work. However, you can't predict which 20% will do 80% of the work. Not only that but it's not always the same 20% that do 80% of the work for all tasks and projects.

Collaboration is the 'glue', that little bit of added information, that combines the work of individuals into truly something great.

The challenge is how do you combine the work of individuals and I can tell you what doesn't work, rigidly planning and executing.

I don't even think in this age it's a "collaboration" issue. We've seen years of mass layoffs at this point and there's little rhyme nor reason. Sometimes being the "producer" saves you, but not always. Hard work isn't rewarded and leverage isn't necessarily respected anymore.

Your best bet these days is "collaborating" with someone high up who can shield you. Not because you're a producer, but because they like you. The illusion of meritocracy has completely collapsed (at least in large companies).

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.

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

now there's pretense of doing work. if you're smoking, you tend to shut up and listen to others.

email though good it terms of faster communication, enabled the whole email chain thing to fake as if one is doing work.

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.

Guy concludes the problem is “collaboration”, in general.

Yeah, no.

> Collaborating means the failure belongs to the process.

This is the way that hierarchy fails to scale. The larger a hierarchy, the more "process" must exist to keep it together. Process in a hierarchy must be defined by superiors, and implemented by inferiors, so it is superiors who must own the failure of process, and inferiors who are blamed for it.

> The average knowledge worker maintains accounts across system after system, switching between applications hundreds of times per day.

This is the more serious problem that comes from hierarchy. Work done by a team must become its own isolated context: the project. Anything anyone hopes to be able to do with a computer must be monopolized somehow by an "application". Why? An application is the only practical goal that a project can have. Anything more would have too broad a scope to be manageable.

---

We don't need hierarchy. There is another way to do work, and despite making incredible the tools for it, we have barely scratched the surface.

We have a decentralized internet, email, and git, so why do we keep making applications? Application is not only a reflection of the hierarchy that makes it, it's also a reflection of the environment. No matter how you contribute to the puzzle, your contribution must be a piece. How else could it fit with the rest?

Free software has been struggling with this dichotomy from the beginning, but it's only getting worse. Most of the systems we use are becoming ever more consolidated and impositional. Most people don't configure their system by editing each of the unique config files: they open the GNOME/XFCE/KDE "system settings", and expect it all to stay consistent. Most of what we actually do with computers is facilitated by one of two major web browser engine implementations. Want to make a new window manager? Get ready to build a feature-complete Wayland compositor (probably leveraging the bulk of another compositor's code). Sure, you can use shell utilities, but it's not like we are doing anything new or interesting with them: just transforming text with a careful emulation of a 50 year old environment.

---

There's no clear way to resolve this situation. Software is useless until it can fit as a piece in the puzzle. If we want a system that is not a puzzle, then wouldn't we have throw away all the precious pieces?

Even so, I think we have really lost touch with the original magic of computing. All these isolated contexts are walls that stop us in our tracks. Formats, accounts, applications, frameworks, platforms... all dead ends. Maybe it's time we make a path that doesn't end?

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.

High performing collaborative teams and teams-of-teams have the ownership culture that he is describing. But they also have a team level view of progress (kanban is one approach, and not a bad one, story backlogs are another, etc.) because any large initiative requires dependency management, throughput flow visibility, and coordination across teams.

Yes, individual small teams with autonomy perform best and should have minimal hard dependencies on other teams. "one piece continuous flow" is similar what he's describing as the optimal team flow with minimal waste, which is what Toyota sought to reach in as many teams as they could. Kanban and such approaches for signaling queues and jobs was a patch when it wasn't possible to get "one piece continuous flow"

But in complex products and projects .. dependencies, uncertainty in requirements, design, knowledge, etc. lead to queues, and thus a need for visibility of the queue. this requires active management of priorities, timelines, risks, and resource allocation, so that it isn't just a blind exercise of "trust me bro".

Progress is also best described as "jobs to be done" (whether user stories, or kanban tasks, or whatever) rather than lines of code or other poor metrics. .. learning things is a job to be done... iterating on design is a job to be done... if these lead to new tangents, restarts, cancellations, code removal, or elimination of bad components, sub-projects, or approaches is just as valuable in the long run as creating new things. All of that requires "collaboration".

I think the issue isn't "collaboration" it is poor "management" and process to organize humans for results.