Collaboration sucks

What “collaboration” means in the thread

• Many argue the article attacks performative collaboration: big meetings, “culture of feedback,” mandatory approvals, and bikeshedding, not genuine joint work.
• Several commenters distinguish between:
  • Collaboration (working jointly toward a shared goal)
  • Feedback / review (input to a single owner)
  • Design‑by‑committee (no clear decider, diluted responsibility).

Critiques of collaboration-as-practiced

• Recurrent complaints:
  • Too many people in the room; combinatorial communication cost explodes.
  • “Concern-trolling” and FUD in reviews; nuisance employees derail progress and rarely get fired.
  • Managers who say “it’s your call” then second‑guess after the fact, forcing rewrites and killing ownership.
  • Bikeshedding (“why can’t you just…”, “all you gotta do is…”) and style nitpicks that should be automated with formatters/linters.
• Design‑by‑committee is seen as producing bland, incoherent products and fragmented codebases, especially when no one clearly owns decisions.

Arguments in favor of collaboration

• Many push back: lack of collaboration leads to silos, fragile “hero” systems, low bus factor, misaligned features, and harder on‑call incidents.
• High‑reliability domains (spacecraft, medical, safety‑critical infra) are cited as places where heavy collaboration, design review, and knowledge sharing are essential.
• Collaboration is framed as a key mechanism for learning, catching bad ideas early, integrating subsystems, and incorporating diverse perspectives.

Ownership, decision making, and “driver” models

• Strong consensus that the real problem is unclear decision authority, not collaboration per se.
• Popular patterns:
  • One “driver” / “informed captain” / RACI‑style owner per project, with others offering input but not vetoes.
  • “Gravitational pull” / small core circles: a few defined stakeholders (e.g., tech lead, business owner, target user).
  • Arbitrator style: collect feedback, then one person decides; avoid mediator/consensus-by-default.

Processes and team structures

• Some advocate: “ship first, iterate later,” with feedback after release to avoid pre‑ship approval thickets—others worry this is incompatible with quality- or safety‑critical work.
• Counter‑pattern: upfront design docs or “empty PRs” for important changes, reviewed by a small group, then code. Seen as high‑leverage collaboration.
• Pair or mob programming is offered as a middle ground: tight collaboration in very small groups, fast learning, and shared context without large‑room thrash.

Context and nuance

• Many stress “it depends”: on company size, domain risk, codebase complexity, and hiring bar.
• Some see the article as helpful clickbait to counter “conspicuous collaboration”; others call it reductive, even “poisonous,” if taken as a universal rule rather than an argument for clearer ownership and less bureaucracy.