As a software engineering manager, I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can. If some things take longer than expected, then I already have a team of engineers with all the context since the project kicked off that can help each other with any longer running tasks. An engineer that has completed a smaller chunk of work can help out with the items on the critical path, for example.

▲

datadrivenangel 5 hours ago | parent [-]

Fred brooks would not necessarily endorse this.

▲

jh00ker 5 hours ago | parent [-]

Please, say more!

>I always look to staff up a project at the beginning as much as possible, looking for doing as much in parallel up-front as we can.

Ah, maybe this is what you think he would take issue with? Fair enough. Perhaps I should have said:

>I always look to staff up as much as is economically and organizationally optimal, to exploit all genuine parallelism opportunities, being careful not to overstaff.

▲

pzoln 4 hours ago | parent [-]

You mileage may vary but in my (unfortunate) experience, stuffing up by any other reason than grassroots "we need more hands" raised by engineers themselves typically backfires. Teams that are constrained by people resources often find creative ways to work smarter. Teams that have an abundance of labor, often end up working unnecessarily harder, duplicating work, reinventing the wheel, not solving the right problems, etc. See also intensive vs extensive development.

	▲	erica123 4 hours ago \| parent [-]
		I agree with that