Feedback Loops

Without a working feedback loop, a team learns the truth about its work in the most expensive way possible: when something breaks loudly enough that someone outside the team escalates it. By then the cause is weeks old, the context is gone, and the fix is a scramble rather than a small adjustment.

Consider a product team that ships a redesigned checkout. They have analytics, but nobody reviews them on a schedule. For three weeks, completed orders quietly drift down. The team only finds out when a sales lead forwards an angry customer email. Now they are reconstructing what changed, who it affected, and when, all under pressure. A fifteen-minute weekly look at one number would have caught the drift in week one, while the change was still fresh and cheap to undo.

The cost is not only the missed orders. It is the erosion of trust. The customer who wrote in hears nothing back, so they stop writing in. The support agent who flagged the pattern early sees no action, so they stop flagging. A loop that never closes back to its source slowly starves itself of signal.

The payoff of getting it right is concrete. In 2026 the bottleneck for most teams is no longer building, since AI coding tools have compressed development from months to days. The advantage has shifted to which team can learn fastest from what it ships. The same logic sits at the core of John Boyd's OODA loop (observe, orient, decide, act): the side that cycles through the loop faster gets to act while the other side is still reacting. A short, deliberate loop is how a small team out-learns a slower competitor with more resources. The mechanism that makes this work is the loop's structure, which the next section breaks down.

A feedback loop is a five-part cycle, and a loop fails at whichever part the team skips. Naming the parts lets you see exactly where yours is breaking.

• Collect a signal. Pick one observable measure that genuinely reflects the question you care about. A signal is just the evidence, such as tickets tagged a certain way, a completion rate, an error count, or the time work spends waiting.
• Make sense of it. Read the pattern across many cases, not the loudest single one. Three people stuck on the same field is a pattern. One furious customer may be an outlier.
• Decide. Choose one change. A loop that surfaces ten problems and acts on none is a report, not a loop.
• Act. Make the change in the real system, not in a backlog item that ages.
• Close it back. Tell whoever raised the signal what you did, and let the change flow into the next round of signal. This is the part that makes it a loop rather than a line.

Two distinctions decide whether your loop is fast enough to be useful. The first is the kind of signal. A leading indicator changes early and predicts a likely result, such as the share of users who begin a step. A lagging indicator confirms what already happened, such as the number of orders completed last week. You watch leading signals often, because they give you time to steer, and you check lagging signals on a slower beat to confirm the steering actually worked.

The second is cadence. The single most common cadence mistake is reviewing both kinds at the same frequency. A practical rule: your review cadence has to be faster than the window in which you could act. If you could fix a stuck checkout step this week but only look at the data each quarter, the signal is functionally useless. Match the beat to the behavior, since people act in days and weeks, not quarters.

The deepest distinction is how far the loop reaches. Single-loop learning detects a gap and corrects the action without questioning the rules behind it. The classic image, from Chris Argyris and Donald Schon, is a thermostat that turns on the heat whenever the room drops below a set point. Double-loop learning asks whether the set point itself, the governing rule, should change. A worked instance: a request reopens monthly. Single-loop re-runs it by hand each time. Double-loop notices the recurrence and asks why the request is manual at all, then removes the rule that creates the work. Finishing this section, you can in principle build a loop. The next one walks one through from end to end.

Take a support-or-request workflow that should feel familiar. A request comes in, gets triaged, waits in a queue, is assigned, worked, reviewed, and sent back. The team, run by a lead named Priya, suspects requests are getting stuck somewhere, but nobody can say where. Here is the loop they build.

