The Second Way: Amplifying Feedback Loops#

TL;DR#

The Second Way is the principle that feedback must flow right to left — from Operations and the customer back to Development — as fast, complete, and unfiltered as possible, so problems are caught and corrected close to their source instead of discovered much later, much further downstream. Where the First Way (phoenix-project/05) is about moving work forward fast, the Second Way is about making sure the signal telling you whether that work is actually good travels backward just as fast, so the pipeline becomes self-correcting rather than blindly fast.

The idea#

A pipeline that moves work quickly left to right but has no fast return signal is dangerous, not safe — it just means bad changes reach production, and reach the next set of changes built on top of them, faster. The Second Way closes the loop: every stage downstream (QA, staging, production monitoring, customer support, security scanning) should surface what it learns back to the people upstream — ideally Development — as quickly, completely, and directly as possible, without filtering, delay, or reinterpretation through several layers of management.

At Parts Unlimited, feedback is slow, indirect, and heavily filtered by the time it's a problem: production incidents are discovered by customers or by a separate monitoring team hours after they start, get relayed through several layers of management before reaching an engineer who can act, and often arrive so filtered and summarized ("something's wrong with billing") that the responding engineer has to re-derive information the system already had (which change, which server, which error) instead of receiving it directly. Erik's core teaching here, echoing manufacturing quality practice, is that the value of feedback decays sharply with distance and delay — feedback that reaches the responsible engineer within minutes, with full technical detail, is worth vastly more than the same information reaching a director's summary report a week later.

How it works#

Feedback loop length determines correction cost#

The core mechanism: the longer a feedback loop (time between an action and finding out its consequence), the more work has already been built on the faulty assumption by the time you learn it was wrong, and the more expensive the correction. This is the same underlying dynamic as phoenix-project/05's "stop the line," applied specifically to the detection side rather than the response side — you can't stop the line for a defect you don't yet know exists.

Worked example. Compare two feedback configurations for a subtle performance regression introduced by a database query change. In configuration A, an automated performance-regression test runs on every commit and flags the regression within 3 minutes of the change being pushed, before it merges — the engineer who wrote it, still holding full context, fixes it in 15 minutes. In configuration B, there's no automated check; the regression ships, slowly degrades response times over two weeks as traffic grows, is eventually noticed by customer complaints, gets triaged by support, escalated to an on-call engineer unfamiliar with the change, who spends 2 days bisecting through two weeks of commits to find the cause. Same underlying bug, same eventual fix — but configuration B costs roughly 100x the engineering time and two weeks of degraded customer experience, purely because of feedback loop length, not because the bug was harder.

Feedback fidelity: raw signal vs. filtered summary#

Beyond speed, the Second Way requires feedback to be as unfiltered and direct as possible. Every layer of summarization between an event and the person who can act on it loses information and adds delay. Parts Unlimited's incident-reporting chain — support ticket, to team lead, to manager, to director, eventually to an engineer — is a textbook example of a feedback loop where each hop both delays the signal and strips detail, so that by the time an engineer hears about it, they're working from "customers are complaining about billing" instead of the actual stack trace, error rate, and affected endpoint that the monitoring system captured within seconds of the first failure.

Worked example. An SRE team gives every engineer direct access to a dashboard showing real-time error rates, latency percentiles, and deploy markers for their own service, plus automatic Slack alerts routed directly to the engineer who made the most recent relevant deploy (not to a generic ops channel first). Compare this to a team where the same data exists but only ops has dashboard access, and engineers hear about problems via a ticket summarizing "users report slowness" filed a day later. Both teams have the same underlying telemetry; only one has actually built a Second Way feedback loop — the other has collected data without routing it to where it's actionable.

Feedback as a cultural, not just technical, practice#

Fast, high-fidelity feedback only works if people act on it without fear of blame, and if the sender trusts that surfacing bad news won't be punished — directly connecting to phoenix-project/01's systems framing and to blameless postmortem practice (devops-handbook/13). If an engineer who reports "my change caused this outage" is publicly blamed, the natural response across the org is to report problems more slowly, more vaguely, or not at all, silently breaking the feedback loop regardless of how good the monitoring tooling is. This is why the Second Way is inseparable from the culture of psychological safety the book develops through Bill's arc — tooling alone (dashboards, alerts) doesn't create fast feedback if the human incentives punish honest, fast reporting.

Worked example. After a production incident, one team runs a review that opens with "whose change caused this?" and assigns corrective action to that individual; engineers on that team start quietly testing risky changes in production during low-traffic windows rather than raising concerns beforehand, because raising a concern in the past got treated as "why didn't you just fix it yourself." Another team runs blameless reviews ("what about our system made this failure likely, and what would have caught it sooner?") and sees a measurable increase in engineers proactively flagging risky changes before deploying them, because doing so is treated as valuable signal, not liability.

