I really enjoyed reading “The Phoenix Project”. It joins “Peopleware” on the list of books I wish every IT manager would read. I found the narrative style very engaging. I wish more “tech” books were written like this. There were times where it dragged and I wished they would get to the point, but the characters and scenarios were so relatable that I forgave it. My biggest criticism would be the dramatic changes in character that occur in the come-to-jesus meeting - several toxic personalities see the error of their ways and behave totally differently the rest of the book. A bit unrealistic :)

My notes and observations from the book:

  1. In chapter 3, a major outage is caused by a developer rushing through an urgent change right before going on vacation. I had to laugh when reading this, since I’ve seen this exact thing happen on at least 2 occasions, both times by very good developers who should have known better! Rushing is a indicator of a bad process. It causes so much grief and misery!

  2. Bill, our protagonist, lays out the archetypal doomed waterfall IT project: A looming deadline that business insists cannot be pushed, and a development team that runs behind schedule and sucks up testing and deployment time. Heroic risks are taken, some of which inevitably fail and you are left with an unstable product mired in tech debt.

  3. There is a great line on page 58 where Bill makes the point that if you want to change practices, it has to start from the top. If you want your team to show up to meetings on time prepared, write good commit messages, write clean code, etc - you, the boss, need to do that as well. Sometimes it is tempting to exempt yourself from the rules because, hey, I’m the important, busy boss. But rest assured it is noticed and emulated by your team.

  4. Theory of Constraints: improvements made anywhere besides the bottleneck are an illusion.

  5. I made a note on page 108 that ties into my criticism: the root of all the problems the team is facing is people problems. There are several toxic personalities on board and many of the problems spring out of turf guarding and ladder climbing. This isn’t a people skills book, so I guess it’s understandable that this side of the issue is glossed over. But it is jarring to see most of these issues magically disappear halfway through the book.

  6. If you want to be able to say “No, we don’t have the bandwidth for this task” you have to first have some hard numbers to back that up. Which means you need to track all work in progress on your team.

  7. Bill makes a great metaphor: poor quality software is like a free puppy: “It’s not the upfront capital that kills you, it’s the operations and maintenance on the back end”

  8. “Unplanned Work” is the great deadline killer: destructive and avoidable. Tech debt leads to unplanned work.

  9. “A great team doesn’t mean that they had the smartest people, What made those teams great is that everyone trusted one another. It can be a powerful thing when that magic dynamic exists” - Agreed! Point 3 is a great way to build that trust. There is a wonderful “subplot” where Bill refuses to jump himself to the front of the replacement laptop queue and suffers for some time with an ancient, malfunctioning laptop - and he does it for the sake of following his own rules. Way to go Bill!

  10. Having developers who are flexible and cross-trained helps ease and prevent bottlenecks.

  11. “Improving daily work is even more important than doing daily work. It almost doesn’t matter what you improve, as long as you are improving something. Why? Because if you are not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors, zero work related accidents, zero loss”

  12. It is critically important to systematically track work
    1. So we can build data-backed schedules
    2. So we can prioritize the work
    3. To prevent “drive by work assignments” distracting team members

  13. The First Way: Reduce cycle time - favor smaller, more frequent releases

  14. The Second Way: Amplification of feedback loops - correct problems more quickly. Feedback can come from automated tests or customers.

  15. The Third Way: Create a culture that fosters continual experimentation and learning and practice

  16. One of the benefits of continuous delivery is that it increases the business value of the software system by getting it in front of users faster.

  17. A “deployment pipeline” is your entire value stream from code check-in to production.