Small Teams Beat Large Organizations

The Basecamp Origin Story

Basecamp (originally 37signals) started as a web design agency. They built a simple project management tool to solve their own problem: keeping client projects organized without drowning in email.

That constraint—being small—shaped everything about the product and company. No massive features that needed dedicated teams. No complex organizational hierarchies. Just a handful of people building software that worked.

The Facebook Problem

DHH contrasted Basecamp's approach with what happens at big tech companies like Facebook:

Each person is a specialist. Each has their own concerns, their own backlog, their own meetings. Shipping a feature means coordinating across all of them. Calendar Tetris becomes the actual job.

The irony: much of the tooling complexity we inherit (React, GraphQL, microservices) exists to mediate between these specialists. Most teams don't have 15 specialists. They have 3-5 generalists. They're using tools designed for problems they don't have.

Why Small Teams Win

1. Communication Overhead Is N²

Every person added to a team increases communication paths exponentially. A 5-person team has 10 communication paths. A 10-person team has 45. A 15-person team has 105. Each path is a potential miscommunication, a meeting, a Slack thread.

# Communication paths = n(n-1)/2

Team Size | Communication Paths
----------|--------------------
    3     |          3
    5     |         10
    7     |         21
   10     |         45
   15     |        105
   20     |        190

# Each path is overhead. Small teams minimize overhead.

2. Generalists Ship Faster Than Specialists

A small team of generalists can build an entire feature without handoffs. One person might do the database schema, API, and frontend. No waiting for the "frontend team" to pick up a ticket. No miscommunication between backend and frontend about the API contract.

3. Ownership Creates Quality

When one person owns a feature end-to-end, they feel responsible for it. They fix bugs quickly because they remember writing the code. They optimize because they see the whole picture. Diffuse ownership creates diffuse responsibility—and bugs become "someone else's problem."

4. Less Process, More Output

Large teams need process: sprint planning, backlog grooming, standups, retrospectives, all-hands, 1:1s. Small teams can just... build. When everyone knows what's happening, you don't need ceremonies to communicate it.

The Economics of Team Size

There's also a business case for small teams:

Basecamp makes tens of millions in annual revenue with a small team. That's not just profitable—it's life-changing wealth for everyone involved. A VC-funded company with 200 employees making the same revenue would be considered a failure.

How to Stay Small

Staying small requires intentional decisions:

1. Say No to Features

Every feature is a commitment. It needs maintenance, support, documentation. Small teams can't do everything—so they do fewer things better. Basecamp famously says no to most feature requests.

2. Hire Generalists

Look for people who can do multiple things well rather than one thing perfectly. A developer who can also write, design a bit, and talk to customers is worth three specialists.

3. Keep Technology Simple

Complex technology requires specialists to maintain it. Microservices need platform engineers. Kubernetes needs DevOps. Monoliths running on simple servers? A generalist can handle that.

4. Resist the Growth Imperative

The default assumption is: more revenue → more people → more revenue. But it's a trap. More people means more overhead, more complexity, more process. Sometimes the best move is to stay the same size and improve margins.

The Counterargument (And When It's Valid)

Not every company can or should stay small:

• Winner-take-all markets: If you're racing competitors for market share, speed matters more than efficiency.
• Platform plays: Building an ecosystem (like AWS or Shopify) genuinely requires scale.
• Regulated industries: Compliance requirements often mandate specialized roles.
• Global operations: Operating in 50 countries requires localization, legal, and support teams.

But here's the thing: most startups aren't in these categories. Most are building SaaS products for niche markets where a small team could dominate.

The Small Team Advantage

DHH and Basecamp have proven for two decades that small teams can build world-class products. Not despite being small—because of it. Less communication overhead, more ownership, faster decisions, simpler technology.

The venture capital model pushes companies to grow headcount, often before they need to. But growth isn't always the answer. Sometimes the answer is staying small, staying profitable, and building something that lasts.