Saying No Like a Pro

Saying no for NDs is hard. We are often very worried about the opinions of our coworkers, we might have spent a lot of our lives being given the message that we’re lazy or being told that our sense that we can’t handle this is wrong.

It’s important to say “no” at work. If we can’t, we’ll quickly get overburdened, stressed and ultimately do our jobs worse. We have a limited capacity, we can’t magically get more done because we said we’d do it. We will pay that cost somewhere else.

But we might not want to say “no” to everything, we want to be known as pro-active, helpful and generally good to work with.

So what do we do?

A new script

Most people’s “yes” is a script; a default response to a certain type of question and we rarely think about. We need to change that scripted response to something more constructive for everyone involved. At first it will be difficult, but over time it will become a natural response.

We need to give a response that gives whoever is in charge all the information they need to make a good decision, while respecting that we have a fixed capacity.

This means there are 2 things to think about:

  1. Who is responsible for deciding your prioritisation? You? Your manager? A product manager? The customer?

  2. What do you currently have on your plate?

We can then come up with our new script! This will look something like:

I’m currently working on <X, Y, Z>, I’d have to drop one of those to take on this. Please talk to <person responsible for prioritisation> to figure out how to slot that in.

Some examples

A customer comes to you and asks for a new feature in the app you’re building while you’re burning down bugs before the launch on June 6th.

The customer is the prioritiser.

“Fix all known bugs” and “launch on June 6th” are the current things on your plate.

You can respond:

That sounds great! Right now I’m working on making sure that we’re bug free before the launch on June 6th. We can slot this in, but we’d either have to push back the launch or leave some bugs unfixed. What would you like us to do?


A person from another team comes to you to ask for a new API call while you’re in the middle of a series of performance improvements to get ahead of increasing demand. You can respond:

That sounds reasonable, but right now we’re really prioritising performance improvements given the growing demand for our service. I’d love to understand if there’s some reason the new call is more important than that.


You are preparing designs for a new feature that engineers are waiting to build. Your manager approaches you and asks you to prepare a presentation for your director about the project.

Hey! I’m happy to do that, but it’ll probably take a few days to prep. That will push back the initial designs by a few days and mean the engineers can’t get started until later. Let me know what call you want me to make!


In all of these examples you’re achieving lots of good stuff!

  1. Maintaining your capacity

  2. Avoiding overwork

  3. Letting a decision maker (which is sometimes you) to make the best decision possible

  4. Avoiding making the decision for them by saying “no” or saying “yes” and then struggling to do it all later

So write it down, and give it a go next time someone asks you to do something.

Previous
Previous

Get Promoted as a Software Engineer with ADHD or ASD

Next
Next

How to Communicate more