How to say “no” to your boss, your boss’s boss, and even the CEO

You’ve got plenty of work to do already, when your boss (or their boss, or the CEO) comes by and asks you to do yet another task. If you take yet another task on you’re going to be working long hours, or delivering your code late, and someone is going to be unhappy.

You don’t want to say no to your boss (let alone the CEO!). You don’t want to say yes and spend your weekend working.

What do you do? How do you keep everyone happy?

What you need is your management to trust your judgment. If they did, you could focus on the important work, the work that really matters. And when you had to say “no”, your boss (or the CEO!) would listen and let you continue on your current task.

To get there, you don’t immediately say “no”, and don’t immediately say “yes”.

Here’s what you do instead:

1. Start with your organizational and project goals.
2. Listen and ask questions.
3. Make a decision.
4. Communicate your decision in terms of organizational and project goals.

Step 1: Start with you goals

If you want people to listen to you, you need a strong understanding of why you’re doing the work you’re doing.

• What is your organization trying to achieve?
• What is your project trying to achieve, and how does that connect to organizational goals?
• How does your work connect to the project goals?

You should be able to connect your individual action to project success, and connect that to organizational success. For example, “Our goal is to increase recurring revenue, customer churn is too high and it’s decreasing revenue, so I am working on this bug because it’s making our product unusable for at least 7% of users.”

When you’re just starting out as an employee this can be difficult to do, but as you grow in experience you can and should make sure you understand this.

(Starting with your goals is useful in other ways as well, e.g. helping you stay focused).

Step 2: Listen and ask questions

Your lead developer/product manager/team mate/CEO/CTO had just stopped by your desk and given you a new task. No doubt you already have many existing tasks. How should you handle this situation?

To begin with, don’t immediately give an answer:

• Don’t immediately say “yes”: Unless you happen to have no existing work, any new work you take on will slow down your existing work. Your existing work was chosen for a reason, and may well be more important than this new task.
• Don’t immediately say “no”: There’s a reason you’re being asked to do this task. By immediately saying “no” you are devaluing the request, and by extension devaluing the person who asked you.

Instead of immediately agreeing or disagreeing to do the task, take the time find out why the task needs to be done. Make sure you demonstrate you actually care about the request and are seriously considering it.

That means first, listening to what they have to say.

And second, asking some questions: why does this need to be done? What is the deadline? How important is it to them?

Sometimes the CEO will come by and ask for something they don’t really care about: they only want you to do it if you have the spare time. Sometimes your summer intern will come by and point out a problem that turns out to be a critical production-impacting bug.

You won’t know unless you listen, and ask questions to find out what’s really going on.

Step 3: Decide based on your goals

Is the new task more important to project and organizational goals than your current task? You should probably switch to working on it.

Is the new task less important? You don’t want to do it.

Not sure? Ask more questions.

Still not sure? Talk to your manager about it: “Can I get back to you in a bit about this? I need to talk this over with Jane.”

Step 4: Communicate your decision

Once you’ve made a decision, you need to communicate it in a meaningful, respectful way, and in a way that reflects organizational and project goals.

If you decided to take the task on:

1. Tell the person asking you that you’ll take it on.
2. Explain to the people who requested your previous tasks that those tasks will be late. Make sure it’s clear why you took on a new task: “That feature is going to have to wait: it’s fairly low on the priority list, and the CEO asked me to throw together a demo for the sales meeting on Friday.”

If you decided not to take it on:

1. Explain why you’re not going to do it, in the context of project and organizational goals. “That’s a great feature idea, and I’d love to do it, but this bug is breaking the app for 10% of our customers and so I really need to focus on getting it done.”
2. Provide an alternative, which can include:
   • Deflection: “Why don’t you talk to the product manager about this?”
   • Queuing: “Why don’t you add it to the backlog, and we can see if we have time to do it next sprint?”
   • Promise: “I’ll do it next, as soon as I’m done with my current task.”
   • Reminder: “Can you remind me again in a couple of weeks?”
   • Different solution: “Your original proposal would take me too long, given the release-blocker backlog, but maybe if we did this other thing instead I could fit it in. It seems like it would get us 80% of the functionality in a fraction of the time–what do you say?”

Becoming a more valuable employee

Saying “no” the right way makes you more valuable, because it ensures you’re working on important tasks.

It also ensures your managers know you’re more valuable, because you’ve communicated that:

1. You’ve carefully and respectfully considered their request.
2. You’ve taken existing requests you’re already working on into account.
3. You’ve made a decision not based on personal whim, but on your best understanding of what is important to your project and organization.

Best of all, saying “no” the right way means no evenings or weekends spent working on tasks that don’t really need doing.