The Three Ways
The Three Ways are fast flow from development into operations, fast feedback that fixes quality at its source, and a culture of continuous learning. Together they describe how work should move through a software delivery system, whatever the stack, team size or decade.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Updated:
Software Engineering 5
Our position. We hold that cheaper development makes engineering discipline more valuable, not less: when everyone can produce code, the advantage shifts to teams that produce the right code, in the right architecture, with the right quality (LinkedIn post (opens in a new tab)). The three ways are that discipline. Cheaper code speeds up one stage of the work, while the First Way judges the performance of the entire system rather than of one silo, and the Second Way shortens and amplifies feedback loops so that corrections can be made continually (The Three Ways: The Principles Underpinning DevOps (opens in a new tab)).
Each way targets a different loss in delivery: work waiting at handoffs, defects that travel far before anyone sees them, and teams that stop getting better.
What does each of the three ways demand?
The Phoenix Project captures how work flows through an organization in three fundamental patterns that hold up regardless of tech stack, team size, or decade.
The First Way: Fast Flow. Understand how to create fast flow of work as it moves from development into operations, because that is what sits between the business and the customer. Every bottleneck, every handoff, every approval gate is friction. Architecture decisions either accelerate or impede this flow. If your architectural boundaries create deployment dependencies between teams, you have failed at the first way.
The Second Way: Fast Feedback. Shorten and amplify feedback loops so you can fix quality at the source and avoid rework. The further a defect travels from its origin before detection, the more expensive it becomes. This is not just about automated tests. It is about information architecture – making the consequences of decisions visible to the people who made them, as quickly as possible.
The Third Way: Continuous Learning. Create a culture that fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to proficiency. This is the hardest one. It requires psychological safety, tolerance for calculated risk, and the organizational patience to let people get better over time rather than demanding perfection on the first try.
These three ways are not a checklist. They are a philosophy of flow. And they only work when the people executing them have internalized the principles behind them – when they don’t need a rule telling them to shorten a feedback loop, because they feel the pain of a long one and know how to fix it.
Related
- The Five Ideals: the daily conditions that make the three ways real.
- Engineering Philosophy: why complex systems need principles rather than rules.
- Architecture Principles: how architectural boundaries speed up or block the first way.
- Agentic continuous delivery: fast feedback when agents write the code.
- Where gains and losses occur: where flow stalls once coding gets faster.
Resources
Articles
- The Three Ways: The Principles Underpinning DevOps (opens in a new tab) - IT Revolution article laying out fast flow, fast feedback and continual learning, the three principles this page describes.
Books
- The Phoenix Project (opens in a new tab) - IT Revolution’s DevOps novel in which the Three Ways first appear, told through an IT manager rescuing a failing project.
Posts
- Ten-dollar development (opens in a new tab) - LinkedIn post arguing that near-free code generation makes architectural discipline and context engineering, not coding ability, the lasting differentiators.