A Model for Saying No

An example of a time I used data to say no and averted waste

Photo by Andy T on Unsplash

Hello again. If you don’t remember, I coach leaders and teams on how to improve the way they deliver value to their customers in ways that work for their business. My promise has always been to give you real world examples, not textbook advice or platitudes from an armchair quarterback.

Saying “No” is quite difficult. I wrote about this and my struggle with busy before, so here is a general recap.

1. Without the ability to say No, our Yes loses its power.

2. We all have associations with being busy and, as a result, most people struggle to say No.

Or, how about a quote from Atomics Habit author James Clear?

When you say no, you are only saying no to one option. When you say yes, you are saying no to every other option. No is a decision. Yes is a responsibility. - James Clear, via X

As a practicing Enneagram 9 (Peacemaker) I am well acquainted with doing everything to keep the peace, including saying yes to things that would be better off getting the “hard pass.” I also know that, when your basic needs could be on the line, saying Yes is the path of least resistance.

But…morals, ethics, Colossians 3:23-24, etc.

There are multiple ways not knowing how to say No to things can cause you problems. For me, there are 3 issues when I say Yes too often:

1. I’m busy doing everything, I rarely accomplish anything, and even when I do, they are not great.

2. I am rarely focused on things that produce value.

3. I start feeling a sense of dread as a I skulk around, avoiding human gazes, as even making eye contact could lead to instant guilt and soul damnation.

After some time of putting my own coaching into play, I have a fun story about a time I said “No” and the lightweight model I used to build the data to back up my decision. Now, I didn’t just say no to just anybody; I said no to the Chief Financial Officer.

Saying No to the CFO

I took a coaching gig helping a small development team learn the ways of Kanban. My goal was to help them, and the Christian non-profit for which they worked, become more product minded and, for a stint, I acted as their Product Manager. There is definitely a culture of saying yes to everything in these types of set-ups so it made sense that this team had cultivated all the great reasons for why saying No was simply not part of their vocabulary. The quote I heard most often, complete with robotic and tired undertones, was

Saying No is bad customer service.

Incorrect. No, when handled correctly, IS customer service.

One day, a particularly interesting request came to the team. Not in the form of a challenge needing solving, but that insidious, “Can you build me this exact solution I think I need.” Before I had a chance to even understand the ask, the team of three software engineers was already brainstorming the best way to build the solution. That’s the problem with a “yes culture.” It becomes so commonplace you don’t even know how to pump the brakes before you start spending precious time, aka money, diving right in. Even something as simple as brainstorming sets off a chain reaction to all involved, especially stakeholders, that you have said or implied, “We will absolutely spend our preciously valuable time building this solution, sight unseen, with no real idea of what the value would be other than you, a valuable person, asked us to do it.”

This works in giant organizations with money to burn, but not in a non-profit where you live donation to donation. It was time to model saying No.

The Model

Here is the lightweight model I put together from various resources. (Since experiencing this, ChatGPT came out. I recently asked it to build a model, and it validated my own. I was elated. Thanks AI.)

I focused on three simple items: Burn Rate, Capacity, and Potential Value of solution

1. Burn Rate - Know how much it costs per week to do some work.

   1. Average yearly salary average, divided by 52, plus a 30% overhead modifier.

   2. Example: For a team of three software engineers with an average salary of $100,000 per year, the weekly burn rate might be $7,500.

   3. That’s roughly $7,500 per week to build any solution.

2. Capacity - Use your team’s Flow Health Metrics - How much work the team, on average, is capable of completing.

   1. WIP, Cycle Time, Throughput

   2. Example: For this team of three, the average cycle time for a request was 10 days.

   3. That meant, roughly, just building this solution could cost $15,000 in burn rate.

3. Potential Value of the outcome- Why would we do the work in the first place?

   1. Ask what value is produced by building a solution. Cost saves, avoidance, revenue, etc. “Value” is defined locally, within your org. It’s not universal.

   2. Example: Your solution helps end some subscriptions that costs $4,000 per year.

I scheduled some time with the requestor, a nice enough guy from the Finance team, and asked what the challenge was and what value solving it might bring. His team was looking to consolidate some of their expense and travel applications and wanted a custom in-house database solution for viewing the data. The value from the solution was an avoidance of about $4,000 per year in monthly subscription fees. I told him I would discuss with the team, do some homework on how much it would cost, and let him know whether we would do the work or not. I’m fairly certain all he heard was “Sure, we will be building this for you.”

I met with the software team and asked them to brainstorm how they might solve this if finance had not asked them to simply build an in-house database solution. I had an idea based on my own research, but kept it to myself. The team didn’t disappoint. Without hesitation they mentioned two things that stood out. First, they knew the companies involved allowed CSV export of all the data. Second, having built a similar solution for the finance team previously, they said, “The past few times we have built this same solution for them and a few other teams, they never use it. It just sits there.”

That was all I needed to hear. I had all the info I needed to schedule some time with the finance team and exercise our “Say No” muscles.

I laid out the details of my findings and informed our finance partners that, while it did not make economical sense to build their requested solution, we did recommend they use the export feature to archive the current data if they ended the subscriptions. I even shared the appropriate documentation from those external vendors on how to perform the exports.

Needless to say, my friend from finance was confused. His response was, “Are you saying you won’t build the solution we requested?” After I confirmed, a second meeting quickly appeared on my calendar, this time including his boss, the CFO. Most of us know how this typically turns out. The HiPPO rule, or Highest Paid Person’s Opinion, was being invoked, and that normally means you will be told to just “shut up and color,” or in this case, build what was requested. I thought we were about to be told Yes was the only correct answer. But that’s not what happened.

After laying out the same information with the CFO, to my surprise, she agreed with me and my team. She had never had a team give her details such as burn rate and flow metrics in order to decide if a particular solution was viable. She thanked us for the work on the solution we offered, and praised our model as responsible and efficient.

Landing the Plane

I wish I could tell you that the finance guy was thrilled, but, alas he was not pleased and told us he’d, “See if someone else could help him.” I only bring this up so you know that not everyone will love being told no. Even when you bring data. Depending on where you work, people will try to eviscerate your model. Instead of becoming discouraged, invite them to help you build and improve the model. I want to encourage you to stand strong and not throw the baby out with the bathwater. Sometimes stakeholders will do whatever it takes to get what they think they need, aka what they want. Stick to your guns, but be willing to adapt your model. Bottom line though, you MUST have a model for saying no. I forget where the quote comes from, so I will make it my own:

If you can’t say No, your Yes is meaningless.

I’ve worked with organizations where saying No was not allowed. Even encouraging people to learn to say No was frowned upon. In fact, I had one manager tell me, “Tristan, the reason we need to avoid this topic is that it will only serve to frustrate people when they realize they really cannot say No.” While that was a heartbreaking thing to hear, it opened my eyes to the fact that some places will refuse to empower you to exercise choice, and sometimes it’s based on years of people breaking trust. Sometimes it’s because your company is highly regulated and trust is not a luxury they can afford. Either way, the law of the Speed of Trust is still just that, a law. When trust is high, speed is high. When trust is low, speed is low. If you have high trust, do your homework and build a model for saying No. If you don’t have trust, do your homework and build a model for saying No, then earn some trust. If you can’t earn trust…dust off the ole resume and start looking for a new place…

Because even then, you are learning to say No.

Until next time,

Keep on Learning, Keep on Growing.