I'll give an example: a software development manager meets with the customer directly, without bringing a developer with him, because hey, this is an executive meeting and I'm an important manager, and I want to score points with this customer. He proceeds to commit his team to delivering a solution on an unrealistic timeline, and doesn't realize that the solution he committed to deliver won't work in the customer's environment because of $various_reasons. Now, his team of poor software engineers is faced with two impossible options: attempt to deliver an impossible outcome on an impossible timeline, or give the customer bad news. Of course, the manager doesn't want to take the blame for bad outcomes (only the credit for good ones), so he makes his engineers deliver the bad news to the customer. Ultimately, the customer is unhappy, and the developers are unhappy.
Most of the bad managers I've seen spend more time "managing up" and trying to score points with their managers than helping their employees succeed. The really good managers realize that they work for their employees, not the other way around, and are a heat shield, motivator, and advocate for their team, willing to fall on their sword if necessary to protect their most junior engineers.
It has made me extraordinarily picky about any future management positions I may pick up.
Part of it is also that as a programmer you learn to micromanage what the computer is doing, to be very precise with your instructions so the program won't fail. When managing people for the first time the instinct is to do the same: give very precise instructions even an idiot could follow. That's exactly the wrong approach to manage effectively (except for a few rare circumstances). That's why programmers tend to make bad managers who micromanage, they've been trained wrong by their prior work.
Would the same idea work for IT? Or, another idea would be, to take a look at how traditional (non-IT) engineering companies work (although the main difference between both medicine and engineering, and IT is that the former are both very high-risk industries that move much slower than IT).
Also, judging from own anecdotal experience, there is a strong tendency (at least in Norway, where I’ve spent most of my career) to promote someone from the engineering pool to management; the reasoning being that as you are a decent engineer, you’ll probably become a decent engineering manager.
Well, chances are you aren’t. At least not until you’ve made a lot of management gaffes. (Cough; I made the switch from decent, in some narrow fields excellent engineer to a decidedly mediocre -for the time being- manager this spring...)