I worked primarily in 2 type of companies as far as this topic goes.
The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though.
That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though.
The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work.
Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!).
I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.
>It's infuriating to have to explain to a manager that the company's darling engineer actually suck
Holy crap, yes. Well it’s not always that the darling TL sucks but often that they themselves are in a role where they aren’t familiar with some of the tech the people working in their team are working on, so they don’t know how to properly make the large scale time estimates that get reported to the manager (and why would you ever ask the people actually working on specific tasks how long something would take? That makes too much sense and they might not tell you what you want to hear). But when they’re the darling and you’re working to meet the darling’s time estimates that were never realistic in the first place, you get thrown under the bus to the manager when time estimates fail. This actually just happened to me today.
This power structure also allows the manager/TL to play good cop bad cop on their employees where all bad news/orders from manager to employee goes through the TL but all good news/orders goes directly through the manager.
You can’t really win in a finger pointing game like this. The only fix is to just leave
While I've definitely seen instances of the darling being a TL, my biggest issue is when its an individual contributor. I've had to deal with cases where the company's "ninja" was some dude who just hid in a corner pumping shitty code 18 hours a day, ignoring all pagers, requests for help, his teammates, or even his own TL. But he shipped software that kind of sortoff worked (well, as long as his teammates handled every pager notification that came every time it failed). Management loved him because of his "productivity" and hated how everyone else was so slow (because they were deleting with the fallout of his crap).
I worked primarily in 2 type of companies as far as this topic goes.
The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though.
That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though.
The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work.
Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!).
I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.