Frameworks
Cross-company patterns synthesized from evidence
Frameworks derived from comparing how multiple distributed companies solved the same problems — with company evidence, not consulting theory.
Framework
The 20-30 Person Fracture Point
Across the distributed companies on this site, a recurring pattern surfaces between 20 and 30 people: the informal coordination that worked at 10 people breaks down, and the companies that scaled cleanly had explicit operating infrastructure in place before that point. This is a cross-company hypothesis grounded in the cases here — not an empirical finding from a survey.
Companies that scaled distributed work successfully — at least in this dataset — built explicit operating infrastructure before reaching 20–30 people. Companies that struggled at that scale hit a recurring set of failure modes: invisible ownership, fragmented communication, lost institutional knowledge, cultural drift. This framework states the pattern as a working hypothesis and lays out what to build before you hit it.
Read frameworkFramework
Scrum in Distributed Companies: What Survives, What Breaks, What to Adapt
Scrum's empirical core — Transparency, Inspection, Adaptation, plus the Sprint Goal, Definition of Done, and Product Owner accountability — is what every high-performing distributed company actually runs on, even when they don't call it Scrum. The events around it (especially the Daily Scrum) and the LeSS co-location rule are pre-distributed prescriptions that the strongest distributed companies have replaced. Keep the core, adapt the events, drop the co-location guidance.
A source-backed audit of which Scrum elements strengthen distributed execution, which conflict with it, and how distributed-native companies (GitLab, 37signals, Linear, Doist) achieve Scrum's intended outcomes through adapted mechanisms. Triangulates the Scrum Guide 2020, Scrum.org and Scrum Alliance distributed guidance, the Scrum@Scale Guide, LeSS principles, and peer-reviewed empirical research.
Read frameworkFramework
Sync vs Async Decision Matrix
The question is never 'should we be async-first?' — it is 'which situations require real-time coordination, and which can be handled better in writing?' Every strong remote company has answered this question explicitly. Most companies haven't.
A practical decision matrix for choosing between synchronous and asynchronous communication — built from the operating practices of 37signals, GitLab, Doist, Buffer, and Zapier. Includes symptom checklist, situation-by-situation guidance, and a framework for setting team-level communication norms.
Read framework