How to Say No

...and when and why to say no

Written in April, 2021


Why might you want to say no?


Common, easy to accept
Not Enough Time

You're too busy to take on new responsibilities.


You don't think the request is feasible, so you don't want to waste time on a sinking ship.

Scope and Responsibility

The request is outside of your personal scope.


You disagree with the premise of the request - anywhere from disagreeing on the importance to thinking the request is unethical.

Interpersonal Reasons

You have a bad history with the requester, or maybe they just didn't ask nicely.

Decision-making Power

"No" = power. More on this later.


Less common, harder to accept

Which of these are good reasons?

Answer: All of them!


Common, easy to accept
If you say yes, you will slip on other tasks, which are presumably at least as important as the new request.
Not Enough Time

You're too busy to take on new responsibilities.

Time is valuable! Why waste it? Not only should you decline these requests, but you could let the requester know, so they can save their time as well.

You don't think the request is feasible, so you don't want to waste time on a sinking ship.

If it belongs to someone else, don't infringe on their scope without consent.

If it belongs to no one, expose the ownership hole; otherwise, who will do these requests in the future? If you take the task, people will believe you own it.
Scope and Responsibility

The request is outside of your personal scope.

People request things they shouldn't all the time because they don't have the context necessary to know the idea is bad. The requesters deserve the change to learn about the context so that they can grow.

Alerting to ethical concerns is necessary for any organization to be ethical.

You disagree with the premise of the request - anywhere from disagreeing on the importance to thinking the request is unethical.

The answer here isn't necessarily "no", but at least "not yet." If collaborators don't get along, they will communicate less, resulting in worse decisions. If you're worried about your ability to communicate with this person, you should at least ask your manager for advice before proceeding.
Interpersonal Reasons

You have a bad history with the requester, or maybe they just didn't ask nicely.

There are certain tasks where you will need some minimal decision-making power to succeed.
Decision-making Power

"No" = power. More on this later.


Less common, harder to accept

These are all good reasons, but...

Why might you NOT want to say no?

If saying no was easy, I wouldn't be writing this right now. So why is it hard?

These are all fair reasons to say yes. Saying no is hard because sometimes, "no" really isn't the right answer.

However, our goal now is to show you that sometimes, these reasons can mislead us to say yes before we realize the hidden cost. Informing ourselves of the cost of yes can mean the difference between spending time on the wrong issue versus having time when the right opportunity arises.

The Hidden Cost of Yes

Something Good that Steve Jobs Said

People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying 'no' to the 1,000 things.

Mental Model: Time = $

This is you. Hello! This is your time.

Each dollar represents 1 unit of time you have available.

Suppose you're planning your work for the next quarter. Simply put, you have 20 units of time to get things done for the whole quarter. How should you choose which tasks to allocate that time to?

Let's use these tasks for this example:

Most Valuable A1: Big Critical Project #1 (Cost=10) A2: Big Critical Project #2 (Cost=10) A3: Automate toil (Cost=5)
B1: Documentation (Cost=3) B2: Carry-over from last quarter (Cost=5) B3: Required maintenance (Cost=5)
Least Valuable C1: Ping (Cost=1) C2: "I'm confused, please explain" (Cost=2) C3: "Could you build me this thing only I can use?" (Cost=10)

Usually, the more important work becomes known first:

Back of your mind: A*, B*
Your manager adds some pressure: A1, A2, B2
C1 comes in.
C2 comes in.
C3 comes in LOUDLY.

The People Pleaser

Let's take a look at how The People Pleaser tackles this challenge. This person says yes to every request, so they work on whatever was asked for most recently.

Most Valuable A1: Big Critical Project #1 (Cost=10) A2: Big Critical Project #2 (Cost=10) A3: Automate toil (Cost=5)
B1: Documentation (Cost=3) B2: Carry-over from last quarter (Cost=5)
2 x
B3: Required maintenance (Cost=5)
5 x
Least Valuable C1: Ping (Cost=1)
1 x
C2: "I'm confused, please explain" (Cost=2)
2 x
C3: "Could you build me this thing only I can use?" (Cost=10)
10 x

