Having a Bench is a Good Thing

Look around at the folks on your team, and ask yourself “Is everyone tasked with stuff?”, and, “Is everybody busy with tickets?”. In short, Is utilization at capacity?

Ok, you did that, right?
I’m guessing that the answer to the above questions either is, or should be, “YES”, right?
And — if you’re the product manager/lead/whatever — you’re probably patting yourself on the back, and feeling pretty happy about it, right?

Oh, you might have issues on the margin (“Well, Bob could be a bit busier, and Alice is about to run out of stuff to do…”), but by and large, you’re good, no?

Well, the answer is NO, and you shouldn’t be happy about this, not by a long shot. You see, “High utilization of resources will improve performance” is one of the major fallacies in Product Management (•).

Wait, what?
If you max out your resource utilization, performance suffers? How can that be?
Well, it’s because we’ve all grown up either ignoring queues, or implicitly believing that queues are Good Things. After all, Stick A Queue On It is one of the very first things all #CowboyDevelopers learn, y’know?

Seriously though, when you consider all the projects that your team, you can be sure that at least some of them will be hard to predict. The reasons will vary from ex ante (You know upfront that this is going to suck, thanks to unclear requirements, external dependencies, etc.), to ex post facto (You predicted wrong, after all, who knew that Alice was going to spend two weeks chasing a memory leak? Or that Bob would get the flu?)

The point being that, inevitably, you will end up waiting on the unpredictable stuff. After all, you can only ship when you’re done, right?

This, my friends, is a Queue of Projects. And the problems with these queues are that

• 1. Project Queues delay feedback. Even with the best of intentions, you’re not really going to know everything that went wrong till you’re done, and you’re only done once the queue is empty. Oh, you’ll get some early feedback, but remember, the worst part (Bob’s memory leak!) might only show up at the very end.
• 2. Project Queues compromise evolution. Your ability to be able to adjust to market needs is not going to be instantaneous. Adding queues just makes it worse — you now have a situation where finding (and addressing) weaknesses in your product just takes that much longer.
• 3. Project Queues aren’t instrumented. If you’re good, you actually have a product management system that uses something relevant like Confluence/Trello/whatever. If you’re very good, you have dashboards that show you the current state of everything that you’re working on. But, with very few exceptions, you probably don’t know what it actually costs to have project queues!

The last point is particularly relevant. Most companies don’t actually calculate the costs associated with project queues (they might measure it, but they don’t actually associate $$$ with it). And that, in a nutshell, is the issue. You knowthat having a bench costs money, but you don’t counterbalance it with queue costs.

The net here is that, left to themselves, companies will blindly go for maximizing utilization, and thus end up unwittingly being less efficient than if they actually had kept some capacity in reserve.

How much capacity? There is really no definitive amount, but in general, try to keep your capacity below 70%, via either having more people, or less projects.
And yes, do focus on making your WIP inventory much more visible. Ask your CFO for help in quantifying this, you’ll be surprised at how effective they can be!

(•) “Six Myths of Product Development” by Stefan Thomke and Donald Reinertsen