How Many People Do You Actually Need?

Fewer than a functional org chart implies, because a large share of a conventional headcount plan exists to service handoffs rather than to build anything. Start from the outcomes the product must deliver, give each one an owner, and add people only where an owner is genuinely capacity-bound rather than coordination-bound.

That distinction is the whole exercise. Capacity-bound means the work is too much for the person. Coordination-bound means the work is waiting on somebody else. They feel identical from inside a standup and they have opposite solutions.

Build the plan from outcomes, not functions

A functional plan asks how many engineers, designers, and marketers you need. It produces a chart that looks reasonable and encodes a delivery model nobody chose deliberately.

An outcome plan asks what the product must do for a customer, then who owns each of those things end to end. The headcount falls out of that rather than being decided in advance. It is a less comfortable process because it exposes outcomes that currently have no owner, which is usually where the real problem is.

What this produces in practice is smaller than expected. Companies reaching $10M ARR in 2025 can do so with teams of 8 to 12 people (Advertising Week, 2026). That is not a target to copy, but it does establish that conventional headcount curves are a choice rather than a requirement.

Stop copying ratios

Engineer-to-everything-else ratios circulate constantly and are close to useless transplanted. A ratio encodes how a specific company delivers a specific product, including how much of its delivery is automated and how much of its sales is self-serve.

Derive yours from queue position instead. Look at where work actually waits:

• Waiting on engineering to ship things the market already wants: you are under-weighted on engineering, or over-weighted on people generating demand for capacity you do not have.
• Engineering shipping faster than you can sell, onboard or support: the ratio is wrong in the other direction, and adding engineers will make the imbalance worse.
• Work waiting between functions rather than inside them: the ratio is not the problem at all. The boundaries are.

The check that separates lean from claiming to be lean

Track two counts over time: roles whose output is production, and roles whose output is alignment. Then watch which one grows faster as headcount rises.

A genuinely lean org holds coordination roughly flat while delivery grows, because it removed boundaries rather than staffing them. An org that bought tooling and kept its structure sees coordination grow in step with headcount, and reports productivity gains that never show up in delivery speed.

A practical gate: require any proposed coordination role to name the specific handoff it exists to bridge, and explain why that handoff cannot be removed instead. Most cannot survive the second half of that question.

Where small teams actually hit a wall

Worth being precise about, because the optimistic version of this argument overreaches.

Very small teams do not usually fail on throughput. They fail on the number of independent decisions a handful of people can hold at once. Each additional product line, customer segment, or compliance regime adds decisions, and decisions do not compress the way production does. That is the ceiling, and it arrives before capacity does.

Common questions

What's the minimum team size to compete as an AI-native startup?

Smaller than most planning assumes, and bounded by decisions rather than throughput. Teams reaching meaningful revenue with under a dozen people are now common where the product is narrow and go-to-market is self-serve. The constraint that appears first is the number of independent decisions a small group can hold at once, not the volume of work they can produce.

What's the right headcount for each function at 100 employees?

There is no correct distribution, because it depends on what the company sells and how it is delivered. A useful check is the ratio of people producing to people coordinating. If coordination roles grew faster than delivery roles between 50 and 100 people, the structure is absorbing the headcount rather than the market.

What is the right ratio of engineers to other roles at Series B?

Ratios copied from other companies mislead, because they encode a delivery model rather than a rule. Derive yours from where work waits: if delivery is queued behind engineering, the ratio is wrong in one direction; if engineering ships faster than the company can sell or support, it is wrong in the other.

How do I build a team that's actually lean due to AI, not just claims to be?

Measure the ratio of producing to coordinating roles over time, and require any new coordination role to name the handoff it exists to bridge and why that handoff cannot be removed. Companies that are genuinely lean removed boundaries. Companies that claim to be lean bought tools and kept the boundaries.

How many people do you actually need to build the product?

Fewer than a functional org chart implies, because much of a conventional headcount plan exists to service handoffs rather than to build. Start from the outcomes the product must deliver, assign each an owner, and add people only where an owner is genuinely capacity-bound rather than coordination-bound.