Book review: The Phoenix Project

Recently read The Phoenix Project – excellent story. This book centers around a company’s transformation from a dysfunctional organization to one uses technology effectively. There are many good lessons for anyone working in technology. The book reflects (though perhaps exaggerated a little) the common realities of working in the tech world. Many comparisons are made to manufacturing processes which is a highly optimized science today – something I’ve witnessed in my occasional visits to the Industry 4.0 Discord sever. It seems IT (and I would lump product development and most knowledge work into that as well) is still an immature science – at least in most organizations.

Some Notes/Quotes:

  • we’ve been meaning to upgrade that SAN firmware for years …
  • (ops have a) deep suspicious of developers breaking things, then disappear
  • only thing more dangerous than a developer is a developer conspiring with security
  • everyone things that the real way to get work done is to just do it
  • for years I’ve been trying to get people to use our change management process and tools
  • three management movements
    • theory of constraints
      • improvements made anywhere besides the bottleneck are an illusion
    • lean production
    • total quality management
  • your job as VP of IT operations is to ensure the fast, predictable and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service.
  • control the release of work … ensure that your most constrained resources are doing only the work that serves the entire system, not just one silo.
  • four types of work
    • business projects
    • internal projects
    • changes
    • unplanned work
  • work center: machine, man, method, measure
  • repetition creates habits and habits are what enables mastery. Studies have shown that practicing 5 minutes daily is better than practicing once a week for three hours
  • our goal is to maximize flow
  • everyone needs idle or slack time. If no one has slack time, WIP gets stuck in the system
  • in any system of work, the theoretical ideal is a single-piece flow, which maximizes throughput and minimizes variance. You get there by continually reducing batch sizes.
  • the flow of work goes in one direction only: forward
  • learning is not compulsory … neither is survival. – Deming
  • without a doubt, the best times for technology are ahead of us, not behind us. There’s never been a better time to be in the technology field, and to be a lifelong learner.
  • 3 ways:
    • flow - quickly stuff moves quickly from left → right
    • feedback - shared from right → left
      • shared goals means shared pain
    • culture of continuous experimentation and learning, habits, repetition → mastery

A few more quotes:

  • Improving daily work is even more important than doing daily work.
  • Being able to take needless work out of the system is more important than being able to put more work into the system
  • We need to create a culture that reinforces the value of taking risks and learning from failure and the need for repetition and practice to create mastery.
  • until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.
  • Left unchecked, technical debt will ensure that the only work that gets done is unplanned work!
  • Remember, outcomes are what matter — not the process, not controls, or, for that matter, what work you complete.