The Three Ways and the CALMS model
Summary: two reading grids structure all DevOps practice. Gene Kim's Three Ways describe what needs to be improved: flow, feedback, learning. The CALMS model describes the five dimensions to assess in an organization. This lesson explains both, with the concrete pitfalls of each.
1. The Three Ways — overview
The order is not arbitrary, and this point is often misunderstood. Start with flow: without the ability to deliver quickly, everything else is theoretical. An organization that sets up sophisticated monitoring while it takes three weeks to deploy a fix has built an excellent alarm system on a door it cannot open.
2. First way — flow
Principle 4 is the one that prevents wasting months of effort. The theory of constraints establishes that improving a step that is not the bottleneck improves nothing about total throughput.
A concrete and very common example: you invest so your tests go from twenty to five minutes. Excellent. But if your production deployment requires a weekly committee approval, your actual lead time remains seven days. You saved fifteen minutes out of a seven-day delay. The constraint was the committee, not the tests.
The correct approach: map the complete journey of a change, measure the time spent at each step including waits, and attack the longest one. It is often an administrative step, not a technical one.
Principle 2 is the simplest to apply and yet the most effective. Reducing batch sizes requires no tool, no budget, no permission. It is a decision.
3. Second way — feedback
Principle 3 is a major cultural reversal. In the classic industrial model, a quality control department inspects the finished product. In DevOps, you equip whoever produces so that they cannot create a defect without seeing it immediately.
Concretely, this means: automated tests that the developer runs themselves, security analyses in their editor, a local environment faithful to production. Quality becomes a property of the process, not an inspection step.
Principle 4 makes the direct link with observability. A developer who never sees production dashboards works blind: they do not know whether their code is slow, whether it generates errors, whether their logs are usable. See our observability course.
4. Third way — continuous learning
Principle 1 conditions all the others. In an organization where reporting a problem exposes you to blame, problems are not reported — they are hidden until they become incidents. No tool compensates for the absence of psychological safety.
Principle 4 is the one that fails most often in practice. A team dedicated 100% to urgent requests will never improve, because improving requires time it does not have. The solution is to explicitly reserve a share of capacity — 20% for instance — for debt reduction and automation. If that time is not protected, it will be consumed.
Principle 5 is the simplest to verify and the most often neglected. Ask the question in your team: "when did we last test a backup restore?". The answer is often embarrassing.
5. The CALMS model
The typical diagnosis revealed by CALMS: most organizations score well on A (automation) and poorly on C (culture). They have all the tools, pipelines everywhere, and the wall between development and operations is intact.
That is precisely why their transformations fail. Automation without a change in responsibility produces an automated wall — the code is thrown over it faster, that's all.
The S dimension is the most profitable and the least practiced. A team that documents what it learns advances the whole organization. A team that keeps its knowledge in the heads of three people creates a dangerous dependency — and loses everything when they leave.
6. Using CALMS as a diagnostic
The most revealing question in the Culture dimension is the one that seems innocuous: "can a developer say a deadline is unrealistic without negative consequences?". If the answer is no, you do not have psychological safety — and therefore no DevOps culture, whatever your tools.
For the Measurement dimension, the test is immediate: if you cannot state your average lead time between approval and production, you are not measuring. And without measurement, you will never know whether your efforts produced any result.
7. Where to start
The most important advice in this lesson: start by measuring, before changing anything. Without a reference point, you will be unable to demonstrate your progress to your leadership, or to know whether a decision was beneficial. It is the most common mistake in transformations: six months of activity without being able to prove any result.
And work on culture from the start, even if the effects are slow. It is the dimension that takes years — starting with it last guarantees never reaching it.
Remember in 30 seconds
- Three Ways: flow (deliver fast), feedback (know fast), learning (improve). In that order.
- A second way without a first way informs you about problems you cannot fix quickly.
- Theory of constraints: optimizing anywhere other than the bottleneck improves nothing. Map before acting.
- The constraint is often administrative, not technical — an approval committee, not slow tests.
- Reducing batch sizes is the most effective lever, and it is free.
- Push quality toward the source: equip whoever produces, rather than inspecting the finished product.
- CALMS: Culture, Automation, Lean, Measurement, Sharing.
- The typical diagnosis: strong on Automation, weak on Culture. That is why transformations fail.
- Psychological safety: if reporting a problem exposes you to blame, problems will be hidden.
- Explicitly reserve time for improvement — otherwise it will be consumed by emergencies.
- A rollback that has never been tested does not work. A backup never restored does not exist.
- Start by measuring, and work on culture from the start because it takes the longest.