It would probably work if the people managers stayed out of the technical side but in reality most managers like to make technical decisions so there is not much space for senior engineers.
It's questionable to me whether an engineering manager can stay out of the technical side completely and actually be competent at their job. I think many non-managers underestimate how technical engineering management actually is. You often have to have a solid understanding of a very wide swathe of the organization's technology, including services whose code you haven't even had a chance to work on. In some ways it's not all that different from some of the expectations for very senior IC roles.
I always take it as a red flag when a manager wants to be responsible for technical decisions.
The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product. Managers who try to babysit developers and tell them how to do their jobs tend to just slow things down and lead to lower quality results.
I think that being involved in the technical side and "babysitting developers" are two very different ideas that have little to nothing to do with each other.
> The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product.
I think you're underestimating the degree to which doing this requires a solid technical understanding when there are dozens of teams involved and interacting with each other. In order for an engineering manager to bring their team(s) a clear plan of what needs to be done with few blockers or obstacles in the way, often a lot of technical planning with other groups has to precede that. As always, management done right is the sort of management you don't notice -- but that doesn't mean a ton of work isn't happening behind the scenes to make things very organized and clear for individual developers. You could have ICs do that, but they wouldn't be writing much if any code, and they probably wouldn't want to anyway.
Isn't what you're describing precisely what senior ICs should be doing more of?
I agree with OP, the purpose of a manager isn't to manage the technical side of things but rather the people side. It's why they have direct rapports: to manage the people.
A better use of the IC's time is to unblock them so they can meet with stakeholders and develop a rich understanding of the work in order to do it most effectively.
In trying to "shield" the IC from developing an understanding of the landscape they'll be working on, the manager may accidentally be preventing the IC from getting the information they actually need to do their job well.
> Isn't what you're describing precisely what senior ICs should be doing more of?
Yes, and I think the point I'm driving towards is that if this is the stuff you want to do, you're really not an IC at all -- you're an engineering manager with zero reports who doesn't have any authority, so you're making life 10x harder for yourself.
I think your view is seriously constrained by the assumption that you can't have both a manager and a senior IC on a team. You need both to be successful. Every team I've worked in that had success had both.
In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why those constraints exist requires a deep technical understanding, which is provided by the IC and the team. Using this knowledge, the manager has a perspective of the system and how to improve the system, and the manager tries to reason with the organization, trying to share that perspective with them.
The manager also relies on the IC to do spikes or POC's (or relies on the IC to select a crack team which have a good chance of success).
Most often, the IC has no interest in being in non-technial meetings all day, but the manager does. The manager loves working with other managers + product and helping them understand the issue, while the IC doesn't. The IC wants to spend most of their time on resolving technical issues, thinking deeply about the future and upcoming projects.
All of this to say: they're not exclusive, and both are required for successful teams. BUT, the idea that a technical manager needs to be super technical is not something I agree with.
Managers don't need to do that however someone needs to attend organizational meetings and deal will all the inter-team semi-technical stuff that keeps a company running. That person will tend to be involved in technical decisions to the extent that they have organizational knowledge and influence. You can have ICs do that however most would prefer a root canal and many lack of the soft skills for it.