Why Small Teams Outpace Large Ones

The Scaling Paradox

It feels intuitive: more developers on a team should mean more code, more finished features, faster results. In practice this works far less directly, and the gap between that expectation and reality is worth unpacking before talking about what small teams actually get right.

It helps to separate three things that easily get blurred together: the number of people on a team, the team's output, and the speed at which a result actually reaches a user. More people almost always means more total hours worked. But delivery speed isn't just a function of how much work gets done, it's also a function of how long it takes to start that work and carry it through to a finished decision.

This is the same mechanism I go into in more detail with an AI lens in the piece on how AI is changing engineering work: as a team grows, it's not just the volume of work it can handle that grows, it's the number of connections between its members, and part of the resource each new person brings goes to coordinating around the work, not to the work itself. Brooks's Law, named after Fred Brooks in his 1975 book "The Mythical Man-Month," describes the extreme case of this effect: adding people to an already-late project usually makes it later still, because new people first need context transferred to them, and that transfer eats into the time of the people already doing the work.

What follows: what this overhead is actually made of, where a small team gets a real advantage, and where "small" doesn't mean "fast."

Communication Overhead

Communication load grows faster than headcount, and that's not a metaphor, it's combinatorics. The number of potential pairs, "who needs to sync with whom on a given decision," in a group of N people works out to N(N-1)/2, a formula Brooks himself walks through in the same book: a team of five has ten possible two-way connections, a team of fifteen has a hundred and five. Tripling the headcount grows the number of connections that could in principle need syncing by more than tenfold.

In practice this shows up as more approvals and more discussion around decisions that used to get made in five minutes in one chat thread. Every new decision doesn't just need to get made, it needs its context passed to everyone it touches, and the more people that potentially affects, the more time goes into that handoff itself, not the decision.

There's a separate problem with communication chains. Changing one technical decision in a large organization rarely stays inside one team: it passes through several people and adjacent teams, each adding its own loop of sign-off before the decision can actually be implemented.

Context and Decision Speed

Building software takes more than understanding the immediate task. It takes shared context: the product's goals, its constraints, and the downstream consequences of a given technical choice. Without that context, a developer can execute the task correctly on its own terms and still make a call that clashes with the rest of the system or with business goals they simply weren't aware of.

A small team finds it easier to keep that context shared across everyone: five people can talk through the product informally, around one table or in one chat, and every such conversation automatically resyncs the whole group. Per John Sweller's Cognitive Load Theory, working memory is limited, and in a small group that context sync happens naturally, as a side effect of everyday conversation, with no dedicated effort required.

A larger group has to do the same job formally: writing documentation, specs, decision records, because informal conversation physically doesn't reach everyone the context matters to. Keeping those artifacts current becomes its own separate, visible line item in how time gets spent, not a byproduct of the regular work.

Shared context ties directly into a team's autonomy: the fewer decisions require sign-off outside the team, the fewer dependencies have to cross a boundary where context reliably gets lost or distorted along the way.

Fewer Dependencies, Fewer Blocks

A team's speed isn't just a function of how fast it does its own work, it's also a function of how much time it spends waiting on someone else's decision. Technical and organizational dependencies on other teams create exactly that kind of downtime: a developer or a small group hits a point where they physically can't move forward without an answer from an adjacent team, and work stops regardless of how fast that group itself operates.

Queueing theory explains why this waiting gets especially painful in busy organizations. Donald Reinertsen, in "The Principles of Product Development Flow," shows that wait time in a queue grows nonlinearly, exponentially, as a resource's utilization approaches full capacity. A team working near the edge of its capacity, typical for large organizations where every specialist is in demand, creates for everyone else a queue that grows faster than it looks like it should.

Small teams don't cut this problem by working faster on their own. They cut it by being able to form more autonomous zones of responsibility, where most questions get resolved without ever leaving the team and, as a result, never join someone else's queue.

Faster Feedback

A short loop between defining a task, building it, checking the result, and getting feedback changes the underlying economics of building software. The faster a team learns a given decision doesn't work, the cheaper it is to fix: a mistake caught within a day costs nowhere near what the same mistake costs when it surfaces weeks later, once something else has already been built on top of it.

A small group of people finds it easier to notice quickly that a chosen direction is wrong and change course: the decision doesn't need defending in front of a dozen stakeholders, each of whom has already sunk something into the prior plan. This ties directly into iterative development: the whole idea of short iterations only works when the feedback loop is genuinely short, not stretched out across sign-offs between stages.

