The Five-Point Framework for Saying No
Learn how to identify the signals that it's time to say no
The fun part of working as engineers is that we get to solve challenges. We are expected to deliver high-quality solutions on time, which puts us under a lot of pressure. As a result, I find that many engineers (primarily juniors) become silent when they need to say no.
But how do you know when to say no? What signals that it’s time to stop?
Here is an oversimplified framework that is easy to remember and use for requests, feedback, bugs, and tasks.
The five-point framework
Product — What are the pain points or opportunities we are addressing? Do I know who will benefit from these changes and how?
Impact — Will the efforts make a difference to the company? Will this be the most valuable thing we can do right now?
Coding — Is it more challenging than it seems? How many “workaround” will I have to make?
Quality — Will the final results compromise any existing functionality? Does the final result meet our standards?
Results — Given the requirements, will the project be completed on time?
The list can be expanded based on your needs, but I strongly urge keeping it short and straightforward.
How to use it
Ask yourself these questions, and if you cannot answer one of them or do not feel confident about your answer, then say no until it is resolved.
You can also say stop in the middle of a task.