My company had non-developers make these decisions and we paid the price. We were an org of PHP and Python developers "forced" to switch to C#/.NET (At the request of two technical-ish, but non-developer VPs) It really sucked because the teams expert knowledge got wiped to zero and we had to spend several months learning new tools while also keeping our original deadlines. At the time, I jumped at the opportunity to explore something new. Ultimately however, it was bad business and continues to cost the company money as nothing we were doing received any direct or indirect benefit from being done in .NET. The only difference was we worked slower and produced more defects.
A manager's job is to make sure his/her employees have the facilities that they need to get their jobs done. They shelter employees from political bullshit, provide them resources, and enable them to make the decisions they need to make. When necessary, they also facilitate/broker conversations where wrinkles need to be ironed out.
A very large problem I've seen with technical managers is there are those that think they know everything and need to provide technical input (or insist on actually coding). More often than not, they think they know more than they actually do (and often refuse to acknowledge their weaknesses). This has provided me more headaches than non-technical managers not understanding what I am working on...
For myself, I've been in a number of senior roles in the past several years, I have my opinions based on knowledge and experience, but I know my limits. I try and encourage those around me to be open about their thoughts/challenges. I would rather take the time (bounded) pursuing a dead-end that someone else (less experienced) proposes, if it seems reasonable, than denying the investigation if I had an opinion based on stories/limited experience.
In general, I always learn from listening to others -- more or less experienced. A good manager will do the same, listen to his/her team, and facilitate their input/and growth.
A lot of managers believe their job is to make decisions, and a lot of employees even encourage that. But technology decisions often have subtle, far-reaching implications. So when managers make decisions they shouldn't (e.g., picking a toolset, or outsourcing a project, or simultaneously fixing resources, scope and schedule), they end up thoroughly screwing the developers involved. But if none of the other managers understand the tech either, then managers can happily blame the devs. Hands up everybody who has seen that?
Software is almost unique, in that it's a collective intellectual work that is expected to function and grow and change over many years. The only close equivalent I can think of is legal code, but I think software is worse in that legal code is made to be interpreted by humans.
The only non-technical managers I've had that I didn't at least briefly consider murdering were the ones who, like Rand Fishkin, were comfortable admitting ignorance. That let them leave technical decisions to the techies.