The Machine That Changed the World

I recently read The Machine That Changed the World: The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos. Originally published in 1990, the book is now a bit dated as business books go, but given the enormous influence lean manufacturing in general and this book in particular has had on software development, it seemed well worth reading.

It was an interesting read, and it left my struck far more by what's different between lean manufacturing and lean software than by what they share. Let's get into why.

Quick synopsis

For those who aren't aware, the core idea is that automobile manufacturing has progressed through three phases. It started as a product of craft manufacturing, in which skilled craftsmen made small batch and bespoke automobiles using inconsistent components. This was replaced by mass production, developed by Henry Ford and later General Motors, which used low-skilled disposable labor, moving assembly lines, and interchangeable highly regular parts to make many millions of cheap vehicles.

Then, in the second half of the twentieth century, Japan's Toyota Motor Corporation introduced  lean manufacturing (as the Toyota Production System), in which workers are purportedly tasked to constantly improve process efficiency and reduce waste, while just-in-time parts requisitions and small flexible assembly lines that can change task quickly enable production that is highly responsive to customer needs. Other Japanese manufacturers followed suit, American and European manufacturers were slow to adapt, and as a result Japan's car manufacturers grew massively and (in 1990) seemed poised to take over the world.

A few interesting bits that stood out to me:

• It's clear that the advantages of the Japanese firms were grounded in real superior productivity, not just macroeconomic conditions like a favorable exchange rate. While the economic environment may have helped at some stages, Toyota and other lean Japanese firms really were producing comparable vehicles with half the man-hours in half the time compared to American firms.
• There were Japanese laggard firms (Mazda, others), and by 1990, American firms had replicated and maybe improved on some parts of lean manufacturing (though a 2007 afterword indicates that Ford, the leanest American manufacturer in 1990, had since backslid considerably). Europe has always been a laggard in adopting new systems of manufacturing.
• Reading a book about Japan's apparently-unstoppable rise to global dominance in 1990 is in part, inevitably, an exercise in appreciating historical ironies. There are two passing references to something like "recent stock market dips." China barely merits a mention, except to say that in 1990, China produced an average of 1 car for every 2.5 auto workers, while Japan produced an average of 26 cars for every single auto worker.

The Machine and Software

The book doesn't touch on lean software development at all, but its discussion of the Toyota Production System touches on a bunch of the buzzwords we encounter in software: reducing waste, pull model, kaizen, empowered teams... they're all there.

I was struck, however, by how different lean software development is in practice from lean manufacturing as (mostly) described in the book. Lean software development has borrowed the terminology and some of the day-to-day practice, but has almost wholly overlooked the broader corporate context in which lean manufacturing emerged.

Labor relations

As Womack, et al., tell it, lean production at Toyota has its roots in a compromise between management and unionized labor. In 1950, a struggling Toyota made a grand bargain with its union: in exchange for a one-time mass layoff to get the firm through hard times, management would commit to never layoff employees again. Toyota's then-CEO resigned as an act of contrition for the layoffs, and the company apparently abided by the deal, avoiding any layoffs until 2009.

The resulting lifetime employment arrangement has a number of salient consequences:

• The firm is motivated to invest in workers' skills and long-term productivity.
• The worker is motivated to care about the long-term success of his/her team, division, and the business overall.
• The firm and the worker are safe to (and even incentived to) experiment with the way work is done.

There's a flip-side to the lifetime employment model of Japan: compensation is tightly coupled with tenure at the firm, and it is very difficult to change employers mid-career. This means the worker is very likely to think of himself as a "Toyota man" rather than as a free agent.

Clearly, this lifetime employment for auto workers is drastically different from the relationship between software professionals and their employers.

Corporate structure

Except for Honda, all of Japan's auto makers were (and are) embedded in keiretsu, which are a variant of corporate conglomerate unique to Japan and Korea. Each is a collection of technically-independent corporations centered on a large bank, with each member of the keiretsu holding equity in each of the other firms in the group. The firms (such as an auto assembler and its parts suppliers) deal preferentially with one another, while the bank provides attractive financing and patient capital.

While many firms in the keiretsu may technically be publicly traded, the effect of the interlocking equity stakes and the common financing mechanism means that the firms do not offer many shares to the public, and are thus insulated from the vicissitudes of equity markets and the desires (or threats) of activist shareholders.

The trusted long-term relationships between firms and the ready access to patient capital are stark contrasts to the environments in which most "lean" software gets written. I've yet to meet a software team that was empowered by its management to shut down the production line to implement process improvements until near-perfection is achieved.

So what?

These large differences in working context (gemba?) fundamentally undermine the linkage between Toyota-style lean manufacturing and modern software development. Given all the noise made about the Toyota Production System and its influence on software development, I expected to see many more clear antecedents in the former for the latter. Instead, I finished the book feeling they had much less in common than I expected. Lean software development, as practiced at the firms I've been exposed to, seems only very loosely related to lean manufacturing.

Lean software may  or may not be a good way to write software  on its own merits, but its Toyota pedigree is a stretch. The Japanese vocabulary words are there, but with such different labor relations and corporate structure in place, the gestures to a Japanese origin appear awkwardly mimed rather than thoroughly practiced.

Should you read it?

If you have an interest in business history or manufacturing, certainly read The Machine if you haven't already.

If you are someone who reads general business books to improve your corporate game, just find and read a fuller summary. There's a lot of car-specific inside baseball and dated 1980s corporate details won't generalize.

If you're a software person looking to understand lean software practice, I think there's not much here for you. If anything, the lesson is in seeing just how distantly-related lean manufacturing and lean software development are.