The Software Engineer's Guide to Saying No
The Software Engineer’s guide to saying “no” #
Excerpt #
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:
[
]( https://www.thecaringtechie.com/p/strategies-for-saying-no)
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
Additional reads #
[
]( https://www.thecaringtechie.com/p/why-learning-to-disagree-can-be-a)
[
]( https://www.thecaringtechie.com/p/how-to-disagree-at-work-without-rubbing)