Who is holding the learning?

Every change programme I have worked alongside has been able to tell me what it produced. The reports, the reviews, the engagement sessions, the recommendations, the board papers, the delivery plan and the milestones against it.

If you ask that same programme who is holding what it has learned, the answer normally becomes much less clear.

Usually the answer turns out to be a person. Occasionally it turns out to be a person who has since moved on.

That is not carelessness, and it is not a criticism of anyone involved. It is what happens when a system commissions delivery and assumes memory will look after itself.

I have started to think this is one of the quietest and most expensive gaps in any organisation trying to change itself. It shows up in councils and health systems, and it shows up just as readily in a scaling business, a community interest company or a charity three years into a strategy. We are increasingly good at designing change. We are increasingly good at governing it, resourcing it, sequencing it and reporting on it. What we very rarely do is make anyone explicitly accountable for holding the learning while the change is actually happening.

So the learning happens anyway, because people are thoughtful and they notice things. It just has nowhere to go.

Someone on the front line sees the same person arrive through three different doors in a fortnight. A contract manager spots that a supplier is technically compliant and quietly failing. A customer explains, in a session that somebody diligently wrote up, exactly why the new process will not work for people like her. A founder knows which part of the business is absorbing the consequence of a decision taken somewhere else entirely. A finance lead can see it in a budget line and cannot say why it moved.

All of that is learning. Almost none of it is held.

It is worth being precise about what I mean, because it is easy to hear this as a records problem and it is not. A system can hold every report it has ever produced and still remember nothing. Documentation is not memory. Memory is what a system can still act on eighteen months later, when the programme has closed, the pressures have changed and the people who were in the room have moved into other roles.

Not a knowledge management problem.

Not an information governance problem.

Not another repository.

A stewardship problem.

The distinction matters because it changes who is responsible. A repository needs a system administrator. Stewardship needs someone whose actual job is to notice what is emerging across boundaries, connect it to what was learned before, and put it in front of the people making decisions at the moment it could still change one.

Nobody currently has that job. It is not in anybody’s objectives, it is not a line in the programme plan, and it is not written into any contract. It falls, when it falls anywhere, to whoever happens to care enough to carry it privately.

I think there are four places this consistently breaks down, and they are worth separating because they need different answers.

None of those four are failures of effort. Every one of them is a design choice that somebody made for entirely sensible reasons, usually years ago, and that nobody has revisited since.

Here is the part I would want to argue for, rather than simply observe.

If learning genuinely happens across a system, then somebody has to be explicitly accountable for holding it, and that somebody cannot be the same person accountable for delivering the change. Not because delivery people cannot be trusted, but because holding learning well requires the freedom to surface things that are inconvenient to the plan. Put those two jobs in the same pair of hands and one of them will always lose, and it will not be the delivery milestone.

That role needs naming, resourcing and enough independence to say uncomfortable things early. It does not need new powers. It does not need to sit above governance or replace anybody’s accountability. It needs to make evidence, experience, interdependencies and likely consequences visible before decisions are taken rather than after.

I have become fairly convinced that this is the difference between a system that changes and a system that learns. Plenty of organisations manage the first. Far fewer manage the second, and the ones that do not tend to find themselves solving the same problem again three years later, with different people, and no memory of why it did not work the first time.

Change is usually designed as a plan.

The organisations that get somewhere treat it as a memory.