Yes exactly! The best boss I ever had explained his job like this (and yes probably some ego stroking in there):
"You guys are like a rock band. You're the stars. You need to show up, practice, and play gigs on schedule.
I'm like your band manager. It's my job to take care of all the random crap like booking tour buses, replacing blown amps, and protecting you from the annoying label guys so you can just focus and do your magic."
It's a good analogy. A good manager protects their team and lets them focus on their work and gives them what they need to succeed.
The difference is that the band manager is clear he works for the band. His goal is to help the band do what the band does best.
A bad SW manager often operates under the idea that he's in charge. He gets to set what the people do, when they do it, and how they do it. He doesn't really care what skills or experience his team has. He's the boss, and they better shut up and do what they're told.
A good manager plays with the team. A bad manager plays against the rest of the team.
Somewhat. Having been there and back, it's not so clear cut. There are really two jobs here that need to be done:
Team manager a.k.a. office mom. Someone who is a lot like the band manager. He doesn't know C from HTML but knows that developers needs snacks, juice boxes, headphones, fast computers, and 4k monitors. He takes care of the "crap political work" and keeps developers busy with what they do best.
Project/product manager. This is someone who may or may not be the technical lead, but definitely needs to understand how software is put together, who on their team will be doing it, how long it will take, etc. The job of this person is to translate business requirements ("We need feature X shipped by March, and bug Y fixed immediately.") into technical tasks, timelines, and assignments. It's also possible that this is the person responsible for figuring out which features the product should have (no developers shouldn't always be the ones deciding this). This job is hard. You are responsible for setting realistic goals and not letting anything drop, but you are also responsible for moving the project fast, and not getting stuck.
The first job is more tactical. We know that developers constantly distracted by noise or going to be unproductive, etc. The second job is strategic. It requires a crystal ball to predict which bugs will come up and where the difficult bits of implementation will be. This isn't booking buses and switching out blown amps. Managers that can do this job alone, or even both at the same time are worth their weight in platinum.
> He's the boss, and they better shut up and do what they're told.
Hypothetically let's assume you are a manager. You have a team of smart people and like any other team, everyone wants to work on the hardest problem. Particularly two guys want to do the same thing: How do you handle this?
The most important thing I advocate in a manager / employee relationship is trust. You should be able to trust that your manager has your best interests in mind and vice versa. If you do trust each other, I don't see why there will be a problem in doing what is told. In fact you won't even see it as being told to. The managers on the 'good end' of the spectrum will also make it appear as if it is a suggestion, but any smart person should be able to see through that for what it is: an order to do X or Y.
Most of the issues happen because of the lack of trust. This is the prime thing I tell new folks: Choosing a manager who is exactly on the same page is prime directive. Get the human element out and build trust. You miss out on that / settle, you are just settling for a life of misery.
Easily, I once worked at a place where everyone wanted to work on the hardest problems. I could have done that also but instead I recognized that there was a lot of grunt work that needed to be done in order to get our product out and meet our deadlines so I volunteered to get that stuff done. The director of our department took note of this and when bonus time came around I received a significantly larger bonus than everyone else and was thanked for my dedication to doing what needed to be done. The lesson being that, you reward people who do what it takes to get the job done not people who are self-serving glory hounds looking to boost their resume with hard problems.
I'll just say every bad boss I've had has made a big deal of how much they isolate me from trouble, but yet their actions have the effect of amplifying trouble.
Oddly enough, every bad engineer I've ever worked with has made a big deal of how good their code is, but yet their code has the effect of causing flaws in the product.
The existence of people who are bad at their job does not mean that the job description is problematic.
Unfortunately "manager" has morphed in meaning to mean something more akin to "boss" or "chief", both in the publics perception and actual company practices.
"You guys are like a rock band. You're the stars. You need to show up, practice, and play gigs on schedule.
I'm like your band manager. It's my job to take care of all the random crap like booking tour buses, replacing blown amps, and protecting you from the annoying label guys so you can just focus and do your magic."
It's a good analogy. A good manager protects their team and lets them focus on their work and gives them what they need to succeed.