Slash the Load

Part 2 of 5 in the series Leading Technical Change

The people who hire me ask me to help their teams make changes. Most of the time, my first step is to see how I can slash those teams’ load.

Here’s a technique card from my seminar, “Leading Technical Change

LTC Technique Card

Raw text of a technique card: Wait, what? First thing I do

To me, this is dreadfully obvious, but for a lot of folks seeking change, it comes as a completely shocking idea.

The weirdest part, though, is that it not only improves our ability to change, it usually also increases our actual productivity.

Let’s talk about the change effect of that first, then the productivity effect.

In its most trivial formulation, it’s as simple as this. To go from doing A to get to doing B, we have to unlearn A and learn B. That takes time. If we don’t have time, we can’t afford to change.

I know, right? This is so very not rocket science, you’d think it wouldn’t even need a technique card.

But it does, believe me.

When we are operating at our full load, when I am firing all cyclinders, when I am dancing as fast as I can, to ask me to change what I am doing is to ask me to increase my load beyond what is possible for me to do, by definition.

  • Learning = load.
  • Practicing = load.
  • Considering = load.
  • Integrating = load.
  • Collaborating = load.
  • Adapting = load.
  • Flexing = load.

If I am already at full load, I can not do any of those things effectively, but to make a change I must do all of them.

And it doesn’t matter that the eventual result will be a higher capacity, the ability to take on greater loads. That’s the eventual result, not the immediate result. The immediate result of asking me to change what I’m doing is to increase my load. Something’s got to give.

Now, I do a lot of SAFe and Scrum rescue work. And I go to people — decent thoughtful caring people, I’m not attacking here — EM’s, SM’s, PO’s, who want to introduce a change. And I tell them, first thing we gotta do is slash our load.

Of course, in most of these shops, the very reason they’ve called me is because they feel they’re being unproductive, that their actual working load is coming in too low.

And the first words outta my mouth: yeah, you’ve got too much load here.

I tell them to slash their load by half every sprint, until they go three sprints in a row where the team hits its mark. I kill off stretch stories, I get their overall sprint goal to have one sentence with no conjunctions, and make them stop using the capacity calculator.

them: …

me: do you want change or not?

them: …

me: do you want higher productivity or not?

Here’s what usually happens, if we get our load down low enough. (I don’t always pull this off, ngl, but often enough I do.)

  1. Change starts to happen.
  2. Productivity goes up.

Let’s move past the change effect into productivity.

After all, the change = load argument is actually pretty easy to grasp. But the productivity effect seems to surprise nearly everyone.

I think it comes down to this, as the card says. All the things we need to have to make changes turn out to be pretty much all the same things we need to be better at making software.

Learning, practicing, considering, integrating, collaborating, adapting, and flexing, all of these are actually central to the act of making software well.

And of course, there’s another thing going on when we lighten the load: we lighten our mood, too. And we have more data about the positive correlation between good mood and good productivity than we have about any other aspect of social science research.

(Sidenote: Please don’t believe that crap about setting targets so you hit & miss 50/50. This is a terrible idea. Why? Because people are people, not machines, and they win more often when they percieve themselves as winners.)

Anyway, that’s the tip. If you want more change, lower the load. And oddly enough, for most of the teams I see in the field, if you want more productivity, lower the load.

12 attendees, 4 sessions, 2 hours, 1 topic.

Real Change In The Real World

An alumni writes: “Leading Technical Change has both given me new insights on techniques I was aware of as well as brought new tools to tackle change.”

Does the GeePaw Blogcast add value?

If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.

Want new posts straight to your inbox once-a-week?
Scroll to Top