The Phoenix Project is a narrative about an organization struggling to evolve to compete in the digital economy. It was written for a general, business-oriented audience to help a few vital concepts sink in at all layers of an organization.

The book uses the lens of a factory to transfer the lessons of the industrial revolution & lean manufacturing to the digital era.

The Three Ways

Flow Efficiency Over Resource Efficiency

Thinking of your business as a manufacturing line where value flows from business needs to the customer can help you reduce bottlenecks and misaligned prioritization between organizations.

Flow efficiency is optimizing for an end to end value delivery. How fast are you able to get work from ideation to end-user value? While resource efficiency is thinking in terms of how utilized your current resources are. It seems the human default is to think in terms of resource efficiency. "If I'm busy & working my hardest and so is everyone else... we must be doing all that we can to reach our desired result!"

The insight of optimizing for flow efficiency is that it teaches you to think in terms of the entire system.

Interestingly, this concept is not foreign to engineers. We all know that your app is only as fast as your slowest bottleneck. Sure, your code may be efficient but as long as your connecting to that old legacy database and running that expensive query every request, your ship is sunk. And you're not going to make it faster by ensuring your CPU & memory usage are always peaked (resource efficiency). In fact, throwing more machines might ultimately cause more coordination overhead and flood the constrained resource making matters worse.

In the world of software & machines, this concept is intuitive. If you zoom out a little... to the software makers. You'll find this lens is useful in optimizing how you make the software itself. Optimize for flow efficiency, end to end value delivery.

• Remove constraints in your system
• Reduce work in progress (it creates coordination & context switching overhead)

Another lens is thinking of your business as a flywheel, if any part of the flywheel isn't forwarding the momentum the whole thing comes to a screeching halt! This metaphor is useful over the assembly line because it shows that outputs of the business feedback in as inputs to the business. Farnam Street had a wonderful podcast with Jim Collins, Keeping the Flywheel in Motion on this subject.

Shorten Feedback Loops

Flow efficiency teaches us to optimize for delivering value from the business to the user. The second insight is to shorten feedback loops from the user to business. This sort of thinking was popularized by the Lean Startup methodology.

Mechanisms for shortening feedback loops are sometimes battle-tested best practices. At other times they look more like creative & novel experiments. If we think of our system fractally, zooming in to our constraints & subsystems we can employ different strategies based on the culprit.

For example, we can drastically shorten feedback loops about our business idea by deferring the expensive cost of building an entire project and first conducting market research. Perhaps offering preorders or a marketing site that gathers emails.

We can shorten the feedback loop of specific user experience decisions by first creating high fidelity prototypes and testing them before paying expensive development costs.

Within the product development subsystem itself, we do all sorts of things to shorten feedback loops. Here are some of my favorites, listed in order of optimizing feedback loops from the individual developer experience out to the broader team.

• Editor integrated automated code formatting that reveals syntax errors I would have otherwise waited for the linter or compiler to reveal.
• Linter to reveal syntax and other statically analyzable errors I would have otherwise waited till runtime to discover.
• Type System or a Typed Language to reveal statically analyzable semantic errors I would have otherwise waited till runtime or integration time to discover.
• Write tests that give you immediate feedback as you author your code you otherwise would need to exercise by hand.
• Write end to end tests that exercise the end user's experience that you otherwise would need to wait for a quality assurance team member, or worse, your end-user to discover.
• Continuous Integration shortens the feedback loop I would otherwise need to wait to manually deploy, integrate with the latest code, update dependency versions, etc.
• Production Monitoring means I get insight into my code failing without waiting for users to contact support, and for support to find their way to me.

The book advocates use of a Kanban board for identifying back pressure & discovering constraints in your system. If many tasks spend a lot of time in a specific column, you've got a constraint to address. Generally, I've found Kanban boards to be very effective if everybody on the team is invested in its data integrity & onboard with using it as a tool for improving the flow of work.

In many ways, there is a meta "feedback loop" for improving the improvement of the system. Individual team members know how to shorten loops at their workstation better than the team does. Individuals know how to shorten feedback loops between each other better than the team. The team knows how to improve their interactions & process better than the department. The department leaders, better than the CEO. Ad Infinitum. In the same way that we ought to shorten feedback loops from the end-user to business, perhaps we would benefit to shorten meta feedback loops about the system itself from individual contributors back to the business.

Learning Culture

The last advocation in the book is to create a culture where constant experimentation & feedback is encouraged. Intentionally put tension into the system to reinforce good habits & improve something. Continuous, never-ending improvement, kaizen.

• Safe retrospectives
• Intentionally creating chaos to exercise crisis response processes
• Distributing technical architecture to mitigate the risk of technical decisions

This third way is particularly poignant to me as a tempering force against the first two ways. Often well-intentioned managers trying to improve flow efficiency & shorten feedback loops institute measures to better understand their system. Unfortunately, in the words of Goodhart,

"Any statistical regularity will tend to collapse once pressure is placed upon it for control purposes."

Or said far more idiomatically, by Marilyn Strathern,

"When a measure becomes a target, it ceases to be a good measure."

The culture will be an authoritarian culture of hiding mistakes, blame & fear if people are externally measured & punished. Their measures will look great but their results won't. A learning culture is a safe culture.