Cut Us Some Slack! (and why that helps both of us)

I decided to write a bit on slack based on my all-to-regular defense of slack in my daily work.

Most employers and managers tend to erroneously equate Activity with Value.

“If we keep people busy, we will get more done” is a common refrain and seemingly fundamental belief. Leaders tend to put more energy into increasing current capacity than the more powerful approach of understanding throughput. This all happens for good, although misguided reasons. Allowing the appearance of “wasted bandwidth” in your system is more than uncomfortable – it feels criminal. Especially in systems that are struggling and overburdened.

There is so much to do! We need to get every drop of available capacity from our teams we can! NO DOWNTIME!

Paradoxically, these are the times we as leaders should lead and teach our teams that slack is not only appropriate, it’s likely the only way to get out of the mess we’re in. I know what you’re thinking. But how could that be?! We’re behind and you’re telling me to allow, nay force people to be less than 100% allocated!?

….yep. And here’s why.

Metered OnRamps

If you think about the (overused by me) analogy of a highway, why is it that we don’t crank the system to 100% of its capacity, filling every available slot on the road with a vehicle? It seems pretty simple in these terms. It’s because our highway would quickly become a parking lot. However, our expectation is that a completely full highway moving at 65 mph yields the best throughput over time. This sentiment is unequivocally true. No doubt about it.

So why does the highway operate so inefficiently at 100% capacity? The reason is that each “seemingly independent” vehicle on the road depends on other vehicles on the road to get to where it’s going. If one of these inter-dependent vehicles brakes suddenly, the cars behind it have no option but to do the same. The result is a tsunami of brake lights and the system slows dramatically. The cars on the road have no ability to absorb even minor changes to the system, and therefore the entire system is affected by minor changes (I assume you’ve heard of “gapers delay”?) Throughput in a system like this is completely constrained by minor issues and ultimately you get wild fluctuations. From very high throughput to near zero.

To achieve the absolute highest levels of throughput in a real world system, the trick is to work and experiment your way to the inflection point where:

  1. too much slack artificially degrades throughput (meaning we are missing an opportunity to add more vehicles without degradation of the system) and
  2. too little slack that ensures any minor (and inevitable) system changes become amplified and choke throughput.

The World of Teams and Portfolios

There’s nothing trivial about building slack into your systems, or daily lives for that matter. What is clear to me is how critical it is. My advice to you as leaders is to “keep your eye on the baton, not the runners” (Vodde, Larman). Work to largely ignore “activity” and focus ALL of your time trying to understand the total throughput in your system. Make small changes to your systems and portfolios and observe the impact.

Slowly filter “work” into your system and observe the point where more work yields less delivery. When that starts to happen, don’t panic and spin up more projects to fill peoples time. Relax. Breathe deep and look around your system for the next challenge. I promise you’ll find some.

5 thoughts on “Cut Us Some Slack! (and why that helps both of us)

  1. Pingback: Jason Montague
  2. Pingback: Jason Montague
  3. Pingback: Jason Montague
  4. Pingback: Jason Montague
  5. Pingback: Erik Weber

Leave a Reply

Your email address will not be published.