> When it's done right, it seems to work well.
I think this is the most interesting truism of leadership. Which leads risk averse companies to minimize the harm a bad leader can have, and utilitarian companies to maximize the expected value - even when that results in tolerating terrible managers. I don't honestly know which strategy I prefer.
> ...is that it keeps a company from hemorhaging technical experts who have little interest in people managing.
In our defense, it's not quite that simple. I personally can and will write code in any product in my scope, often at the behest of an ongoing incident where the team in question lacks the necessary experience to get themselves out of the situation they find themselves in. E.g. breakdown of some communication protocol, backend knocked offline by a firehose of retries, corrupt database. But even more, my job is to _prevent_ incidents, whatever that takes. Over the last ~year I've concluded that a lack of sufficient staffing prevents any good long term future, and so my main (self imposed) project is evangelizing leadership for headcount. Primarily through the lens of technical arguments - I can tell you which systems will hit fundamental scalability limits first (that aren't being invested in!), and also the individuals across the org that are at highest burnout risk from toil.
Am I an architect? Sometimes. More often I'm a janitor. But most of all, I spend an inordinate amount of time understanding the technical product of hundreds of engineers, to be able to speak to any part of it.
And what does that qualify me for in terms of organizational responsibility? I have no clue :).