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:

Strategies and examples on how to say “no” effectively and guilt-free

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.

Image by storyset on Freepik

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

Caleb Mellas

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

---

Additional reads

Why learning to disagree can be a competitive advantage

How to disagree at work without rubbing people the wrong way

---