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.
