The 20-30 Person Fracture Point

Thesis

This framework is a synthesis across the distributed companies on this site, not the result of a representative survey. Read it as a working hypothesis: the pattern recurs cleanly enough across the cases we cover that it is worth naming, and the prescription that follows holds up against each of those cases — but the underlying claim (“a fracture point exists in the 20–30 range”) is an inference from a small, biased sample of companies that did publish operating documentation. Companies that quietly failed at this scale do not write handbooks about it.

With that caveat: across the cases on this site, a recurring pattern surfaces. Each distributed company has a fracture point — a headcount threshold where the informal operating system that worked in the early days breaks down. In the cases we have studied, that point arrives between 20 and 30 people.

The fracture is not caused by growth. Growth is the catalyst that reveals whether the operating infrastructure exists. The actual cause is the invisible transition from a coordination model based on proximity and shared context to one that requires explicit, documented, maintained systems.

Colocated companies hit this fracture too — but they have the office as a buffer. Physical proximity masks coordination failures: you overhear a conversation, you catch a colleague at the coffee machine, you walk past a whiteboard and get the context you needed. Distributed companies have no buffer. When informal coordination breaks, it breaks completely.

The companies in this dataset that scaled distributed work successfully — 37signals, GitLab, Automattic, Doist, Zapier — all have one thing in common: they built explicit operating infrastructure before or at the fracture point, not after.

Symptoms

If your company is approaching 20–30 people and you are seeing these patterns, the fracture is either in progress or imminent:

1. “Who owns this?” is a question without a consistent answer. Projects exist with no clear DRI. Everyone assumes someone else is on top of it. Work disappears into the organization.

2. Key decisions are made in conversations that nobody records. The CEO made a product decision in a 1:1, then told someone else in a Zoom call, then the engineering team found out from Slack three days later. The decision trail is invisible.

3. New hires cannot figure out how to work without extensive hand-holding. Because the operating system is not written down, onboarding requires the existing team to transmit knowledge verbally — each time, for each new person.

4. Different teams are running on different rhythms. Engineering is doing two-week sprints. Marketing has monthly planning. Sales runs weekly. Nobody knows what everybody else is working on until the quarterly all-hands.

5. “Everyone knows” knowledge turns out not to be universal. A team member describes a company policy or process that has changed — and three others look surprised. What “everyone knows” is actually only known by the people who were in the room when it was decided.

6. Communication has fragmented across too many tools. Decisions are being made in Slack, documented in Notion, tracked in Jira, and discussed in meetings whose notes live in someone’s Google Drive. Nothing is findable.

Root Causes

Informal coordination does not scale. At 8 people, everyone knows everything. You can hold the entire company’s context in your head. Decisions reach everyone via proximity. At 25 people, that is no longer possible — the context is too large, the decision volume is too high, and the informal network cannot carry the load.

Remote removes the passive coordination mechanisms. In an office, even a poorly organized company gets some coordination for free — people overhear, see, and bump into each other. Remote removes these passive mechanisms. Without active replacements, coordination fails.

Early-stage hiring over-selects for people who work well in informal environments. The first 10 hires of most companies are people who thrive in ambiguity, enjoy figuring things out, and do not need process. This is an asset at 10 people. At 25, it becomes a liability: these same people often resist the process infrastructure that the company needs.

Founders do not see the coordination overhead they are absorbing. At 15 people, the founder is often the informal operating system — they hold the context, make the calls, resolve the ambiguities. As the company grows, this is unsustainable and invisible until it becomes a crisis.

What Companies Get Wrong

They add process as the cure instead of as the symptom treatment. The right question is not “what process should we add?” but “what coordination need is not being met?” Process for its own sake at 25 people creates overhead that destroys the autonomy that made the company work.

They wait for the fracture before building infrastructure. The fracture point is too expensive to navigate in real time. Building documentation norms, communication systems, and decision ownership models at 30 people in crisis is much harder than building them at 20 people proactively.

