See how Alex worksWork with Alex
All frameworks

Framework

The 20-30 Person Fracture Point

"Treat 20–30 people as a prompt to inspect coordination needs, not a measured breaking point. The company cases support explicit documentation, ownership and communication norms; they do not establish a universal threshold or when every company first adopted those systems."

A working hypothesis and diagnostic guide for growing distributed teams. Uses documented company practices to suggest what to inspect as coordination becomes harder, while separating those examples from unverified claims about headcount thresholds and founder histories.

By Alex Karasyov — Operating consultant for product & engineering teams

Last reviewed September 12, 2026

Diagram · Inference

Inference — an illustrative sketch of the framework's working hypothesis: growth may expose gaps in informal coordination, and explicit practices may help. The 20–30 range is a prompt to inspect the work. The curves are not measured costs or predicted outcomes; their shapes and intersection establish no failure threshold or required intervention.

Thesis

[Inference — working hypothesis.] Growth can expose gaps in ownership, written context and communication norms. Use the 20–30-person range as a prompt to inspect those systems, not as a measured threshold at which every distributed company breaks.

The companies on this site publish examples of explicit operating practices. They are a small, selected set, largely from software. Their present systems do not establish that each company experienced the same failure point, built those systems before reaching it, or succeeded because it adopted them at a particular headcount. No survey of failed companies or founder-interview dataset underpins this framework.

Symptoms

[Inference — diagnostic examples, not reported incidents or measured prevalence.] Look for coordination costs in the work itself:

  1. Unclear ownership. People disagree about who can make a decision or move a project forward.
  2. Missing decision records. A decision travels through several conversations without its reasoning being recorded.
  3. Repeated onboarding questions. New hires depend on informal explanations for recurring tasks and expectations.
  4. Uncoordinated dependencies. Teams use different rhythms without explicit handoffs or shared review points. Different cadences alone are not evidence of failure.
  5. Uneven context. A policy or priority is familiar to one group and unknown to another.
  6. Fragmented records. People cannot find the current decision, owner or plan across the tools they use.

These symptoms can occur below or above 20–30 people. Diagnose their frequency and cost before choosing an intervention.

Root Causes

[Inference — hypotheses to test locally.]

  • Context may depend on too few people. If routine work waits for a founder’s explanation, identify what could be documented or delegated.
  • Access to context may be uneven. People in different time zones or newly hired roles may lack information available to an established group.
  • Ownership may have changed without an explicit handoff. Inspect who has authority now, rather than assuming early informal arrangements still apply.
  • Documentation may lack a maintainer. A growing archive is useful only if readers can identify what is current.

The cases do not establish a universal hiring personality, founder background or sequence in which these causes appear.

What Companies Get Wrong

[Inference — implementation cautions.]

  • Adding a process before defining the need. Identify the missing decision, context or handoff before choosing a ritual.
  • Choosing tools before maintenance responsibilities. Define what must be recorded and who keeps it current.
  • Copying an entire larger company’s system. Evaluate the specific practice against the team’s work and resources.
  • Waiting for a particular headcount. Visible coordination costs are a better trigger than treating 20, 30 or 150 people as a proven boundary.

What Works Instead

[Inference — a proposed starting set, not a proven minimum or universal recipe.] Inspect five areas:

1. Findable, maintained records. GitLab’s handbook, 37signals’ written workflows and Automattic’s P2-based records provide different examples. Automattic also uses Linear and chat tools; a canonical decision record does not require every interaction to live in one tool. (GitLab, 37signals, Automattic)

2. Explicit decision authority. GitLab documents DRIs. 37signals’ manager-of-one concept addresses self-direction and is not an interchangeable formal DRI role. The reviewed Zapier primary supports defaulting to action and working in public, not a universal DRI-plus-single-page-spec rule. (GitLab DRI, 37signals, Zapier)

3. Communication routing. Buffer’s 2023 account used Slack for short or urgent messages, Threads for longer or non-urgent discussion and Zoom or phone for complex urgent discussion. Treat the named tools as a historical example. [Inference.] Write current routing and response expectations for your own team. (Buffer)

