Please say “NO”

For a while now, I’ve had the feeling that the teams reporting to me are trying to do too much. I’ve been taking an analytical approach, building up a list of things the teams are doing and reflecting on our planning process to get some insight into how we reached our current workload — and to some extent, that’s been working — but I’ve realised that by doing so, I missed a much simpler approach.

First, though, some background. As far as I’m concerned, one of the goals of any planning process is to even out the workload to make it relatively consistent and sustainable over time. In principle, we can do this in a single planning session, where the various customers are represented and we reach appropriate compromises between those customers and the capacity of the team. All the methodologies I’m familiar with assume that this can happen, and it’s certainly a reasonable starting point. However, it’s also inconsistent with the experience of any team I can remember working on in the last 10 years.

Instead, all my teams have experienced multiple sources of demand that weren’t reconciled before they hit the team. To be fair, often it was one large source of demand and multiple small ones, which is close to the normal planning model, but there were always small things injected at both the team and individual levels — a piece of work that needed to be urgently accomplished for a third party, or something outside of software development, like performance reviews or guild meetings. None of this was inherently bad, but it wasn’t part of the planning process either.

Every team, and every individual, needs a way to deal with extra demands on their time.

A common model of dealing with extra time demands (hopefully becoming less common over time) is “best efforts”. When someone asks the team or an individual to do something extra, they say “I’ll do my best”. In my opinion, this is dysfunctional for a number of reasons — first, it’s likely to put undue pressure on the individual, who will probably be going above and beyond to meet the new demands (not everyone reacts this way, but many do). Second, it’s probably moved a business prioritisation decision into the technical team: although I might sincerely do my best, the linear flow of time will force me to do something first (higher priority), and my choice might not be the same choice the overall business would make if they had the chance.

Instead, I’ve got a simpler model — and if you work for me, this is the model I expect you to follow.

When you get a request that takes you, or your team, over the amount of work you’re comfortable with, say “No, I don’t have capacity”. Say it clearly, without equivocation. Then see how the world reacts. If you’d like a possibly less confrontational approach that’s slightly more complex, try “I’d love to. What would you like me to stop doing in order to fit that in?”.

The world may react by sending the work somewhere else. It might also react by starting a sensible prioritisation conversation, involving more people. It might lead to a different conversation, where you discover that you had the wrong idea about what was required for some of the things you were doing, and you actually do have capacity. If it doesn’t lead to any of this, though — if the response is along the lines of “I don’t care if you have capacity or not” — then you’ve learned something interesting about your workplace that you can act on at another time.

Many people are reluctant to take this approach, mostly because they think it will lead to negative impressions (like “not a team player”, or “not willing to go the extra yards”). There are places where that’s true, but I’ve also seen it assumed where it definitely wasn’t true. I’ll guarantee it’s not true when you’re working for me.

The irony is that most managers assume you will say no at some point. They’re not keeping detailed track of what you or your team is doing (and realistically, they can’t if the demand is coming from multiple sources; even central tracking systems rarely include absolutely everything that is being done). As a result, they’re assuming that your response to new work reflects your capacity. If you keep saying “yes,” they assume you still have capacity, so they keep giving you more stuff to do.

There’s still a weakness lurking here, which is that an individual’s impression of their own capacity is somewhat flexible. I can decide that I can actually do a bit more, maybe by cutting a few corners, or by deciding that in this specific case those particular corners are redundant, so it’s not really cutting anything. We rely on teams and individuals to maintain their personal standards of quality; while there are some things that can be externally verified, it’s often at the cost of introducing unwelcome levels of process, and there are still many more things that can’t be externally verified. Hence my mention of Pirsig’s “Zen and the Art of Motorcycle Maintenance” at Unruly last week: I think personal standards of quality are very important.

I think this is a pretty general model, but here are the key takeaways if you work for me:

  • Say no when you run out of capacity as an individual.
  • Say no when your team runs out of capacity.
  • Make sure your capacity reflects your personal standards of quality — don’t lower quality or safety to create more capacity

This approach may lead to difficult conversations, but they’ll be valuable conversations, and I welcome them.

After I drafted this I realised that it might seem that I’ve laying off process problems onto individuals. I agree with Deming that “A bad system will beat a good person every time”, so I’ll continue to investigate other parts of the system. However, explicitly creating the space for people and teams to say “no” is also part of the system — if anyone on one of my teams thinks they’re said no and been ignored please raise it will your team leader, or with me directly.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.