Satire
We're Bringing In Three More Engineers
The release was six weeks behind. Now it's nine.
The Q4 release is six weeks behind schedule. Leadership approves three engineers from another team on a temporary basis. Brooks' Law was published in 1975. It was not referenced in the approval.
What Actually Happens
The three existing engineers spend week one in context-sharing sessions. Week two is dedicated to codebase walkthroughs and access provisioning. By week three, six people are working on the same two modules, generating merge conflicts daily. A new ceremony is added: "sync on branches."
The original three engineers are now slower than before the reinforcement arrived. The release is nine weeks behind. In the retrospective, a team lead asks whether adding two more engineers might help.
The PM adds a risk item to the project register: "resourcing model."
“You doubled the coordination cost. The code did not write itself faster.”
DivineForge Advisory
Recognise this pattern in your organisation? I help teams cut through the governance, make the right technical calls, and actually ship.
Let's talk architecture →How a Builder Should Respond
Identify the actual constraint before adding people. Late projects are usually blocked on decisions, dependencies, or unclear scope — not labour. If the work can be split cleanly without onboarding cost, add people to the clean split. If it cannot, remove the blocker instead. Headcount is a slow instrument. Use it deliberately.
This scenario illustrates Brooks' Law. See all 13 laws →
Stay in the loop
New satire drops when the enterprise does something worth documenting. No spam — just the next article.
20 articles about enterprise dysfunction. None of it billable. Buy me a coffee.
Buy me a coffee