The Second Way of DevOps: Feedback

If the First Way (Flow) is about moving work from left to right — from development to the customer — then the Second Way is about creating a flow of information from right to left.

This is the principle of Feedback.
In The DevOps Handbook, Gene Kim and his colleagues describe the Second Way as the practice of shortening and amplifying feedback loops so that we can fix problems faster and prevent them from happening again.

Why Feedback is Essential

Imagine driving a car at 100 km/h.
Flow is what keeps the car moving forward. But without feedback — the speedometer, the fuel gauge, the sound of the engine, and the view through the windshield — you are driving blind. You wouldn't know if you were speeding, running out of gas, or about to hit a wall until it was too late.

In software, feedback is what tells us if our "car" is safe, efficient, and actually going where we want it to go.

The Goal: Shorten and Amplify

The Second Way has two main objectives:

1. Shorten the Loop: Reduce the time between an action (like committing code) and the feedback about that action (like a test result or a performance alert).
2. Amplify the Loop: Ensure that feedback is loud enough to be heard and clear enough to be acted upon by the right people at the right time.

Feedback for Every Role

For Developers

Feedback means knowing immediately if a change broke a feature or introduced a security vulnerability.
Instead of finding out about a bug three months later during a QA phase, developers get automated feedback within minutes via CI/CD pipelines. This allows them to fix issues while the code is still fresh in their minds.

For Operations

Feedback is about Observability.
It means having clear visibility into the health of production systems. When something goes wrong, operations teams shouldn't have to guess. Metrics, logs, and traces provide the feedback needed to identify the root cause and restore service quickly.

For Security

The Second Way integrates security into the daily work of development and operations.
By providing automated security feedback in the pipeline (e.g., "This library has a known vulnerability"), security teams empower developers to make safer choices without needing a manual security audit for every change.

For Managers

Feedback provides data for better decision-making.
Are we delivering value? Are our customers happy? Is our system stable?
By looking at metrics like lead time, deployment frequency, and mean time to recovery (MTTR), managers can see the health of the entire delivery process and invest in improvements where they are needed most.

How to Shorten and Amplify Feedback

1. Automated Testing as First-Class Feedback

Manual testing is slow and creates long feedback loops. Automated unit, integration, and end-to-end tests provide near-instant feedback every time code is changed.

2. Telemetry and Observability

You cannot fix what you cannot see. Every part of the system — application code, infrastructure, and the deployment pipeline — should produce telemetry. This data allows teams to detect problems (like a slow database query or a spike in 500 errors) before users even notice.

3. Peer Reviews and Pair Programming

Feedback doesn't always come from machines. Peer reviews (Pull Requests) and pair programming are powerful ways to get human feedback early in the process, improving code quality and sharing knowledge across the team.

4. Swarming on Problems

When a critical problem is detected, the team "swarms" it. Instead of passing tickets back and forth between silos, everyone needed to fix the issue comes together until it is resolved. This prevents the problem from moving further downstream and becoming more expensive to fix.

5. Blame-Free Post-Mortems

When things go wrong, the feedback shouldn't be "who did this?" but "how did the system allow this to happen?". Blame-free post-mortems turn failures into learning opportunities, ensuring that the entire organization benefits from the feedback provided by an incident.

The Risks of Weak Feedback

When feedback loops are long or silent:

• Bugs are expensive: A bug found in production costs 10x-100x more to fix than one found during development.
• Technical debt accumulates: Without feedback on quality, teams keep building on top of shaky foundations.
• Operations becomes "Firefighting": Instead of improving the system, teams spend all their time reacting to unexpected outages.
• Trust erodes: Customers lose trust when the software is unreliable, and teams lose trust in each other when they can't see the impact of their work.

Feedback Leads to Learning

The Second Way transforms "deploy and pray" into "deploy and learn."
By creating fast, loud feedback loops, we move from a culture of fear to a culture of scientific improvement. Every failure becomes a data point, and every success becomes a baseline to improve upon.

But feedback alone isn't enough. To truly excel, we need to take what we've learned and turn it into a continuous habit of experimentation.

Next in the Series

In the final article of this series, we will explore the Third Way of DevOps: Continual Learning and Experimentation — how to create a high-trust culture where taking risks and learning from failure is the norm.

Together, the Three Ways provide the path to building a high-performing, resilient, and innovative organization.