Brooks’ Law Is A Ceiling, Not A Verdict
Ask any engineering team why adding headcount doesn’t magically accelerate delivery and someone will eventually name-drop The Mythical Man-Month. Frederick Brooks’ 1975 observation that adding people to a late project makes it later has become something of a reflexive response whenever ambitions outpace capacity. It’s a real constraint, but it’s often cited as if it were a law of nature rather than a description of one specific failure mode.
Software projects are dense with interdependencies. New hires need onboarding, work needs to be carved out for them, and every additional person multiplies the coordination overhead. At some point, the communication burden outweighs the added capacity. That dynamic is real and worth respecting. But treating it as an absolute limit turns every product decision into a zero-sum game: to start something new, you must kill something old. That’s where the myth creeps in.
If Brooks’ law were the whole story, the fastest tech company would employ a handful of people. The obvious absurdity of that conclusion points to the missing nuance. Brooks’ own work contains the counterexample: work that can be cleanly partitioned scales just fine with additional people. The problem isn’t adding people — it’s adding people to work that can’t be split into independent threads.
Think of a CPU. Adding cores won’t speed up a single complex computation, but it absolutely helps when you’re running many independent tasks in parallel. Product development works the same way. The job isn’t to choose between scaling and prioritization — it’s to ruthlessly prioritize the work that must be sequential while scaling up the portfolios that can run in parallel.
Dependency Management Beats Headcount Debates
The real job of a product executive is shaping the work so it resembles the parallelizable graph rather than the tangled one. Interdependency is never fully curable, but its symptoms can be managed. One approach is to deliberately construct a portfolio of initiatives that minimizes cross-team coordination. Projects that touch different products naturally require less communication than projects that all land on the same surface.
Ironically, these lower-dependency portfolios often get criticized as unfocused. They look like scattered efforts rather than a concentrated push. But from a pure throughput perspective, they’re often the smarter choice — they’re precisely the kind of work that accommodates added personnel without grinding to a halt. That doesn’t mean choosing random, unrelated work. Everything should still drive toward the same long-term direction. It just doesn’t all need to weave through the same codebase at the same time.
Process design matters just as much as portfolio selection. The instinct to manage coordination by adding more meetings and status updates usually backfires — you end up with teams spending more time synchronizing than building. Brooks’ communication formula is an upper bound, not a mandate. Different roles require different levels of interconnectivity. A good cadence eliminates unnecessary communication rather than institutionalizing it.
Tools and incentives can also do some of the heavy lifting. If two teams’ KPIs push them toward compatible outcomes, their independent work is more likely to fit together without constant cross-team supervision. Design systems, automated testing, and shared principles serve the same function: they reduce the coordination tax on independent work.
The Customer Experience Dilemma
For a company like Mailchimp, whose customers are often marketing novices running small businesses, clean partitioning has a hidden cost. The product needs to feel seamless end-to-end — users shouldn’t be able to tell where one team’s work ends and another’s begins. That’s Conway’s law in action, and it applies to the customer-facing experience just as much as the engineering architecture.
Perfectly firewalled teams may ship independently, but the result can be a Frankenstein’s monster of inconsistent interfaces. Enterprise players can paper over integration gaps with consultants and account managers. Consumer products don’t have that luxury — the product has to be understandable out of the box.
This is a different flavor of the same Brooks problem. It’s not about code dependencies but experience dependencies. Making everything seamlessly connected across teams demands constant collaboration, and that collaboration slows delivery. The release valve here is deliberate trade-offs. A product leader has to decide where a disconnected experience is acceptable — often in new, low-traffic areas where iteration and learning matter more than polish, rather than in the established features that anchor customer trust.
These trade-offs aren’t universal. Building a medical device with this approach would be reckless. But in contexts where the software doesn’t put anyone in harm’s way, deliberately isolating teams and accepting some incompatibility risk is a legitimate way to buy scalability.
Brooks’ law is not a dismissal of growth — it’s a warning about how the work is structured. Parallelization and dependency mitigation are the levers that let companies scale without collapsing under coordination overhead. The next time someone invokes The Mythical Man-Month to argue that adding people means slowing down, the real question isn’t whether they’re right. It’s whether the work is lined up in a way that lets new people actually help.
The Human Cost of Scaling
Even with solid engineering practices in place, the Mythical Man-Month will still surface as a conversational weapon. Engineers invoke it less because of its technical accuracy and more because scaling is emotionally and cognitively draining. Those who are paid to ship code and solve customer problems rarely want to disrupt their workflow to accommodate new teammates and larger structures.
Adding even one person transforms the team's trust dynamics and culture. People grow weary of constant change, so while you tackle dependency management and process improvements, you must also address the emotional toll of growth. This human side of scaling often proves to be the hardest part to manage.
The belief in the Mythical Man-Month can also become self-fulfilling. Just as belief in flight powers Peter Pan, a team convinced that scaling will slow them down will find ways to make that true. If engineers don't buy into the transition, they will grind to a halt regardless of the structural changes around them.
To counter this, communicate the rationale behind every new process or tool that targets man-month problems. Bring people into the decision-making so they own the practices meant to ease coordination pain. When engineers feel part of the solution rather than subjects of it, scaling at least becomes culturally viable, even when the logistics get messy.
