Eric Brechner wrote an interesting post titled “Don’t panic“, about how to deal with requests. I sometimes agree and sometimes disagree with what Eric writes, but it’s usually a pretty good read.

In this case, I agree with his approach, but disagree with his advice.

He advocates that when anybody comes with you for a request, your first response should always be “Yes, I’d be happy to help”.  Which is wrong.

Way back when my daughter was 4, I was sitting on the couch and she came and asked me for something. My memory is a bit hazy on what she asked for, but I think it was some sort of snack. I didn’t think deeply about it, and made a quick decision and answered “no”. She got pretty upset and started crying and asked again.

At that point I had a quandry. I thought about it a bit more, and realized that her request was a reasonable one (lunch was a long time ago) and that there was really no reason to grant it, but I knew that I couldn’t because at that point is wasn’t about the request but instead was about the way it was asked and the pattern me changing my mind would set. I didn’t want to set up a behavior where getting upset and crying is expected to make your dad change his mind. So I held firm.

And felt really bad about it, because I made the wrong initial call.

The whole point of the story – assuming that there is a point – is that you need to look not at the current interaction but instead at the meta-level. What message is your response sending? What pattern of interaction is it reinforcing?

If somebody comes and asks you to do something and you say, “yes”, once that word leaves your lips you can assume that the person making the request will think that they are getting everything they want from you. They have in mind a big feature delivered on an impossible date, and your job then becomes trying to scope their expectations down to something manageable, but even if you succeed they’ll still be stuck on what they originally had in mind, and will be disappointed with you.

Not to mention the fact that if you immediately say “yes”, it seems like you’re either working on unimportant stuff and/or not working hard enough.

The right thing to do is to say “no”, but in the right way. Something like “I’m/we’re currently booked and have a lot of high-priority work planned, so I think that would be hard to fit in, but let me understand exactly what you’re asking”. That puts the requester in the position of having to convince you of the importance of what they want to do and be able to explain the details coherently.

At that point, you can start the nuanced discussions that Eric talks about – talking about the details of what they want, why they think it’s important, etc. It becomes very clear very fast whether the requester has done his homework, and if they haven’t you can point out the additional things he needs to figure out before you talk more. If he has done her homework, you can discuss where you think the feature ranks (always subject to the approval of whoever approves features), and how it might be broken apart/modified to bring it in earlier.

At that point, the answer usually becomes, “yes, we can do <x> in timeframe <y>”, which makes the requester happy – you’ve spent the time to explain to them why you put a specific priority on the request and you’ve made your life harder by rearranging things to slot their request into your current schedule and (probably) taking on the task of explaining to everybody who’s below the new feature’s priority why they aren’t getting what they expected.

And, you’ve set up a healthy pattern of behavior. Requesters are likely to do a bit of homework before they talk to you, and you are busy but willing to take on new work if it makes sense to do so.

And that’s the power of “no”.