Then you'd expect fewer developers, and fewer managers overall. Unless you hit some really low threshold (e.g. 5 developers, so the same manager is only worth 50% an IC) where the cost of manager doesn't "pay back" in developer-headcount-reduction, it'd still follow the same strategy.

And of course, the amount of "pay-back" you get from a manager would naturally be how one derives their value, and thus their paycheck.

But IC --> Manager as the only promotion track is completely unnecessary, and generally a mistake. That's just intentionally driving into the peter principle (promoted to the level of their incompetence), because you've simply left no other way to go. Usually you have the alternate track for IC's expanding into larger/more abstract/more important domains, but not head-count; technical/solution architects and what-not.

But the story hasn't changed -- if you assume the role of the manager is to make their resources more efficient, then a manager's value scales with the number of resources under him; an IC does not. It will always eventually make sense for a manager to be more valuable than an IC, and this only holds false at low headcounts.

Any tech manager even remotely worth their salt should be able to function as a senior+ IC if necessary. If that skillset is lacking.. maybe you want to rethink your hiring. You'll likely never see the effect of a good manager if you don't.

As for your argument that developer scarcity somehow makes managing worth less - the opposite. If you can hire a single person that can effectively give you 10+ devs without having to hire those 10+ devs, you want to hire that person.

And for the "ICs need better raises, or they turn managers" - uh, no. But you do need to offer parallel development tracks, with comparable advancement opportunities. (In reality, IC & mgr raises should be roughly similar in terms of percentages. If you value managers, at least)