Totally agree - I know of at least one IT manager in 2000 who was fired by the CFO (acting CIO) because he wasn't prepared to support her Blackberry on the mail server (we weren't an exchange shop - Netscape Mail server).
More like he was fired because he didn't have the social intelligence to say "Sure boss, we'll sort that out for you, I'll pull together a business case for the migration and let's meet on monday pm to go through it for sign off."
"No, I won't" is the wrong answer. The above comes to the same thing, but in my experience is not going to result in dismissal.
He could advise her and tell her why it is a bad idea, and if she still wants to use it, he must support it.
Instead he said no, which is fine from his side. But If you don't want to do something the company expect from you, don't be surprised if you get fired.
He was the kind of guy who thought he knew best. He also refused to add a new VPN technology when he was asked to add PPTP to our already existing Netscreen IPSec environment.
Basically, he didn't like being told by the not particularly technically knowledgeable CFO/CIO what technologies to deploy. We had Netscape Calendar/Email. He knew Netscape Calendar/Email. He wasn't interested in deploying a new Calendar and Email technology that he didn't know. The new boss really wanted support for her Blackberry.
To some degree it worked out well for everyone. He was fired, and went to a new job where he got to work with Unix Technologies, and the new IT Manager was hired to deploy Microsoft Exchange.
I concur, and still see that sometimes it really is the right way to just say flat out No.
Ive tried to play ball and call to meetings for distasteful and wasteful requests/requirements from business/manager people, but its such a drain on my energy as a developer, I just began saying flat out No. I take the risks of getting fired, but I will not be bitter 10 years from now for sitting in meetings discussing what is a change request and what is a requirement with people who have not read one paragraph on software engineering, trying to get me to once again change the functionality of the app because of their change in opinion, or trying to just get me to do things just because they say so. Fuck that, and fuck no. Im out. If I am expected to be a code monkey at a workplace, thats not the workplace I want to be at.
In some ways that's your job :) If I was managing you and the situations that you describe came up I'd probably be saying things like "That's why we have antocv - he's normally right, and what do we know anyway". Possibly I'd get "We should boot him and hire a monkey", and if that is the rational thing to do I'd be thinking, "you know what, I need to let antocv know that he is wasting his talents here"
Also I would start looking for a new gig myself...
But it's a different context and situation to the one above. If I came to you as a software engineer and said; "Antocv, our new customer is insisting that we add an extra step in our QA to get our contract signed off" I would expect you to either say "Sure, no problem" or "My friend, it sounds easy, but the thing is that doing it will sink us. Because..." if you said "No" and left it at that I'd conclude this is a guy who I can't work with.
The thing is the reasonableness of the behaviour - if I come to you with a request that you can fulfil reasonably and you are paid to do it, you should do it, or find a way to let me know that I do not really want you to do it in the first place. The "because" is the critical thing; random acts of rebellion are not helpful.
But be clear; nor are dickheads from HR/Accts/Sales appearing and announcing that they know how to do the jobs of skilled professionals by remote control. That's every bit as unacceptable as uncooperative techies, and if you are in an environment where that washes it's definitely for the short term only. It just means that money is being wasted and no one knows what to do.
Either leave now, or put up with it until they go bust; there is no third way.
Thanks for your insightful comment. It is as you described, dependent on situation. For me, I will perform this last project as best I can and leave for new challenges, its only about 3 months left. My plan is to bring up these issues in a diplomatic way on next retrospective, let them know money and time is wasted and ways it can be improved, for example our "standup meetings" every morning inspired by scrum are all more than 30-minutes long, a suggestion would be to just impose the 5-minute rule for a start. I dont know, Im up in the project right now, Ill think more when it settles down towards the end.
And I'd fire him too, any IT manager that can't support a Blackberry doesn't deserve to be an IT manager. Not to mention his bad attitude in not even trying.