Watch this video on YouTube (opens in a new tab)

Here's the setup. Your team is building something big and ambitious. Leadership thinks progress is a little slow. So they decide to grow the team by a third to hit the timeline.

Makes total sense, right? More people means more output. More output means you ship faster.

Except scaling doesn't always work. Sometimes it costs you a lot of money. Sometimes it makes delivery slower. And sometimes it does both, which is a real achievement.

(Quick definition so we're on the same page: when I say "scaling," I mean adding more people to a project.)

Three Inconvenient Truths

Before we get into it, there are three things lurking around every scaling conversation whether anybody mentions them or not.

Scaling has coordination costs. More people means more people you have to talk to. Talking isn't bad. But it isn't free either.

Some work isn't shareable. Some kinds of work split up nicely across lots of people. Some kinds of work can't be split at all. And then there's the messy middle — work that kinda sorta splits, but not cleanly.

Multitasking is expensive. By multitasking I mean trying to hit multiple goals roughly at the same time. Every switch from one thing to another burns a surprising amount of time. I've written about this a lot, and the numbers never get less depressing.

Yes, There Are Real Reasons to Scale

You can probably already tell I'm a little skeptical about scaling up teams. But I want to be fair here, because there are absolutely legitimate reasons to do it.

Market timing. If there's a window and your current team can't hit it, the cost of being late might genuinely dwarf the coordination overhead. That's a real tradeoff, not a trap.

The work genuinely decomposes. Sometimes the work actually breaks apart into independent streams. Different teams own genuinely separate things and nobody steps on anybody. When that's true? Scaling works.

You need skills you don't have. Security, performance, some specific domain — you can't train your way into everything fast enough.

I've been in rooms where every one of those was the right call. So the goal isn't "never scale." The goal is to ask the right question first: will adding people actually make this go faster?

Brooks's Law

In 1975, Fred Brooks published The Mythical Man-Month, and in it he wrote a sentence every software leader should have printed on their office wall:

"Adding manpower to a late software project makes it later."

Not might make it later. Makes it later. And a big chunk of the reason is some very simple math.

The Math: N × (N-1) / 2

The number of communication channels on a team is N × (N-1) / 2, where N is the number of people. Here's what that looks like in practice:

Look at 15 versus 30. You doubled the people. You didn't double the coordination — you roughly quadrupled it. (Technically that's quadratic growth, not exponential. Your calendar will not appreciate the distinction.)

At five people, everybody just knows what's going on. At fifteen, somebody's full-time job is coordination. At thirty, you've got meetings about meetings and syncs about syncs.

If you've ever watched a company go from 8 people to 40 and wondered why everything suddenly got harder, this table is a big part of the answer.

What Kind of Work Are You Scaling?

Brooks made another point that I think is even more important than the math. It's about what kind of work you're doing.

Perfectly partitionable work. Harvesting wheat is the classic example. Twice the people, half the time. You divide up the field and everybody goes. Nobody has to coordinate with anybody.

Unpartitionable work. This is the one people usually quote as "nine women can't make a baby in one month." (Brooks's actual phrasing is that bearing a child takes nine months no matter how many women are assigned, but the internet has spoken.) You can't parallelize it. Adding people doesn't help.

And when you try to parallelize work that doesn't decompose, you don't add capacity. You add coordination overhead. Work collides with other work. Everybody gets slower.

Here's the uncomfortable part: software leans hard toward that second category. Most of the work has dependencies. Most of it can't be cleanly split up and handed to someone new.

So be honest with yourself. Does your work actually decompose into independent streams? Or are you hoping it does because you need it to? Because if fifteen teams all deploy into the same database, or they're all touching the same monolith, they're coupled at the code level — no matter what your org chart says. (I've written about this flavor of pain before. Splitting the monolith and ending up with twelve monoliths is a very popular way to discover it.)

Before You Scale: Four (Five) Questions

Before you commit to growing the team, walk through these. The order matters, because each one depends on the one before it.

1. Decomposability: can you create independent streams? Can different teams own genuinely separate work without stepping on each other? If not, everything downstream gets awkward. It's really hard to org-chart your way around a monolithic problem.

2. Architecture: can teams actually work independently? Even if the work decomposes on a whiteboard, if everybody deploys into the same codebase or the same database, they're coupled. Your architecture has a lot to say about how many people can productively work on your system at once.

3. Coordination: how will teams stay aligned? At the new size, how does everybody know what to work on and when to ship? If you can't answer that clearly, you've got a coordination crisis on layaway.

4. Current efficiency: are you already good enough at your current scale? This one I want to deliver with a hug. If things are going fine, recognize that scaling could mess up a good thing. Sometimes the right move is to leave it alone.

5. (The bonus one) WIP: are your teams juggling five things at once? If so, work on focus first. Doing more with less is easier than it sounds — just do fewer things at once. At five simultaneous tasks, Weinberg's numbers put about 75% of your time into context-switching waste. Drop to three and you get back something like 35% of your productive capacity. No new hires required. (Here's the math on a kanban board if you want to see it worked out.)

Everything here is a fuzzy judgment call. Give each question a gut-check score. The lower the scores, the less likely scaling is to pay off. That's not a moral judgment about your project management. It's just project management math.

The Elephant in the Room

Now let me say out loud something everybody in leadership knows and almost nobody discusses openly.

In most companies, your budget, your influence, and — honestly — your career trajectory are tied to the size of your team. That's not a character flaw. That's how the system is set up. If your boss's boss measures success partly by headcount, that's the world you live in. I get it.

So I'm not saying ignore that pressure. I'm saying know which reason is driving the decision. Are you scaling because the work demands it and the checklist checks out? Or is there some organizational gravity pulling you toward "more people" because that's what gets rewarded? Both can be true at once. That's fine. Just go in with your eyes open.

"How Do We Keep Everyone Busy?"

Here's a free diagnostic.

If you've ever been in a meeting where somebody asks "how do we keep all these people busy?" — that's the signal.

When the work is pulling you forward, nobody asks that question. Everyone's busy because the work demands it. You only hear it when you're pushing people toward work to justify the headcount. It's one of the clearest signs you've gotten out over your scaling skis.

"But Ben..."

"...we've got competitive pressure. There's a market window." You're right, and that's real. I said market timing is a legitimate reason to scale. But the checklist still applies. Scaling into a market window with a team that can't coordinate at its current size doesn't get you there faster. It gets you there later and more expensively.

"...aren't you just saying don't hire?" Nope. I'm saying hire deliberately, not reflexively. If you've walked the checklist and the work decomposes, the architecture supports it, and you can coordinate at the new scale — go for it. That's the informed version of the decision. What I'm pushing back on is "we need more people" as the default answer to "we're not going fast enough." That default answer has a hidden math problem. And now you know what it is.

What to Do Monday Morning

Run the checklist before you post the job reqs. If you can't answer the questions cleanly, fix what you've got first.

Fix your flow at your current size. Limit work in progress. Get cycle times down. Stop context-switching your people across five things at once. You might find out you don't need more people at all.

Change the question. Next time someone says "we need more people," try asking: what if we could get more throughput from our current team than we expect from a bigger one? Sometimes smaller is faster and bigger is slower.

Scaling isn't wrong. Thoughtless scaling is wrong. And the difference between the two is a handful of honest questions.

-Ben

If your organization is trying to decide whether to grow the team — or you already did and things somehow got slower — that's the kind of problem I help teams diagnose and fix. Let's talk.