The second way to introduce DevOps is to build a strong flow of feedback going in the opposite direction of the value flow — from customers and production back into the business and into development. This is the Second Way in Gene Kim’s Three Ways framework, and it is what stops the First Way from optimising in the dark.
Why Feedback Comes Second#
The First Way optimises how value flows to the customer. The Second Way makes sure you actually know what is happening once it gets there. Without feedback, fast flow just means you ship the wrong thing faster. With feedback, every release becomes a controlled experiment — you ship, you measure, you decide what to do next.
Feedback also closes the loop between development and operations. The team that built the feature should be the team that hears about the production issue. That is what changes behaviour over the long run.
Production Problems Flow Back Fast#
The first kind of feedback is operational. When something breaks in production, the signal needs to reach the people who can fix it — fast and with enough context to act. Logs, metrics, traces, alerts that page the right team, dashboards that show what is unusual. The goal is not just to detect; it is to detect early enough that you can fix the issue before customers notice, or at least roll it back before it spreads.
A team that does not see its own production data will keep building features in a model of the system that does not match reality. A team that does see it builds different features and writes different code.
Customer Feedback Reaches the Business#
The second kind of feedback is customer behaviour. Which features are people actually using? Which ones do they ignore? Where do they drop off in a workflow? You answer these questions with focused measurement and usage analysis — instrumented features, funnels, cohort analysis, qualitative feedback channels.
This is what gives the business real input for the next decision. Should we expand this feature, or kill it? Should we add a third option, or simplify down to one? Without usage data, those decisions get made by the loudest voice in the room. With usage data, they get made by what customers actually do.
Make Feedback Loops Short and Specific#
A feedback loop only matters if it changes a decision. If a customer reports an issue today and the team hears about it next quarter in a status report, the loop is too long to act on. If usage analytics live in a tool nobody opens, the loop is too distant.
Short loops, specific signals, in front of the right people. Production telemetry on a screen the engineering team sees. Usage data in the product manager’s planning ritual. Support tickets surfaced to the team that owns the feature. Each loop should be aimed at the specific decision it is meant to inform.
Blameless Response Is Part of the Loop#
Feedback only flows freely when it is safe to surface it. If reporting a problem leads to blame, people stop reporting problems — and the loop dies. Blameless post-mortems, focus on system causes rather than individual mistakes, treating incidents as learning opportunities. This is the cultural piece that makes the Second Way actually work, and it is also what bridges into the Third Way.
Key Takeaways#
- Without feedback, fast flow ships the wrong thing faster. The Second Way is what makes the First Way safe.
- Production problems must flow back to the team that can fix them. Same team builds and runs.
- Usage data drives product decisions. Without it, decisions get made by the loudest voice.
- Short, specific loops change behaviour. Long or generic loops do not.
- Blameless response keeps the loop alive. Punishment kills feedback faster than any tool can revive it.
- The Second Way bridges to the Third. Feedback only generates learning if the culture supports honest signal.