How To Say No - Ask Why Instead
There was an interesting topic that came up in last Fridays' HangOps session that I wanted to expand on in a blog post. We were talking about Gene Kim’s new book The Phoenix Project, and I mentioned how I believe an interesting point in the book was how they stopped work in order to get a handle on their work in progress (WIP). I had some unique experience in doing something similar while I was running the Ops team at Sonian. One of the most important things I learned while there, especially when the work was piling up and systems were crashing, was simply this:
Don’t Say No - Ask Why Instead
When you have work coming in - inventory to release to the factory floor - don’t say no and stop the release of work, and don’t blindly say yes and push more work to your team. By agreeing to the request, you have done two things.
- You have released work to your team and negatively affected your work in progress (WIP)
- You have signaled to your management team (or where the request came from) that you have excess throughput available (or else why would you have said yes?)
In most organizations the Ops team is the bottleneck (it definitely was when I took over the team while at Sonian), and the Theory of Constraints (ToC) tells us that releasing work to a bottleneck resource is the LAST thing we should be doing in that situation.
Here is one scenario - an executive comes to you and gives an abstract request for work. You can respond one of three ways:
- Yup - we’ll do it right away
- No - We don’t have time
- Why do you need X request done? Can you give me more information?
You blindly said yes, now what happens
You look at the request, and it appears that it should take about a week to finish. It’s highly likely that a few parts of this request are quite easy to complete, you knock them out in days, but a couple more are taking longer than expected. Turns out two of the tasks require bottleneck resources, and you can’t pull the resource you need from other tasks. Weeks and months go by before you are able to complete the request, but at what cost? You just released more work to your already constrained resources. And you probably didn’t make a great impression on the executive who thought it would only take a week to complete.
The ToC also says that an hour lost on a bottleneck resource is an hour lost across the whole system. So not only did you stress your bottleneck, you also slowed down everything that was dependent on Operations.
Let’s move on, what happens if you simply say no to this request
Well, this one is much easier to break down, if you were to simply say no (which sometimes is a necessity) you can come across as combative, argumentative, and identified as “not a team player”. Sad as it is, this is often why people can’t say no to requests. Sometimes you don’t want to let people down. You want to be the person that “gets it all done”. But the reality of the situation is that we can’t do everything. There is not enough time in the day and we don’t have unlimited resources even if there was. Our first job as managers is to prioritize and release work to the team. The whole system can, and often does, fall apart when we fail to do our jobs.
So what can you do instead?
Ask why, break down the request, understand the impact
Why ask why? We need to break down the request, find out what impacts our bottlenecks and which ones do not. Let’s go back to our request, 3 of the 5 items are non-bottleneck tasks, which means we can release that work and not stress our bottleneck, these are the items are get done quickly. That leaves 2 items left. You either need to find a way to release this work without impacting your bottleneck, or you just need to say no to that part of the request.
Saying “no” is not a bad thing, and you need to say it more often
Saying no helps you manage the expectations with your executive team. Remember last month when you all agreed on the next set of projects, your team is focused on 3 main company goals. Half way through the month the company wants to add a 4th task to your list. When this would happened to me, I would handle it simply:
“Yes”
then quickly followed by
“Which of those other 3 tasks do you want us to push to another month?”
As a manager, you should know how much work in progress your team can handle. And you need to make sure to communicate that to the necessary parties at your company.
I always believe that more tech people should take business classes. Not only is it great to learn new things, but part of the game is learning how to speak the language. Learning what is important to the business, and finding out ways that you can help enable the business.
I had a manager who told me this:
“I’m going to just continually give you work, it’s up to you to say no”.
It was my responsibility to push back when necessary and let him know when I was being overloaded. I was the bottleneck resource, and when I was reaching my limits of throughput he would stop releasing work to me. He was able to avoid slowing down the entire system my limiting the work that was getting released to his team. I’m not saying that this is the best or the correct way to do it, but any system of managing your WIP and how you release work is better than no system at all.
If you haven’t yet - I highly recommend you read the following books. “The Phoenix Project” tells a fantastic story about Agile & DevOps process while touching on the Theory of Constraints in a technology focus. “The Goal” is a story about a man and his factory, a story about how to identify and exploit your bottleneck for fun and profit.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win