Recent experience has taught me to think of those type of people as delivery managers, rather than people managers, and so long as they understand the limits of their knowledge they can be invaluable.

I've worked with two people who were excellent in that role, they work with the rest of the business to clearly define priorities, and to ensure they understand what we can and can't deliver. When it comes to hard technical decisions they delegate to technical leads and developers, but they have enough experience of engineering to be able to intuit whether what they're hearing makes sense.

I've also worked with someone in the same position, but without the self awareness to know where his knowledge ended and it was time to delegate. That was possibly the worst six months of work I've done, but thankfully he was eventually forced out by the board.

One of the best managers I ever worked for was a “people manager”. He knew his limitations and worked within them. He was reliant on the tech lead for technical knowledge but between the two of them made a pretty good team.

Some of the worst managers I’ve worked for have been technical people who don’t really want to manage but git Peter Pricipled into management.

Not a pure people manager - managers with a background of coding are important so they won't swallow BS, can understand tradeoffs between e.g. refactoring vs accepting tech debt to get a feature finished quickly, etc., understand the reliability or otherwise of dev estimates, etc.

But few strong developers are also strong people managers. The two attributes seldom overlap. And I think being good with people is more important in a manager than being good with code.

Of the companies I've worked at, my favorite setup was:

* people manager dealt with people issues

* technical reviews performed by senior technical people (under the same people manager, or cross teams if noone else is at the same / higher level)

* technical review is a part of the people manager's management responsibility: is it done on time, is the reviewee satisfied with the content and criticism of the review, etc.

This prevented a lot of personal opinion blight from influencing technical reviews- aka avoided subjective criticism from being part of the review score, focused instead on more objective metrics.

The time and place for subjective criticism and discussion is in planning and in-situ reviews (aka pull / merge requests), not formal reviews.

That's my experience at least; the particular managers I had at that company (3 over 7 years) also happened to be excellent people on the whole. A bad people manager is, of course, just as bad as a bad technical manager.

Management skills are orthogonal to technical skills.

People who are good technically are not necessarily good at management and should not be put in that position. They should however be put into a code-reviewing position.

Where I work, we separate the roles of Product Manager and Engineering Manager. The former focuses on roadmaps and priorities and works with the engineers directly while the latter focuses on people’s growth and career goals, and has almost no say on what people are working on or the handing out of tasks.

It works well. It’s nice to have someone to talk to and work with who isn’t invested on what you are working on today or riddled with conflicts of interest.