Library→Foundations→The Three Ways
The Three Ways
Gene Kim's framework for DevOps thinking. The principles that underpin every tool and practice in this library.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
The origin
Gene Kim introduced the Three Ways in The Phoenix Project (2013) through the character of Erik Reid — a mysterious mentor who teaches the protagonist a framework for thinking about IT operations as a manufacturing and flow problem. The DevOps Handbook (2016) expanded this into a full treatment of principles and practices.
The Three Ways are not a methodology or a certification. They are a way of thinking — a lens for diagnosing why software delivery is slow or unreliable, and a vocabulary for describing what good looks like.
Flow
Left to right
Fast, smooth delivery from Dev to Ops to customer. Maximize throughput, minimize WIP.
Feedback
Right to left
Fast, amplified feedback at every stage. Problems surface immediately — not at the end.
Continual Learning
Across the system
Turn failures into improvements. Generate organizational knowledge. Experiment and adapt.
First Way: Flow
The First Way is about maximizing the flow of work from left to right — from business need, through development, through operations, to the customer. It draws directly from lean manufacturing: identify the value stream, eliminate waste, reduce batch sizes, prevent defects from passing downstream.
Business
Dev
Ops
Customer
Make work visible
You cannot improve what you cannot see. Kanban boards, pipeline dashboards, and deployment metrics all make flow visible.
Limit WIP
Work in progress is inventory. Inventory is waste. Limiting WIP forces focus and exposes bottlenecks.
Reduce batch sizes
Small changes deploy faster, fail less catastrophically, and are easier to debug. Trunk-based development and CI enforce this.
Eliminate waste
Rework, waiting, context switching, unnecessary approvals — every form of waste lengthens the value stream without adding value.
Second Way: Feedback
The Second Way is about creating fast feedback loops from right to left — from production back to development, from testing back to coding, from operations back to architecture. Every problem should be caught as close to its source as possible and as quickly as possible.
In complex systems, feedback is what enables safety. Without fast feedback, problems accumulate silently until they cause catastrophic failure. The Second Way is why monitoring, alerting, automated testing, and code review all matter.
At commit time
Pre-commit hooks catch lint errors and failing unit tests before the code leaves the developer's machine.
In CI
The build runs the full test suite. A broken build notifies the team within minutes of the offending commit.
In staging
Integration tests and acceptance tests run against a production-like environment. Problems surface before users see them.
In production
Metrics, logs, and alerts detect anomalies within minutes of deployment. On-call knows before users complain.
The goal of the Second Way is to make feedback so fast and so complete that every developer knows within minutes whether their change improved or degraded the system. Slow feedback is no feedback.
Third Way: Continual Learning and Experimentation
The Third Way is about creating a culture of continual learning — turning failures into improvements, converting local discoveries into global knowledge, and creating time for the team to improve the system it works in.
This is the most organizationally difficult of the Three Ways, because it requires psychological safety and a willingness to treat failures as learning opportunities rather than occasions for blame.
Blameless post-mortems
When things go wrong, the goal is to understand the system — not to find a scapegoat. What was the failure mode? What assumption was wrong? How does the system change?
Game days
Deliberately inject failure to practice recovery. Teams that have practiced failure are not surprised by it. Chaos engineering is the most mature expression of this.
Improvement kata
Reserve time each sprint for improvement work — not features, not bugs, but making the system better. Without deliberate allocation, improvement never happens.
The Three Ways in the Nexus Corp missions
Every Nexus Corp mission maps to one or more of the Three Ways. The progression is not accidental — you build flow first, then feedback, then the organizational conditions for learning.
Further reading
The DevOps Handbook — Kim, Humble, Willis, Debois
Part I: The Three Ways. The definitive treatment of the framework, with extensive examples and research backing.
The Phoenix Project
The novel that introduced the Three Ways. Bill's journey from firefighting to flow is the Three Ways as narrative.
Accelerate — Forsgren, Humble, Kim
The DORA research. The Three Ways as measurable predictors of organizational performance.
The Unicorn Project
The sequel to The Phoenix Project. Introduces the Five Ideals — a complementary framework focused on developer experience.