The Anti-Headcount Manifesto
More people add capacity, but they also add coordination. Architecture decides how much of the work reaches the product.
A feature becomes an org chart
The industry often responds to more work with more people. A feature becomes a team, the team needs a platform, and the platform needs coordination. You started with a product requirement and ended with an organization chart.
Company size can look like a proxy for capability. Additional people add capacity only after onboarding, coordination, and shared context are paid.
People are not overhead. Systems and organizations create overhead. Our answer is to reduce the work that exists only because those systems became large.
Where the time goes
Some engineering time is created by how the product is built rather than by the product itself.
Teams evaluate, update, patch, and debug outside libraries. Build systems, delivery pipelines, containers, monitoring, and configuration all need maintenance. Engineers debug framework internals and work around general tools that do not fit the product. As ownership spreads, changes require more planning, handoffs, reviews, and context rebuilding. A Microsoft study of Windows development found that organizational structure helped predict engineering outcomes.
Hiring into that work can create more coordination, and pressure to hire again.
What a small team changes
Removing package work, shortening the build, reducing layers, and keeping ownership broad all return time to the product.
Many design choices remain conversations rather than coordination projects. More of the team can understand a change end to end. The person who encounters a problem can follow it through the system and fix it without first routing it across an organization chart.
Language models can accelerate first drafts for well-specified work; the argument for that is in the thesis. Specification, testing, review, and responsibility remain human. A small team's constraint is often implementation bandwidth. A larger organization may remain limited by coordination, so faster code generation does not translate into proportional output.
Some products need more people because the domain is broad, deadlines overlap, regulation requires separate roles, or users need continuous support. Products that require constant human coverage must staff it. Simpler systems do not repeal the need for sleep.
Small teams also have less redundancy. Readable code, tests, shared ownership, automation, and durable decision records reduce that risk. They do not eliminate it.
We will hire when the mission needs more people. Hiring to expand capability is different from hiring to manage accidental complexity.
Grow the mission. Do not grow the overhead.