Don’t Say No
Get Them to Understand Your Team Delivery Capacity
Do you, or the teams you work with, feel pressure from stakeholders to say “yes” to everything they ask for? If so, you’re not alone.
The Cycle of Distrust
There’s a problem with saying “yes” to everything. It tends to create a reinforcing loop that builds distrust in the organization.
I often see advice from coaches that teams should learn to say “no” to stakeholders. The teams know they can’t deliver everything that is requested. They’re afraid to “push back” on stakeholders.
I think maybe that’s not quite the point.
Why Don’t Stakeholders Trust You?
What does it take for stakeholders to get off your back? They have to trust you.
What does it take for stakeholders to trust you? You have to deliver what you say you will deliver.
What does it take to deliver when stakeholders are asking too much of you? Collaboration. Work with stakeholders so that you properly understand what they need and so that they properly understand your delivery capacity.
The Slippery Slope of “Yes”
In many cases, stakeholders of technical teams ask for everything they can imagine they might need. They often express those requests in an incomplete, contradictory, or even nonsensical way.
That’s because they don’t understand your work, but they think they have to describe it to you in detail.
They think they have to describe it to you in detail because they have experienced poor results from you over time.
You aren’t aware you’ve been delivering poor results because from your point of view you’ve been working very hard, doing difficult things under pressure, going the extra mile, and so forth. Why aren’t you being rewarded for all this effort?
Stakeholders think you’ve been delivering poor results because you keep telling them you can deliver everything they ask for, and then you don’t do it.
Breaking the Cycle of Distrust
You have to break that cycle. There are two aspects to this.
First, you have to gain a really clear understanding of what stakeholders need. They don’t know how to tell you. You have to learn enough about the domain to help them clarify their needs.
If you can get them to describe the problems they’re trying to solve instead of the solutions they think they need, you’ll probably find they don’t need everything they ask for. That’s one way of reducing the volume of requests.
Second, you have to understand and be able to communicate your actual delivery capacity. That requires measuring your delivery performance. I’ve found a very good metric to use for this purpose is Cycle Time. That’s the mean time it takes the team to complete one “item” (whatever “item” means in your context). You collect the raw data by keeping track of the date/time when you begin each item, and the date/time when you complete it.
You’ll point out that items vary in size, complexity, duration. Yes. That doesn’t matter. The important thing is the mean cycle time. Let’s say that on average stakeholders request a couple of large items, a couple of medium-sized ones, and five small ones in any given cadence, iteration, release, or whatever unit of time your organization uses for such matters. If your team takes on average 4 days to complete a large item, 2 days for a medium-sized one, and half a day for a small one, then this is how how long it takes your team on average to complete the amount of work stakeholders typically request on average for a single development cadence:
(2 x 4) + (2 x 2) + (5 x 0.5) = 6 + 4 + 2.5 = 12.5 days
Let’s say you’re using a two-week cadence, as that’s pretty typical and is what most agile coaches recommend as a starting point. In 10 working days, your team can complete on average about 10 items. In a typical cadence, stakeholders ask you to complete 12.5 things, and you agree.
Then you deliver 10 things. Time after time.
From the stakeholders’ point of view, you never deliver what you say you will deliver. You are reliably unreliable. Why should they trust you?
By the way, why do I keep writing on average like that? It’s because almost invariably when I talk about this subject people get hung up on individual measurements. “But we had this one item that took 44 days!” That’s not important. It’s the aggregate values that matter.
How to Build Stakeholder Trust
For stakeholders to trust you, they have to understand your delivery capacity is on average about 10 per cadence. So the key to building trust is for you to teach your stakeholders how much your team is actually capable of delivering, and then to collaborate with your stakeholders to identify the highest-value set of items that should be completed next.
Depending on your stakeholders’ backgrounds and roles in the organization, they will react differently to this. Your strategy may have to differ accordingly.
If your team mainly does the bidding of a mid-level IT manager, they might not relate to this approach immediately. IT managers operate with a “cost center” mentality. They are handed a list of “requirements” that they have to deliver within a given budget and timeline. In effect, they’re in the same boat as you are. You’ll have to teach them this idea and help them carry it “up” in the organization.
If your team is fortunate enough to work directly with business stakeholders, you might be surprised at how naturally they relate to this approach. Business stakeholders operate with a “profit center” mentality. All day, every day, they have to pivot to deal with changing market conditions, making high-stakes decisions quickly based on limited information. Their plans never play out as originally envisioned. Everything changes constantly. That’s the water they swim in. If they have the facts, they can deal with them. So give them the facts. Show them the numbers. They’ll understand.
Conclusion
It isn’t about “pushing back” or “saying no,” as your conventional agile coach might have told you. It’s about strengthening collaboration across the organization so that everyone understands both the needs and the capacity to deliver on those needs. That way, everyone can work together to deliver the maximum value possible.