August 22, 2012
The Three Ways: The Principles Underpinning DevOps

In this blog post, I talk about the “Three Ways,” which are the principles that all of the DevOps patterns can be derived from, which we’re using in both The DevOps Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. We assert that the Three Ways describe the values and philosophies that frame the processes, procedures, practices of DevOps, as well as the prescriptive steps.
It has been especially fun working on this with fellow co-author Mike Orzen, the most recent winner of the cherished Shingo Prize for his contribution to operational excellence for his book “Lean IT.”
The Three Ways are as follows. In a future blog post, I’ll describe the DevOps patterns that can be derived from each.
The Three Ways
- The First Way: Flow/Systems Thinking
- The Second Way: Amplify Feedback Loops
- The Third Way: Culture of Continual Experimentation and Learning
The First Way: Flow/Systems Thinking
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
The focus is on all business value streams that are enabled by IT. In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.
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, and always seeking to achieve profound understanding of the system (as per Deming).
Read a deeper dive on The First Way here.
The Second Way: Amplify Feedback Loops
The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.
The Third Way: Culture of Continual Experimentation and Learning
The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
We need both of these equally. Experimentation and taking risks are what ensures that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone. And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.
The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.
In my follow-up book, The Unicorn Project, I revisit Parts Unlimited and describe my learnings through the Five Ideals.
In IT Revolution’s latest novel, travel to Investments Unlimited to discover how DevOps can be applied to Security, Audit, and Compliance.
Leave a Comment
More Like This
Creating Joint Ownership of Outcomes Between Business and IT
Moving beyond mutual understanding, true business-IT partnership requires shared ownership of outcomes. This means…
Building Shared Understanding and Trust Between Business and IT
The foundation of any effective business-IT partnership is shared understanding and mutual trust. Without…
Vibe Coding Workshop For Leaders (September 2025, ETLS Vegas)
As you know, I’ve been working with Steve Yegge (famous for his 20+ years…
Why the Business-IT Gap Exists and How to Begin Closing It
The divide between business and IT has been a persistent challenge in organizations for…
14 Comments
Pingback: Overwhelmed by Ambiguity: DevOps, Innovation, and the Search for Clarity with Daniel Lemire (3/4)
Pingback: Reflecting on 15 Years of Books: A Journey Of DevOps, Organizational Wiring, and So Much More! - Alireza Gharib Blog
Pingback: The Three Ways – IT Blog
Pingback: DevOps Handbook with AI Agents: Transforming Automation and Efficiency
Pingback: What is a Value Stream Network? - sdrefocus.com
Pingback: Case Study: AO.com Builds Single Customer View with MongoDB — SitePoint
Pingback: Le DevOps, une philosophie ou un métier ? Blog Devoteam Revolve
Great! your research appreciated thanks for great
The Phoenix Project book has had a profound effect on how I approach work. I learned to simultaneously building quality & the desired functionality into a product as it’s developed. Drastically reducing rework and saving time in the long run. Those savings can be reinvested into the product to improve it even more. It’s a virtuous cycle where everybody wins.
Your emphasis on not passing known defects downstream in the First Way resonates significantly. It brings to mind a recent scenario in our team where a tiny bug, overlooked in the development stage, morphed into a monstrous issue in production. It was like passing the baton in a relay race, only the baton was a ticking time bomb! This experience was a live tutorial on the importance of addressing issues head-on, rather than playing hot potato with defects.
Pingback: Migrarse a la nube es un cuento viejo - Tech and Solve
Highly Indebted details....Appreciate your share Gene.
Great! your research is appreciated by our Team. Keep it up. Keep updating this post on time.
Great! your research is appreciated by our Team.