There's another great essay on Hacknot. In A Dozen Ways To Sustain Irrational Technology Selections, the author explains there is a myth about software developers:
External observers often think of programmers as being somewhat cold and emotionless...Those who have watched programmers up close for any length of time will know that this is far from the case. I believe that emotion plays a far larger part in IT decision making than many would be willing to admit. Frequently developers try and disguise the emotive nature of their thinking by retrospectively rationalizing their decisions...
With tongue-in-cheek, the author goes on to list twelve ways to protect your image in the face of a bad technical decision. Here's number ten:
10. Exclude The Technically Informed From The Decision Making Process
As a self-appointed evangelist for your chosen technology, your worst enemy is the voice of reason. The technology's inability to fulfill the promises its vendor makes should be no obstacle to its adoption in your organization - and indeed, it won't be, so long as you can keep those who make the decisions away from those who know about the technology's failings. Let their be no delusion amongst your staff and colleagues that it is management's purview to make these decisions, and the techies' job to implement their decision. Some will try and argue that those who know the technology most intimately (technical staff) are in the best position to judge its value. Assure them that this is not so and that only those with an organizational perspective (management) are in a position to assess the technology's "fit" with the corporate strategy. Allude to unspoken factors that influence the decision to use this technology, but are too sensitive for you to discuss openly (conveniently making that decision unassailable).
In my opinion, it's a good list, but the author missed at least one item. Here's my contribution:
13. Banish the Infidel
When pleading your case to management, lament the fact that those who disagree with you just aren't "team players". Label the dissenters as malcontents. Make it clear it is they, not you, who are being emotional about your technical decision. Of course, you can't literally banish the dissenters -- especially if it is a large group. Who would implement your design? However, you can ostracize the dissenters to the point where their voices are not heard, and here's the silver lining. When your design fails, you can blame the implementers. Your choice of technologies was sound, but the dissenters, perhaps unconsciously, made it fail by suboptimizing the implementation.
What else is missing from the list?