The fastest way to make a late project later is to invite six helpful strangers into the codebase on a Monday morning and call it ✨ acceleration ✨.

I’ve been the person doing the explaining. I know where some of the bodies are buried. I’ve also been the one who buried a few… unrealistic deadline, tight scope, “we’ll come back and clean this up” (we did not come back).

Yes, this is a Brooks’ Law post. “Adding manpower to a late software project makes it later,” from The Mythical Man-Month, 1975. Everyone in software has heard it and nobody in management seems to have internalized it, which is maybe the definition of a cliché that still needs saying. I’m not going to re-derive it. Brooks did the communication-channel math fifty years ago (two people have one channel, ten have forty-five), and Coda Hale did the modern version in Work Is Work: coherence costs grow quadratically as you add people, while work capacity grows linearly at best. Read it in full if you want the math behind why your twelve-person standup accomplishes nothing.

What I want to add is the part the usual telling skips, because it’s the part that actually bit us.

We had a project to build an AI-powered automation template. Internally we call these PBJs 🍞 (pre-built journeys… and yes, the acronym and emoji use is real). The mandate came down from leadership, fully formed, without much input from the people who’d actually be writing the code. This is how it goes… someone three or four levels up decides it’s a priority and it lands on your sprint board and now it’s your problem.

The issue wasn’t headcount. We had enough engineers. The issue was that everyone needed to write code in the same small part of the codebase at the same time, and the deadline was yesterday.

Brooks’ Law usually gets told as a people problem: ramp-up time, meetings, channels. That’s all real, and it’s a cost you can at least see coming and budget for. What nobody budgets for is density. Call it people per square foot of code. Ten engineers spread across ten services is a team. Ten engineers in the same three files is a mosh pit. You can’t onboard your way out of six open PRs touching the same function.

And when you put that kind of density on a tight area of code with a short fuse, people stop building within abstractions. They stop reading the existing patterns. They (or their AI IDE) just start throwing spaghetti at the wall. Of course they do. Nobody gave them the time to do it right. That’s an organizational failure, not an engineering one.

Merge conflicts everywhere. Conditionals nesting inside conditionals. Someone accidentally reverts a change from a PR that merged two hours ago because there’s no time to review properly and nobody can keep track of what landed where. You open a PR and it’s 400 lines of diff across files that three other open PRs also touch and you just… stare at it.

And it’s not like Slack helps. Forty-five communication channels turn into forty-five threads, twelve of which are in channels nobody monitors, three of which contain decisions that’ll surprise someone in two weeks, and fifteen backchannel DMs you may or may not be part of, because who needs open communication anyway.

By the time things stabilized, the deadline had passed and everyone was quietly exhausted. The people who’d been pulled onto the project ended up being solid contributors… after the pressure dropped, after they’d had time to build context organically. The ramp worked. It just didn’t work on the timeline that mattered.

Which is why I don’t think “never add people” is the lesson. Adding people works fine when there’s somewhere for them to stand: early in a project, when tasks split cleanly, or when they’re picking up peripheral work that frees the core team. Adding people to one hot spot mostly adds collisions. So before anyone “adds headcount,” I’d ask a dumber question than “how many?” Ask where they’re all going to be typing.

And sometimes the right move when a project is late is to cut scope and protect the people who can fix it from the people who want to help. That’s a hard sell in a room full of people who believe effort is fungible… or when you truly don’t have a say in the deadline or scope and you’re just set up for failure. Brooks would say you can’t have nine women produce a baby in one month (his metaphor, not mine… and no, it hasn’t aged well). My addendum is less poetic: nine engineers in the same three files won’t ship the PBJ in one month either.