Tell Them No, Just Never Use that Word

I was at an agency meeting some time back, when the head of the company addressed the sales team requesting they take programmers to client meetings as needed. It was at this point I witnessed a lead salesman turn to his colleague and say, “not a chance.” This event didn’t go unnoticed and got around the IT department fast which led to a few conversations. The one concern we got back from the sales team is that the IT people always say no. There is a solution to this, but we need to understand the problem first.

From the time we are little kids, we live in a world of no. No dessert until you finish your vegetables. No, you didn’t clean your room. There’s a lot of big frustration around such a little word. We all want to run around and do what we want. As children, the first part of being punished for misbehaving starts with your parents yelling the word no. It takes our heads out of the clouds and puts our feet back on the ground.

As adults, no gets internalized. We don’t kick and scream when we hear it, although that would be funny to see a board room full of executives “expressing” themselves. Under the calm veneer of professionalism, we are all emotional animals that get mad when we don’t get what we want. That’s not to say we are all boiling under an icy exterior, but telling someone no has real consequences.

No comes from the head, but goes straight to the heart. A programmer rationalizes why something can’t happen because of logically based perceptions. These opinions are not formed out of malice or petty dominance, but far too often are treated like they are.

Before you whip out the big N-O, remember it’s an emotionally charged and potentially damaging word. People are scared to hear it. In the world of business, you will be judged for using that word and the negativity will come right back at you. People will make up all kinds of reasons why you told them no without diving in to deeper issues. It can be a little ridiculous, but it’s the world we live in and we need to adapt.

There are ways to disagree without saying no.  And before you call me out on being manipulative, I am not advocating any level of political doublespeak and clever misdirection. Not because it doesn’t work, but because programmers are smarter than that and we don’t need to lie. So you take no out of your vocabulary, but what happens when you find yourself in a no situation?

The two situations I normally encounter are when requests are literally impossible to achieve and the other is when they makes no business sense whatsoever. Programmers are problem solvers. So use your talents and think about what can happen and what does make sense. Focus on the reasons why something won’t work and develop a solution that fixes those problems.

A common situation is being given an unrealistic deadline. So instead of saying no, tell them about what you can accomplish in that timeframe. Figure out how to stage multiple releases and let the client know that you will concentrate on getting the core functionality right. This helps the team focus on what’s important. If you come up with a better solution, everyone wins.

It’s an educational process that involves the programmers, account service, and the clients. Don’t be mad at them for not knowing. You have to educate them about what reasonable possibilities are and they will educate you about what their problems are. When you fully understand the problem, you should have the confidence to offer up an alternative if what they are asking for doesn’t make sense. And remember, you’re employment depends on your company’s ability to sell something. I would rather be coding than playing salesman, but a good team has to help each other out.

Sometimes a dumb request can be a smart one with a little work. And sometimes despite everyone’s best effort, our clients won’t be persuaded at all. Even if you fail, the best part is you learn what will and won’t work. In time you find ways to shelf the word no in favor of a conversation, at least that’s what works for me.

I love the responses I get from my posts. What I would like to do this week is for those of us out there who have had success in dealing with these situations to post how they handled themselves to help others who might be struggling. After a week, I will take my favorite top three and repost to the main blog as guest entries. Thanks!

Advertisements

7 comments

  1. I’ve been in IT consulting for about 10 years, and I’ve been asked to code some fairly stupid things from time to time. I figured out that ‘No’ was a pretty quick way to get my contract terminated at worst, or not get an extension at best. Either way, ‘No’ meant money out of my pocket. I tried a different tactic which has served me fairly well since. I listen to the request and understand the problem as best as I can. Then I explain why I think it’s a bad idea, identify 2 or 3 major flaws in their request and try to be as objective and professional as I can. Then I end with, “That being said, if you still want me to code it for you, I’ll be happy to do it. I get paid by the hour, so I’ll write whatever you want me to. But, in the interest of maintaining a good partnership between us, I felt like I needed to give you my thoughts on the subject.”

    Clients seem to appreciate the objective analysis, and the not-so-subtle reminder that, while I’ll code whatever stupidity they ask for, it’ll cost them. And the analysis gives them time to rethink the request. This approach won’t work in a large meeting, since the requester needs to be able to back off of their original position. People are less likely to do that with a lot of witnesses. If you need to, take the requester aside after the meeting to discuss it 1-on-1 and let them save face that way.

    Just my $0.02, your mileage may vary.

  2. Quoting from your post, “So instead of saying no, tell them about what you can accomplish in that timeframe. Figure out how to stage multiple releases and let the client know that you will concentrate on getting the core functionality right.”

    This works! I have actually tried this and was surprised at how even a rather tough customer turned very co-operative once we walked him through the specifics.

  3. I just find this too obvious and common sense in a employee-client relationship. “Sure, whatever you want to pay me for that isn’t illegal nor jeopardizes my health.” Just ask why? Then only debate it if it’s worth your time.

  4. I completely agree. I’ve always found the role of a programmer an interesting one. Sometimes business people will think up solutions to problems that don’t make sense. I generally go with what I call a ‘staged’ approach. That is, when you’re new somewhere and the people around don’t necessarily know your competencies yet, just do as close to what the customer wants as possible. When you’re seasoned and trusted you can then make bigger decisions and not risk loosing a client.

    It takes time to learn a system. When the new company has a large system that you’ve been trusted to improve and work with it’s important you don’t make yourself look bad by saying ‘no’ to something that another developer said ‘yes’ to. Or something that you may not know how to do but your client knows someone else was able to deliver.

    In the end asking the person more questions will generally lead to a better overall picture of what they are asking for. I try to get a feel for how technically competent the person making the request is. This helps me to understand if the request they’re making of me is something they know can be done (because they understand technology) or if they’re just confused because computers in general confuse them. Often I glean this information pretty quickly, for example if they call their database ‘the information’, or if they know it’s an access / oracle / sql server application. Any amount of knowledge they have changes how I perceive what they’ve requested.

    Another tactic I’ve used is to deliver the solution in steps. Write a part of the solution and show the person involved your solution. Take note of how they react. Someone that understands development will acknowledge the part of the solution that has been created, or offer different information if it’s not quite what they were looking for. A person that has little to no ability will be confused by the partial solution, having little to no idea what it is they are looking at.

    Always strive to make your client feel like you’re happy to be working with them. Treating them like they’re under educated or ‘stupid’ will loose you work real fast.

    Be sure to stop by my blog when you have a moment!
    http://anthonystechblog.wordpress.com
    — Anthony

    1. I agree that the technical competency of the person making the request is a huge factor. For me that actually changes how I bid out work. I’ve always called it client volatility. If you have to educate someone consistently it will dramatically effect your bottom line.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s