Small Teams That Ship Will Win. Big Teams Are Overhead.

There's a hiring reflex in startups that kicks in the moment things get busy. The roadmap grows, the backlog expands, someone says "we need more engineers", and suddenly you're interviewing, onboarding, running more standups, and shipping slower than you were with half the people.

The best teams I've worked with and built have been small. Three, four, five people. Senior, autonomous, moving fast. And they consistently outship teams three times their size.

This isn't anecdotal. There's a structural reason for it.

The coordination tax is real

Every person you add to a team increases the number of communication paths exponentially. Two people have one path. Five people have ten. Ten people have forty-five. Each path is a potential misunderstanding, a meeting to align, a Slack thread that needs context.

Most large engineering teams spend more time coordinating than building. Standups, sprint planning, retros, cross-team syncs, dependency meetings, architecture reviews with twelve people where three are relevant. The calendar fills up, and the IDE stays closed.

Small teams don't have this problem. Everyone knows what everyone else is doing. Context is ambient. Decisions happen in minutes, not meeting cycles.

AI changed the economics of team size

The reason small teams can compete with large ones now, in a way they couldn't five years ago, is AI.

I use Claude across every part of my workflow. Data extraction that would need an analyst runs through a prompt. Code review that would need a senior engineer gets a first pass from an AI agent. Design-to-code translation that used to require hours of back-and-forth is collapsing as Figma MCP lets agents read design files directly.

This isn't about replacing people. It's about not needing to hire for tasks that AI handles better, faster, and more consistently than a junior hire would.

When every person on a team is senior and autonomous, and AI handles the multiplier work, you don't need the extra headcount that traditionally came with scaling. You need fewer, better people with better systems.

Async by default

The small teams that ship fastest tend to work asynchronously. Written updates, not spoken ones. Context in tickets, not in someone's memory of a call. Video walkthroughs when something needs explaining, watched when the recipient is ready, not when a calendar invite demands it.

Calls happen when there's a specific reason — an architecture decision, a live demo, something that genuinely needs real-time back-and-forth. Not as a default ritual.

A 30-minute sync with five people isn't 30 minutes. It's 2.5 hours of collective time, plus context-switching on both sides. Small teams avoid this cost because there's nothing to sync — everyone already has the context.

What small teams need to get right

This doesn't work with any small group. It works because of a few things:

Everyone is senior and autonomous. Nobody waits for instructions. If something's unclear, they figure it out or ask a specific question. There's no room for passengers.

Written communication is non-negotiable. If you can't write a clear ticket description or a concise status update, async falls apart. The quality of your writing is the quality of your coordination.

Tooling is tight. One project management tool, one communication tool, one design tool, AI for everything that multiplies output. No tool sprawl. No "let me check the other system."

Trust is the operating system. Track what shipped, not when someone was online. If the work is done and it's good, nothing else matters.

The shift

The companies that will move fastest in the next five years won't be the ones with the most engineers. They'll be the ones with small, senior, AI-native teams that carry almost no coordination overhead.

Headcount used to be a proxy for capability. It's becoming a proxy for bureaucracy.

Ship small. Stay fast. Let the big teams schedule another meeting about it.