“Adding manpower to a late software project makes it later.” That is the most famous line from The Mythical Man-Month, a legendary work first published in 1975, and its logic extends far beyond software.

In fact, growth may be an even purer case of the problem than software. Growth is inherently cross-functional, highly experimental, and commercially exposed. Teams are constantly testing high-stakes assumptions in a competitive environment, often with incomplete information and little uninterrupted maker time. Product, data, engineering, and go-to-market all have to move in sync. Everyone ends up talking to everyone.

That coordination-heavy structure of growth makes it especially susceptible to coordination costs which compounds exponentially as team size increases. And AI sharpens the tension rather than removing it. In our era, as execution gets faster, cheaper, and more abundant, growth teams have to find a new way to scale themselves without scaling coordination costs at the same rate.

Many bad ideas emerge from some kind of death cycle. In product, there is the well-known product death cycle where teams keep shipping features without a clear product vision, and the product slowly collapses under its own weight.

Growth has a similar trap. The response to growth friction is often adding more PMs, more analysts, more engineers, more markets and more channel owners. On paper, it feels rational. If growth is falling behind, more headcount should mean more output, more experiments, and more learning. But that logic breaks down quickly in highly interdependent work.

The issue with scaling headcount in growth is that people fail to account for coordination overhead that comes with the additional capacity. When headcount increases, the capacity increases linearly but the coordination cost grows exponentially. There is bound to be a tipping point where additional capacity results in lower overall productivity.

In that sense, growth is almost cursed by the man-month problem. Learning velocity is the lifeblood of the growth team, and once headcount starts eroding it, scale becomes self-defeating. The real challenge is no longer how to add more people, but how to scale growth without scaling coordination costs that inevitably comes with additional headcount.

If the core problem in growth is that learning velocity gets traded away as headcount rises, then the answer is not simply to keep expanding the core team. It is to change the unit of execution. Instead of routing every initiative through a growing web of specialists, growth teams should normalise strike teams: small, high-autonomy groups with enough combined depth and adjacent range to test a major standalone assumption end-to-end.

The success of strike teams lies on three important factors.

When AI commoditises general knowledge, shallow generalism loses value fast. If everyone can produce decent first drafts, broad but undifferentiated capability is no longer enough. The premium shifts to people with real depth: specialists with unique taste, strong judgment, and the ability to operate on the far right of the bell curve.

But strike teams are small by design. They do not contain every function in full, and they cannot afford to recreate the dependency chains of a large growth org. So depth must be paired with range. Not shallow breadth, but at least adjacent fluency: enough understanding of neighbouring domains to reduce handoffs, challenge assumptions, and move an experiment forward without waiting on the whole system. In fact, some cross-functional capabilities are quickly becoming table stakes. Analytics is the clearest example. In an AI-accelerated growth environment, every serious operator increasingly needs to reason about metrics, instrumentation, experiment design, and signal quality, even if they are not the designated analyst.

The skill sweet pot for the AI era is not generalists without edge, and not specialists trapped in silos, but 10x specialists whose expertise travels. In today’s world, functional purity and rigid role clarity start to look less like strengths and more like constraints.

It is well known that most business outcomes are shaped by only a handful of highly leveraged decisions. Those decisions, in turn, rest on assumptions that cannot be known to be true or false before they are tested. That is why shared context around one bounded assumption matters so much.

This is easier said than done. Focusing on one thing that truly matters is hard, so teams often substitute it with something safer that sounds adjacent enough to feel legitimate. For example, the real task may be to improve retention, but the team can drift toward predicting attrition instead. The two sound related, but only one has direct commercial value by itself.

The problem becomes even more pronounced when specialists are involved. Specialists naturally approach an assumption through the lens of their own craft, biases, and preferences. That is often useful, but it can also pull the work away from the actual question that needs to be answered. A data scientist may gravitate toward modelling, an engineer toward system design, a marketer toward messaging, and a product manager toward workflow changes. Yet none of those, on their own, is necessarily the assumption that the team most needs to prove or disprove.

That is why strike teams need shared context around a sharply bounded assumption. The point is not simply to bring together strong specialists and let them each contribute from their function. It is to align them around the same commercial question, the same decision to be made, and the same evidence threshold for learning. The assumption being tested should serve the organisation’s objective, not the comfort zone of any one discipline.

Strike teams only work if they have the spine to make decisions. Small teams lose their advantage quickly when every meaningful move still has to be escalated, socialised, and endorsed through layers of managerial bureaucracy. If the team cannot decide, it is not really a strike team. It is just a smaller queue inside a larger system.

That is why decision-making spine matters. Strike teams need people who can reason from first principles, question inherited assumptions, and surface unconventional insights rather than defaulting to familiar workflows. In growth, the highest-leverage progress often comes from reframing the problem, not just executing the obvious faster.

They also need the courage to act on that judgment. Most organisations reward caution through bureaucracy: align first, escalate early, seek cover. Strike teams are meant to do the opposite. With a bounded assumption, clear ownership, and known constraints, they should be able to put forward decisions without constantly waiting for permission.

Without decision-making spine, a strike team is just cross-functional theatre.

Growth is almost a pure case of the Mythical Man-Month problem. As team size grows, coordination cost compounds far faster than useful output.

What is interesting is that this pattern shows up well beyond org design. In entity resolution, complexity also explodes if every record must be compared with every other one. The solution is indexing: partition the problem into smaller blocks, then compute locally rather than globally.

Strike teams play a similar role in growth. Instead of routing every assumption through one expanding web of specialists, they break the problem into smaller, bounded loops. Each team owns one assumption, works with tighter context, and learns without imposing full-system coordination costs. In that sense, strike teams are not just a staffing model. They are growth’s version of indexing.

When a pattern solves scalability in multiple domains, it is usually no longer just a tactic but evidence of a more universal truth.