Since the least valuable tasks are requested last, The People Pleaser completes these first, producing 3 very happy customers. Of course they're happy; people aren't usually this accommodating! Then, they have 7 left for the work their team actually wanted them to do.

IMPORTANT: The point of this exercise isn't to shame The People Pleaser. People pleasers are often are very responsible people who have a hard time rejecting work that needs to be done. This is a great trait to have, but it seriously limits your productivity, as we can see here.

The result is that The People Pleaser must allocate 5 of their 7 remaining to the required maintenance, leaving only 2 for forward progress. Unfortunately, this means the carry-over from last quarter is only 2/5 complete by the end of this quarter. It'll get carried forward again to the next quarter.


By end-of-quarter, the only task The People Pleaser has completed for their team is the 5 mandate. They also made a bit of progress on some work that's already overdue.

One Optimal Allocation

Let's take a look at different allocation of work. There isn't a single correct solution to this problem, but this is one optimal way to do it.

Most Valuable A1: Big Critical Project #1 (Cost=10)
10 x
A2: Big Critical Project #2 (Cost=10) A3: Automate toil (Cost=5)
5 x
B1: Documentation (Cost=3) B2: Carry-over from last quarter (Cost=5) B3: Required maintenance (Cost=5)
5 x
Least Valuable C1: Ping (Cost=1) C2: "I'm confused, please explain" (Cost=2) C3: "Could you build me this thing only I can use?" (Cost=10)

In this example, we've actually completed an entire large project for the team! In addition, we've completed the mandate and also automated some toil. Next quarter, the team members could have 21 or even 22 available to spend. Generally, you can prioritize toil-automation work the same way you'd evaluate the cap rate of an investment property. Essentially, how many quarters will it be before the work pays for itself? Often, the payback will scale across the whole team, such that these tasks can pay themselves off in the first quarter alone.

For example, suppose a 5 task will give each engineer 1 back each quarter. If you have 7 engineers on your team, you'll have +2 (1 x 7 - 5) in the first quarter. You'll be cashflowing +7 forevermore.


Not only did a lot of important work get done, but we've actually reduced toil, which means we've freed up even more to spend next quarter!

How do you accomplish this?

Notice C* come in last, but you'd rather do A-B than C. What do you have to say to C*? ;)

Risk: Missed Opportunities

I've found that in order for people to say no, they need to actually be afraid of saying yes. Basically, their brain needs to resist saying yes as hard as it resists saying no. So, here are some stories where I'll try to give you that fear.

Saying yes to too many things

You say yes, yes, yes to request after request until your entire plate is full. Suddenly, your dream project comes up for grabs.

Oh no, you don't have time! What do you do? You've made so many promises. You can't go bak on those, can you? You would disappoint so many people. They already expect you've budgeted time to do their thing. They already have other plans dependent on you pulling through.

Saying yes to the wrong thing

You've always wanted to work with the alpacas but the only options you have right now are turtles. You say sure, you'll work with some turtles.

After you're done, you get 2 options: turtles or ostriches? You already know turtles, so you go with turtles again. Why no? Next round, it's turtles vs iguanas. Your teammate thinks, "Since they like turtles so much, I'll give them turtles instead of iguanas."

Maybe alpaca tasks come up soon after, but no one offers them to you anymore. You're the turtle master now. All turtles get automatically assigned to you, and no one wants to give you alpacas because you're needed for turtle support.

How to become project owner

A final note on why to say no...

Saying "no" gives you decision making power.

Most decisions that are made in meetings are made by consensus.

/kǝn' sensǝs/

  1. a general agreement: UNANIMITY

In other words, consensus means everyone agrees. So who holds the most power in a room trying to get consensus?

Answer: the last person to say "yes."

See also: pork barrelling

