Skip to content
outpace.
Leading change

Learning Loops, the Skill That Makes Everything Else Work

Most retrospectives are theatre. What real learning looks like in a team, and why every other skill depends on it.

Illustration of people on walkways around a large circular structure, with figures on a path in the foreground looking on.
On this page
  1. Experience Is Not the Same as Learning
  2. What a Learning Loop Actually Is
  3. Why We Avoid Real Learning
  4. The Retro That Actually Changes Something
  5. Small Loops Beat Big Reviews
  6. Blame Kills Loops, Curiosity Feeds Them
  7. Learning as the Meta-Skill
  8. Building Loops Into Real Work

If you want to understand a team's relationship with learning, do not look at their strategy. Look at their retrospectives.

You have probably been in this one.

A project finishes. Someone books a "lessons learned" session. The invite goes out with an earnest agenda: what went well, what did not, what we would do differently.

On the day, half the people who were closest to the work cannot make it. The rest arrive late, slightly tense, half in delivery mode. You walk through the project timeline, name a few predictable themes, put some actions on a slide.

"We should engage stakeholders earlier." "We need clearer roles next time." "We should communicate more."

Everyone nods. Someone promises to write it up.

Then everyone goes back to their day jobs. Within a month, the document is in a folder no one will ever open. Within a year, you run almost the same project and make almost the same mistakes, with slightly more frustration.

In a past life as an agile coach, I spent a lot of energy trying to fix this with better formats. We ran timelines, sailboats, starfish, mad–sad–glad. We covered walls with sticky notes. In the room, the conversations felt rich. On paper, the insights looked sharp. And yet, two or three sprints later, we were having almost the same conversation about almost the same problems. It slowly dawned on me that the issue was not the design of the conversation. It was that nothing in the system outside that hour was changing.

We did retros. We did not build learning loops.


Experience Is Not the Same as Learning

We like to tell ourselves that experience automatically makes us better.

In reality, experience just gives you more data. What you do with that data is what matters.

Without some kind of loop—a regular habit of noticing what is happening, making sense of it, deciding what to try next, and actually changing your behaviour—experience can just as easily harden into habit. You get more practised at doing things the same way, even when the context has moved on.

A team that never really learns:

  • Has the same arguments in slightly different words
  • Writes the same action items in slightly different formats
  • Explains away bad outcomes as "unavoidable" or "just how it is here"

From the outside, they look busy and experienced. From the inside, it feels like running on a treadmill.

A team that has learning loops embedded feels different. You can see the compounding. The way they run meetings, make decisions, roll out changes—it all gets a little cleaner, a little smarter, a little more humane over time.

The difference is not intelligence. It is rhythm.


What a Learning Loop Actually Is

Strip away the frameworks and labels and a learning loop is very simple:

do a thing → pay attention to what happens → talk about what that means → change what you do next time

You can see versions of this everywhere: in aviation's after-action reviews, in the military's observe–orient–decide–act cycle, in any craft where feedback is baked into the work.

The key is not the shape of the diagram. It is the habit.

Most teams put all their "learning" at the end. One big review, if there is time, when the work is over and everyone is exhausted. By then, the political and emotional stakes are high. Careers are attached. Narratives have formed. It is very hard to be honest enough to change anything meaningful.

Real learning loops are smaller and closer to the work. They happen weekly or even daily, not just at the end of the project. They sound more like:

  • "What did we expect to happen this sprint?"
  • "What actually happened?"
  • "What surprised us?"
  • "What do we want to try differently in the next two weeks?"

Nothing mystical. Just a short, regular pause where you look at reality and let it change your mind.


Why We Avoid Real Learning

If it is that simple, why do so few teams do it well?

Partly: busyness. Reflection is always the easiest thing to sacrifice. There is always another meeting, another deadline, another urgent request.

Partly: ego and fear. Real learning means looking at where you misjudged, where you overcommitted, where you stuck with a plan longer than you should have. That is uncomfortable in cultures where being wrong is treated as weakness rather than as normal.

Partly: sunk cost. Once you have poured time, money, and reputation into a direction, it is very hard to admit, "If we knew what we know now, we would not have done it this way." It feels like throwing everything in the bin, even when it might save you more pain later.

So we reach for softer moves.

We rename problems as "learnings" without changing behaviour. We write "lessons learned" documents instead of altering how we work. We say, "We will keep this in mind" and then design the next project in almost exactly the same way.

It is not that we do not know how to reflect. It is that we have built systems where real learning carries more short-term social risk than repeating the pattern.


The Retro That Actually Changes Something

Every leader has at least one memory of a conversation that felt different.

Maybe it was not even a formal retro. Maybe it was three people in a room after a hard month, when someone finally said:

