Five more books to make you a better business technologist

By James Kaplan

How time does fly. Just about five years ago, I published an article called “Ten books to make you a better business technologist” about the books on the organizational, strategic, and human dimensions of business technology that shaped my thinking. Given how hard it was to keep my list to just ten books and how many interesting books I have stumbled upon since that first article, I have always intended to write a follow-up.

A couple of months ago, I published a review of Gene Kim’s The Unicorn Project, for which I received a lot of positive feedback. It seems that there is quite an appetite for truly interesting reading on enterprise technology beyond the usual avalanche of tactically focused books on one of this year’s hot technologies.

So here are five more books to make you a better business technologist.

The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford

I hesitated to put this book on the list, both because I just reviewed The Unicorn Project (its quasi-sequel) and because it seems everyone has read it. The Phoenix Project describes the transformation of a dysfunctional and underperforming IT organization. It has contributed mightily to introducing traditional enterprises to technology practices developed in companies “born digital.” If you haven’t read it, you should. I don’t think any book has ever caused me to rethink more of my assumptions about enterprise technology, from the importance of speed, the viability of waterfall processes, and the trade-offs in consolidating common tech functions.

Boyd: The Fighter Pilot Who Changed the Art of War, by Robert Coram

Yes, US Air Force Colonel John Boyd midwifed a generation of devastatingly effective jets: the F-16, the F-18, and the A-10. Yes, he developed the equations for describing fighter performance and likely designed the “left hook” strategy used by American forces to great effect in the Gulf War. However, Boyd was also agile before agile was cool—or even considered. Using data from aerial combat in the Korean War, he demonstrated the value of iterating quickly, from collecting data to taking action. He distilled this insight into the observe-orient-decide-act (OODA) loop for decision making (sometimes called the Boyd cycle). In effect, Boyd’s insight—that the further ahead you plan, the harder it is to make intelligent decisions and take effective actions—underpins agile technology delivery as well.

The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger, by Marc Levinson

If Boyd’s biography is essential reading on agile delivery, The Box can be read as a book about cloud computing, even if it notionally talks about containerized shipping. Why? Despite massive potential benefits, companies have been slow to adopt cloud computing, as they have struggled to drive alignment across multiple stakeholders (business leaders, developers, infrastructure managers, CISOs, and vendors) in the face of huge sunk costs in existing applications and infrastructure. Similarly, even though transportation executives realized in the 1950s the massive value in using containers to create an intermodal logistics system, getting manufacturers, railroads, trucking companies, shipping companies, ports, and unions to accept standards (for the size of a container, for example) in the face of massive investments in existing infrastructure took the better part of two decades. Levinson does a terrific job explaining how the shipping industry surmounted these barriers to get to the massively more efficient logistics system the world enjoys today.

The Martian, by Andy Weir

Yes, another novel, and unlike The Phoenix Project, one that Ridley Scott made into a major motion picture. Stranded on Mars, an astronaut needs to arrange for water, sustenance, shelter, heat, and communications with NASA back on Earth. In addressing each of these problems, the astronaut resolves to “science the s**t out of it.” The protagonist doesn’t test hypotheses to develop new knowledge. Instead, he applies well-understood scientific principles to construct a solution in the face of (daunting!) resource constraints. In other words, he engages in the same type of engineering problem solving that technologists perform every day—and provides one of the best explications of the problem-solving process I have seen in a book.

How the War Was Won, by Phillips Payson O’Brien

You could fill libraries with volumes debating the Allies’ path to victory in the Second World War, but O’Brien takes a novel approach with a fascinating argument about the importance of resource allocation across types of technologies. He points out that the United States and the United Kingdom heavily weighted their investment toward planes and ships compared with tanks, which allowed them to destroy Axis forces on the way to the battlefield more easily than they could destroy forces on the battlefield. By June 1944, the Allies had established air supremacy over France, so the Wehrmacht simply could not get sufficient reinforcements to overrun the Normandy beachhead. This allocation concept applies to IT as well. We love our domains in IT—enterprise resource planning (ERP) systems, storage networks, identity and access management (IAM) environments—and we often reward technologists for developing deeper and deeper expertise in a single domain. However, there’s tremendous value in looking across all the domains in a technology environment and developing a systemwide view of the points of highest leverage, which deserve disproportional investment because they can create or enable the most business value.

Even more than in the past, business technology today demands the discipline to make complex judgments, trading off risk and reward in the face of scarce information. Given the pace of change, there simply is no manual for many decisions, but there are insights from novels and from history that can provide invaluable insights into ways of navigating these challenging situations.

James Kaplan is a partner in McKinsey’s New York office.