(1) Filter requests for work to his team to avoid them having to constantly task-switch, with the associated loss of productivity and job satisfaction.
(2) Provide his team with the business context for the work he asks them to do, and trust them to handle details.
(3) Get his team the support they need to do their jobs.
These all involve tradeoffs. If you constantly tell your team every part of every business discussion that takes place as part of (2), you can fail at (1) and distract them from their long term goals and work.
I've worked with managers that didn't protect their team at all, and who constantly forwarded emails and repeated conversations to us until we could barely get anything done before having to switch to a new task. I've also worked with managers who didn't tell anyone anything, and let their reports toil in the dark for months before letting them know that most of their work was wasted.
A good manager will sometimes fall on either side of the line; a bad manager will consistently err to one side. Managers are just like engineers - there are a lot of bad ones, and some good ones, and size of the company is pretty orthogonal.
The only take away here is that you have to treat malice and stupidity the same. The person in question either messed up intentionally, or is too stupid to do their job. You should fire them, or quit, whichever position you happen to be in.
Stupidity can also be more subtle. It's not always clear cut idiocy, there's a continuum between total and absolute head-desk stupidity, and ignorance or information blindness that's outside one's control.
Whereas malice is much less a continuum: the only question is, to what degree is this person an asshole, and when will they strike next? Intentionally and willfully hurting others is another world from anything unintentional.
The law treats it the same way. Hence, I believe it is helpful.
In any case, it's a razor: it separates illogical conceptual rabbit-holes from that which is more likely to be true.
"Never attribute to incompetence that which is adequately explained by bad management."
It's a leftover from a time when I unfairly criticised a number of programmers who were actually heroically fighting to deliver a quality product under bad management.
This is very Deming-esque, you know? http://en.wikipedia.org/wiki/W._Edwards_Deming
When a person is working under good management, with the autonomy to do what they need to be successful, the ability to get better at their work and master a field, and a clear purpose, responsibility is a given.
It is when individuals are falsely given responsibility for things they cannot possibly control that personal responsibility loses its credibility.
You don't have to blame management (or the system you're in) every time (and most people don't), but you should every time it is true, to preserve the very idea and value of responsibility itself.
Your vision fails to describe why information is withheld from engineers that would help them do their job. We wont even talk about why doublespeak and so often what seem to be outright lies are told to trusted members of the team.
The world you describe is some rational honest place where people are trying to build a system they understand. In an engineering project when we're doing that, you don't withhold information or surprise people, because that causes all sorts of conflicts and false starts, and robs people of the power to contribute.
That deliberate lack of communication, which steals perspective and the ability to think about your situation, is the hallmark of the division between management and workers in a growing company. And the only explanation for it is a paternalistic disrespect for the underlings who 'can't handle the truth'.