I was sitting nodding me head with that, but I did have a manager who was a trained engineer. He was good. Knew enough to know what to ask you, but didn't assume that he knew enough to implement something - so left the fine details to the developers.
Now I have a team leader and group leader on top of that, who are in my opinion junior to intermediate level programmers who have gone for the management option early. They are annoying because they think they know how to solve a problem. Their requests come in the form of half though out solutions. "We need a new table in the database with these fields" as opposed to "I want to track this information and see it here". I have to translate these to higher level requirements, then work out the implementation details myself, as often their "solution" has flaws - we actually need two related table, or an additional field in an existing table - not the new table they have suggested.
Your second example is exactly what I had in mind. It reminds me of the final group listed in this quote from General Kurt Von Hammerstein-Equord:
"I divide my officers into four groups. There are clever, diligent, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and diligent -- their place is the General Staff. The next lot are stupid and lazy -- they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the intellectual clarity and the composure necessary for difficult decisions. One must beware of anyone who is stupid and diligent -- he must not be entrusted with any responsibility because he will always cause only mischief."
Explaining why testing is necessary. Corollary: Explaining why despite having delivered the application once without testing once, it does not mean testing is useless.
Explaining that our testing is not useless because the client found a bug.
Explaining that it is normal that we get some specification wrong and need to change them after further discussion with the client. No we do not need to fire the BA.
Explaining why, despite coding our apps "by the spec" we still need to schedule some integration testing.
Explaining that public shaming of a developer that committed a bug is counterproductive.
Explaining that the priority on task to LOW allow us to know what task will not be done if running out of budget. Also explaining that setting all the task as HIGH is not a workaround for lack of budget.
Explaining that budget consumption is not a proper indicator of progress. Also 9 women cannot have a baby in 1 month.
Sometimes the client is wrong, it is ok to discuss with the client.
It is ok to be wrong. Yes developer are wrong all the time and that does not make them bad developers.
You cannot estimate with 100% certainty.
Analogies and high level description are not substitute for in depth knowledge.
Now I have a team leader and group leader on top of that, who are in my opinion junior to intermediate level programmers who have gone for the management option early. They are annoying because they think they know how to solve a problem. Their requests come in the form of half though out solutions. "We need a new table in the database with these fields" as opposed to "I want to track this information and see it here". I have to translate these to higher level requirements, then work out the implementation details myself, as often their "solution" has flaws - we actually need two related table, or an additional field in an existing table - not the new table they have suggested.