November 16, 2025
Process vs Panic: Fight!
How to Scale Distributed Product Teams from 10 to 100
From small crew to big ship: plans praised, cleanup chaos sparks a comment war
TLDR: A new guide says remote teams must split into small groups, write everything down, and plan one size ahead. Commenters agreed on planning but clashed over “cleanup time,” with many saying that budgeting 20–30% for fixes sounds great—until real-world fires make it the first thing cut.
Scaling a far-flung product team from 10 to 100 just got a playbook, and the crowd had feelings. The guide name-drops winners like Stripe, Notion, and Linear, then lays out simple steps: break into small “squads,” group them into larger “tribes,” and keep craft communities called “chapters.” Go all-in on writing: RFCs (request-for-comments docs), product briefs, decision logs. Set “team APIs” (clear rules of engagement) and even trim meetings to 25 or 50 minutes. Fans cheered: finally, a map for remote chaos.
But the comment section turned into group therapy. One voice, ift, pushed the big idea: plan for the next size up—don’t wait. The flashpoint: the guide’s call to reserve 20–30% of time for cleanup and platform fixes. Willio58 said the quiet part out loud: once emergencies hit, “cleanup time” is the first to get cut. Cue the “meeting about meetings” jokes and gallows humor about “we’ll document it later.” Camps emerged: the write-it-down diehards vs. the process skeptics who fear paper pushing. Still, most agreed that distributed growth needs structure, or you end up with ping-ponging DMs, mystery decisions, and very loud Slack channels. The vibe: solid roadmap, but the real boss is chaos—and it doesn’t book meetings.
Key Points
- •The guide advocates planning for the next growth stage while operating in the current one, as practices break at higher team sizes.
- •Stage 1 (10–30): Establish autonomous squads (5–8 people) with clear ownership and roles; adopt decision frameworks like RAPID; create foundational playbooks.
- •Stage 2 (30–75): Implement tribes and chapters to balance autonomy and consistency, providing functional communities and career paths.
- •Adopt async-first communication: use RFCs, product briefs, weekly written updates, decision logs, and rigorous meeting hygiene.
- •Define Team APIs to clarify ownership, request processes, SLAs, and escalation paths, illustrated by a Platform Squad example using GitHub and Slack.