Feedback loops at multiple scales#

The Second Way applies at several nested scales simultaneously: within a single deploy (automated tests, canary analysis), within a single day (monitoring and alerting), within a sprint (retrospectives), and within a quarter (customer and business metrics). A mature Second Way implementation has fast, high-fidelity loops operating at all these scales — a team with excellent per-deploy testing but no mechanism for surfacing quarterly customer-satisfaction trends back to engineering priorities still has a Second Way gap, just at a different timescale.

Pros#

Dramatically reduces the cost of correcting mistakes by catching them close to their source, before more work is built on top of the faulty assumption.
Builds organizational trust and honesty when paired with blameless practice, because fast, unfiltered feedback becomes something people actively provide rather than something extracted under pressure.
Compounds with the First Way (phoenix-project/05): fast flow with fast feedback is self-correcting, whereas fast flow alone just moves problems downstream faster.

Cons#

Building genuinely fast, high-fidelity feedback loops (automated testing, real-time monitoring routed directly to the responsible engineer) requires real, sustained tooling investment that competes with feature work for priority.
Feedback that's fast but low-quality (noisy alerts, false positives) trains people to ignore it, which is arguably worse than no feedback loop at all — speed without fidelity and relevance backfires.
Requires a cultural precondition (psychological safety, blameless practice) that tooling alone cannot manufacture — an organization can buy excellent monitoring and still have slow, filtered, fear-driven feedback if the culture punishes bad news.

Alternatives#

Periodic batch reviews (e.g., quarterly business reviews, weekly status reports) — feedback still happens, but at long, fixed intervals rather than continuously and close to the event; appropriate for strategic-level feedback (phoenix-project/10) but far too slow for operational correction.
Centralized ops-only monitoring — a dedicated ops team watches dashboards and files tickets when something looks wrong, rather than routing signal directly to the responsible engineer; better than nothing, but reintroduces the filtering/delay problem the worked examples above illustrate.
Manual QA gate before every release — rely on a human tester to catch issues before shipping, rather than automated, continuous feedback; can catch some classes of problems but is inherently slower and more expensive per cycle than automated feedback, and doesn't scale with delivery frequency.

When to use it#

Invest in Second Way feedback loops wherever the cost of a defect grows significantly the longer it goes undetected — which is nearly always true in production software, and especially true for anything customer-facing or revenue-affecting. Prioritize closing the loops with the longest current delay or the least direct routing first (per ToC-style reasoning, phoenix-project/03), since that's where the marginal improvement in correction cost is largest.

When NOT to use it#

Don't over-invest in fast feedback for low-stakes, easily-reversible, low-blast-radius changes where a slower, cheaper review process is genuinely sufficient — real-time monitoring and automated regression suites have a cost, and applying maximal feedback infrastructure to every trivial change is wasted effort better spent elsewhere. Also recognize that fast feedback without the cultural precondition (psychological safety) will underperform its technical potential — don't treat a monitoring tooling purchase as sufficient on its own without addressing whether people will actually act on and honestly report what it shows.

Key takeaways / mental model#

Ask, for any given class of mistake: how long, and through how many filtering layers, before the person who could fix it finds out? Shrink that distance and that delay as much as the stakes justify, and make sure the culture rewards surfacing bad news fast rather than punishing it — a fast pipe carrying a filtered, fearful signal is not a working feedback loop.

Self-check questions#

Using the performance-regression worked example, explain why the same underlying bug costs roughly 100x more to fix under the slow, high-filter feedback configuration versus the fast, direct one.
Why does psychological safety matter for the Second Way even if an organization has excellent monitoring and alerting tooling already in place? What specifically breaks if it's absent?
Describe a feedback loop from your own work (or a plausible scenario) that is fast but low-fidelity (noisy, low-signal) versus one that's slow but high-fidelity. Which would you prioritize fixing first, and why?
The Second Way applies at multiple timescales (per-deploy, daily, sprint, quarterly). Give an example of a team with a strong per-deploy feedback loop but a weak quarterly one, and explain what business risk that gap creates.

References#

The Phoenix Project (Kim, Behr, Spafford), Part 2 (Erik's Three Ways framework).
See also phoenix-project/05 (the First Way, which the Second Way closes the loop on) and devops-handbook/10 through devops-handbook/13 (telemetry, monitoring, incident feedback, and blameless postmortems), which operationalize this concept into concrete practice.