Less Organizational Overhead

As an organization grows, it accumulates processes that become necessary mostly because of scale, not because of the work itself: extra layers of management, regular planning cycles, status reporting, syncs between teams that physically don't overlap during the day. Some of this is genuinely useful. A lot of it exists mainly because the organization has grown to a point where it would fall apart without formal coordination. The coordination itself rarely adds value to the product.

A small team can afford to keep a short chain between a decision and the action that follows it: if the person making the call is the same person implementing it, there's no intermediate link that needs convincing, sign-off, or scheduling around. Every extra layer between a decision and the action it triggers adds not just the time of that sign-off, but the risk that the decision gets distorted along the way.

Responsibility and Ownership

Team size ties directly into how much personal responsibility for the outcome an individual actually feels. On a small team, everyone's contribution is visible: if something breaks, it's usually obvious who's fixing it and why it's them.

As headcount grows, ownership dilutes. Psychologists call this the Ringelmann Effect, or social loafing: individual effort tends to drop as the size of the group someone works in grows, simply because their personal contribution to the outcome becomes less visible and less personally significant. The effect was first documented in 1913 in a rope-pulling experiment, but it applies to any collaborative work, software included.

Small teams are easier to tie to a specific outcome or a specific slice of the product: it's concretely "the two people who own exactly this," not a diffuse label like "the backend team." That tie shows up in the quality of decisions and in how fast someone reacts when something goes wrong. A result that clearly belongs to you gets fixed faster and more naturally than a problem in a system where responsibility is spread across a dozen people, none of whom feel it as theirs.

Fewer Approvals

Approving technical and product decisions is its own separate source of delay, not reducible to the plain communication load covered above. The difference is that approval doesn't just require passing along information, it requires getting someone's permission before acting at all, on top of just informing them.

A team that can make decisions on its own within its scope of ownership, and a team that depends on outside sign-off at every step, operate at fundamentally different speeds even with equally skilled people. Value stream mapping analysis of real development processes regularly finds that waiting on approvals and sign-offs eats up more of a task's total path from idea to production than the actual coding and testing. In one documented case, the share of time actually spent creating value rose from 21% to 71% purely by cutting the number of those waiting points, with no change to the volume of work itself.

There's a principle here that's easy to miss: speed isn't only a function of how fast a team executes an already-made decision, it's also a function of how fast it can make that decision in the first place.

Why Adding Developers Doesn't Always Speed Things Up

Scaling software development runs into a hard limit that has nothing to do with how well the team is organized. Amdahl's Law, originally about parallel computing, applies here directly: the speedup of the whole system is capped by the share of work that can't be parallelized at all, whether that's architecture design, final integration, or testing the system's key components. No matter how many people get added to a sequential, non-parallelizable stage, it won't go any faster.

There's a practical problem on top of that: splitting work into independent pieces rarely comes out clean. Splitting is almost always followed by integration, and the more independent chunks get built in parallel, the more expensive it gets to bring them back together, sync them, and hold onto a shared architectural picture across parts that different people built with different understandings of the details.

That reframes the intuitive formula "more people, faster" into something more accurate: speed comes not from the team with more people, but from the team with more genuinely independent streams of work that don't collide with each other at integration time.

Where Large Teams Are Still Necessary

None of the above turns a small team into a universal rule. There are real conditions where scale is justified: large products with several parallel tracks of development, work that simultaneously needs several highly specialized skill sets that simply don't fit inside one small group.

Tellingly, the actual source of the problem is usually how interaction between people is structured, not their raw number. A large organization split into isolated groups that barely talk to each other stays slow at any size. The same organization split into clear, autonomous zones of responsibility can move almost as fast as a small team, just at a bigger scale.

The logical move from there: restructure the organization so that small, relatively autonomous teams exist inside it. Cutting headcount mechanically doesn't fix the underlying problem on its own.

Small Autonomous Teams Inside a Large Organization

Nearly every practical approach to scaling development converges on the same idea: decompose a large organization into relatively independent teams instead of growing one big one. Matthew Skelton and Manuel Pais, in their Team Topologies framework, describe several types of such teams: some own an entire product stream, some take on a genuinely complicated subsystem, some provide a shared platform to everyone else, and some temporarily boost other teams with specific expertise. Different kinds of work call for different team types, and blending these roles into one blurry structure is usually exactly what produces that "we're big, but slow" feeling.

