Rands in Repose (Michael Lopp) talks about this in his book "Managing Humans" as volatiles and stables, the former being largely analogous to rockstars. He (I believe accurately) describes how volatiles ignite the fire that leads to big change, then become stable around the new solution (or leave) and get disrupted by new volatiles. It's very similar to Clayton Christensen's work on disruptors.

If you're a manager, the math of having true rockstars on your team rarely works. They take more effort to manage yet produce fractional more output (they might be 10x better than a terrible developer but they're not multiples of solid devs). So I'm way further ahead if I can focus my efforts on improving broad-based productivity 5-10% than if I cater to my rare unicorns that are 30-50% better than my average team. Something I think ICs often overlook is a focus on leverage and scale to drive big improvements.

I feel like I'm currently living in a gray area between those two alternatives. I'm US as the lead architect for this project. I've written much of the code, made most of the architectural decisions, and all PRs go through me. The curveball in my situation is that all of my engineer teammates are offshore of varying levels of quality. I don't really have a choice to cut all the fat because I work at a consulting firm but on a unique project where it's a joint ownership between my consulting firm and a client. The project behaves more like long-term internal project work but its the client paying us and our bills. We're incentivized to keep these green offshore guys on the payroll even though their contributions are pretty small. For whatever reason, even though the client knows they submit low-quality work, the client still wants them on the project. We've tried over and over to push the devs critical thinking skills to the level where they can take a prototype and not royally fuck it up, but they just can't seem to meaningfully push through and take ownership of a prototype. It's weird, because I do end up architecting and developing in isolation (which is sweet, honestly) but stakeholders are somehow happy enough with our throughput that they won't shell out for more US senior engineers. I guess the upshot here is that a team is only as flexible and scalable enough as the average level of talent on the team.

It seems like all these comments assume everyone is working on roughly the same class of problem. That's probably a mistake.

This is a super strong, on point message.

As someone who has built prototypes and has worked with others who do the same, I couldn't agree more.

The problem is there aren't many prototype gigs out there, so it's not a great specialty.