Flow. Feedback. Continuous learning. The three ways have been the spine of DevOps for more than a decade. Here is what each of them actually looks like in 2026 — after a generation of practice, several waves of platform engineering, and the rise of AI in the toolchain.
The first way — Flow
The first way is about moving work from idea to production without unnecessary friction. In 2010, that meant continuous integration and continuous delivery. In 2026, with most CI/CD tooling commoditised, the harder flow problems live further upstream.
The bottleneck has moved.
For most mature engineering organisations, the time from commit to production is no longer the bottleneck. The bottleneck is upstream — code review, decision-making, prioritisation, the time between "we should do this" and "this is in the backlog ready to be picked up." Value-stream mapping past the deploy pipeline matters more than tuning the pipeline itself.
The platform team is the flow engineer.
The platform team's job is to reduce friction across the value stream. That includes the deploy pipeline, but it also includes the developer environment, the test cycles, the secrets management, the documentation tooling — everything between an engineer and "this is shipped."
The second way — Feedback
Feedback is about making the consequences of decisions visible quickly enough that they can be acted on. In practice, feedback in 2026 has three layers.
Build feedback.
Did this commit compile, pass tests, deploy successfully? This is the layer most teams have solved. Cycle times under ten minutes are routine.
Production feedback.
Did this change behave correctly in production? Observability — structured logs, metrics, traces — has become the dominant practice here. The work in 2026 is less about whether you have observability and more about whether your alerts route to the people who can act on them.
Outcome feedback.
Did this change produce the outcome we expected? This is the layer most organisations still cannot answer. Feature flags and structured experiments help. So does the discipline of writing down the expected outcome before shipping the change. Without that written hypothesis, the experiment is unfalsifiable.
If you cannot articulate what you expected, you cannot tell whether you got it.
The third way — Continuous learning
The third way is about systematically improving the system over time, including the parts that made the last failure possible. Post-incident reviews. Game days. Chaos engineering. Communities of practice.
Blameless reviews are table stakes.
Blameless post-incident reviews are no longer the cutting edge — they are the floor. The cutting edge is the discipline of acting on the reviews. Most organisations conduct excellent post-mortems and then file them. The third way works when the action items are tracked, owned, and closed.
Game days, with intent.
Game days — pre-planned operational exercises — are increasingly common. The ones that work define a specific hypothesis to test: "Can we fail over in under fifteen minutes?" The ones that do not work test "general resilience," which is unfalsifiable.
AI in the loop, carefully.
AI in the DevOps toolchain has matured from auto-completing CI configs to genuinely useful incident triage and runbook generation. The risk is the same as always: a layer of useful automation that obscures what is happening underneath. We use AI assistance in tier-2 work (routine triage) but require human judgment in tier-3 work (the unknowns that the AI cannot recognise as unknowns).
What has not changed
The cultural prerequisites. None of the three ways works in a low-trust organisation. None of them works when failure is punished. None of them works when "production access" is a status symbol. The technical practices are the easy half; the cultural conditions are the hard half. In 2026 as in 2011.
Closing
The three ways are durable because they describe what the system has to do, not which tools to use. Tools have churned several times since 2010. The three ways still hold. A team that internalises flow, feedback, and continuous learning will adopt whatever toolchain is current in 2030, and the toolchain will work for them.
The team that does not will be on the same toolchain everyone else is on, complaining that it does not work.