This only works with clear boundaries of responsibility between teams: if two groups are formally on the hook for the same thing, conflicts and repeat sign-offs are inevitable no matter how much autonomy each has on paper. Those boundaries are usually carried by APIs, service contracts, and documentation, mechanisms that let a team on the other side of the boundary rely on the contract instead of syncing every detail in person, every time.

There's a principle here that's easy to miss: team boundaries should line up with the boundaries of the system's independent parts wherever possible. Conway's Law also runs in reverse: if the product's architecture doesn't split into independent modules, trying to decompose the team into autonomous parts runs into the exact same dependencies as before, just now they sit between formally separate teams instead of inside one.

Where a Small Team Starts Losing

There's a flip side. A team that's too small can run short on the skills it actually needs, simply because the right specialization doesn't physically exist in any of its two or three people, and nobody inside the team can close that gap quickly.

This is where the bus factor kicks in: the risk that losing one key specialist, to burnout or to leaving, stalls critical work because domain knowledge ended up concentrated in a single head. On a team of two or three, this risk is a genuinely likely scenario, not a hypothetical: a vacation, an illness, or simply one person changing jobs can stall for weeks whatever was formally considered team-owned work.

Parallelism is limited too: with too few people, some work inevitably waits on a resource to free up, because the one person who can close a given task is already tied up with another. A small team loses exactly the advantage it's valued for in this case: the short loop from decision to result turns into a queue of one.

The right team size comes down to a balance between autonomy and enough throughput for the actual volume of work, not simply the smallest possible headcount.

What Actually Makes Small Teams Fast

Everything above adds up to one coherent set of factors, not a list of unrelated observations. Autonomy in decision-making: a team whose calls don't need to travel up a chain above itself. A clear zone of ownership: it's obvious who's on the hook for a specific outcome, concretely, not some abstract "the team as a whole." Shared context and understanding of the goals: every person holds not just their own task in their head, but why it matters to the product. A minimal number of outside dependencies: the team doesn't spend half its time queued on someone else's decision. A short feedback loop: mistakes surface in hours, not weeks. Simple communication with no redundant layers of sign-off: decisions get made in the same place they get discussed.

Self-service infrastructure reinforces that last point specifically: a team that runs its own CI/CD, deployment, and monitoring through an internal developer platform, instead of a ticket to a neighboring department, removes a whole class of outside dependencies physically, not just organizationally.

The Practical Test: Count Interactions, Not People

It's more useful to look at team size through the number of communication links and dependencies a single decision needs to travel from idea to execution, not through headcount.

"How many developers are working on the project" doesn't say much about speed on its own. The sharper question is "how many people have to interact for one specific decision to get made and carried out." A team of fifteen where any significant call is really made by two or three people functions, in practice, like a small team. A team of five where every decision needs sign-off from three outside parties functions, in practice, like a large and slow one, whatever the headcount on paper says.

Cutting the number of necessary interactions often has a bigger effect than simply growing headcount: adding a person to a team is easy, removing an unnecessary sign-off step from a process that's worked that way for years is usually much harder, and much more useful.

A personal example of this test taken to its limit: I run both my products, Cruxly and Planio, alone, and the question "who do I need to sync this decision with" literally doesn't come up. There's nobody to interact with. It has nothing to do with personal speed. This isn't a recipe for a ten-person team, but it's a clean illustration of what this test is actually pointing at.

Conclusion

Back to the paradox this piece opened with: development speed doesn't scale linearly with headcount, and the intuitive "more people, more done" breaks exactly where the cost of coordinating them starts to climb.

The mechanisms covered here add up to one picture: communication, shared context, autonomy, ownership, feedback speed, and the number of outside dependencies. None of them works alone as a universal recipe, but together they explain why a five-person team sometimes ships faster than a fifty-person department, and why that stops holding the moment those five people run short on the skills or the throughput the work actually needs.

The key takeaway: an effective engineering organization is built not around maximizing headcount, but around minimizing coordination costs while keeping the competence and throughput the work actually requires.

A more accurate version of "a small team is faster" would read: the faster team is the one that can make its own decisions, do the work, and get feedback with the fewest outside dependencies, regardless of how many people formally sit on its roster.