I think one of the more fundamental issues is the programmers access to that conversation itself. I’ve seen this scenario be far more common when developers try to get business context :
Management: “I want an app that does A.”
Programmer: “Alrighty. Can you give me more details on why you want that app and what you’re hoping to achieve?”
Management: “No. Now how long will it take to get App A out the door? Executive Foo said he wanted app A, so we need to give it to him ASAP.”
Programmer feels satisfies they’ve at least tried, and any screwups are managements fault. Scrambles to get App A out the door. Management comes back with feedback
Manager: “What is this? This isn’t what we asked for. It doesn’t even remotely address Business Problem B and now Executive Foo is on the warpath after championing this project and looking like a fool!”
Management finds a way to convince Executive Foo it was all the overpaid, useless developers that screwed up and reinforces the stereotype of IT being an untrustworthy and frustrating blackhole of a cost center. Management saves face and they pay a consultant to do it. The programmer is left dizzied by the sudden political flak they were just blindsided by.
Ha! I'll take your word for it. Makes me think I would not last long at all in that kind of workplace, as I'd go right over managers head to executive foo with evidence if he pulled that on me.
I've only worked in a place like that twice. Once (a large company), I didn't last long. In the other (a growing company), the blame-shifting and credit-stealing politics and the people who brought them in didn't last long.
In that situation, it's really a lose-lose for the developer. If they go over their manager's head, they've just made a very unfortunate enemy. And as the manager has more rapport and access to the executive, it's likely going to wind up fruitless as the manager finagles doubt into your evidence (by leaning on that existing relationship and handwaving misunderstandings and referencing non-existent verbal conversations into the points of contention that you raised).
And if they don't go over the manager's head, they now have an internal reputation for incompetence that'll negatively impact the rest of their time at that employer. So they're screwed either way.
At that point it's better to just leave rather than make waves. If you make waves they can come back to drown you later on during your career or job search. If you leave with little ado it stays more compartmentalized to that toxic environment.
Management: “I want an app that does A.”
Programmer: “Alrighty. Can you give me more details on why you want that app and what you’re hoping to achieve?”
Management: “No. Now how long will it take to get App A out the door? Executive Foo said he wanted app A, so we need to give it to him ASAP.”
Programmer feels satisfies they’ve at least tried, and any screwups are managements fault. Scrambles to get App A out the door. Management comes back with feedback
Manager: “What is this? This isn’t what we asked for. It doesn’t even remotely address Business Problem B and now Executive Foo is on the warpath after championing this project and looking like a fool!”
Management finds a way to convince Executive Foo it was all the overpaid, useless developers that screwed up and reinforces the stereotype of IT being an untrustworthy and frustrating blackhole of a cost center. Management saves face and they pay a consultant to do it. The programmer is left dizzied by the sudden political flak they were just blindsided by.