Most organizations I meet are not short on feedback. They have engagement surveys, NPS scores, customer complaints, ticket tags, retrospective notes and escalation emails. They lack feedback loops. These are places where signals reliably lead to small adjustments in how the system works. Here, people can actually see that connection. When feedback disappears into a void, people eventually stop offering it. They may offer it with a shrug, assuming nothing will change.
From an AO and systems‑thinking perspective, feedback loops are not an HR topic or a nice‑to‑have. They are crucial for a living organization to learn and adapt. The process involves regularly comparing intentions with actual outcomes. Then, adjustment of structure, flow, and behavior is done in small steps. In this issue, I share a story of a team. They improved their work by moving from tired rituals to a simple, tight loop. I also provide a concrete AO move you can try. This move is helpful if you sense feedback in your system is getting stuck rather than closing the loop.
From the field: from tired retros to a living loop
A cross‑functional product team told me they were “doing retros” but not really learning. Every two weeks, they spent an hour filling a digital board with sticky notes. They noted what went well, what didn’t, and ideas for improvement. At the end, they picked a couple of actions. By the time the next sprint ended, nobody remembered what those actions were, or whether anything had changed. The ritual was there; the loop was not.
When we looked closer, two patterns stood out. First, the scope of their retros was too broad. They tried to talk about everything at once: coding practices, stakeholder communication, deployment issues, team dynamics, long‑term strategy. Second, nothing outside the team room changed. Many of their frustrations were about upstream and downstream parts of the system. They dealt with unclear priorities, last‑minute requests, and release policies. However, their “actions” stayed within their own bubble.
Rather than abandoning retros, we narrowed and repurposed them. For a month, we focused the team on one specific flow for learning. This was the journey of one particular type of change, from idea to live usage. We also invited one person from customer success. Another was invited from operations. They joined for a short part of the session. This way, the loop included those who saw the impact outside the team.
We introduced a simple visual that became the backbone of their new loop. It was a board with three columns labeled “Signals”, “Experiments”, and “Effects”. Each week, rather than listing generic “went well/didn’t go well” items, they identified 2–3 specific signals about that flow. These signals could include a recurring support ticket pattern, a delay hotspot, or a positive surprise in customer behavior. For each important signal, they designed one small experiment. It could be a tweak in how they coordinated. They might also adjust how they sequenced work. Another option was tweaking how they checked quality. Alternatively, they could change how they communicated changes.
Crucially, the board stayed visible in their team space and in their digital workspace. The following week, they didn’t start from a blank slate. They returned to the same board and asked: “What did we actually do? What did we see? Do we keep this change, adjust it, or drop it?” Over time, some experiments became the new normal, others were retired, and new ones appeared.
Within a few iterations, their energy shifted. The team started noticing patterns earlier. They could see that a change in how they handled handoffs reduced a certain kind of support ticket. They also noticed that a change in release timing created new issues elsewhere. Customer success felt heard because their signals were now explicitly part of the loop, not an afterthought. One team member summed it up neatly: “We used to collect feedback about the past. Now we have a place where feedback changes what we do next.”
Try this AO move this week – design one tight loop
You don’t need to redesign all your feedback processes to start tightening your loops. You can begin by creating one simple, explicit loop around one important flow, and running it for a few weeks.
- Pick one flow that really matters.
Choose a concrete slice of work where better learning would help. It could be Onboarding a certain type of customer. It might involve handling a particular class of incidents or claims. Consider delivering a type of feature or running a recurring service. Make it narrow enough that everyone can picture real examples. - Define 2–3 signals you will look at every week.
Ask: “If this flow were getting healthier or sicker, what simple signs would we see?” These signs could be things like repetition in support tickets. You might also notice a specific delay point. A satisfaction indicator may appear. There could be a handoffs that often goes wrong. Alternatively, you might hear a frontline story from customers or staff. Keep the list short and easy to see at a glance. - Install a small, regular loop into an existing meeting.
Instead of adding a new ceremony, use a meeting you already have. Reserve 15–20 minutes in that meeting. For example, use the end of a weekly team meeting, service review, or leadership huddle. Use that slot only for this flow and these signals. Every time, follow the same pattern:- look at the signals;
- choose at most one small adjustment you will try before the next loop;
- write it down where everyone can see it.
- Keep a tiny “signals → adjustments → effects” log.
On a physical board or a shared document, track three things. First, note which signal you reacted to. Next, record what adjustment you decided to make. Lastly, write down what you noticed by the next meeting. You don’t need perfect data; you need enough observation to see whether your system responds. - Review the loop itself after 3–4 cycles.
After a few weeks, step back: Is this loop giving us useful learning? Are the signals still the right ones? Are our adjustments too big or too vague? Do we need to involve someone else (e.g. another team, a function) to make the loop complete? Adjust the design of the loop as well as what you do inside it.
If you repeat this pattern across a few important flows, you’ll discover that your AO work doesn’t rely on big initiatives anymore. It starts to feel like part of how you move. Signals come in, small experiments go out, and everyone can see the connection between the two.
You want more?
If you’d like help designing feedback loops and lightweight review practices tailored to your AO work, you can book a short conversation with me.
Menschgeist 
Leave a comment