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