Yes, and . . .

Yes! (and . . .)How many times have you said “Yes” to a request, only to regret it later?

Many of us like to please our coworkers (and especially our bosses), but always saying “Yes” to a request puts you on the fast-track to being needlessly overburdened and overworked.

And yet when you say “No”, the listener almost always stops listening immediately and prepares for a fight.

How about some example requests:

Q: I know this is due next Friday but can you have it for me tomorrow afternoon?

Q: I need these three features added to this sprint, can you squeeze them in?

Q: Can you grant admin-level access to all the developers in all the production environments?

I don’t know anyone who enjoys saying “No”, but sometimes “No” is the right answer. And yet “No” is such a conversation-stopper. It can get you in trouble with the requester, too. It sends a “can’t-do” attitude to your boss and peers.

Jeffrey Aside

We won’t be getting into the “why”—presumably you have a valid, defend-able technical, business, personal or other right reason for saying “No”.

Yes, and . . .

When “No” is the right answer and it’s not wise, smart or otherwise helpful to say it, try something else.

Q: I know this is due next Friday but can you have it for me tomorrow afternoon?

A: Yes, I think we can, and to do that, we’ll need to delay these other two projects, <name them> while we work on yours instead.

You started with “Yes”, so they’re still listening to you after your first word. And you gave a “Yes” with qualification and not a harsh “No”. After all, this isn’t really your problem. You’ve presumably committed to delivering “this” (whatever it is) next Friday and are well on-track to meeting that commitment. It’s the requester who has the problem. (Oh, and make sure they get buy-in from the other two projects before you change your focus.)

Let’s try this again:

Q: I need these three features added to this sprint, can you squeeze them in?

A: Hmm, let me see (check your list), yes, we can squeeze them in, and you’ll need to get approval from the change board to drop these four other features <name them>.

It certainly beats saying:

A: No, you committed to this feature list (showing the sign-off). Besides, the last time we squeezed your must-have feature into a sprint, it delayed the project two weeks, caused a famine and accelerated global warming. No, No, NO!

One more example:

Q: Can you grant admin-level access to all the developers in all the production environments?*

A: Yes, and we would violate least-privilege access and break our change-management processes.

 

Taking a “No” habit and developing a “Yes, and . . .” approach takes practice and some inventiveness. (You have been saying “No” all along to these ridiculous requests, haven’t you?)

You’ll also need to work on slowing down a little bit when you answer. It takes time to think about the impact of a “Yes” answer on your schedule, the project, your life. But it’s time well-spent if you end up educating the requester and maintaining a good relationship with them.

 

Readers, have you tried this technique and if so, what was your result?


*You might think this is stretching things a bit to just to provide an example. But not really; I was asked this once.

Advertisements

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

%d bloggers like this: