Why don't software engineering teams just say no?
Why don't software engineering teams just say no?
And how you can get better at it.
Tell me if you've heard one of these before...
“You're absolutely right. We should do that. We are going to add it to our backlog."
"We don't have a lot of time right now but that is something we can get to next quarter."
As a software engineering manager I've been on the giving and receiving end of these types of statements many times. Whenever you hear them, there is a subtle subtext.
They really mean No without actually saying it.
So why are we so squishy about how we say “no” and how can we get better at it?
Why Don’t Teams “Just Say No”?
We Keep Telling Our Engineers to Say “No”
A lot has been written about the effectiveness of saying no at the individual level. We have:
If "no" is so great at the individual level, then why are we dancing around it at the team level instead of just saying it?
From my experience, there are two main reasons. First, there are the customers…
Saying “No” is Hard #1 - Your Customers Don’t Trust You
When I talk about the customers of an engineering team, I don’t really mean the customers your product team has to deal with (although I highly recommend using your product team to say "no" to external customers. They are typically very good at it). I’m really talking about internal customers (internal teams in your company who want something).
Dealing with internal customers is hard. A software development team is typically close knit. Hopefully, people trust each other. Saying “no” when you have a trusted relationship is easy. You can empathize with the other person and you have a bank of positive interactions to rely on their judgement.
This is not always the case with other internal teams or different functions in a company (see this infamous Microsoft org chart joke). These team to team interactions have different incentives.
Creating a trusted relationship with these teams is the easiest way to make “No” easier, but that isn’t always possible. Other teams may have different goals (think Sales goals vs. Engineering goals) or your team just may not have a lot of previous history to garner trust.
Even if you are able to achieve alignment on goals, there is a second reason your team may not want to say “no” and that’s because…
Saying “No” is Hard #2 - Estimates Usually Wrong
Stop me if you’ve heard this one before…
Estimating software delivery timelines is hard, even when we’re only talking about short sprints. It doesn’t mean you shouldn’t do it but it does mean that when you try to predict what you will deliver you will probably be wrong (66% of the time, according to McKinsey).
When estimates are hard it means you don’t exactly know how much you can deliver over longer time frames. And that means you don’t trust some of the longer lived deliverables on your backlog.
So not only do your customers not trust you… you might not trust yourself.
The “No” Toolkit
Okay, so we know saying “No” is hard and we know why. Now we need to figure out what tools we can use to help our team say “No” more effectively.
Tool #1 - Your Backlog
One of the most effective tools for “No” is your backlog, but only if you’re willing to use it the right way.
How Big Is Your Backlog?
I’m going to assume you’ve already got a backlog. If not, go read that article and come back here when you’ve got one.
I’m going to give you my highly technical, metric driven, proven mechanism for pruning your backlog. Ask yourself:
How much of this stuff can we reasonably get done in 6 months?
If there is anything on your backlog that is longer term than that… cut it.
But that’s scary! What if we lose something important?
Here is my other highly technical, metric driven, proven rule of backlog management:
If it’s important, it will come back.
I can guarantee you an important feature, piece of tech debt, or otherwise screamingly important item will bubble to the top of your backlog even if you close every single issue associated with it. Be ruthless. Don’t be afraid. It’s liberating. For each item on your backlog ask yourself “does this bring me joy?”
Why Did I Just Chainsaw My Backlog?
A giant backlog is the enemy of saying no. Let me take a minute to pick on some open source projects:
The GitHub Runner has over 300 issues (I own this one so do as I say, not as I do)
If I file a new issue in any one of these repositories do I have any confidence as a customer that my issue will be looked at? Do I have confidence it will get addressed?
Adding an issue to the backlog with a “next quarter” type of “No” might feel great at first (we might do this!) but the longer it stagnates the worse your customers are going to feel. If you really want to build a trusted relationship with them, you have to be ready to be honest about your priorities.
Speaking of which…
Tool #2 - Advertising Your Priorities
One thing I like about the backlogs I called out above is that they are public. There isn’t much of a better way to advertise what is on your backlog than publishing it on the internet. Obviously, not every company or team is ready to do that but there is no reason you can’t share your backlog internally.
Summarize Your Priorities
There is one big caveat here… giving someone a link to your backlog is sort of like giving me an instruction manual for a jumbo jet. At some level I know it can be used to fly a plane, but I have no idea what anything does because I am not a pilot.
Rather than advertising your backlog, you really need a very simple list of priorities for the next 6 months.
A lot of companies now use OKRs for this but a lot of times they don’t go all the way down to the individual engineering team level or they are poorly advertised.
Whether you use OKRs or some other mechanism, the key here is a way to summarize your team’s priorities to the rest of the company (not just other software teams).
Say “No” But Feel Bad
Congratulations! If you made it this far you have:
A backlog that only has 6 months of work on it.
A clear list of priorities for your team that even non-technical folks can understand.
You are ready to say “No”!
There’s only one more thing to understand.
Every time you say “no” you are going to feel bad.
A little part of you is going to die at your inability to make time for someone’s good idea. Because make no mistake, a lot of the things you are going to say no to are going to be great ideas.
But there is good news. If you’re feeling that sadness then you’re doing it right. Entropy is the natural state of the best software and teams. They are constantly learning and evolving. More people are using their stuff. And that means more debt and more product features.
The day you start to run out of a never ending backlog is the day you might want to start wondering about the future of your team or your product.