They solve communication tools before communication norms. “We need a better wiki” is the wrong first step. The first step is: “what are we writing down, who writes it, and who maintains it?” Then pick the tool.

They copy bigger companies’ processes. A 25-person company that copies Atlassian’s project management system or Spotify’s squad model is importing organizational overhead designed for 5,000 people. The fit is wrong and produces bureaucracy without benefit.

What Works Instead

The minimum viable operating infrastructure for a 20–30 person remote company has five components:

1. Single source of truth. One canonical place for decisions and processes. Not the right Notion workspace or the best Confluence setup — whichever tool the team will actually maintain. The tool is secondary; the norm of writing decisions down and keeping them current is the practice.

Companies that have this: GitLab (handbook), 37signals (Basecamp), Automattic (P2 blogs). All three made the canonical-place decision early and maintained it.

2. Explicit decision ownership. For every significant project or decision: one named person owns it. Not the team. Not “leadership.” One person. When the owner changes, the handoff is explicit and documented.

GitLab calls this DRI. 37signals calls it “manager of one.” Zapier calls it DRI. The name does not matter; the practice is universal across the best distributed companies. ([Sources: multiple company pages])

3. A communication routing guide. Which tool for what type of communication. What the expected response time is. When synchronous is appropriate. This can be one page. Without it, every team member is making independent judgment calls that produce inconsistency.

Buffer published theirs: Slack for short/urgent, Threads for longer/non-urgent, Zoom for complex/urgent. (Source)

4. A planning cadence. A consistent, company-wide rhythm that creates six or so natural moments per year to make hard prioritization decisions. Not infinite roadmap refinement — a cadence that creates forcing functions for decision-making.

37signals: 6-week cycles + 2-week cooldowns. GitLab: nested quarterly/annual OKR cadence. Doist: heroes vs. housekeeping within cycles. ([Sources: company pages])

5. Onboarding infrastructure. A structured first-90-days experience that does not depend on whoever has time to answer questions. A personal onboarding checklist, named support contacts, real work in week one, and a 90-day check-in.

37signals’ Basecamp onboarding project and GitLab’s onboarding issue are both at this level. Neither is elaborate — they are simply designed.

Company Evidence

37signals / Basecamp — The five components above are all present, documented in their public handbook, and have been in place for most of the company’s 25+ year history. DHH explicitly states that the manager-less model would break at “hundreds or thousands of employees” — acknowledging the scale ceiling while demonstrating it works at their current size (~60). The systems were built early and have been maintained. (Source)

GitLab — Scaled to 2,500+ people all-remote with the handbook as the primary coordination mechanism. The handbook was started when the company was very small — the documentation culture was built before scale demanded it. The DRI model, meeting norms, and communication guidelines were all codified before they became critical at scale.

Doist — ~93 people, bootstrapped, 15 years of async-first. They credit their slow, deliberate hiring and early cultural investment for being able to maintain the operating model. The 20/30 person fracture point for Doist came when they needed to decide whether to hire faster (which would have required more process) or maintain the model by hiring slowly. They chose the latter. (Source)

Automattic — The large-scale evidence. At ~1,500 people (post the April 2025 restructuring, down from a 2024 peak near 1,900), they still maintain the P2 blog system, the trial project hiring process, and the customer support rotation that were all in place at 100 people. The systems that scaled were built before they needed to scale.

Founder Actions

Before 20 people:

1. Name a DRI for every active project. Put the name in the project doc. This takes 10 minutes per project and creates the habit before it becomes critical.

2. Write down three things: how decisions get made in your company, how work gets communicated, and where important information lives. These do not need to be long. One page each is enough to start.

3. Pick a planning cadence and enforce it. 6 weeks, 8 weeks, a quarter — it does not matter which. What matters is consistency. Hold to the cadence for three cycles before evaluating whether to change it.

At 20–30 people:

4. Define and publish your communication routing guide. Slack vs. written doc vs. video call — what goes where, why, and what response time is expected. Post it in your onboarding materials.