That said, I am not advocating for you to go out and start empire building by blocking a bunch of projects. This reason for saying no is a bit special:

I want you to understand this dynamic, so that you can recognize when it's happening. Blocking urgent projects for negotiating power is a fairly common strategy among area leads, for better or for worse. You might notice other leads blocking your work for this reason. If you notice this during the meeting, you can regain control by subtly calling it out. For example, you can say, "This thing you're asking for is not really related to the goal of this meeting. I'd be happy to discuss that offline with you, but in the interest of everyone else's time, what do you think of the proposal we're discussing now?" Since they never had a real reason for rejecting this proposal, this will usually corner them into granting approval.

On the flip side, you may even notice your lead doing this to other people! Frankly, there is a valid reason for employing this strategy - sometimes you will need to work with people whose incentives are misaligned from yours, and you fundamentally cannot shift their stance without creating this type of leverage. If you see your lead doing this for a good reason, then stay out of their way and let them succeed. On the other hand, if you notice your lead doing this regularly without a good reason, then you've learned something important about how they do business. How you choose to act on that information is entirely up to you.

Alright, so how do we actually say no?

i.e. what you actually read this for

A few ground rules

  1. Know your scope. What do you own? What are you officially tasked to contribute to?
  2. Know your team's scope. How would your manager answer the previous question?
  3. Know what's important. What are the top priorities for the business? What factors are most likely to outshine the others based on the current business cycle? On the flip side, what is needed (by your team, project, partners, etc.) that isn't a top factor for the company? These are often the hardest but most impactful to prioritize.

Basic Template for Refusal

1. Clarify their request.

Listen closely, and ask follow-ups until you both agree that you are on the same page. The goal is to get at the underlying need, or the high-level premise. This will come in handy later.

2. Clarify the real requirements.

Sometimes, requesters don't realize how much complexity is hidden in their request, beneath the seemingly simple surface. State what information you would need if you were to fulfill the request. If this is a time consuming (expensive!) request, would you be able to slot this into your prioritization?

What are the project tradeoffs? For example, suppose they are asking for a new table of metrics. Do they care more about data precision or delivery time? If they want infinite precision and instant delivery time, their request is infeasible, even if they "need it yesterday," no matter how many VPs demanded it.

3. Explicitly say no.

This must be very clear.

I used to work with a guy who always gave a detailed rundown of everything that made a request too expensive or infeasible, then leave it at that. The bolder customers came up with a neat trick: as soon as he finished talking, they'd reply, "That sounds challenging. I'm so glad our engineers are as brilliant as you, so you can finish it by next week anyway! Bye!" They'd leave before he could come up with a response, and usually he'd deliver some garbage around the deadline that they'd demanded.

4. Provide next steps.

Unblock them somehow. If they're reporting a bug, try giving them a workaround. If someone else can help them, suggest they talk to that person. Pass along their email or team mailing list.

Notice how this template isn't just for refusals. It's really a generalized template for gathering requirements. Steps 1 and 2 are critical if you end up saying yes. If you don't follow both of those steps when receiving and consenting to a request, then you may well be setting yourself up for failure.

The point is that you need to go into every request with eyes wide open. That said, there is a wide gap between legitimate needs and infeasible requests - that is the canvas for the art of negotiation. :)

Strategies You Can Try

Give a Cost

Instead of saying "no I won't do X," say "X costs Y."

When to Use
The requester doesn't seem to realize how hard X is. X doesn't have to be hard-hard, just harder than they think.


Eddy: "Edd, could you implement this metric for me?"
Edd: "In order to implement that metric, I need you to give me a clear description of what you want that metric to measure, and we need to work through these logging edge cases to make sure we're on the same page with what this metric counts. Then, it'll take a day or two to run test pipelines to compute sample values for this metric. If those samples look good to you, then I'll need another day or two to submit the code, and the metric will show up in your dashboards in about a week."

