Gene Kim's "Three Ways," from The Phoenix Project, gets cited constantly and read carefully rarely. Most teams absorb it as "flow good, feedback good, culture good" and move on — which is a shame, because the actual structure is a sequence with a specific logic, not three independent virtues to sprinkle in. Skipping the order is why a lot of DevOps adoption stalls at "we have a pipeline now" and never gets further.
The First Way: Flow
The First Way is about the left-to-right movement of work — from a developer's laptop through build, test, and deploy, to production. The goal is to make that flow fast and visible, and to never let local optimization at one stage slow the whole system down.
This is the part every team adopts first, because it's the part with the most obvious tooling: CI/CD pipelines, containerization, infrastructure as code. It's also the part that produces the most visible wins early — a deploy that took two days now takes twenty minutes — which is exactly why teams stop here. The dashboard looks good. The problem is flow alone only tells you how fast you can ship something. It says nothing about whether what you shipped was any good, or whether the system can tell you if it wasn't.
Note
A fast pipeline that ships a bad change quickly is not progress. It's the same failure, delivered faster. Flow without feedback is acceleration without a steering wheel.
The Second Way: Feedback
The Second Way is the right-to-left loop — production telling you, quickly and clearly, what actually happened after a change went out. This is where observability, monitoring, and alerting live, and it's also where most of the actual engineering difficulty sits, which is probably why it gets adopted second and half-heartedly.
Feedback has to be fast to be useful. A monitoring dashboard that would have shown you the problem, if you'd thought to look at it three days later during a retro, isn't feedback — it's an archive. The Second Way is specifically about shortening the distance between "something went wrong" and "the person who can fix it knows."
Teams that get flow right but skip feedback tend to look, from the outside, like they're moving fast. From the inside, they're shipping into a void — every deploy is a bet, and nobody finds out if it lost until a customer says something.
The Third Way: Continuous Learning
This is the one that gets skipped most often, because it's the least tool-shaped. The Third Way is about building a culture where experimentation is safe, where failures turn into institutional knowledge instead of blame, and where the organization actually gets better at its own practices over time — not just better at shipping the same practices faster.
Concretely, this looks like blameless postmortems that produce real action items, time genuinely allocated for improving tooling rather than only shipping features, and psychological safety high enough that someone says "I think this is going to break" before it breaks, not just in the retro after.
Why the order matters
You can't productively practice the Third Way without the Second — you have nothing to learn from if you have no feedback signal. And the Second Way is much less valuable without the First — fast feedback on a process that takes three weeks to ship a fix is still a three-week fix. The ways compound. They don't substitute.
Where most teams actually are
| Way | What it requires | Common state |
|---|---|---|
| Flow | CI/CD, IaC, deployment automation | Usually adopted first, often adopted well |
| Feedback | Observability, alerting, fast on-call loops | Partially adopted — dashboards exist, nobody trusts them |
| Continuous Learning | Blameless postmortems, protected improvement time | Rarely adopted with real follow-through |
If your organization has invested heavily in pipelines and containers but incidents still feel like archaeology and postmortems still produce zero action items that get done, you haven't finished adopting DevOps — you've adopted a third of it, the third with the best tooling market. The other two-thirds are cultural, harder to buy, and where most of the actual reliability and velocity gains are still sitting unclaimed.
