This is a great point (although I hate the term "headcount"). It takes time to get engineers up to speed in any organization, and it usually cuts into the productive time of current engineers.
*On average.
My interpretation of Brooks' observation on second systems is that they're what happens when the first system has been enough of a success to give people a relatively free hand to solve problems with it - so they try to solve all the things and wind up with an over-ambitious and unusable system, from which a pared-back third system emerges.
It talks about allocating memory to the various components of the OS. It begins with a delightfully outdated section on the cost of memory: if the OS weighs 400ko it costs the user $4800 per month when renting just for that memory!
His take-aways on allocating a limited resource (memory here but it could be $) are:
* Budget every aspect, not just the resource itself. Otherwise implementers will end up swapping to disk to respect the limit, killing performances.
* Define what must be achieved along with the budget. Otherwise things will be thrown over the fence to a neighbour.
* Perspective and overall integrity must be watched : "The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. [...] Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager".