# The Phoenix Project: the novel that teaches FDEs to see incidents from the operations side > An unapproved change means employees are not paid on time. From there, Gene Kim, Kevin Behr and George Spafford build a lesson about the flow of work that every FDE will meet again at a customer site. Original: https://fdetimes.net/en/books-courses/phoenix-project-book-review-fde/ The book begins with employees not being paid on time. An unapproved change has brought down the payroll system at Parts Unlimited. Anyone who has been at a customer on the day production fails will recognise the scene. *The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win* is by Gene Kim, Kevin Behr and George Spafford, and was first published by IT Revolution on 10 January 2013. It is written as a novel, but what it teaches is how operations work. The case for FDEs reading it is simple. Most of your time at a customer is spent inside someone else's systems, with someone else's operations team, following someone else's change process. The book helps you understand why they are slow and what you can do to help. ## One good engineer can block a whole system The protagonist is Bill, an IT manager. The CEO gives him 90 days to clean up the mess, or the whole department will be outsourced. The publisher presents the book as a place to learn the Three Ways and the Theory of Constraints, two founding principles of DevOps. John Willis calls it a modern version of *The Goal*, Goldratt's novel about the Theory of Constraints. This article covers only the First Way and the Second Way, the two an FDE runs into most at a customer; the Third Way is out of scope. The three ideas worth keeping below are not the Three Ways either: two build on the first two Ways, and the third comes from change control. The most memorable character is Brent. IT Revolution's official summary describes him as a brilliant but overloaded engineer. Because he is constantly pulled into firefighting, Brent's expertise becomes the bottleneck for the entire organisation. The character Erik offers advice: reduce work in progress (WIP) to improve efficiency and throughput. Put next to Brent, the advice becomes concrete. If every task has to pass through him, each new task released only joins the queue in front of him, and nothing finishes any faster. Reducing WIP therefore means stopping the practice of pushing work in faster than the bottleneck can process it. That is also the spirit of the First Way as Gene Kim summarises it: look at the performance of the whole system, not of individual silos. Sandor Dargo, an engineer who has written about the book, repeats the factory lesson: keep the amount of work in progress small. Picture a situation. The customer's data team has one person who understands the legacy pipeline, and ten tickets are waiting for that person. Opening an eleventh ticket for your integration only makes the queue longer. Do the opposite: write down what that person knows as documentation, then do yourself the part you can do without them. ## Where does unplanned work come from? The publisher's page emphasises the four types of work. According to Dargo, the first two are business projects and internal IT projects. They generate changes, and changes are usually tracked in a ticketing system. The fourth type is unplanned work, defined as urgent, reactive work that cuts into planned work and slows progress. The payroll outage shows where unplanned work usually starts: an unauthorised change. Bill then sets up a Change Advisory Board (CAB) to review and approve changes to IT systems. The chain of cause and effect worth remembering is this. Uncontrolled changes come back as unplanned work, and that work lands on people like Brent, the very bottleneck that was already overloaded. For FDEs, one thing is worth doing early. In your first week at a customer, ask about their change approval process before you deploy anything. If you cause the next payroll outage, the customer will stop trusting you. ## Feedback has to flow back to the people writing the code The Second Way is about creating feedback loops from right to left, that is, from operations back to development. FDEs sit exactly at this junction. You see how the product breaks in a real environment; the product team at headquarters does not. When an incident at a customer is over, do not stop at the point where the system is running again. Write the core team a short note in three parts: which change caused the incident, how long it took to detect, and what should be fixed in the product so the next one does not need firefighting. **Key point:** Adding work to a bottleneck only makes the queue longer; it does not make work finish faster. ## What order to read in, and how to put it on a CV Tim O'Reilly wrote that everyone who has ever worked on a failed IT project should be forced to read this book. The advice goes a little far, but if you have lived through a project that went wrong, many scenes will feel uncomfortably familiar. Read *The Phoenix Project* first, because the novel format is easy going. Gene Kim names *The DevOps Handbook* as the place where the Three Ways are applied further, so that is the second book. Leave *The Goal* until last, if you want to see how the idea of flow came out of manufacturing. On a CV, do not write something generic like "Experience in operations and DevOps". Describe specific work, for example: "Wrote runbooks for a legacy pipeline that only one of the customer's engineers understood, so their team could handle common incidents on their own." That sentence shows a recruiter that you can spot a bottleneck and remove it. If you have real numbers on tickets or waiting times before and after, add them. Bill had 90 days to save the IT department. An FDE usually has less time to win a customer's trust, and the fastest way is still not to become an unapproved change. **Try this week:** - Log everything you do for five days, split into planned and unplanned work, then work out the share of each - At your current customer, find their 'Brent': the person every incident ends up calling. Write down three things only that person can do - Set a personal WIP limit: no more than three unfinished tasks at once, held for a week ## Sources - [The Phoenix Project (IT Revolution)](https://itrevolution.com/product/the-phoenix-project/) - [The Three Ways: The Principles Underpinning DevOps (IT Revolution)](https://itrevolution.com/the-three-ways-principles-underpinning-devops/) - [10-Minute Summary of The Phoenix Project](https://itrevolution.com/articles/10-minute-summary-of-the-phoenix-project/) - [The Phoenix Project by Gene Kim (Sandor Dargo)](https://www.sandordargo.com/blog/2021/08/28/the-phoenix-project-by-gene-kim)