I’m spending some unplanned time off work this week and thought I should make note about the book reading streak I’ve been on since November last year. Though this time it’s a slight departure from high-fantasy worlds and at least partially rooted in reality. I’ve been going through books about what I would label as management systems or thinking systems and it all started with a recommendation from a Microsoft Architect whom I encountered during one of our client workshops, it was The Phoenix Project. Initially I didn’t quite recognize the name, but somewhere along the way I remembered it being recommended as “The DevOps Bible” and, well, it does make a convincing use case. While I had a good grasp of the DevOps practices and I have been part of transformation projects I somehow had missed reading the source material, relying on summaries and trainings that focused on the tools. But here, listening to the book (I tend to find more time for audiobooks rather than paper medium) I was exposed to the process of coming to the conclusions, and that felt so relatable. The other part that got me hooked was the ideas about Theory of Constraints.

Enough so that after even before finishing the book I had purchased the next read: The Goal: A Process of Ongoing Improvement. Tone wise this book is a throwback to the time it was written - smoking and alcohol in the workspace, yet the book resonates so well when it gets to the main characters discussion about welding robots in their factory and how little tangible change they’ve had on overall factory productivity - and here we are more than 40 years later looking at the same phenomenon happening with knowledge work and AI introduction in existing processes. Any improvement not at the bottleneck will not bring you closer to the goal and the overall importance of flow.

All this reminded me of older blog articles I had clicked though back when I was first learning about Kanban and Lean and the importance of making work visible. Next read was: The Toyota Way (Second Edition) While this felt more long winded ideas about waste, continuous learning and continuous improvement neatly aligned with the previous reads. Even more when it came to “standard work” and “enabling bureaucracy”, something felt similar to initiatives I’ve seen working in large scale software development projects. I’ve yet to explore some of the tools that the book introduces - like their way of documenting proposals on A3 sheets - the book is careful to remind that the tools are just that, tools that had worked for them to surface issues and apply process of learning and improvement. So at it’s basis it’s a change in perspective, a change in interpreting the systems around us and our interaction with them. While reading this I also stumbled on some YouTube videos showcasing applied lean principles. Yes it’s physical problens with physical solutions, but the principles are still valid - minimizing context switching, emphasis or order.

Next on the bookshelf was Accelerate: Building and Scaling High Performing Technology Organizations While the book itself was a rather dry listen I liked the approach they took to pull together evidences and connect in a concise narrative “selling points” for the ideas and principles introduced in The Phoenix Project (and The Unicorn Project for that matter). One of the reviews summarized this as the book to help you convince C-level & management to take steps in the right direction. And here I agree that management buy-in in the principles used for business operations is essential. It’s been again and again re-iterated in all the previous books and in itself makes a good case for it.

Here I was, four fairly interconnected books later. I decided to fill in the blanks from the recommendation stream from the authors to see how much the ideas were developed and expanded in related works. It’s Not Luck: Marketing, Production, and the Theory of Constraints was the next listen. Goldratt maintains his style and it’s an easy listen, even if the formula starts to wear down a little. This was a book where I felt I was missing out a little by listening to it rather than reading it as it leans heavily to visual tools like “Evaporating cloud”. It’s not a deal breaker for the story, but I feel I should still dedicate some time to practice with this to form a better viewpoint for myself. The other part is the focus on conflict resolution and negotiation that felt very familiar to ideas from negotiation lectures I have been lucky to attend. To sum things up - value of “things” is not determined by their cost - and it’s a very common mistake that people who participate in making said “things” make.

And finally here I am today, in the middle of reading The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data. Back in a more familiar territory, that feels less controversial than the other books. I suspect that’s because I’ve had the privilege to work with one project long enough to get chances to to be part of transformations towards agile practices and over time introducing many of the good ideas. And despite setbacks, it’s ongoing work that I cherish. How can I not - being told things are impossible and then (with the help of others) doing said things is a wonderful feeling.

Going though this book journey has reenforced two things for me:

10-point summaries and short blog posts can’t replace books and trainings. To change our thinking we need to do the thinking part - walk the walk.

Change is not just possible, it’s inevitable and those who do, decide what gets done.