Somewhere along the way, DevOps became a tooling conversation. Ask someone how mature their DevOps practice is and the answer will often involve CI/CD pipelines, automated testing, infrastructure as code, observability, deployment frequency, or some combination of the above. All valuable tools, but that is often where the conversation ends. They compartmentalize DevOps principles to a niche scenario and ignore those same principles when it comes to team dynamics, organizational design, strategy, product development, and so on.
This becomes more obvious when we return to the Three Ways, commonly summarized as Flow, Feedback, and Continual Learning. These ideas are often explained through software delivery because that is where DevOps emerged, but nothing about them inherently limits their application to software tooling. They describe how information moves through a system, how the system learns what happened, and how that learning changes what happens next.
It is essentially PDSA in action. That should be no surprise, since DevOps gets much of its guidance from Lean, and the same underlying pattern emerges throughout Agile, Product, Design Thinking, and most modern approaches to improvement: plan, do, study, act. The branding may change, but the underlying mechanics are often remarkably similar.
Don’t Stop The Flow
Flow is usually interpreted as the movement of code from development into production. We optimize handoffs, reduce batch sizes, automate deployments, and remove constraints that slow software from reaching users. All of that is useful, but the flow of value begins long before someone commits code. To borrow from John Willis, what does the movement of value look like from aha to ka-ching? An organization can deploy code 20 times per day while taking 6 months to decide what it wants to build. That organization has optimized one narrow segment of flow.
This is a familiar problem in systems thinking. Local optimization can make one portion of a system remarkably efficient without improving the system as a whole. Mik Kersten tells the story of Nationwide in Project to Product. Nationwide measured roughly 120 days of end-to-end flow and found that only 2.5 percent of that time was spent in development. Adding more developers, whether human or AI agents, would have done little to improve throughput because development was not the constraint. Eliyahu Goldratt warned of the same problem in The Goal: “An hour lost at a bottleneck is an hour out of the entire system. An hour saved at a non-bottleneck is worthless.”
Amplify the Feedback
The same narrowing happens with Feedback. Automated tests, telemetry, and monitoring alerts are all common forms of feedback. These loops are valuable because they shorten the distance between an action and evidence about its consequences. The idea comes from Toyota’s andon cord: how do we make an abnormal condition visible quickly enough to stop and respond before producing more of an undesirable thing?
Now what happens when we apply that to value creation? How do we know to stop making something that is not creating the desired value? Value can only be judged by the customer, which means it cannot possibly be known without customer feedback. What is your customer’s andon cord?
As Kent Beck wrote in Extreme Programming Explained, “The development of a piece of software changes its own requirements. As soon as the customers see the first release, they learn what they want in the second release… or what they really wanted in the first. And it’s valuable learning, because it couldn’t have possibly taken place based on speculation. It is learning that can only come from experience. But customers can’t get there alone. They need people who can program, not as guides, but as companions.”
Many organizations become so enthralled with the craft that they forget the reason. Pendo found that 80 percent of software features are rarely or never used, with similar findings published by The Standish Group, Microsoft, and Google. It’s like when Homer Simpson built the perfect car, The Homer, which was loaded with features from triple horns to extra-sized cup holders, only to have the company go under because no one bought it.
Learning Without Boundaries
The Third Way, Continual Learning, is about what we do with that feedback. Every roadmap and business case contains assumptions. Every reorganization, process change, feature request, and strategic plan is built on some prediction about what will happen next. Whether you validate them or not, they are hypotheses until tested.
Learning is not the presence of feedback. It is a change in understanding or behavior resulting from processing that feedback. More flow creates more opportunities for feedback. More feedback creates more opportunities to learn. What we learn can then help us improve flow again. The Three Ways form a reinforcing learning cycle.
The toolchain is where many of us learned the Three Ways, but it doesn’t have to be where we leave them. They apply to customer research, strategic direction, or a frontline worker surfacing a recurring problem. Frequent retrospectives can create feedback about how a team works, while experiments can test whether changing that system produces the expected result. Leadership can apply the same cycle to organizational effectiveness. The principles scale from a line of code to the organization itself. This is the way.