Buford: "Isabella, I need this report done by tomorrow."
Isabella: "My plate is already full with reports on A, B, and C for tomorrow. Which of A, B, or C should I drop to make time for this new report?"

Pay for it ("Give a Cost" ++)

First, give the cost. Then, ask them for headcount (either on loan or permanent depending on the cost) in exchange for the task or territory.

When to Use
The requested task is explicitly not your responsibility. You also want more resources for your team. If you're an individual contributor (IC), you've discussed this plan with your manager, and they're cool with it. (Company-specific constraints apply, obviously)

Why it works

TTMM: "Talk to my manager"

Why it works

When to Use
You aren't confident you'll be able to reason with this person (give a cost), and you don't think they'll feel any empathy for you (basic template). You don't want to directly say "no" for whatever reason. You just need the effect of a "no".

You might be worried that this influx of requests will make your manager annoyed with you. YMMV, but no one I've said this to has ever actually talked to my manager (according to my manager).

UPDATE: 2 years since I originally wrote this, there have actually been 2 intrepid souls who went and talked to my manager. Both of them turned out to have legitimate requests, albeit expensive, so both ended up giving headcount to my team. So all in all, this strategy is still working beautifully as intended!

Garner Sympathy

Sometimes, the requester doesn't understand that you're really busy, so they think poorly of you for telling them no.

Whey Not to Use
This strategy is literally just complaining. Complaining too much is annoying. Also, complaining about being overloaded specifically can result in projects/opportunities being taken away from you because leadership believes you can't handle it. And critically, it's important that the requester doesn't feel like you're saying your problems are more important than theirs.

When to Use
The requester seems to think that you're at their beck and call. They've clearly shown they are not willing to allow you reasonable lengths of time to take action on requests. Alternatively, this strategy can sometimes be a kindness. If they also feel overloaded, it's possible to express this in a way that makes them feel less alone in their overloaded-ness.

Example: "I really wish I could help, but I'm super underwater right now with X, Y, and Z. I'm really sorry about that, I'm sure this feels unfair and I wish I could do something to fix it."

Message sent: "I'm on your side, but there's nothing I can do."


Instead of communicating with the requester, either don't respond at all or say literally just "no" with no other words. Tell your manager you did this and why, so they have a heads up and they can work with you on next steps.

IMPORTANT: When Not to Use
You have a long-term working relationship with this person, so your interpersonal issue is well worth the effort to resolve.

When to Use
You've tried all of the other strategies. They just won't leave you alone. You just need to get away from this communication channel because it's taking too much time and stopping you from making progress on anything else.

Sometimes, this strategy is useful just to get a pause. A break can help you clear your head and figure out who your allies are. Then, you can get support from someone close to you (teammate or manager), strategize together, and then proceed.


Commit to the No

Don't say no unless you're sure, because going back on your word will teach requesters that your "no"s can be undone with sufficient pestering.

If you aren't sure, talk to a teammate before responding.

Remember, after you've said no, the requester will finish feeling the pain very quickly (order of minutes-hours)! Saying "nvm yes" 3 days later won't take that pain away. It will, however, make them re-live the pain of your initial no.

Present a United Front

Saying no is problematic if someone else (e.g. a partner or teammate) later says "yes".

Saying no costs social capital because everyone feels like their request is reasonable, and hearing "no" sounds like you're saying the request is not legitimate. We mitigate this by convincing the requester that the "no" is legitimate.

If someone changes that answer to "yes", then your initial "no" seems extra illegitimate. The requester may never trust the legitimacy of your "no"s again.

Empathy is Effective

People generally think of empathy as just a piece of being a good person, but it really goes deeper than that. The literal definition of empathy is: the action of feeling someone else's feelings. In other words, empathy = internalized understanding that is shared between 2 people.

Empathy is evidence of effective communication. You can use this as a signal by checking: whenever you don't feel mutual empathy, there may be something missing in your communication.

Saving Time

The implicit theme of this whole doc is on how to save time, but we haven't talked about how saying no itself takes time. Ideally, you wouldn't have to say no at all, if the person didn't ask you to begin with.