1. Pick the question. Priya phrases it tightly: "Are requests waiting too long before anyone picks them up?" One question, not ten.
2. Choose one signal. The queue time between "triaged" and "assigned" already lives in the ticketing tool. No new survey is needed. This is a leading indicator, since long queue time today predicts late delivery and complaints tomorrow.
3. Set the cadence. Because the team could reassign work within a day, a daily glance plus a fifteen-minute Friday review fits the window in which they can act.
4. Make sense of it. The first Friday, the median queue time is 31 hours, and the pattern is clear: tickets arriving after Wednesday wait through the weekend because triage stops on Thursday.
5. Decide and act. One change: move the Thursday triage slot to Friday morning so nothing sits over the weekend. They also reply to the two requesters whose tickets had been stuck, telling them the cause and the fix.
6. Watch the loop. The next Friday, median queue time drops to 9 hours. Three weeks later, the lagging signal, on-time delivery, has climbed from 74% to 91%.

Then the recurring part. A month in, the same weekend backlog creeps back whenever the Friday triager is on leave. Priya stops patching it case by case and switches to double-loop: the rule "one person owns triage" is the real cause. She makes triage a shared rotation with a named backup. The signal stays flat through the next two absences. The loop did its job, and the cast (Priya, her queue, her requesters) carries into the pitfalls below.

The traps are tempting because each one feels like progress while quietly breaking the loop.

• The dashboard nobody reads. Building the instrumentation feels productive, so teams stop there. A signal with no scheduled human review is decoration. The fix is to attach a named owner and a recurring time to every signal you collect, and to retire any signal nobody acts on.
• Chasing the loudest voice. One vivid complaint pulls attention away from the quieter pattern affecting many more people. Read the aggregate first, then let individual stories illustrate it. The complaint is a prompt to look at the data, not a substitute for it.
• Closing back to the team but not the source. The team learns and improves, yet the requester or the support agent who raised the issue hears nothing. Their signal dries up. Make the reply to the source part of the definition of done for the loop, not an optional courtesy.
• Cadence mismatch. A fast leading signal reviewed quarterly is the same as not having it. A slow lagging signal checked daily generates noise and false alarms. Set each signal's review rhythm to its own speed.

Then the genuine edge cases. The signal that takes a quarter to move. Some outcomes, such as retention or trust, are inherently slow lagging indicators. You cannot run a weekly loop on them directly. The handling is to find a leading proxy you can watch weekly, such as repeat usage in the first session, and treat the slow measure as the confirmation rather than the steering wheel.

The signal that lies under AI-assisted work. A 2026 wrinkle: when AI generates a large share of shipped changes, raw delivery speed can climb while quality quietly drops. A loop watching only "deployment frequency" would read green during a slow-motion failure. Pair any speed signal with a quality signal, such as rework rate or reopened tickets, so the loop sees the trade-off, not just the throughput. Handling these well is harder when more than one team shares the signal, which is where scale comes in.

A single person can hold a loop in their head. The moment two or more people, teams, or quarters are involved, the loop has to become a visible habit with a lightweight artifact, or it quietly stops happening.

The cheapest durable artifact is a standing review with three columns: the signal and where it sits now, the one change decided last time, and whether the signal moved. Software teams already run a version of this. The DORA delivery metrics (deployment frequency, lead time for changes, change fail rate, failed deployment recovery time, and the newer rework rate) are read together in a recurring review precisely so the loop closes against data rather than opinion. The artifact matters less than the recurrence.

For incidents, the team version of the loop is the blameless postmortem. The blameless stance assumes everyone acted reasonably on the information they had, which keeps people surfacing problems instead of hiding them. Its value is measured by the action items it generates and tracks to done, not by the writeup itself. A postmortem with no tracked follow-through is the incident version of the dashboard nobody reads.

Scale also changes what counts as closing the loop. With one requester you send a reply. With a hundred, you close back through a changelog, a status update, or a visible "you asked, we changed" note, so the population that raised the signal sees the response even when you cannot write to each person.

The durable principle to keep, whatever the size: a loop earns its place only when a decision and a visible change come out of it, and only when that change reaches both the system and the people who fed it the signal. Start with one signal you will actually act on, run it on a cadence that matches how fast you can move, and add loops one at a time as the habit holds.