At Google, engineers start committing code in their first week too.

That doesn't mean they're fully on-boarded until 6 months in.

I was on a project where we added 6 people to an 8 person team in 2 weeks. Velocity stayed exactly the same as before for a sprint or two but quality issues jumped. We then spent an enormous portion of time on bug fixing. It took about 2 months before the overall team really saw a net benefit to velocity by adding those people.

Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.

> We have developers committing code in their first week. Sometimes day 1 or 2.

If you're doing anything complex (which can just be: if your codebase is more than a year or so old) than the quality and velocity of code someone can contribute on day 1 is vastly lower than they can a month later.

I see the Mythical Man Month tossed around as an excuse for not trying sometimes - by people who haven't even tried to split up and spread out chunks of work in parallel - but onboarding cost is definitely real.

You gotta evaluate "can I get enough overall throughput at this point in time to make up for the total efficiency lost" and also the rest of the business priorities outside of this one project.