Check if you could prevent these requests in the future by asking:

A Quick Diversion into Prioritization

The Prioritization Matrix

This is a variant of the "Eisenhower Matrix", which recommends Do/Decide/Delegate/Delete in place of Manage/Focus/Prevent/Avoid.

Important Urgent

Strategy: MANAGE

These things must get done, but prioritize important-non-urgent whenever possible.

  • Migrate off deprecated infra
  • Last minute demands from leadership

Important Non-Urgent

Strategy: FOCUS

These are often the most impactful because they enable long-term growth.

  • Strategic planning
  • Security (usually)

Non-Important Urgent

Strategy: PREVENT

Minimize your time on these things; push back when possible and fulfill quickly otherwise.

  • Random interrupts
  • Some meetings (especially recurring)

Non-Important Non-Urgent

Strategy: AVOID

Try not to do these things.

  • Watch Dragonball Z
  • Cross campus for better ice cream flavor

Most people start out doing work that's Non-important Non-urgent, just because it feels good. The first phase of engineer maturation involves learning to reject Non-important Non-urgent in favor of the primary workstream, which tends to be laden with Non-important Urgent.

The next phase of maturation is learning to recognize importance. This allows the engineer to distinguish between Important Urgent and Non-important Urgent. They will shift their work to prioritize tasks by importance. At this stage, they have not seriously decoupled importance from urgency. However, now that all the work they do is urgent, they may start to notice that some flavors of work come up that are clearly important, but aren't getting worked on.

The final shift comes in learning to prioritize Important Non-urgent against the Important Urgent. The tricky part is that the vast majority of your colleagues will be at an earlier stage, where they can't yet distinguish between importance and urgency. So in prioritizing Important Urgent work, you may initially be criticized for doing work that's "less important," simply because it's less urgent.

The really interesting point to observe here is that generally, Important Non-urgent work is actually much more impactful than Important Urgent work. That's because, no matter how hard we try to decouple importance from urgency in our minds, they are still inextricably linked. A lot of Important Urgent work involves fulfilling mandates to prevent regression, which just keeps the boat afloat. Important Urgent work, by its nature, tends to provide only short-term gains. Important Non-urgent work encompasses nearly all the transformational, broad efforts that are needed for long-term growth.

There are 2 broad flavors of Important Non-urgent: transformational impact and long-term guardrails.

Transformational change is never urgent. Good transformational ideas are harder to grasp, simply because there is no clear basis for comparison. A great example of this is successful hackathon projects. Many large companies can name at least one critical feature that came out of a hackathon. Why? Because those ideas never would have gotten prioritized in the standard process, because not enough people will buy into staffing non-urgent work.

Long-term guardrails include everything from security, to test and lint coverage, to setting a culture. None of these needs ever come with deadlines, but the longer we procrastinate, the harder they are to implement when we finally do prioritize them. Usually, in mature companies, these topics fall into the "too late" bucket: ICs will get dispatched to churn on the issue for a while without making any progress, just so that leads can say they allocated manpower to the issue.

There's no easy solution for this, but we can use the tactics described above to gain leverage in prioritizing this work against those who may not understand the criticality.

Flavors of "no" that really mean "not yet"

Sometimes you buy into the importance of a rquest, or even the spirit of a request, but you just can't feasibly fulfill it in the immediate future. Here are some options:

Talk to your manager (i.e. escalate the staffing hole)

Assigning appropriate staffing to products based on organizational needs is a big part of your manager's job, so if you encounter an issue here, you should let them know.

OKR for next quarter

If this is a well-scoped request that you just haven't budgeted time for, suggest adding it to the next quarter.

Add to vision doc

It's helpful to have a vision doc to track your "dream" scope (and associated headroom) for each major product you own. When you see a great idea, or a need, but don't have a well-scoped, feasible solution, you can track the need in your vision doc.

That's all, folks!