I’ve always found Gene Kim’s work interesting and his new book is no exception. When I read The Pheonix Project I was a relatively new Dev Manager and getting my first taste of IT Operations. It allowed me to see the problem I was given in an entirely new light. Kim solved that problem and moved on to bigger challenges (along with collaborator Stephen Spears), culminating in this book which tackles a much more sophisticated problem; how to make an entire Organization more effective. While the evolution of Kim’s thinking has advanced a bit faster than my career, this book is much more relevant to me (while running/leading an organization of 100+) than another DevOps book would have been. It was fun to take inspiration at this new stage of my career from the same guy I took inspiration from in the last phase.
I enjoyed the way this book was laid out. Each primary topic had a section for theory, a section for examples, and a section for a deep case study. It made it easy to navigate the book the way I wanted to. The book was also centered around two core ways of looking at an organization that can be stated and understood simply. The concepts aren’t simple of course, and each requires another hundred pages to expand. One aspect of these expansions that I found extremely captivating was the authors’ comparisons with known management systems and an exploration of why people think they will work and then why they often don’t. This lead to one of my favorite sections of the book, where they break down why using escalation and expediting is not as effective as having iterative, modularized, linear work assignments.
The first way of looking at the organization that Kim explorers is thinking of the organization in Layers:
- Layer One is the technical object and the people doing the “line” work.
- Layer Two is the tooling and the people who maintain the tooling that allows the “line” work to proceed.
- Layer Three is the social circuitry that links Layer One, Layer Two, your customers, your management, other parts of your organization, etc…
I’ve started incorporating this concept into my retrospectives. When we don’t get an outcome we want, I’m having the team think about which level we think can be adjusted.
The second way the authors break down the organization is into three categories of how work can be improved; Simplification (breaking down big problems and giving teams/people something they can solve), Slowification (finding the right time/place to solve problems (for example moving an issue into a lab or testing a change with a small population), and amplification (making sure problems are well known and discussed). Obviously there are dozens of techniques for each of these and the book goes through many of them, but I love the simplicity of the overall solution.
I highly recommend this book for anyone who leads (even if they don’t manage) a team of more than ~15 that is managed on outcomes. It’s less of an answer key with specific tips, and more of a guide to understanding why some things work and others don’t.
If you do pick it up, make sure to read Appendix B on leadership!