"We cannot keep doing it this way. We are burning people out, and the quality is slipping."

And instead of defending or blaming, someone else said:

"You are right. Let us work out what we want to try differently next month."

In that moment, you can feel the loop close. You have moved from commentary to commitment.

What makes those conversations different is not the template. It is the stance:

  • You are allowed to say out loud that what you are doing is not working
  • You treat that as data, not as a personal failure
  • You are willing to make one concrete change and see what happens

It might be as simple as:

"For the next fortnight, we are going to cap work in progress at three items per person, and we will track how often we get interrupted."

That is a learning loop. Not because the idea is clever, but because it is specific, time-bound, and tied to reality.


Small Loops Beat Big Reviews

There is still a place for larger after-action reviews, especially after major events. But they should sit on top of a rhythm of small loops, not try to substitute for one.

A team with learning loops:

  • Does not wait until the end to notice patterns
  • Does not save everything difficult for the big review
  • Adjusts in flight, instead of creating a giant list of "things we would do differently if we ever do this again"

Most "we will do a lessons learned" promises are really a socially acceptable way to say, "We do not want to talk about this honestly right now."

The antidote is not a more elaborate retro process. It is a culture where small, honest check-ins are normal.

If you look at your own team, when was the last time you changed a real behaviour—not a policy, a behaviour—because of something you noticed together in a retrospective?

If you cannot think of many examples, that tells you something about whether you have a learning loop or just a learning ritual.


Blame Kills Loops, Curiosity Feeds Them

There is one more ingredient that often gets missed.

You cannot run real learning loops in a blame culture. People will not tell you where things went wrong if they know that information will later be used against them.

Blameless does not mean responsibility-free. It means you treat problems as something to be understood and solved, not as ammunition.

It sounds less like:

"Who dropped the ball on this?"

and more like:

"Where did our system make it likely that this would happen? What was invisible to us when we made that call?"

You still hold people accountable for patterns and choices. You just do not confuse honest reporting with incompetence.

Curiosity is the fuel here. Teams who learn ask more "how did that work in reality?" questions and fewer "who can we point at?" questions.


Learning as the Meta-Skill

The reason learning loops matter so much is that they unlock everything else you are trying to do.

You can have the best narrative about the future. Without learning loops, you keep telling it the same way, even when the context changes and people stop believing it.

You can work hard on psychological safety. Without learning loops, you might get more candour, but nothing in the system changes as a result, and people eventually give up telling you the truth.

You can embrace probing and safe-to-fail experiments. Without learning loops, all you have is noise—lots of activity, not much compounding insight.

With loops, each of those things starts to compound. The story gets sharper because you are testing it against reality. Safety deepens because people see their input change things. Probes turn into patterns you can actually build on.

It is the difference between a team that has ten years of experience and a team that has one year of experience repeated ten times.


Building Loops Into Real Work

Treat learning loops as a practical discipline, not a nice idea.

Do not start with hypothetical scenarios. Start with a real initiative or team you are responsible for, and look at:

  • Where you are currently relying on big, end-of-cycle reviews
  • Where you could add one or two short, regular check-ins tied to real decisions
  • What kinds of questions would make it safe and useful for people to tell the truth

Then ask the only question that really matters:

"What is one small change to your rhythm you are willing to make in the next month that would increase the chances you actually learn from what is happening?"

Sometimes it is adding a fifteen-minute "what surprised us this week?" slot to an existing meeting. Sometimes it is committing to stop one thing that clearly is not working, rather than pushing it through because of sunk cost. Sometimes it is as simple as writing down your hypotheses before you act, so you can test them afterwards.

None of these moves is dramatic on its own. That is the point.

Learning loops are not about the occasional heroic insight. They are about turning the way you work into something that quietly, relentlessly, gets smarter over time.

In a world where your plans, structures, and strategies will all be forced to change, that meta-skill—the ability to notice, adjust, and genuinely learn—is what makes every other skill worth having.

ExperimentsLearningChange

Continue reading

All articles →
The words "Is your job safe?" on a bright blue background above the Claude, Cursor and GitHub Copilot logos12:34

Will AI Replace Designers?

A designer of 29 years on the line that decides it: whether your week is spent producing things, or being accountable for how they turn out.

Illustration of a man standing in the shadow of a doorway, watching butterflies cross an orange and blue sky.

Change Does Not Hurt, Losing Does

People don't resist change. They resist losing things. Until you name what they're giving up, your change story sounds like propaganda.

Simon Sinek speaking to a large audience in black and white, with the words "Don't try to convince others, do this instead."7:59

How to Create Change

Simon Sinek on why change stalls when you try to convince the sceptics, and why a rollout should start with the early adopters.