The problem is that one senior person can’t oversee tons of unmotivated juniors on multiple projects. It’s not that the senior people aren’t typing all of the code, it’s that you’ll never see them again and your “architect”, “tech leads”, etc. will be a couple of people who have a couple years of excreting Java code into legacy apps for a bank.

When the project falters, attempting to parachute the actual skilled people back in will fail because of both Brooks’ law and simply their mandate being to stabilize things to the point where they can claim minimal satisfaction of the contract requirements, which will likely not include fixing the deep architectural problems.

> it’s that you’ll never see them again ...

> When the project falters, attempting to parachute the actual skilled people back in will fail ...

The argument there seems a little inconsistent to me. The skilled people aren't going to be rushing from failed project to failed project - that is less productive than just getting involved to start with.

> The skilled people aren't going to be rushing from failed project to failed project - that is less productive than just getting involved to start with.

You're thinking about it from the perspective of the customer, not the an ethically-challenged contractor focused on maximizing revenue. If you have an A-team which you use to close deals, cycling them from project to project to close the deals which you will then staff with the C-team will generate more revenue than having them work on just one project as long as you don't have many disasters where you have to eat the cost of fixing the project.

If the client is either overly-trusting or made enough mistakes to plausibly share responsibility and the punishment for failure is more billable hours, you're _way_ ahead financially if you get to bill 14000 hours of C-team-masquerading-as-A-team instead of 2000 hours of actual-A-team.

Splunk Proserve ABSOLUTELY does this (they have a few superstars they spread thinner than a WW2 kid spreads butter). They get in at the beginning, hand the project over to less experienced people, then parachute in only after the project has gone so far off the rails it's unrecoverable to a point that's truly what the customer needs, but good enough to get the customer off their back.

Source: extensive experience on projects with Splunk proserve.

I wonder if the provider is really that interested in productivity though. They are not usually bidding fixed price. The longer the project can go on, without the customer just getting so frustrated they admit defeat and cancel, the better for the vendor. So it makes complete sense to keep a close watch on the customer's pulse, and only send in the cavalry when cancellation is looming.

Having senior people write all of the code shuts down your ability to create new senior people. If you have a bimodal distribution of employment longevity for your devs, this may be why. If nobody gets promoted for three years because you can't trust new developers with the code (until they've memorized everything) this is probably why.

Nobody wants to touch the lead's code. The more of it there is, the slower things go. Or the more workarounds/end runs (duplicate functionality) you find in the code. It's best if the leads only stick their fingers into code that absolutely has to work, has a low expected rate of change, and relates directly to architectural or (better) operational concerns. Everything else they should keep an eye on, insist on quality, but otherwise butt out.

People write code that seems obvious to them. Very, very few of us make a conscious effort to do much more than that. You can write a great deal of solid code that is still write-only. Too much of this, and it makes it difficult to improve your bus numbers, and grooming people for growth is a huge investment of time, energy, and social capital (if you can do it at all). Rather than bringing the whole team up, people play favorites, because that's all they can afford.