How to say "no" for the sake of your customers

The key to saying "no" in an open organization? Be prepared to explain why.
562 readers like this.
Sky with clouds and grass

Flickr user: theaucitron (CC BY-SA 2.0)

When you're working in an organization where statements like "Good ideas can come from anyone" and "Experiment! We learn more from our mistakes than our successes!" are commonplace, does saying "no" create a contradiction that impedes adaptability and inclusivity?

The answer depends on how you say "no" and the things you say "no" to.

I didn't always know this. In fact, I was once a person who said "yes" to most of the opportunities I encountered. Saying "yes" was fun. Trying new things brought me joy, and I became the organization's go-to person for creative pilot projects. Eventually, though, the number of hours I needed to work to sustain all of the commitments took a toll on my health.

I just wasn't sure how to begin moderating my "yes" commitments with "no" statements. How could I get better at saying "no," while continuing to cultivate an open culture on my team and in my organization?

The answer: Practice, making lots mistakes, and communication.

A few clumsy attempts

My initial attempts to moderate my "yes's" with "no's" were clumsy. For example, one of my teams was working on project with a huge backlog of bugs, and I went through the list and closed many of them. While many people were thrilled that I set criteria for closing bugs and seemed to have no hesitation about saying, "No, I'm not going to work on this item," others were outraged. I received some horrified messages. So I had to explain: Bugs can be reopened and reprioritized (in fact, we reopened and fixed several bugs).

In hindsight, I realize now I should have been more proactive about communicating the problem, the severity of the issue, and how we were going to solve it. I could have also explained how we'd make exemptions available and how we's work through those special cases. But the lesson remains clear: If you're going to say "no" in an open organization, then be ready to explain why you're saying "no."

I continue to perfect my ability to say "no" without creating too much confusion. Now I often ask more questions that help me understand what people have identified as a primary goals. When I assume I understand the thinking behind an initial request, I'm quite often wrong. So I spend time understanding what motivates people submitting requests, and I explain the tradeoffs we face if we say "yes."

Additionally, I often ask for contributions from the party making the request. These can take a variety of forms—there's no "one-size-fits-all" contribution. But when people making requests are themselves invited to contribute and they say no, it says a lot about the value they place on the request. Why am I (or my team) expected to say "yes" and work solo, while someone else feels no responsibility for sharing ownership? I let that question sit in the air (and I have learned to love the silence that follows!).

Saying "yes"

When I think about saying "yes," I think about the people I'm impacting:

  • Do customers lose because this single "yes" means "no" to several other things that are of higher customer value? If customers are going to lose, then what I need to do becomes abundantly clear.
  • What about the team I'm leading? Does the team have the resources needed—or can I get the team the resources it may need? How am I going to motivate people to share saying "yes" to this commitment?

Stepping back and considering the deliberate work involved in deciding to say "yes" or "no" takes significant time and energy. A co-worker once labeled this type of work the "meta" work that's essential to a well-functioning organization. He's right. Think you can save time by avoiding this effort? You'll find yourself working on items that don't align with your team's core values and mission.

You need to be as committed to good decision making—saying "no" so you can get to the best "yes" for your customers—as you are to doing the work. Otherwise, you'll ask people to spend time on non-essential work. Have the courage to recognize the inevitable missteps, and you'll have the next challenge waiting for you.

picture of Angela Robertson
Love leading teams to develop products customers love and can use with ease.;

5 Comments

Some people who submit bugs or make complaints or suggestions don't seem to understand how individual, esoteric, and personal their submissions are. Often they are also the first to say, "I don't have the skills to work on this." It can be challenging to explain the limitation of resources to deal with every request.

When people rebuff closing bugs, it's a great time to talk about customer impact and how to prioritize work. I hadn't thought about the skills gap you identified. Great point - when people act strongly, good to consider the possible subtext.

In reply to by Greg P

Thanks for writing this, Angie! Saying no is critical for success, and also so hard. I really like your method of asking more questions to clarify the importance of the request. One of my biggest takeaways here is that when you say "yes" to one thing, you are likely implicitly saying "no" to something else that you might not have fully considered.

The most trying times I had as a system admin/engineer in academia was telling faculty "no". I am normally very obliging but there are just some things that can't or shouldn't be done. Some people just don't take no well. A few faculty fail to understand they are not the center of the universe.

Are you familiar with Gretchen Rubin's 'four tendencies framework?' I find that when we know our predominant tendency (for example, you identify as being more obliging), we can work with our natural inclinations to say no when necessary. Also - when I say no, I do not intend for people to take it personally. I want my no statements to be constructive. If people take the no personally, that's their decision. Hope this helps and thank you for the conversation.

In reply to by Gary Scarborough

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.