I’m happy to announce that my book, The Origins of Efficiency, is now (officially) available for preorder, and will be released on September 23rd.1 You can preorder on Amazon, Stripe, Barnes and Noble, or Bookshop.com.
Why I wrote this book
Seven years ago, I joined a well-funded, high-profile construction startup called Katerra. At the time I was a structural engineer with about ten years of experience, and over the course of my career I had become increasingly disillusioned with the inefficient state of the construction industry. Over and over again, engineers and architects were designing similar sorts of buildings, instead of building multiple copies of the same design. Contractors were putting up buildings on-site, by hand, in a way that didn't seem to have changed much in over a century.
Productivity statistics told much the same story: unlike productivity in other industries, like manufacturing or agriculture, construction productivity has been flat or declining for decades, and it’s only getting more expensive to build homes, apartments, and other buildings over time.
Katerra had a plan for changing all that. It would efficiently build its buildings in factories rather than on-site, doing for construction what Henry Ford had done for cars. Katerra already had several factories in operation or under construction when I joined, and planned to build even more. At the time, I thought Katerra’s approach was exactly what was needed to change the industry. It seemed obvious that factory-built construction would be more efficient, but that some combination of incentives, inertia, and risk aversion kept the industry locked into using old, inefficient methods of production. I thought that with a sufficient jolt, the industry could be disrupted and new, better ways of building could take root. Katerra had raised over $2 billion in venture capital to supply that jolt.
But within a little over three years, Katerra had burned through all its venture capital, gone through increasingly brutal rounds of layoffs (one of which cut the engineering team I was leading by around 75%), and declared bankruptcy. I survived the layoffs, but had left the company several months before its final end. When Katerra closed its doors, I was working at a new engineering job, back to designing the same sort of buildings, built using the same old methods I’d used for most of my career.
Since then, the construction industry hasn’t improved its track record of productivity. In fact, post-Covid, construction costs had one of their steepest rises in history.
As Katerra was collapsing, I became obsessed with understanding why things had gone so wrong, and what it would take to actually make the construction industry more efficient. I started writing Construction Physics just after I left the company, as a way to work through an understanding of how the construction industry worked and why Katerra had failed to change it.
Some of Katerra’s failure can be blamed on operational missteps: trying to develop too many products at once before finding product-market fit, failing to integrate acquired companies, and so on. But it also gradually became clear that Katerra’s fundamental thesis — that construction would be much cheaper and more efficient if it was done in factories — was either incorrect, or woefully incomplete. Time and again at Katerra, the engineering team would design some new factory-produced building, only for the costs to come back too high. Time and again executives would complain how hard it was for Katerra, with its expensive factories and high overheads, to compete against “Bubba and his truck,” who could put up buildings using little more than hand tools. Rather than enabling radically cheaper construction, as Ford’s assembly line had done for the Model T, Katerra’s factories were making it hard to even compete in the existing market.
It also became clear that Katerra was far from the first company to try and fail to transform the industry using factory-built construction. I learned that such attempts stretch back decades: from the Lustron Corporation in the 1940s, to Stirling Homex and the other Operation Breakthrough companies in the 1960s, to Veev in the 2020s. Often these companies failed as quickly as Katerra did. Other times, they managed to carve out successful businesses: National Homes successfully built prefab homes for nearly 50 years. But no one had managed to use prefab to become the Henry Ford of housing.
And the problem didn’t seem limited to the US. While prefab, factory-built construction is often much more popular in other countries than it is in the US, nowhere did I find it ushering in dramatic cost reductions. Toyota, arguably one of the best manufacturers in the world, formed a prefab housing company in Japan in the 1970s to apply its manufacturing expertise to homebuilding. But while in car manufacturing Toyota was so efficient and successful that it eventually set the global standard, Toyota remains a niche player in homebuilding, and its homes are surprisingly expensive compared to site-built construction.2 In Sweden, nearly all single-family homes are factory-built, but their construction costs are higher than conventionally-built homes in the US.
It eventually became clear to me that we didn’t really understand what it took to make some process more efficient. Those of us hoping to use factory-built construction to drive down costs were acting as a sort of cargo cult — duplicating what we saw work elsewhere, without truly understanding the mechanisms that made the process successful. To understand why the construction industry was so resistant to efficiency improvements, and why it never seemed to get cheaper to construct buildings, I needed to understand how, specifically, things get cheaper to produce over time.
This book is the fruit of that effort.
Over the course of roughly a year and a half, I looked at dozens of production processes — from cigarette making to package delivery, from steel production to tomato harvesting — to see how they improved over time. I read about the history of virtually every industrial improvement system: from scientific management to Lean production, from DFMA to SMED, from Taguchi methods to statistical process control. I read the work of economic historians who had studied industrial progress like Joel Mokyr, Alfred Chandler, David Hounshell, Gregory Clark, Sam Hollander, and John Enos. I bought lots and lots of books. The bibliography of the book has around 600 separate references, and on its own would be one of the longest pieces of text I’ve ever produced. (Writing this book is what forced me to start using proper reference management software.)
I initially thought that turning all this reading into a book would be essentially the same process as writing the newsletter. At the time, my newsletters averaged around 2,000 words each, and I estimated that the book would be around 100,000 words, or require around 50 newsletters’ worth of work. But I was sorely mistaken. It turns out that it's comparatively simple to write 50 stand alone pieces of text that collectively add up to the length of a book. Tying many disparate ideas into a single, coherent thesis, and then explaining that thesis via separate chapters that draw on and reference each other, is much more complex. (This is why you see so many books which are loose collections of thematically similar chapters: it’s much easier to write that sort of book.)
Over the course of writing the newsletter I had developed a writing process that worked very well, but this process was ill-suited to produce a book-length work. Once I signed the contract with Stripe Press, I thought I’d immediately able to start cranking out chapters, but for roughly six months I struggled to produce anything useful (there were multiple times when I sent a draft chapter to someone, then quickly followed up with “Don’t read that, it’s trash,” and started over).
Writing the newsletter is essentially a linear process: I read everything I can on a topic, take note of the especially interesting or relevant facts and information, and then come up with a structure for an essay that can incorporate it all. Once this structure is in hand, it's simply a matter of expanding the basic structure into a draft, and a draft into the final version. For the book, I eventually figured out that I needed to turn this linear process into a cyclical one. Instead of going from reading to structure to draft to final version, I would read, come up with some tentative ideas for a structure, then use those ideas to guide further reading, repeating the process until I felt like things had “clicked” and my structure was robust. Only then could I start fleshing out the basic ideas into a draft.
After several months of this, I was able to condense down the mass of information I had collected into a relatively simple framework: a small number of specific things you can do to make a process more efficient.
The book is 10 chapters, plus an introduction and conclusion. Chapter 1 explains this basic framework: the structure of a production process and the options you have for making it more efficient. Chapters 2 through 6 explain each one of these strategies, drilling into the details and nuances of how they work, when they don’t work, and examples of how they’ve reduced costs or improved operations in actual production processes. Chapters 7, 8, and 9 explain how these various strategies can work together and reinforce each other, collectively creating enormous efficiency improvements. Chapter 10 explains what happens when these paths to efficiency improvement are blocked, using the construction industry as an example.
I’m immensely proud of this book; if it sounds interesting or valuable to you, I hope you’ll pre-order it.
It’s technically been listed on Amazon for months, but only recently have the cover and everything else been finalized.
Preordered! 🙌
What a lovely, concise explanation of the process of developing a serious novel argument. I have pre-ordered the book. Thanks so much for the excellent newsletters.
“Writing the newsletter is essentially a linear process: I read everything I can on a topic, take note of the especially interesting or relevant facts and information, and then come up with a structure for an essay that can incorporate it all. Once this structure is in hand, it's simply a matter of expanding the basic structure into a draft, and a draft into the final version. For the book, I eventually figured out that I needed to turn this linear process into a cyclical one. Instead of going from reading to structure to draft to final version, I would read, come up with some tentative ideas for a structure, then use those ideas to guide further reading, repeating the process until I felt like things had “clicked” and my structure was robust. Only then could I start fleshing out the basic ideas into a draft. After several months of this, I was able to condense down the mass of information I had collected into a relatively simple framework: a small number of specific things you can do to make a process more efficient.”