5. Build a structured onboarding process. A personal checklist, named support contacts, and a 90-day ramp expectation. The document should be maintainable by whoever owns People Ops — not dependent on the founder’s personal involvement.

6. Create a “decisions” document or channel. Every significant decision gets recorded with the reasoning. Not meeting notes — the decision itself and why it was made. This becomes the institutional memory that prevents revisiting resolved questions.

Where This Framework Breaks

This framework is a synthesis across companies that documented their operating systems. That sample is biased and the framework inherits the bias. Read this section before applying the prescription.

• Outside the dataset’s archetype range. The cited cases (37signals, GitLab, Automattic, Doist, Zapier) are mostly product-led software companies whose work is decomposable into self-directed contributions. The fracture-and-prescription pattern may not transfer cleanly to companies whose work depends on tightly coupled real-time coordination — sales-led organizations with shared pipeline ownership, agencies with concurrent multi-client billing, or hardware companies whose product cycles span years. Apply with skepticism outside the product-led software archetype.
• For companies that intend to grow past 200 quickly. The five-component prescription is calibrated for companies that will live in the 20–80 range for years (37signals, Doist) or that will scale with the operating infrastructure they build early (GitLab). If your plan is to triple headcount in 12 months on the way to 500+, the components still matter, but you also need explicit organizational scaffolding (formal management, divisional structure, dedicated People Ops) that this framework does not address.
• In organizations that already passed the fracture point. The framework is forward-looking — what to build before the fracture. If you are at 60 people and the symptoms in the page are already visible, retrofitting all five components in parallel is more expensive and politically harder than building them at 15. Sequence one component per quarter and accept that the recovery is a year-long effort, not a sprint.
• Where the founder is unavailable to model the new norms. Several of the cases (Basecamp DHH’s “manager of one,” GitLab Sid’s handbook discipline, Doist Amir’s hiring rigor) depend on the founder visibly operating to the new norms. Companies installing the components without founder behavioral consistency tend to find them ignored.
• As an empirical claim about the 20–30 range itself. The fracture range is a working hypothesis grounded in the cases on this site; companies that fail at this scale without publishing handbooks are not in the sample. Treat the range as an alert horizon rather than a measured threshold.

Do not apply this framework if: the company is below 10 people (over-engineered) or above 200 (too late for the framework as scoped); the work depends on tightly coupled real-time coordination that documentation cannot replace; or the founder is not in a position to model the new operating norms.

Sources

1. DHH on no full-time managers at 37signals: https://world.hey.com/dhh/we-once-more-have-no-full-time-managers-at-37signals-f8611085
2. 37signals Handbook: How We Work: https://basecamp.com/handbook/how-we-work
3. GitLab All-Remote Drawbacks: https://handbook.gitlab.com/handbook/company/culture/all-remote/drawbacks
4. How Doist Works Remote: https://doist.com/how-we-work/how-doist-works-remote
5. Expectations — Automattic: https://automattic.com/expectations/

Inferences

• The 20–30 person fracture point is not a single event — it is a range where different failure modes surface at different times. Communication fragmentation typically appears first (around 15–20 people). Ownership ambiguity follows (20–25). Culture dilution emerges last (25–35). Companies that watch for these in sequence can address each before the next arrives.
• The companies that navigate the fracture point most successfully are the ones whose founders experienced a version of it in a previous company or role. They knew what was coming and built the infrastructure proactively. The founders who have only known their current company tend to discover the fracture point by experiencing the failure, not by anticipating it.
• Building operating infrastructure at 10 people feels like over-engineering. This is the trap. The time to establish writing norms, decision ownership, and communication routing is before the coordination volume makes them necessary — because once the volume arrives, there is no time to build them carefully.

Work with Alex

If your company is approaching the 20–30 person threshold and you want to build the operating infrastructure before the fracture rather than after, Alex helps leadership teams design the minimum viable operating system for distributed execution at scale.