Don't say no, say "yes, but"

These days as companies get a bit wiser about their projects and continue moving towards cross-functional teams it is highly likely that you as a developer will be tossed into a mix of people without technical skills or a real understanding of what you do.

One thing I have seen over and over throughout my career is the perception that the IT guys are the enemy.  They're arrogant, sarcastic, they act like they want to run your department, hell, there was even a Saturday Night Live skit about this.

So here is a pro-tip for you IT workers out there who take part in these teams.  First, realize that the business users around you, they are your customers, and just like you wouldn't expect any sarcastic flack from your service providers, they don't expect it from you.  Second, remind yourself that it is highly likely that none of them have the background, experience, or passion for technology that you do.  Third, learn to say "yes, but" instead of no.

You don't want to be seen as the ambassador of no, the preventer of information services even. People want to be listened to, they want to feel that their opinions are considered and that they have some input into their processes.  Thus, we must resist the urge to do the following things:

1. Interrupt someone in the middle of their speaking- Yes, you can instantly see the road they are going down and know it is a bad one, but don't just jump in and interrupt them, it's rude.
2. Use any dismissive gestures such as looking at your smartphone, gazing off into the distance, squirming in your seat.  Make an effort to keep a reasonable level of eye contact and attentiveness.  If eye contact makes you uncomfortable (yeah, IT has a lot of introverts), then glance at the speaker and take notes.
3. Don't say no.

"But Eric, ", I hear you saying, "we must say no, their ideas are usually bad, they have no idea what it takes to do things".

I agree, but you can say yes, but and still say no.  Let me give you some examples:

User: "We need you to change the scope of this feature"

You: "Yes, we would be happy to do that, but that is going to have a schedule impact, would it be ok if we examined this and got back to you with an estimate?"

This is much more effective than:

"No, we can't do that right now, we're far to busy and we don't have time".

User: "I think we should do _insert really bad idea here_"

You: "Yes... we could go in that direction, but how are we going to handle x, y, and z?"

This is much more effective than:

"No, we absolutely should not do that, if we do that then x, y, and z are going to cause big problems"

In the first case, you said yes, and you're appearing to be cooperative and asking for collaboration on the issues you perceive.  In the second you're putting the user in the position of feeling rejected without any further discussion, which can lead someone to digging in and defending their position whether logical or not.

If you master this skill, you can not only be viewed as a great service provider, but you can often get users to talk themselves out of bad ideas.  Give it a try!