Currently Empty: $0.00
DevOps
The Three Ways of DevOps Explained
Legendary Ways Academy · Foundations
The Three Ways of DevOps, Explained Plainly
Flow, Feedback, and Continual Learning: the foundational principles from The Phoenix Project that still define what “doing DevOps well” actually means in practice.
Foundational theory
Real examples
Practical application
“The Three Ways” is the foundational framework behind modern DevOps thinking, introduced in Gene Kim, Kevin Behr, and George Spafford’s book The Phoenix Project and later formalized in The DevOps Handbook. Nearly every DevOps practice you’ll encounter, CI/CD pipelines, monitoring, blameless postmortems, traces back to one of these three underlying principles. Understanding them directly, rather than just memorizing the tools that implement them, is what separates genuinely understanding DevOps from just following a checklist.
The Three Principles
1
Flow
Optimizing the movement of work from development through operations to the customer, left to right. This means eliminating bottlenecks, reducing batch sizes, and making work visible so problems surface early rather than compounding downstream.
2
Feedback
Creating fast, constant feedback loops right to left, from production back to development, so problems are detected and corrected as close to their source as possible, rather than discovered much later.
3
Continual Learning
Building a culture of experimentation and learning from failure, treating incidents as opportunities to improve the system rather than occasions to assign blame to an individual.
How Flow Shows Up in Practice
Flow is why DevOps teams push hard toward smaller, more frequent deployments instead of large infrequent releases. A large batch of changes deployed monthly carries more risk per deploy and makes it harder to isolate which specific change caused a problem when something breaks. Deploying smaller changes more frequently, the core practice behind CI/CD pipelines, directly implements the Flow principle: work moves through the system in smaller, faster, more visible increments rather than large opaque batches.
Flow also explains why DevOps teams invest so heavily in removing manual handoffs and approval gates that don’t add real value. Every unnecessary handoff between teams (a ticket sitting in a queue waiting for a different team’s availability) is friction that slows the movement of work, even when each individual step is fast; the waiting time between steps is often the larger cost, not the work itself.
How Feedback Shows Up in Practice
Feedback is the principle behind monitoring, alerting, and automated testing, all mechanisms designed to surface problems as close to the moment they’re introduced as possible. A test suite that runs on every commit implements Feedback by catching a broken change within minutes rather than after it’s already deployed to production. Production monitoring and alerting, covered in our monitoring and incident response guide, implements Feedback at the next stage, catching issues that testing didn’t, as close to real-time as possible so the team fixing it isn’t working from stale information.
How Continual Learning Shows Up in Practice
Continual Learning is the principle most often missed by teams that adopt DevOps tooling without adopting the underlying culture. Blameless postmortems, a practice where an incident review focuses on what in the system allowed the failure to happen rather than who made the mistake, directly implements this principle. So does dedicating real engineering time to internal tooling and technical debt reduction, treating that investment as compounding value rather than a distraction from “real” feature work. Teams that skip this principle tend to repeat the same category of incident repeatedly, because nobody is systematically extracting and applying the lesson.
Why This Framework Still Matters More Than Any Specific Tool
Tools change constantly in this field; the specific CI/CD platform, monitoring vendor, or cloud provider a team uses today will likely be different in five years. The Three Ways don’t change, because they describe outcomes rather than implementations: reduce the time and friction it takes for work to move through the system, get information about problems back to the people who can fix them as fast as possible, and build an organization that gets systematically better at both over time. Any specific tool or practice is only valuable insofar as it serves one of those three underlying goals.
This is a genuinely useful lens for evaluating a new tool or practice before adopting it: rather than asking “is this tool popular” or “does this look impressive,” ask which of the Three Ways it actually improves, and by how much relative to its cost and complexity. A tool that adds significant operational overhead without clearly improving Flow, Feedback, or Continual Learning is a candidate for skipping, regardless of how well-marketed it is.
Frequently Asked Questions
Do I need to read The Phoenix Project to understand DevOps?
Not strictly required, but it’s widely considered essential context for understanding where modern DevOps thinking originated, told through a business novel format that’s more approachable than a technical manual.
How does this relate to the DevOps maturity model?
The maturity model essentially measures how consistently an organization applies these three principles across its practices; higher maturity levels reflect stronger Flow, Feedback, and Continual Learning.
Which principle should a team focus on first?
Flow is usually the most immediately actionable starting point, since reducing batch size and deployment friction produces visible, fast results that build momentum for the cultural changes Feedback and Continual Learning require.
Is this framework still relevant, or has DevOps thinking moved past it?
Still highly relevant. Newer frameworks and specific practices (SRE, platform engineering) are generally implementations or extensions of these same three underlying principles, not replacements for them.
Related reading: see what a DevOps pipeline actually is, review the DevOps maturity model explained, or check our monitoring and incident response guide for the Feedback principle in practice.