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 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.
50% of the work is done by the square root of the total number of people who participate in the work.
that is a meaningless buzzword salad masquerading as a deep insight
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.
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).
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.
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.
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.
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)
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.
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".
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.
And FWIW I don’t think you can solve this by always hiring the “best” either, at least not beyond a certain team size.
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
https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...
> 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.
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.
> 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.
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.
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.
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 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.
What everybody keeps forgetting over and over again is that software is super complicated even if it can be changed from a keyboard without the use of physical morphing tools.
People who do not themselves generate software are in the position of telling the people who generate software how to do it and what the constraints should be on the outcomes.
Accept that it is complicated and that you cannot know in advance when it will be done unless it is a super simple request.
It is indeed more like oil field exploration than it is like sweeping the floor.
You cannot really know where the solution to a complicated problem lies in advance and therefore you cannot predict how long it will take you to find it.
People on the finance side just need to face the fact that there is risk that cannot be eliminated in advance or even quantified particularly accurately.
If your investors cannot stomach this, they probably need to invest in something other than software development.
Good luck with finding that in 2026.
Yeah but you'd think not dying involves killing those who want to kill you, or at least shooting at them! Isn't it super interesting to learn that 80% of riflemen don't ever shoot?
Linux and Wayland.
Both are collaborative efforts, one has fairly effective and tyrannical leadership with the best interests of the community in mind. The other is lead by committee with competing interests and goals where they all have veto power.
Those same collaborators are reflected in the distro situation... Here is a group that also has some rather tyrannical leadership but they have dependencies (see the software they run) and some of those folks are sick of the distro's maintainers nonsense, and went to things like flat packs (see Bottles for an example).
> most managers think the way to solve IT problems is just to trow more people / more money
Leadership vs Management, a tale as old as time.
If you get a bunch of people in a room and ask them for a design, one person is going to write the design while everyone else gets in the way. That's simply the nature of groups. The one person who writes it isn't even necessarily the best designer—they're just the one most willing to grab the whiteboard marker.
Conversely, if you ask one person to produce a preliminary design, they can leave, gather requirements, do research, produce a plan, and then convene everyone in a room to review it. Now all the abstract hypotheticals have been put to bed, the nebulous directionlessness has been replaced with a proposal, and the group can actually provide useful feedback and have a discussion that will inform the next draft of the design. And once the design is finished, everyone can easily work together to implement it as written. Collaboration is great, after someone has proposed a design.
That's part of what I like about the idea of Amazon's "culture of writing," though I've never worked in an environment like that in practice. Every idea needs to be preprocessed into an actionable memo before anyone tries to have a meeting about it.
That's before we even think about all the consultants and similar roles where busywork really is work. Then all the organizational or agile roles.
The fact that some product gets shipped and we still have customers is good, because that's what pays for it all, but that is just the foundation we all rest on. Almost like background noise.
b) even if it was remotely true, context matters. Refusing to shoot someone point blank because of reasons is one thing, refusing to go against Tiger 2 is another.
others need to fill a gap -- the "insecure overachiever" demographic.
https://www.bbc.com/worklife/article/20180924-are-you-an-ins...
how do align ruthless sociopaths, gropy / rapey executives, angry mother hens, and phone-it-in interns?
Collaboration between us is the default (no one exists in isolation), but forcing a particular sense of collaboration onto people is a different thing.
By default in the dominant culture, most systems come down to individual incentives for individual drive and shame dynamics for collective drive, and that covers a decent chunk of how people are motivated, but leaves out people who are motivated differently and actively harms people for whom these are paralyzing.
Another example: bugs that are not found by testers - whose fault is that - development or test?
Clarity is just another way in which one person or group try to lay blame.
This newsletter is free to read, and it’ll stay that way. But if you want more - extra posts each month, access to the community, and a direct line to ask me things - paid subscriptions are $2.50/month. A lot of people have told me it’s worth it.
In 1944, the Wehrmacht launched into Hitler’s last ditch effort to save the Third Reich. The Battle of the Bulge was a doomed campaign and a doomed gamble from a doomed regime, but its brutality was a true second test of the US Army on the Western Front. During the battle, Army historian S.L.A Marshall began interviewing infantry companies who’d been baptised in combat. Published 3 years later in his 1947 book, Men Against Fire, Marshall’s research showed that just 15-20% of riflemen in active combat positions ever fired their weapons - most kept their heads down. They moved when they were ordered and they held their positions, and they mimicked the outward appearance of a soldier in battle - but shoot, they did not. By any standard organisational metric, the men were present and accounted for, but 4 out of 5 never pulled the trigger.
You can debate the extent of Marshall’s numbers, and you can debate his methodology, but his ratio shows up, again and again. IBM stumbled onto it in the ‘60s when they discovered that 80% of computer usage came from 20% of the system’s features. The pattern recurs because it describes something real about how effort is distributed inside groups, where a fraction of the people do most of the work, and the rest provide what you might ~charitably call “structural support.”
Anyone who has worked in any large organisation knows exactly what I’m talking about.
The modern tech industry looked at the problem of human coordination and participation and decided the solution was “collaboration.” If only 20% of us are operating with a “killer instinct” we need to be better at managing the shared instincts of the other 80%. And so collaboration became our shared obsession. We pursue “teamwork” as a holy grail.
The teamwork revolution, if you can call it that, gave us Notion for our documents, ClickUp for our tasks, Slack for our conversations, Jira for our tickets, Monday for our boards, Teams for the calls that should been emails, emails for the things that we couldn’t squeeze in anywhere else, and now agents attempting to re-invent the whole stack. The average knowledge worker maintains accounts across system after system, switching between applications hundreds of times per day. And they produce, in aggregate, a staggering amount of coordinated and collaborative activity that never actually becomes anything resembling ~output.
When you strip away the product marketing and the dev relations and the blog posts and the funding rounds and the fuckery-upon-fuckery of it all, we’re left with a simulation of collective engagement - but very little else. Transparency got confused with progress, visibility got confused with accountability, and being included in the thread became the same thing, socially and organizationally, as owning the outcome.
Once that confusion set in at the cultural level it became nearly impossible to dislodge. The feeling of collaboration is pleasant in a way that personal accountability can never be. Owning something means you, specifically and visibly you, can fail at it, specifically and visibly, in ways that attach to your name.
Collaborating means the failure belongs to the process.
So everyone chose collaboration, and we called it culture.
Marshall's riflemen were ordinary people responding to the diffusion of responsibility that happens inside any group. Maximilien Ringelmann measured the same phenomenon with ropes in 1913, long before there were Slack workspaces to offer an emoji-react to it. Individual effort drops predictably as group size increases. The presence of others dissolves the sense of personal responsibility in a way that feels, to everyone experiencing it, entirely reasonable. You're part of a team, you're contributing, you're also (measurably) pulling less hard than you would if the rope were yours alone. Every single person on the rope is doing this simultaneously, which is why the total force never adds up the way the headcount says it should.
Frederick Brooks identified the same dynamic in software development in 1975, watching IBM's System/360 project illustrate his emerging thesis that adding people to a late project makes it later. Communication overhead grows faster than headcount, coordination costs compound, and every new person contributes their capacity along with their relationships to everyone else. Those relationships require maintenance and produce misalignment and generate the need for more meetings to address the misalignment those meetings created.
Brooks might as well have described your company's Q3 roadmap planning cycle and your startup's sprint retrospective, all of which have gotten longer every year and produced, relative to their investment, less.
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.
Communication matters, and shared context matters. 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. They’ve constructed extraordinarily sophisticated machinery for the social management of work, without actually doing the work they’re socialising about.
If and when it exists, ownership looks like an individual who deeply gives a shit, making a call without waiting for group-consensus. That individual will be right sometimes, and they’ll be wrong other times, and they’ll own it. They won’t sit around waiting to find out who has the authority to move a card from one column to another and post about it in the #celebrations channel.
But being that person sucks when “collaboration” is the reigning value, because 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.
You can see this excess everywhere. Standups where people announce their busy work and as long as everyone’s “on the same page” nobody changes course. Documents that are written to perform thinking so somebody else can perform thinking, with no decision in sight. Retros, and kickoffs, and WIP meetings that spawn their own retros, kickoffs and WIP meetings like cells dividing and re-dividing, with zero connection to the work that it’s nominally organising around.
Every project now seems to carry more coordination overhead than execution time, and when it fails the postmortem just recommends more collaboration...
At some point (and I think that point was fucking yesterday) we have to ask ourselves - what are we actually producing and who is actually responsible for producing it?
Because at some level, the answer for “who is responsible for X” has to be one single person, no matter how much the collaborative apparatus layered over modern work has been engineered to make that person invisible and dissolve accountability.
We need to find some path back to trusting that individuals will do their jobs, without every responsibility being visible to an entire organisation, without follow-ups being scheduled by a cadre of overpaid managers with their overfed metrics.
Maybe - just maybe - we could make our lives a little easier. Maybe we could let human beings keep their own lists of tasks, and we could let them sink or swim by how they manage those tasks, and we could assign blame to them and to them alone when they fuck up. Maybe we could do it without needing to have team-level views of every Kanban, calendar and task list. And maybe - if we let go of the warm, expensive fiction of collective endeavour - we could make it a little easier to see who among us are pulling the trigger and who are just keeping their heads down.