Are you tired of late-night pages, deployment failures, and the constant friction between Development and Operations?
If you’ve been following our 51-Day journey through The DevOps Handbook, you know the “Why” (Day 1) and the “Core Conflict” (Day 2). But today, we stop talking about the problem and hand you the solution.
This is Day 6, and we are unveiling the “Grand Unified Theory” of DevOps.
Gene Kim, Jez Humble, Patrick Debois, and John Willis didn’t just write a list of tips; they codified a philosophy known as The Three Ways. These are not just rules; they are the foundational principles that separate elite performers (like Amazon, Netflix, and Google) from the rest of the pack.
If you understand these three concepts, you understand the entire DevOps movement.
The Core Philosophy: What Are The Three Ways?
The “Three Ways” are the principles that underpin all DevOps patterns. Whether you are automating a deployment pipeline or running a blameless post-mortem, you are applying one of these three ways.
- The First Way: Flow (System Thinking)
- The Second Way: Feedback (Amplification)
- The Third Way: Continual Learning (Experimentation)
Let’s dive deep into each one.
The First Way: The Principles of Flow
Direction: Left-to-Right (Development → Operations → Customer)
The First Way is all about speed and system thinking. It focuses on the fast, smooth flow of work from Development (where value is created) to Operations (where value is delivered) and finally to the Customer.
In a traditional “siloed” organization, work passes through the system in giant batches. It gets stuck waiting for tickets, waiting for approvals, and waiting for “integration windows.”
The First Way asks: How can we make work visible and reduce the time it takes to go from “Idea” to “Production”?
Key Outcomes of The First Way:
- Small Batch Sizes: Moving away from massive quarterly releases to daily (or hourly) deployments.
- Limit Work in Process (WIP): Stop starting, start finishing.
- Never Pass Defects Downstream: Fix problems immediately rather than passing a broken build to QA or Ops.
- System Thinking: Optimizing the whole global system, not just making one person’s job faster while creating a bottleneck for someone else.
Viral Takeaway: Speed isn’t dangerous. In DevOps, speed is safety. The faster you flow, the smaller the changes, and the less likely you are to break the system.
The Second Way: The Principles of Feedback
Direction: Right-to-Left (Customer/Ops → Development)
If the First Way is about speed, the Second Way is about steering.
The Second Way focuses on creating reciprocal, fast, and constant feedback loops from the right (Ops and Customers) back to the left (Development and Product).
In the old world, developers would write code, throw it “over the wall” to Ops, and never hear about it again unless the site crashed. They had no idea if their features were being used or if their code was causing server fires at 3 AM.
The Second Way asks: How can we amplify feedback so developers see the consequences of their code immediately?
Key Outcomes of The Second Way:
- Telemetry everywhere: Dashboards that show real-time metrics.
- “Swarming” on problems: When the “Andon Cord” is pulled, everyone stops to fix the issue.
- Developers on Pager Duty: The quickest way to fix bad code is to have the person who wrote it wake up when it breaks.
- A/B Testing: Getting feedback from customers on whether a feature is actually useful.
Viral Takeaway: You can’t improve what you can’t measure. The Second Way ensures that if something breaks, you know about it before the customer does.
The Third Way: The Principles of Continual Learning
Direction: Cyclical (The Cultural Layer)
The First and Second Ways are largely technical. The Third Way is cultural.
It focuses on creating a high-trust culture that supports dynamic, disciplined, and scientific experimentation. It recognizes that in a complex system (like modern IT), we cannot predict everything. Therefore, we must learn to adapt.
This requires two things that usually scare traditional managers: Risk-taking and Learning from Failure.
The Third Way asks: How do we create a culture where it is safe to fail, provided we learn from it?
Key Outcomes of The Third Way:
- Institutionalized Improvement: Reserving time (like 20% of cycles) just to improve daily work.
- Blameless Post-Mortems: When accidents happen, we look at the process, not the person. We don’t fire people for mistakes; we fix the system so the mistake can’t happen again.
- Injecting Faults: Purposefully breaking things (like Netflix’s Chaos Monkey) to practice resilience.
Viral Takeaway: The best organizations aren’t the ones that never fail. They are the ones that learn from failure the fastest.
The Journey Has Just Begun
Understanding The Three Ways is the “Red Pill” moment of your DevOps journey. Once you see the world through the lens of Flow, Feedback, and Learning, you can never go back to the old way of working.
For the next 45 days of this series, we are going to deep dive into exactly how to implement these three ways. We’ll cover everything from Value Stream Mapping and Deployment Pipelines to Chaos Engineering and Blameless Post-Mortems.
Stick around. We are just getting started.
Keep the flow going! If this explanation of The Three Ways clicked for you, share this post with your team and let us know: Which of the Three Ways is your organization struggling with the most?