4. Planning and handoffs. 37signals uses six-week build cycles and two-week cooldowns. GitLab publishes nested horizons from weeks to thirty years. Doist’s September 2022 account describes DO cycles of one to six months; current onboarding references cycle planning but does not publicly establish the exact present cadence. These examples do not imply one rhythm works for every function. (37signals, GitLab, Doist 2022, Todoist onboarding)

5. Structured onboarding. Written tasks and named support contacts appear in 37signals and Todoist’s onboarding. [Inference.] Define expectations and checkpoints for the role; a first-90-days guide does not establish a universal time to full productivity. (37signals, Todoist, onboarding evidence)

Company Evidence

37signals / Basecamp publishes written working practices and has described operating without full-time managers. This supports a documented example of self-direction; it does not date adoption of all five components to a specific early headcount. (Handbook, DHH’s account)

GitLab reported 2,580 team members across 60 countries at January 31, 2026 and publishes extensive operating guidance. This establishes documented operation at scale. The filing does not establish a 20–30-person fracture point or the causal effect of early documentation. (Filing)

Todoist (formerly Doist) currently lists 108 people in 38 countries and publishes a public handbook. These sources do not establish a specific 20/30-person hiring decision or the timing of process adoption. (About, handbook)

Automattic currently lists 1,422 people and describes written workflows, trial hiring and support rotations. The current snapshot is separate from the April 2025 restructuring; the sources reviewed here do not establish that every current practice existed at exactly 100 people. (About, working practices)

Founder Actions

[Inference — implementation guidance.]

  1. Review recent delayed decisions and repeated questions. Identify the most expensive recurring gap.
  2. Make ownership and authority explicit for the affected work, including handoffs when they change.
  3. Record decisions and reasoning where the relevant people can find them; name a maintainer for durable guidance.
  4. Publish communication routes and response expectations, including when a live discussion is useful.
  5. Clarify planning dependencies and onboarding checkpoints. Use company examples as options, not compulsory templates.
  6. Test one change and inspect its effect before expanding it. The evidence does not prescribe ten minutes per project, three cycles of testing or a year-long recovery schedule.

Where This Framework Breaks

  • As a measured threshold. The evidence does not establish that failure begins at 20–30 people, or that communication, ownership and culture fail in a fixed headcount sequence.
  • As a causal success story. Current handbooks do not establish when a practice was introduced or what would have happened without it.
  • Outside the case mix. Client services, hardware and work requiring simultaneous action may have different coordination needs from these software-company examples.
  • As a rigid size rule. A small team can benefit from explicit ownership, and an organization above 200 can improve documentation. The useful unit is the coordination problem.
  • As a substitute for capacity or organizational design. [Inference.] A routing guide cannot by itself resolve missing skills, conflicting priorities or unclear management authority.

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/
  6. Buffer is Remote but not Async-First: https://buffer.com/resources/remote-not-async-first/

GitLab DRI: https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/

Zapier async: https://zapier.com/blog/how-to-work-asynchronously

GitLab cadence: https://handbook.gitlab.com/handbook/company/cadence/

Doist September 2022 accountability: https://async.twist.com/accountability-remote-workers/

Todoist onboarding: https://handbook.todoist.net/s/6ca6f66e-2d02-4e05-b629-b1c772f5ff23

Todoist About: https://www.todoist.com/about-us

Todoist handbook: https://www.todoist.com/handbook

GitLab FY2026 filing: https://www.sec.gov/Archives/edgar/data/1653482/000162828026018731/gtlb-20260131.htm

Automattic About: https://automattic.com/about/

Automattic working practices: https://automattic.com/how-we-work/

37signals — Getting Started: https://books.37signals.com/3/the-37signals-employee-handbook/7/getting-started

Inferences

  • Growth may expose reliance on informal context; inspect the work rather than predicting a fixed failure threshold.
  • Maintained documentation, explicit authority and communication norms are plausible responses to specific coordination gaps. The company examples do not establish a universal minimum system or the effect of adopting it at a given size.

Work with Alex

If growth is making coordination harder, Alex helps leadership teams identify gaps in ownership, communication and documentation, then test a proportionate operating system.

frameworkscalingleadershipplanningcommunicationdecision-making

Last reviewed September 12, 2026