

Discover more from The Caring Techie Newsletter
The Software Engineer's guide to saying "no"
A 3 part framework for saying "no" + how to apply it + examples
At a Tech company, on a Wednesday afternoon:
Product Manager 👨🏻💼: “So, do you think we can squeeze this small feature in by Friday?”
Software Engineer (thinking 🤔): … to get this in by Friday I need 1 hour to refactor something, 4 more hours to actually implement the feature, then I need to add tests. But wait, I also have 4 meetings, a couple of code reviews to do, and I need to finish this other feature .…
Same Software Engineer 😑: “Yeah, I think so!”.
It’s a tale as old as time: a mid-sprint request (aka scope creep) from a PM meets the software engineer who can’t say “no”. We all know how it ends: the engineer either works long hours, one (or both) deliverables are missed or the quality of work is poor. What would’ve happened if the engineer said “No, I don’t think so”?
The most effective software engineers have mastered saying “no” when needed. Today’s article explains why saying “no” is a must-have skill for software engineers and how to use this skill to manage your workload and align with stakeholders on requirements, timelines, and deliverables.
In last week’s article, we discussed 3 universal strategies for saying “no”:
Simply Decline
Decline and Counteroffer
Buy More Time
These same strategies can be used at work as well. I’ll show you when to apply each of them and provide examples, so keep reading!
Feel free to check out last week’s article here if you missed it:
What happens if you don’t say no
In my journey as a software engineer, I learned to say “no” the hard way. Some of the instances where I didn’t say “no” resulted in:
projects taking 3x longer because I didn’t push back on timelines
the team morale was low because we always felt overwhelmed
our performance degraded
the roadmap got behind
… and the list can continue.
One of my worst experiences was not saying “no” to dangerous shortcuts, and then getting blamed for the bugs.
My biggest lesson was: saying “yes” to something that should’ve been a “no” feels good in the moment, but the price is paid in the long run.

Think of saying “no” as part of your job
As a software engineer, you’re paid to think, design solutions for users, and solve problems, not just to execute. Consider it part of your job to challenge what doesn’t make sense, whether it’s unrealistic ideas, timelines, or workloads.
Saying “no” doesn’t make you seem unprofessional. On the contrary! Look around you, you’ll notice that the more senior people are, the better they are at saying “no”. The reality is that the more you advance your career, the more you’ll need to prioritize your time ruthlessly.
I understand it can be intimidating to say no to someone in a higher position of authority. As a manager, I assure you your manager wants you to be honest when you are unable to do something. They may not be aware of your workload or challenges, it’s on you to communicate it to them. Remember, it is your manager's responsibility to challenge you, and it is your responsibility to push back when necessary.
The key is in how you do it.
Remember the principles
Remember the principles discussed in last week’s article:
Use a calm, but assertive voice
Be polite, but don’t sugarcoat
You’re saying no to the idea, not rejecting the person
Frame your “no” as a tradeoff
A “no” can easily become a “yes”, but it’s harder to go from “yes” to “no”
The 3-part framework for saying “no” at work
I will present the 3 options in the order from the strictest to the most flexible. My recommendation is to try them in the opposite order, first try to buy more time, then think of a counter offer, and only if that doesn’t work use the hard “no”.
1. Simply Decline
Why it works: This strategy works when you want to inform someone of your boundaries and availability. Most people don’t know how busy you are, or what your priorities are, so just telling them can be good enough.
Optional:
explain why: ”Due to other commitments…”
express regret: ”Sadly”, “Unfortunately”
express gratitude: ”Thank you for understanding”, “Thank you for considering me”, “I appreciate it”
Examples:
2. Decline and Counteroffer
Why it works: This strategy works best when you want to show the other person you are interested in helping but under different conditions. This “no” might not be final, just starts a negotiation.
Like my friend
puts it very nicely: “That way you are seen more as a partner who’s aligned towards a shared goal, rather than just someone who’s against them.”Examples:
3. Buy More Time
Why it works: We often think we need to give answers right away, but that’s not always the case. This strategy takes advantage of that and gets you the time you need to decide whether to say “yes” or “no”.
If applicable:
request what you need
involve another authority–usually the tech lead, manager, or product manager–in making the decision
Examples:
TL;DR
Not pushing back can result in overwhelm, delayed roadmaps, and poor team morale.
Saying “no” is not unprofessional as long as you approach it correctly.
It’s possible to say “no” and still negotiate a solution to achieve the original goals/priorities.
Declining, counter-offering, or buying time are effective strategies for saying “no” at work.
Always saying “yes” to bosses, teammates, and others can make us feel like we’re doing our job, but can also decrease our effectiveness. It’s also unsustainable.
To be sustainably successful in your career means to get really good at saying “no” when the reasoning isn’t sound or there is no clear plan of attack. We can all get there, over time, with practice.
Are there situations where you wish you said “no”, but didn’t? I’d love to hear from you.
Until next time,
Your Caring Techie
The Software Engineer's guide to saying "no"
I just quitted on the 2nd of November because of this.
It's not that saying "no" was hard; it's more like the CEO forced us to take work like a "family" thing. If you don't pick up calls to handle an issue at night (after work hours), then "you're not a reliable friend."
In some chaotic workspaces, they'll label you the incompetent one; and I felt the only thing I could do was just quit.
Thank you for the followup on this topic, I was looking forward to this post!
A common case where I should have said "no" and didn't is when it comes to managing feature creep. I recently wrote about how a refactor can turn into a never-ending project (aka "death march"), and the difficulty of declining extra requests and changes definitely contributes to that.
Hope this article will help people be better prepared to say "no" when needed!