Management Lessons from The Phoenix Project

The Phoenix Project is novel about IT, DevOps, and helping business to win in a competitive retail market. A lot of friends in office recommended me this novel so I decided to give a shoot. They all say it’s so resonate with life in IT company; development, quality assurance, deployment, bug fixing, and system down, are just few examples of day to day typical encounter for us. Life in IT is hard, and this novel make me realize that it’s even harder when you have no idea how to manage that complex work. So this book for me is more like business and management lessons for whoever want to solve complex problem from higher level. I always thought what’s executive management people actually do. Because at the end, it’s all down to engineer people like me to solve their problem, the escalated issues, the bugs that always exist, or some tricky way to solve problem and then once it’s solved the credit goes to management people like engineer don’t exist. What’s so great about them that they deserve higher credit (and paycheck)? This book answered that question. In fact the book gives me as sense of problem solving skill that is more sustainable in the organization.

Think of it just like two complementary different set of skills, one focuses on low level problem like designing architecture, or finding the most efficient algorithm. That’s great and hard skill to be mastered at, and every IT industry is rooting their business to folks like that. The other one focuses on much higher level. These people have little idea about code implementation and how they work, they might not even know how to code effectively. But these people are so great at planning the work flow, managing the resources over works, and preventing minimum outage from happening. These skills are different level of intelligence, their brain work differently compare to the technical geeks, it’s more on looking problems from higher system. People who master on this has laid their way down to the leadership path. I find my self appreciating executive people more than before. Let’s accept this, they have more pressure, more complex problems, longer work-hour, and of course more paycheck!

Before going further, what is DevOps? DevOps is set of practices/formula that aims to integrate the process of software development and software operation within project. In other words, DevOps is continuous software project life cycle from the moment the code is checked in until the code package is deployed in production to finally reach customer as finish goods. DevOps make sure that project is delivered on time with full required features at minimum defects. This book in a nutshell talk about DevOps principles and why they are important to business. These principles could also apply to non IT work for example manufacturing process. In fact most of the case studies are derived from manufacturing line because their entire work flow is more visible, hence it’s easier to track them down. There are three principles in which all DevOps pattern is derived from, they called The Three Ways.

First Way, always think the entire performance of system as opposed to specific performance of department. This will help us understand how to fast flow of work as it moves from Development into IT Operations.

Second Way, amplify feedback loops between Development to Operations, in my office we called it Retrospective. It’s an hour session to evaluate the past project of what goes wrong and how to improve it in the next cycle. But my case is a practice within the Development side, Second Way talk about cross functional feedback. This is the most critical part, if you understand it well, you could solve some serious problem related with work throttling which is the heart constraint of any business process. The goal is to keep up with the market demand by doing continuous delivery. In manufacturing they have a measure called takt time, which is the number of cycle needed to keep up with customer demand. If any operation in the flow is longer than takt time, you will not able to keep up with customer demand. For instance, company want to deliver two features to the market in one week time. But the deployment time (or final assembly time in manufacturing) takes 1 weeks to fully operate with the new changes, which in turn impossible for business to keep up with the market demand. Having feedback loops would allow us to identify which part among the process becomes the constraint and therefor try to minimize the takt time.

Third Way, create culture that foster two things; continual experimentation, taking risk, and learn from failure; and understanding that repetition and practice are prerequisites to mastery.

I would recommend this book highly to people trying to understand higher level thinking in IT business, what those calibre of CEO or VPs think in mind when problem arise, pretty interesting for me. The only downside of this book is that it’s quite hard to read by non-IT people, but if you’re patient enough until every terms are explained that shouldn’t be major problems. Go read!