THE LARGE - BATCH DEATH SPIRAL
From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that's the theory. Unfortunately, reality seldom works out that way.
Consider our hypothetical example. After passing thirty design drawings to engineering, the designer is free to turn his or her attention to the next project. But remember the problems that came up during the envelope-stuffing exercise. What happens when engineering has questions about how the drawings are supposed to work? What if some of the drawings are unclear? What if something goes wrong when engineering attempts to use the drawings?
These problems inevitably turn into interruptions for the designer, and now those interruptions are interfering with the next large batch the designer is supposed to be working on. If the drawings need to be redone, the engineers may become idle while they wait for the rework to be completed. If the designer is not available, the engineers may have to redo the designs themselves. This is why so few products are actually built the way they are designed.
When I work with product managers and designers in companies that use large batches. I often discover that they have to redo their work five or six times for every release. One product manager i worked with was so inundated with interruptions that he took to coming into the office in the middle of the night so that he could work uninterrupted. When I suggested that he try switching the work process from large - batch to single-piece flow, he refused - because that would be inefficient !
So strong is the instinct to work in large batches, that even when a large batch system is malfunctioning,we have a tendency to blame ourselves.
Large batches tend to grow over time. Because moving the batch forward often results in additional work, rework, delays, and interruptions, everyone has an incentive to do work in ever -larger batches, trying to minimize this overhead. This is called the large-batch death spiral because, unlike in manufacturing, there are no physical limits on the maximum size of the batch. It is possible for batch size to keep growing and growing. Eventually, one batch will become the highest-priority project, a "bet the company" new version of the product, because the company has taken such a long time since the last release. But now the manager are incentivized to increase the batch size rather than ship the product. In the light of how long the product has been in development, why not fix one more bug or add one more feature ? Who really wants to be the manager who risked the success of this huge release by failing to address a potentially critical flaw ?
I worked at a company that entered this death spiral. We had been working for months on a new version of a really cool product. The original version has been years in the making and expectations for the next release were incredibly high. But the longer we worked, the more afraid we became of how customers would react when they finally saw the new version. As our plans became more ambitious, so too did the number of bugs, conflicts, and problems we had to deal with. Pretty soon we got into a situation in which we could not ship anything. Our launch date seemed to recede into the distance. The more work we got done, the more work we had to do. The lack of ability to ship eventually precipitated a crisis and a change of management, all because of the trap of large batches.
