Saying No
I’ve developed a bit of a reputation inside and outside work as being pretty good with “saying no” and setting boundaries. In this post, I will help you do so, too.
Why say “no”?
I’ve been consuming a lot of Brené Brown’s podcasts and read one of her books recently, and they’ve got me thinking about what’s at the root of being able to say “no” regularly and well.
Brown uses the BRAVING acronym to refer to the elements of Trust. Out of these, the ones that jump out to me for saying no are boundaries, reliability and integrity. To meaningfully trust others on these axes, you cannot be someone who says yes to every request. In doing so, you maintain no boundaries, professionally or personally, and will not be a reliable coworker.
To the software engineers reading this, I’m sure we’ve all worked with some APIs that have been great and some that have been terrible. An API with inconsistent and unpredictable behaviour with the same inputs is terrible. A poorly documented API is terrible. An API that attempts to accommodate your request and consistently times out rather than failing immediately is terrible.
Human relationships are like APIs: consistent and predictable responses make them more pleasant. A bad API for your coworkers is when you’re someone who gives radically different estimates for the same work based on whether you want to impress the person or not. A bad API for your coworkers is when you state you’re on holiday or sick but still appear in conversations and meetings anyway. A bad API for your coworkers is when you tell them a 19:00 meeting is fine, but you’re hangry and irritable because you’ve missed dinner and your children’s bedtime.
A previous performance review of mine from a great manager started with the sentence “Mike is very strict with his boundaries”. “Oh no”, I thought to myself, “I’m going to get criticised for always prioritising being there for my children’s dinner and bedtimes four nights of the week”. Instead, he went on to say that this made me easier to work with, set an excellent example for other members of the team to not overwork and set expectations for new parents on the team. Ironically, in this case, being a little more selfish with my time and strict with my boundaries produced an outcome that benefitted the entire team.
Having these boundaries clear and upfront is more complex but crucial for unexpected tasks. If when asked for an estimate, you can tell there’s a bunch of complexity that the requester did not consider and know that your realistic one will disappoint them: you should give them the realistic estimate. If you already feel overwhelmed or have too much to do when asked to do something new: you should say “no” regardless.
I call this “front-loading disappointment”. It’s better to have a conversation about your full workload or longer estimate now when people can prepare for it. Making them happy now and then disappointing them in a few months when you don’t deliver what they planned for you is worse. I’ve also found it less disruptive in my workplaces to ship a project earlier than planned rather than later than planned. If you’re the type of person who hates disappointing others: you’ll need to take my word for it that there’s reduced disappointment overall when it’s pushed earlier. Similarly, you’re not responsible for others disappointment with the facts they didn’t know before you (nicely) revealed them.
When to say “no”
Ok, we’ve touched upon why you should say “no”, so let’s discuss when it’s appropriate to do so.
What’s your current workload right now? How are your stress levels outside work? Do you have many commitments you need to meet soon to coworkers, family or friends? What are your goals for the next 3-12 months and what’s the best use of your time to achieve them? What tasks do you have on your plate that are “essential” rather than “nice to have”? Regularly asking yourself these questions can help prime you to remind you of them when receiving a request.
When a new request comes in, and you’ve asked yourself the questions above, you’ll probably have a good sense of whether you can meet the needs and expectations of the requester or not. If you think you cannot right now: say “no”. Every “yes” is implicitly a “no” to something else you might not know yet.
Don’t worry about if you’ve been saying “no” a lot recently; this is not necessarily a problem. Of course, if you’re saying no to every request from coworkers, friends and family, this could be a symptom of a broader problem. At work, though, it’s expected that there will be more demands on your time than your available time. If you’re saying “no” a lot, but you’re still delivering great work, and your coworkers and manager are happy with you: you’re doing enough.
How to say “no”
There’s still a little bit of art involved in saying “no”. It may be that your “no” actually means “no because …, “no unless you …” or “no if this …”. These “no”s may be conditional on you as an individual, the timing of the request, the scope of the request or many other reasons. Try to share your reasoning with the person who has requested this of you; it may be that something you understood as critical to the task is actually optional and can be removed given the extra context of a “no because …” or “no unless …” provides.
At least in software engineering, one word to avoid is “impossible”. There are very few things that are genuinely “impossible” (e.g. the halting problem) and avoid it unless it’s one of those. If you’re saying you cannot do a task now, avoiding “impossible” ensures that you don’t try to generalise that to state that no one can do it ever.
If you’re feeling like you’re saying “no” a lot and this is dragging you down, you can ask others to help you. The engineering/project/product manager or a staff-plus engineer on your project may be able to say no on your behalf. It may also be if you repeatedly state “no” to the same person that they are asking the wrong layer of the organisation, i.e. an individual contributor rather than their engineering manager or product manager.
Finally, a “no” is generally a disagreement in either values or information. Figuring out which one applies now may help you figure out how best to communicate or get past the “no”. For example, my current GitHub organisation (Communities) has tight values alignment. When we need to communicate a “no” in Communities, it’s a matter of sharing missing information rather than resolving a values difference. In open source, my “no”s are often due to a misunderstanding about what my obligations are (not) to those people who use my projects.
Thanks to @nerdneha for talking through this post with me and to my long-suffering coworkers and contributors to the open-source projects I maintain for all my “no”s over the years. Thanks to @kenyonj and @katestud for providing excellent feedback on this post.
