The Phoenix Project

First let me start by saying that this is not a book review, my intention is to share some of the most insightful thoughts and ideas in the book The Phoenix Project and reinforce that this should definitely be a must read to everyone working in the software industry (but not only), from individual contributors to leaders and executives.

The book uses the same approach as The Goal from Eliyahu M. Goldratt and tells the story of a company in trouble and how an IT Manager (Bill) has 90 days to fix the continuing delays and problems of the already over-budgeted Phoenix Project, which is critical to the company, otherwise the company will be sold in parts and IT will be outsourced.

One of the interesting things mentioned in the book is the 4 types of work: business projects, internal projects, changes (maintenance of every tech system) and unplanned work – this last one mentioned as the most destructive force in any company and therefore should be avoided/tackled by any means necessary.

The Three Ways

One of the core ideas of the book is The Three Ways, a result of the interactions between Bill (the main character, who was promoted to VP of IT Operations) and Erik (a Board candidate and experienced Tech Leader) that serves as a kind of Yoda figure in the story. The three ways mentioned establish the necessary steps to ensure success across all projects:

• The First Way – Flow (Systems Thinking)
  • It’s all about having a holistic view of the value stream,  from requirements to shipped software to customers, or as they call, “it’s all about left to right“
  • This enables assessment on the performance of the entire system – fast flow of work and it allows to apply known Lean principles, like monitor WIP
  • Focus is on all business value streams enabled by IT
  • The outcomes of putting the First Way into practice include:
    • never passing a known defect to downstream work centers
    • never allowing local optimization to create global degradation
    • always seeking to increase flow
    • always seeking to achieve profound understanding of the system
• The Second Way – Feedback (Amplify Feedback Loops)
  • Understanding and responding to all customers, internal and external
  • Shortening and amplifying all feedback loops
  • Embedding knowledge where you need it
  • Eradicate largest sources of unplanned work
• The Third Way – Experimentation and Learning (Culture of Continual Experimentation and Learning)
  • Creating a culture that fosters two things:
    • Continual experimentation, which requires taking risks and learning from success and failure
    • Understanding that repetition and practice are the prerequisites to mastery, reinforcing a culture of operational rigor and discipline
  • The outcomes of the Third Way include
    • allocating time for the improvement of daily work
    • creating rituals that reward the team for taking risks
    • introducing faults into the system to increase resilience
  • There’s a school of thought that says how high performers win in the marketplace is because they out-learn the competition, or as Andrew Shafer said:

You’re either a learning organisation or you’re losing to somebody who is.

Beyond the Phoenix Project

Mastering the Three Ways is essential to enable a DevOps mindset – something that the author Gene Kim has been a long time advocate. This is one of the topics discussed in Beyond the Phoenix Project which states that in order for technology to help organisations win in the marketplace, they have to respond to urgent business needs. That means being able to ship changes ever more quickly, but also ensuring world-class reliability, security, and stability.

Another important topic is the notion of technology value streams and how to create “an isomorphic mapping between the Lean principles as applied to manufacturing and the Lean principles as they applied to the entire technology value stream“.

The dysfunctional marriage

In the last chapter there’s an interesting event (SPOILER alert!), Steve (the CEO) offers Bill the position of COO acknowledging that is better to bet on successful IT leaders to acquire business skills and know-how than the other way around, mostly due to IT’s increasing complexity and to tackle the relation between IT and the Business (which is characterised as “a dysfunctional marriage – both feel powerless and held hostage by the other“). This decision brings a new way of thinking about this relationship and the way companies can/should be structured:

A dysfunctional marriage assumes that the business and IT are two separate entities. IT should either be embedded into business operations or into the business. Voilà! There you go. No tension. No marriage, and maybe no IT Department, either.

Or as the own author said:

In ten years, I’m certain every COO worth their salt will have come from IT. Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.