𝗔𝗱𝗱𝗶𝗻𝗴 𝗺𝗼𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝘄𝗶𝗹𝗹 𝗺𝗮𝗸𝗲 𝘆𝗼𝘂𝗿 𝗽𝗿𝗼𝗷𝗲𝗰𝘁 𝗹𝗮𝘁𝗲𝗿

Most of us are familiar with this scenario. A project is a month behind schedule, then management adds three engineers to a five-person team. A month later, the project is two months late.

This is Brooks's Law:

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

Fred Brooks wrote it in The Mythical Man-Month after managing IBM's OS/360. He explained it with a line that's lasted 50 years:

"You cannot get a baby in one month by impregnating nine women."

Some work just takes the time it takes.

The mechanism is communication. Two engineers have one path between them. Five have 10. Ten have 45. Twenty have 190. Adding one person to a team of N adds N new paths, not one. Cost grows quadratically. Output grows linearly. At some point the curves cross.

This is why throwing people at a late project makes it worse. The new engineers don't know the system. People who has experience in the project need to spend their time to onboard them. Coordination meetings multiply. Review queues lengthen. Basically, the team spends more time syncing than shipping.

I lived this on an eight-person team. We often missed deadlines, so our instinct was to ask for more people. We did the opposite. We moved two engineers to another project. The smaller team picked up pace inside a week. It delivered more than the bigger one had.

The fix wasn't adding people. It was removing them.

Brooks didn't say more people never helps. On long projects with parallelizable work, adding people early pays off after the onboarding cost.

𝗟𝗶𝘁𝘁𝗹𝗲'𝘀 𝗟𝗮𝘄 makes this measurable:

𝗟𝗲𝗮𝗱 𝘁𝗶𝗺𝗲 = 𝗪𝗜𝗣 / 𝘁𝗵𝗿𝗼𝘂𝗴𝗵𝗽𝘂𝘁

A team finishes 5 tasks per week with 20 in progress. Lead time is 4 weeks. Push WIP to 40 at the same throughput, lead time doubles. Adding people to a late project grows WIP without growing throughput.

If you want faster delivery, the first move isn't adding people. It's reducing work in progress. Finish what's started before starting more.