3 Reasons Why You Must Say No As A Developer
DevEvolution EP 7 - It can be a game-changing skill
"I'm sure that if you work hard, you would be able to pull off the changes before the deadline."
I have heard that line many times. Sometimes directed at me and other times at my unsuspecting colleagues.
In my opinion, this is the most insidious line that managers use to get their way.
I use a word as strong as "insidious" because it's a sort of low blow hitting you right where it hurts the most.
With this statement, the manager manipulates you into thinking that they have great expectations from you. And if you aren't able to meet them, you'd likely disappoint the manager in a big way.
As human beings, we are hard-wired to seek approval and spend most of our lives trying to please others. It is part of our genetic makeup, meant for surviving and thriving as a social animal.
Not doing so triggers a Fear of disappointing others (FODO) within us. Ultimately, we end up saying YES to things we don't want to do.
In my view, this is a big problem in a professional setting. It not only makes us vulnerable to unrealistic goals as an individual, but it can also create severe issues with regard to the business goals of the organization.
Welcome to another edition of DevEvolution where I discuss actionable tips to help you grow as a software developer.
In this post, I explain 3 reasons why you must learn to say NO as a developer.
1 - Setting False Expectations
As a developer, if you commit to an impossible target, you are setting false expectations.
Saying yes may feel addictive at the moment as the manager pats you on the back and offers a word of praise. However, doing so just to avoid disappointment is equivalent to lying.
In truth, saying yes without being sure is a destructive habit.
But no one wants to set false expectations intentionally.
Typically, when a developer conveys a lack of confidence in meeting a particular deadline, managers don't take it seriously. They try and negotiate.
Since developers aren't usually very good at negotiating their positions and most managers have excellent persuasion skills, developers end up giving in to the pressure. To avoid confrontation & FODO (Fear of Disappoint Others), they agree to try their best.
But trying your best is not a good situation.
For managers, "trying" means "yes, it will be completed". Moreover, by promising to try your best, you have made it explicit that you do not normally try hard enough and that this time, you will give your best.
It is almost like saying that you usually slack off and are agreeing to put in your maximum effort since the situation demands it.
2 - Saying No Is Not Unprofessional
The general thinking is that saying no is unprofessional. And that's one of the big reasons why developers hesitate in doing so.
However, saying no becomes professional if we do it with a set of alternatives. This means that before telling your manager that you can't meet a deadline, you should analyze the problem and create an opportunity to brainstorm different ideas.
Managers are usually looking to solve a business problem. Listening to a flat no does not give them anything. The manager has to still figure out how to solve the problem and that usually means forcing the developer into a corner.
As a developer, your job is to stay upfront if you don't know how to solve a problem. Make this fact clear as quickly as possible.
Once the hard truth is out of the way, offer that you'll investigate the problem further and give your best shot at finding a solution without making any blind promises.
Also, keep providing regular updates on your progress to the manager and the team so that every piece of new information can be analyzed and acted upon. This will create an environment of mutual trust and keep things professional.
3 - Saying No Opens Other Options
A few years ago, I worked on the GDPR project to build a system that can compile all the data of a user held within the system and generate a report that can be handed over to the user for compliance purposes.
Since it was a regulatory project, there were monetary fines and the bank's reputation was on the line. The deadlines were extremely challenging and the system was not in a position to be ready by that time.
The initial push from the business was to force the developers into working extra hours and over the weekends. Apparently, there was too much at stake.
Luckily, the entire team realized that even if we worked our socks off, it won't be possible to build the entire system as imagined. Instead of getting forced into a corner by the business, we refused to work extra hours and said no to the deadline.
Since every task, its estimate, and the current status was visible to the business on the Kanban board, it was quite obvious that we weren't lying.
Instead of creating panic, the information liberated everyone involved in the project. Rather than bickering about what could not be done, the conversation shifted to what could be done. No matter how impossible it seems, there are always multiple ways of solving the problem.
Turns out that in this case, the issue was with a few systems from which the automatic data collection process would not be ready before the deadline.
However, the regulation did not mandate automatic collection of data. It just said that users should be able to get the desired information (digitally or physically).
Ultimately, we ended up creating a solution that was a mix of automated data collection for the majority of the applications and then enabling the bank tellers to collect the remaining information manually.
This approach helped us meet the deadline for solving the actual business problem without cutting corners and compromising the quality.
Over time, everything was shifted to the automated collection process without the bank suffering from any fines.
All of these became possible only because the developers decided to say no to unrealistic deadlines.
Saying no is not illegal.
We feel bad about it because we've been brought up with the ideology that the default response should be a "Yes", or else we will end up disappointing someone.
However, saying no for the right reasons is actually far more useful and productive as it lets the people involved look for more reliable solutions.
In fact, who said saying no is a permanent no?
It's always easier to go from No to Yes rather than the other way around.
"Saying no is so powerful because it preserves the opportunity to say yes" - Brent Beshore, Investor
🕹️ Over to you
Have you agreed to insane deadlines for delivering some change?
If yes, what was the experience like?
Write your thoughts about the whole thing in the comments section.
If you are finding this newsletter valuable, consider doing any or both of these:
👉 Support the Newsletter - if you haven’t done so already, consider becoming a paid subscriber.
👉 Share it - Progressive Coder grows thanks to word of mouth. Share the article with your friends or colleagues to whom it might be useful!
Wishing you a great weekend ahead! ☀️
See you later.