The Three Ways

The Phoenix Project / DevOps Handbook foundational philosophy. Three principles that organize every DevOps practice.

Overview

The Three Ways of DevOps

The Three Ways are the foundational organizing principles of DevOps. They were articulated in The Phoenix Project (Kim, Behr, Spafford, 2013) and codified in The DevOps Handbook (Kim, Humble, Debois, Willis, 2016; 2nd ed. 2020). Every DevOps practice, from CI/CD and observability to blameless postmortems, chaos engineering and error budgets, applies one or more of them.

First: Flow — Left to right — Optimize the whole value stream — Lead time from commit to production
Second: Feedback — Right to left — Amplify and shorten feedback loops — How fast a bad commit surfaces
Third: Learning — Continual — Generative, high-trust culture of experimentation — Improvements that actually ship

The First Way: Flow

Optimize the entire value stream from concept to production. The unit of optimization is the SYSTEM, not individual silos (dev, QA, ops).

Batch sizes, handoffs, queues, wait times, rework — Trunk-based development, continuous integration, automated deploys, small-batch releases, infrastructure-as-code

> [!NOTE] Handbook: "We must always seek to increase the flow of work from Development to Operations."

The Second Way: Feedback

Amplify and shorten feedback loops from production back to development. Make problems visible while they are cheap to fix, and catch defects at the earliest possible stage.

Telemetry everywhere; observability (logs, metrics, traces); automated testing; fail-fast deployment gates; customer feedback loops; blameless postmortems

> [!NOTE] Handbook: "We need a constant flow of fast feedback at all stages of our value stream." If a bad commit takes a week to surface, it took too long.

The Third Way: Continual learning and experimentation

Build a culture that allocates time to improving daily work, rewards risk-taking, and treats failures as learning opportunities.

Blameless postmortems, game days, chaos engineering, "20% time", cross-team improvement kata, communities of practice, public learning artifacts

> [!NOTE] Handbook: "We need to create a generative, high-trust culture that supports a dynamic, disciplined, scientific approach to experimentation."

Why the order matters

> [!IMPORTANT] The Three Ways describe the SOCIO-technical system, not just tools. A pipeline without trust between dev and ops is not Flow; it is "automation around the silos." DevOps is a culture change that tools enable, not a tooling change that culture follows.

Key concepts

First Way — Flow: Optimize the entire value stream from concept to running in production. The system view, not the silo view. Reduce batch sizes; eliminate handoffs and queues. Trunk-based dev, CI, deploy automation, IaC are all First Way practices.
Second Way — Feedback: Shorten and amplify feedback loops from production back to development. Make defects visible while cheap. Telemetry, observability, fast tests, deployment gates, blameless postmortems. The metric: time from defect introduction to detection.
Third Way — Continual Learning: Generative high-trust culture that allocates time to improvement and treats failure as data. Game days, chaos engineering, communities of practice, postmortem follow-through, kata sessions. Without it, the first two ways stagnate.
Generative culture (Westrum): The third pillar — Ron Westrum's organizational typology distinguishes Pathological (power-driven, hide failure), Bureaucratic (rules-driven, silo defense), and Generative (mission-driven, share information). DevOps research (Accelerate) shows Generative cultures predict software performance.
Value stream: The full sequence of activities from idea to value delivered to a user. Including code, build, test, deploy, run, learn. Lead time = time from commit to running in production. The unit of optimization for the First Way.
Tools enable culture, not the other way around: A common DevOps anti-pattern is "we bought Jenkins so we're doing DevOps." The DevOps Handbook is explicit: tools are necessary but not sufficient. Without trust, shared accountability, and the Three Ways, tools just automate dysfunction faster.

When to use it

Explaining DevOps to leadership — the Three Ways are the right vocabulary, not "we have CI/CD"
Diagnosing why a DevOps transformation is stalling (usually one of the Three Ways is being skipped)
Designing the org's DevOps capability roadmap — Flow → Feedback → Learning is the natural order
Postmortems and retrospectives — "which of the Three Ways did we fail at?"

Interview questions

Walk me through the Three Ways and how each shows up in practice.
Why is "we bought Jenkins, so we're doing DevOps" a misconception?
What does Westrum's organizational typology have to do with the Three Ways?
How would you diagnose a stalled DevOps transformation using the Three Ways?