Should we try to optimize the busyness of the workers? No!

Michael Wollin, in another forum, raised this issue several weeks ago. Or rather, said that he had a client who was thinking "keeping everyone really busy is useful", and Michael was wondering how he might explain this to them.

Introduction

Lots of people and managers have thought about how to get a group of people to do work effectively.

Let's be fair: I think any conscious notion is probably better than "chaos" because at least we have started to be conscious, and that suggests at least the possibility that "the school of hard knocks" (reality) just might teach us something.

Next: Many people see groups of people who are supposed to be working, with at least some of them appearing to be "not busy", and have the thought "if everyone were working now, we could get more done." And it is true in some situations.

So, let's start there.

Goals

Some people say, if you have a group of people (ok, a small Team of 7), the goal should be to optimize the end-to-end productivity of the Team.

Note already: if it's a real Team, the productivity of the individuals is irrelevant. The productivity of the Team is relevant.

What do we mean by productivity? Well, some would say it is "effort" or "ergs" as inputs. Nope. We do not care about inputs, we care about outputs.

Some would say it is the number of widgets produced!

Well, maybe, but not really.

I (and others) think it is the amount of business value produced. Right now let's call that: business value for the customer.

To be honest, business value itself is a complex subject. And sometimes our work is for internal people. So, commonly hard for the team to know or understand how delivery to internal customers affects end-customers of the company. We also may have the fight with people who argue (somewhat rightly) that business value is really the total return to the widows and orphans who are the ultimate shareholders of the company. But let's leave that as a fight for another day.

So, let's stick with business value for the customer. Let's agree that this is like love and beauty. Business value is in the mind of the beholder. Or the heart of the customer. (Geez, this is sooo squishy! Yes, sorry!) As a proxy, for now, let's call business value the $ that customers will pay for our product or service. (Yes, I am simplifying.)

[Note: Let me offer what I think is most true: It is more blessed to give than to receive. For those who have ears to hear, let them hear.]

More specifically, let's say our business goal is to maximize business value delivered in a year.

So, by our current definition: it is units sold * net avg price/unit.

Notice how I "tricked" you. Real productivity ONLY happens after it is sold, and, really, when the product is being used by the customer (sometimes notably after the sale).

So, if we call productivity (as a proxy) units delivered by the Team to "outside the Team" you see we are fudging things a lot. Units delivered to a warehouse are only trouble. That, by itself, is AT BEST only potential business value, but not real business value.

Oh, you say that in theory software products can be delivered almost in zero time to the customer. Ok, easy to say and yes, kind of true in theory. But, that's almost never true in practice. Even now.

Oh, let's also make clear something about the opposite. Yes, we do need some slack to enable the other goals. BUT: our goal is not to maximize people being "busy." The slack does not need to be 100% (ha ha). What is a ballpark? Maybe slack should be 20%? This is hard to know, and depends on many factors. Again, do NOT focus on slack %, but rather on the other goals we suggested.

This is hard!

Let's back up and make it simpler for ourselves. Let's assume business value is units delivered "out of the Team." (Yes, ok, a fudge.)

How to try to optimize that?

First, set it as a goal. (And admit it is a fudge. An approximation.)

Second, I assume you have a small Team of pretty good knowledge workers. So, teach them some of these basics (mostly from Lean) and let THEM figure it out.

Third, the Team is a human system. They must figure out "everything together" (in a human way) to "optimize" it.

Note: Optimize is a word we use. Actually what we mean is "improve it continuously." Because there is no such thing as an optimal team. Everything that a single person or team has done, when we come back to it later, somebody (or some Team) eventually does it better. So, there is no known optimal level.

(Yes, Virginia, there are physical laws of the universe, such as the speed of light. Which might suggest to you that there is a "close" optimal, maximum level. I say "no". I think we are so far from that maximum level that it is a waste to even discuss this "worry.") (The good news: we have barely begun to tap the full power of a human or a Team.)

