Gene Kim has a new book coming out in November, The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data. It’s an interesting read, describing a path to an amazing turnaround of a doomed technology inside a traditional business. The Five Ideals are a nice encapsulation of many of the ways people talk about continuous improvement with a notable addition of Psychological Safety. (Note: I received an advance copy for review.)
The book follows on The Phoenix Project from six years ago (my review) with the same company and some of the same characters. Strangely, the successes of the first book seem to have turned into sludge in this new book - getting assigned to the Phoenix Project is now considered punishment. And that is the core of the challenge described in this new novel: How can a team - or a whole company - recover from all the technology and processes that were created for good reason, but now seem to prevent the organization from doing anything?
This change is the heart of how the principles behind the DevOps movement work - look for what is blocking flow and unblock it. And when that is unblocked, what is the next one? Take the opportunity to learn and think - none of this working until your eyes bleed stuff. In the context of the novel, these are represented in The Five Ideals:
THE FIRST IDEAL: Locality and Simplicity
THE SECOND IDEAL: Focus, Flow, and Joy
THE THIRD IDEAL: Improvement of Daily Work
THE FOURTH IDEAL: Psychological Safety
THE FIFTH IDEAL: Customer Focus
These ideals are discussed - mostly by example in the story - throughout the book. They all make sense, and they build upon the concepts described as “the three ways” in The Phoenix Project.
The element that jumps out to me as critical to any drive for improvement is the idea of Psychological Safety. I’ve seen it discussed in many places, but putting into the context of this book and the relentless drive to improve and get better makes a lot of sense. Without the confidence that we can take action and be encouraged to learn from mistakes and successes, people (and organizations) revert to blaming and safe positions. Checklists and review boards become the norm and the way people protect themselves from “damage.” It’s a natural response in the system. I almost wonder why this isn’t the first ideal.
The value of “simplicity” over “complexity” comes up quite a bit in the book. In particular the idea that we have a choice to design-in simplicity - whether it is software, processes, or the business as a whole. Or more specifically, if we aren’t paying attention to enforcing simplicity then business processes of all types naturally become more and more complex. They get gunked up. For example in Chapter 11, “Each year, we used anything that went wrong as an excuse to create more and more rules … which just slowed us down even more.” One of the big elements of this book is having the courage and ability to stop the insanity and intentionally detangle the ball of yarn. Not only does this make sense in software, but in business too. It’s so easy to emphasize local optima - making it easy for “us” - that we lose the focus on the customer (The Fifth Ideal). In the end, the customer pays for what they value, not all the stuff we do inside the organization.
Some additional thoughts as I read the book:
I worked at an auto parts store during the summers in high school, so some of the discussion of the stores of Parts Unlimited brought back memories. Those 3-foot-long catalogs of parts for every imaginable vehicle felt like the core of the business.
As is the structure of these kinds of books, The first several chapters really hammered home the challenges that the main characters experienced. I could almost see a current reality tree or other situation analysis as the characters talked about the challenges they have.
I really liked one of the descriptions of the importance of fast feedback (chapter 3): “If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes … so the link between cause and effect disappears without a trace.” I’ve seen this as well. Even if you have some kind of tracing matrix, the fact that the impact is felt much later than the change leaves no room for feedback. What if we’ve made the same change many times between now and then? How many places will it break? It’s much better to check as quickly as possible - ideally by the same people making the change.
Systems thinking is a big element of the new way of work. Even when an individual makes a clear mistake (as happens in the book with Brent), what is it about the system we’ve created that allowed that to happen? This isn’t about creating more checklists - it’s about designing a system that makes it easy to do the right thing.