Why your default response must be "No"
Summary
Jim Collins once said, “If you have more than three priorities, you don't have any”, and yet we say “Yes” too often, resulting in overload for us and our team. I argue that instead of the instinctive “Yes”, our default response to new requests must be “No”. To say “No” tactfully, we can:
use our backlogs to assess new ideas alongside existing priorities;
leverage our bosses to postpone work, delegate it to others or reduce its scope;
or tactfully decline work in a way that helps coworkers empathise with our existing workload.
Too often, as technologists, product teams and knowledge workers, we say “Yes” to incoming work requests, more often than we say “No”. We like being responsive, and the image of being doers and go-getters. But it’s a truism that the more work you say “Yes” to, the less chance you have of completing that work on time, and at high quality. I argue that our default response to new work requests must be “No”. Radical, or even counter-cultural as it may seem, it may be the easiest solution to fend off overload.
Back in the day, I worked with a colleague, Anya - an incredibly well-read individual, who you’d characterise as one of the “sharpest tools in the shed”. She prided herself on responsiveness.
Send her an IM, and you’d get a response in minutes, if not seconds.
Ask her for a meeting, and she’ll be there.
Quick question? No problem!
You could ask Anya to do something, and you could count on her to be the person who’d make it happen. But as Anya became more senior in the company, her responsiveness became more of an Achilles' heel than a strength.
Smart as she was, Anya had no backlogs or buffers – she treated every incoming idea with urgency, because there was no place to shelve it. As her sphere of influence broadened, her responsiveness became a source of endless parallel commitments for the teams she led. Anya herself struggled with her focus and productivity. When the pandemic-induced remote work revolution began, her poor systems started to show their weaknesses. Soon, her calendar was a frantic mess of shallow commitments. She was busy, yes, but achieving little of substance. Each Friday, her most strategic work remained untouched.
Anya’s trials are a familiar story. As Peter Drucker put it,
"There is nothing so useless as doing efficiently that which should not be done at all."
Interestingly enough, most of us say “Yes”, even when our hands are full, hoping that we’ll have time to make good on future commitments. But of course, we know little about the future and how busy we’ll be. This future-discounting leads to what Cassie Holmes calls the Yes-Damn effect.
“By having this bias that we think we will have more time available in the future, that we will be less busy in the future than we are today, we take on these commitments that when the day comes that we've said 'yes', and then when the day comes we say 'damn', hence the Yes-Damn Effect.”
The Yes-Damn effect has a deep-seated root cause. We equate busyness with value, responsiveness with importance. But as Cal Newport argues compellingly in Slow Productivity, this relentless pace is the enemy of quality.
Pseudo productivity or slow productivity? You choose.
Newport has a name for the phenomenon where we mistake frantic activity for genuine achievement. He calls it “pseudo productivity”. Indeed, when you say “yes” to every request that comes your way, you don’t say yes only to the evident work or its perceived value. You also say an implicit yes to the administrative drag that comes with it.
Responding to emails and instant messages.
Bringing team members up-to-speed.
Communicating with stakeholders.
Providing regular status updates.
Such administrative drag is the enemy of deep work. The more commitments you make, the more administrative drag, and the less time you and your team have for deep work.
Don’t get me wrong, administrative drag is a necessary evil - consider it a tax you pay to achieve an outcome. But just as you plan your investments with an eye on limiting your tax liabilities, plan your work in a way that you restrict the administrative drag.
As you know, I’m a big fan of Cal’s three-point formula for slow productivity.
Do fewer things: Radically reduce concurrent work to the few things that matter most. As Greg McKeown notes in Essentialism, "You cannot overestimate the unimportance of practically everything."
Work at a natural pace: Allow sufficient time and reject artificial urgency. 40-hour work weeks and a notion of fixed schedule productivity are effective forcing functions for maintaining a natural pace.
Obsess over quality: Give the work you do, a good, hard crack. A little of the best is better than loads of the average.
But it’s easy to say that we must do fewer things and say “No” more often. It’s quite another thing to implement this strategy. Like most implementations, slow productivity at work begins with the fundamentals.
Tame idea monsters with a humble backlog
A prioritised backlog is standard practice on agile software development teams, but it’s not as common in general management. When you and your team maintain this system for all potential work, you can shift from saying a naked “No” to a more nuanced, "Not now, let's backlog it".
I’ve always maintained that ideas are cheap and execution is costly. When you don’t have a backlog, you have no option but to keep all ideas and competing priorities inside your head. After a while, the cognitive load gets the best of us. We come upon new, exciting ideas in a
“hot state”. For fear of forgetting ideas, we rush to execute them right away. Soon, the “Yes-Damn” effect ensues.
Here lies the evident benefit of team and personal backlogs. You can park your ideas and revisit them in a “cold state”, when your excitement has died down, and you can evaluate the new item against other priorities.
There are several other benefits to these shared backlogs. You can limit work-in-progress, facilitate autonomy for how people find the next piece of work to complete, and foster a sense of calm in your team. Every individual and team needs these tools, even if they resist them.
Most importantly, backlogs are vital to articulate your strategic “No”.
Say "No" without being a curmudgeon.
Let's acknowledge it: declining requests feels awkward. We worry about seeming uncooperative, damaging relationships, or missing out. The fear is real. So here are a few ways I suggest articulating a strategic, reasoned “No”.
The "backlog it" buffer (your default)
Each time you get a new request, resist saying “Yes”. Pick a variation of the following lines.
"Thanks for bringing this up! Our team’s focus is currently on [X, Y]. Can you please document this request/ idea (e.g., problem, proposed solution, impact) so we can add it to the backlog? We review our backlog [periodically] to prioritise upcoming work. When we have capacity, having the details will help us assess your request against other commitments."
I’ve found that this style of response works like magic. It acknowledges the request but defers commitment. It also introduces healthy friction – the requestor must do some work, beyond just throwing work across a wall.
The healthy friction filters out low-effort/low-value ideas. If they do document it, you get valuable context to evaluate later (in a cold state!). Sometimes, simply writing things down helps the requester realise it's not feasible or urgent, or they forget about it later. Like magic, the work disappears without even appearing on your plate.
Ask the boss to prioritise
An effective boss shields their people from overwork, but bosses are also the source of new work. To help them help you, avoid the instinctive, thoughtless yes, and try something like this:
“We’re already doing [X, Y & Z]. Compared to our existing commitments, how important is this new piece of work? If we start working on this new problem, what do you reckon we can pause for now?”
Your boss or client is probably already aware of your priorities. Asking them to prioritise is a tactful way to have them respect your capacity and protect you from overwork.
You can also ask your boss to deflect work from you to a more appropriate group.
"I’m focusing on [X, Y] items, as you already know. Perhaps [relevant person/ team] is better positioned for this?"
If nothing else works, you can negotiate a conditional yes – i.e. say yes to an inescapable part of the work, while saying no to the rest.
"Given our focus on [main Project from backlog], we could contribute [specific, small, low-dependency, high-value part], but we can't take on the broader scope right now."
You can convert a naked no into a strategic no by letting your boss deprioritise incoming work or delegate it to someone else. Of course, these approaches work only when you deliver cracking outcomes for the few streams of work you commit to. Otherwise, your strategic nos will seem more like cop outs, and no one likes a colleague who weasels their way out of work.
While involving your boss is effective for managing upward requests, you'll also need strategies for handling requests from peers, other teams, or stakeholders where direct prioritisation isn't an option.
Other ways to say "No"
Apart from using your backlog or your boss to articulate tactful, strategic nos, sometimes you may need other approaches, especially with peers and other departments. These are more precise articulations of “No”, but they provide a rationale for refusal that coworkers can empathise with. Here are a few variations I’ve tried over the years.
The "not now": "That seems like an interesting idea. I’d love to give it some thought, but with our existing commitments, I may not be able to start on it until [future date]..." Very few people will challenge your existing commitments or ask you to drop your bar on quality. This response style gives them a realistic expectation of when to follow up with you. If they do follow up on the date you set, you’ll know that the work is essential!
The "focused no": "Thanks, but to maintain the quality bar on [current priority from backlog], that [the boss] wants us to focus on, I must decline new commitments right now." Such a response directly connects your "No" to quality and existing, tracked commitments. If people disagree, they can take it up with your boss.
The “no, and here’s why”: "Saying yes to this piece of work now would mean deprioritising [important project from backlog] or compromising its quality, so I must decline." A response like this links your "No" directly to core, tracked commitments and potential negative consequences of saying yes. Rarely will someone outside your department ask you to drop the quality of your work.
Reclaim your time: become the boss of "No"
I wish I had a happy ending for Anya’s story. But her transition from an automatic “Yes” to a considered "Not now, let's backlog it" is still a work in progress. But she’s committed to a slower, more deliberate, and ultimately more productive way of working that protects her group’s time for her top priorities.
Meanwhile, Anya’s team is making power moves with their backlog on… hold your breath… the world’s most glamorous platform… Jira 😀! Yes, Jira! The team uses the platform to defer ideas, evaluate them coolly, and guard their capacity. I so admire that discipline.
As I end this week’s article, I remember Steve Jobs’s famous interaction from WWDC in 1997. Explaining the process of simplifying Apple’s product line, he said,
"You think focusing is saying yes! No… Focus is about saying no, and the result of that focus will be some great products where the total is much greater than the sum of the parts."
So, the next time a request lands, pause. Resist the urge to say yes instantly. Say strategic "No." Notice the space it creates and how it feels when you visit ideas in a cold state.
Escaping the cult of busyness is not just about productivity; it’s about reclaiming your focus and delivering work you can be proud of. Well then, how about making “No” your default response, starting today?