How to Say No

Why

Why might you want to say no?

Which of these are good reasons?

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?

• You really feel for the person asking you for help. They're stuck in an unfair spot, and you know you have the power to save them. Maybe they aren't even in that big of a bind, but you've felt their pain before and still really want to help them.


• You want to prove you're capable.


• You think the owner won't do enough in time.


• The person asking has positional authority over you (e.g. your manager).


• The person asking is your friend.


• And many, many more!

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

Mental Model: Time = $

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:

Usually, the more important work becomes known first:

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.

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.

Conclusion

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.

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.

Conclusion

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.

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?

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

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.

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.

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.

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."

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.

• No one wants to give up headcount (unless the task is really important)
• You aren't saying "no", you're giving them a reason to say no to themselves. So the ball's in their court, not yours. This means they probably won't nag your, whereas saying no directly could result in a long sequences of "please"s.

TTMM: "Talk to my manager"

• Oftentimes, people ask ICs for things because they know the IC's manager would say no. → TTMM = proxy no
• Managers are busy, so they are hard to get a hold of (i.e. asking a manager = high cost). → TTMM = "Prove your request is worthwhile by doing this costly thing."
• A lot of people are scared of managers and will drop any request if manager interaction is involved.
• This sends the message that you are aligned with your manager. A lot of people go through life assuming managers are just a hammer to drop on ICs. When you flip the script, they suddenly feel very alone fighting against you, so they give up.

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.

Stonewall

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.

Guidelines

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.

• Is the need behind the request legitimate? If there is a real business need for coverage of these requests, but no one tasked to take care of them, then the organization needs to change in order to sustain this need going forward.
• If the person didn't know you aren't responsible for this task, why did they think you were? Can you add a gate so they go to the right owner in the first place?
• If the person was pushing you to do something you're not responsible for, with the knowledge that you're not responsible, their behavior is improper. Does your manager know what they're up to? Does their manager? Sometimes people get results by bullying. This is not okay.

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.

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:

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.

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

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!