Aside: We will discuss stress and sustainable development later. We are NOT suggesting over-stressing the system (the Team for us, now).

Fourth, do NOT suggest to them "keep everyone busy all the time." Keeping everyone busy every moment is counter-productive.

One way to think of this is: the human production process is imperfect and (fairly) highly variable for our products. We need some "slack" people to jump in and overcome "bumps in the road." To keep things moving well. The value of moving along steadily is far higher than the value of keeping the people completely busy.

Fifth, in knowledge work, we always need collaboration between members of the Team. For many reasons, eg, to share knowledge, to help each other, etc. Exactly how much to collaborate and exactly how to collaborate (with each person) are questions that only the Team can answer in the moment. Ex: Each person is weird and wonderful in their own way.

Sixth, with knowledge work, at least over a year, you must also maximize (or increase) learning. By "everyone" in probably "all" knowledge domains. Notice that an excellent way of learning is to build "something small" (an MVP) quickly, and get feedback. And the feedback is commonly from mainly from an independent set of people, perhaps customers. Some of you will recognize this as "fail fast to learn faster." Two key things should happen from the learning: (a) more widgets are produced, and (b) the customers like the widgets better (think: on average the BV per widget is higher).

Note on widgets: In Agile the Team produces or completes "user stories" commonly. Calling the user stories widgets suggests that all the user stories are quite similar, and of course this is typically NOT the case. They are rather dis-similar from each other. But: In a blog post we must simplify.

Seventh, you want to minimize WIP. Work-in-Process.

Wait. What? Why?

It amazes me that so many people in technology innovation do not understand WIP at all, or understand so little about it.

A. The work we do as knowledge workers virtually always has a HIGH time value (fast deliver is heavily wanted). One example: If we give an MVP to the customer on Day-35, it is unique and the customer LOVES it. On Day-37, a competitor introduces their competitive product. On Day-38 our product is perceived to have a much lower value.

B. The Earnings Integral is higher. Imagine a curve (curvy line) of revenue after we release the first version over time. And then that curve continues for the life of the product. And the curve tends to go up for a couple of years, and then later to start to slope down, as our product lifecycle moves toward "death." But, in a simple model, if the line extends longer (in part by starting earlier) and if the line's apex goes higher, then the area under the curve (our gross revenue) will be MUCH bigger.

C. Knowledge work products are extremely expensive. Our people are expensive, and so the cost of those people inputs (plus other inputs), especially if we are waiting to release and earn revenue, must be financed in some way. The auto industry knows this well, and has spent decades minimizing WIP. Our knowledge products industry should also minimize WIP, even more strongly.

Note: How relatively important minimizing WIP is for our products is a more difficult question.

D. "Nothing good from sitting on the shelf." As a metaphor, think of all WIP simply as product sitting on the shelf, waiting to be shipped to the customer. While it is there, nothing good can happen to it. And everything bad can happen. We can lose it (it can walk away). It can "rust." Change can happen (eg, the competitor change mentioned above) that can reduce or eliminate its value. Etc. So, if it is "done", then deliver it now!

Eighth, if people are "standing around" too much, one common real problem is they are not motivated. Or, similar, but a bit different, the Team morale is down. Don't fix the surface problem (lack of busyness); fix the real problem.

Conclusion

Focus on what's important, not just on things you can see (that are often not important themselves).

You need some slack in the system to get good throughput and single-piece continuous flow (or close to that). So, congratulate the Team if speed of average throughput and total throughput (this sprint) have gone up BECAUSE they had some slack.

Teach the Team and focus them on what is important. Business value delivered to the customer - is a simple way of putting it. Then, let them teach you how they are continuously improving, and how they are balancing everything (think: dynamic equilibrium) -- so that, despite all the noise and change of life, more real value is getting delivered to customers.

Real life is pretty complex. Everything, everywhere, all at once, is changing. We need a real Complex Adaptive System (the Team) to continuously adapt to it toward success.