We’ve all heard those horror stories: a product manager dropping you a Slack message late on a Friday, saying that they desperately need a new drop-down menu added to the app for a client presentation. Or maybe your CEO has the brilliant idea that everything needs to “utilize blockchain” but can’t explain why. Maybe the newest junior developer doesn’t get that they need to read the documentation carefully and that they can’t just dive in and start coding without it.
In a professional environment, saying no can be uncomfortable, and it can have consequences if done poorly. You have bosses to appease, and that can make you feel like you could lose your job for refusing a task. Or maybe you subconsciously seek approval in your work. Maybe you just want to prove something to yourself.
Sometimes you’re just too busy to think and have hard discussions. You might have too many Jira tickets on your backlog and feel there’s just no time to discuss anything else. You then counter-intuitively say yes to something without fully scoping out the consequences.
And yet sometimes, saying no is good both for you and your organization.
By informing your stakeholders and educating them, over time they can learn more about what’s possible and what’s considered best practice. Moreover, practicing saying no could improve your mental health, and in turn, being happier will make you even more productive.
In this post we’ll take a look at how you can nip these little injustices in the bud before they become bigger problems. Learning to say no is an integral part of any successful career, and software development is no different.
A Codified Process for Saying No
Though you should of course also take into consideration the circumstances of your own workflow, the process below will help you get started.
If you aren’t accustomed to setting boundaries, then this might be a bit awkward. Even if you perform the first few push-backs poorly, you will learn how to do this better in the future. Before long, your confidence will build, and you’ll start to do this subconsciously.
Understand Your Surroundings To Get the Upper Hand
We programmers have the tendency to be hyper-focused on the code base. This can sometimes blind us to the bigger picture of what’s happening around us. Sometimes, it’s easy to think that management are idiots.
But a more productive way to think is that everyone has different job responsibilities and skills. Knowing that people think differently is a great step toward being able to say no and finding out why these issues come up in the first place. It’s good to ask a lot of questions about where the request came from because you might find something useful.
Here’s an example: One of our clients’ marketing team came to us asking for contact lists. The request was unreasonable because our job was to build apps that interfaced with their database, not handle SQL queries. Why couldn’t they get it themselves? After some investigation, it turns out that another vendor had completely botched a migration of a mission critical platform for them. This had left the company unable to reach their customers. D’oh!
The challenge here is that saying yes means you’ve created an unsustainable path of least resistance. The client would have pestered us endlessly for data, which is outside of our remit. But on the flip-side, saying no could have hurt our client relationship. Finding out the details of how that vendor dropped the ball was our key to saying no. The way we said no was to properly consult with them on a more correct course of action while helping in the short-term.
Be Assertive, Factual, and Respectful
You don’t need to apologize for saying no. You’ve got legitimate reasons for doing this, and you probably have years of development experience to call upon. When saying no, it’s important to be assertive and respectfully explain why the request isn’t reasonable. Try to explain this in the least technical way possible.
Good example: “I won’t be able to complete this feature implementation in that time-frame. I need to ask some additional questions about the spec. There will also be quite a few additional steps to take in that time. Can we have more time to do this?”
Be prepared for the next immediate question you are likely to hear at this point. You’ll probably be asked what you consider a reasonable time-frame. Admittedly, it’s really tough to estimate how long something is going to take until you’re halfway through. So be mindful of this, and don’t be afraid to give a range estimate, maybe a best case and a worst case scenario.
Bad example: “Let me explain it in a way that even you can understand …” Be careful of how your perceptions of others can affect your language and how you speak with them. Yes, I have heard somebody say this to a product manager before.
This developer had complained publicly in the past that they thought the PM was “a moron.” So eventually it slipped out, and it definitely hurt the relationship, and the programmer was left with zero chance of successfully saying no. It’s best to just not think badly about people at all. Remember what we said about people having different strengths?
Offer Alternatives
Sometimes the request is unreasonable due to time constraints. Ask, does this need to happen right this instant? Can you deprioritize something else? This helps ensure that people around you understand the consequences of being moved and can help prevent this from happening in the future.
There can also be occasions where the request just isn’t technically feasible. If you don’t agree with a change, or if this feature request is impossible, can you offer something that is more technically feasible or better thought out?
Practice Regularly
Practice not saying yes on a regular basis. Always buy yourself the time to get more information about the request. Instead, simply agree to assess every request and nothing more. Doing this should win you the respect of your colleagues, plus you will be seen as more consultative.
After all, who doesn’t want to be the oracle of their organization, consulted on every matter that concerns you? Maybe you don’t care about that but that sounds much better than endlessly being ordered around!
It’s Not About Winning
Saying no will work in your favor some times, but not all of the time. Remember, it’s not about winning. You won’t always be able to negotiate and get a positive outcome every time. The important thing is that you can set a precedent for what others expect when they request something from you.
Ultimately, learning to say no is teaching others to treat you with the respect you deserve as an integral part of the organization instead of someone who can always be bullied into accepting impossible tasks.
Learning To Say No Is a Change in Mindset
In a nutshell, this is a change in mindset and process. I encourage you to think on a higher level about where these issues originate in your organization. Practicing a process of never agreeing immediately but agreeing to assess the request can make the experience more consultative. It will buy you the respect you deserve in the workplace or from your clients.
Hopefully, as a side effect you’ll no longer be feeling like you are losing control at work. And with enough practice at setting boundaries for your time and energy, you will become happier and more productive in your career.
