Why Your Programme Will Not Survive the Next Resignation

Every experimentation programme has a person who holds it together. They know the history. They remember what was tested two years ago and why it mattered. They understand the stakeholder relationships, the unwritten rules, and the reasoning behind decisions that were never documented. They are the programme's memory, its quality standard, and its political navigator. When that person leaves, and they will, the programme does not just lose headcount. It loses context. Institutional knowledge. The thread that connects two years of experiments into a coherent body of evidence. What remains is a collection of results that nobody can fully interpret because the person who understood the context is gone. This is not a personnel risk. It is a structural one. And it is fixable, but only if you recognise it before the resignation letter arrives.

What Actually Gets Lost

The learning history. The programme has run hundreds of experiments. The results are stored somewhere, probably across multiple tools, spreadsheets, and presentation files. But the interpretation, the understanding of why results mattered, what they meant in combination, and how they informed subsequent work, that lives in one person's head.

Ask your team: If nobody from the current team was available, could someone reconstruct what this programme has learned in the last two years from documentation alone? If the honest answer is no, then the programme's knowledge is rented from whoever currently holds it. You are paying for institutional memory that walks out the door with an individual.

The decision context. Past decisions made sense at the time for reasons that were not written down. 'We stopped testing urgency messaging because three separate experiments showed it backfired with our user base.' That reasoning is critical for the next team, but if it is stored only as a memory, the next team will try urgency messaging again, waste a quarter, and rediscover what was already known.

Ask your team: Where are the reasons behind our major programme decisions documented? Not the decisions themselves. The reasoning. If the reasoning is not recorded, future teams will either repeat past mistakes or make decisions without context.

The quality standard. Many programmes rely on one person to maintain quality. They review the experiment plans. They push back on weak hypotheses. They insist on decision protocols. When they leave, the standard drops because the standard was never embedded in a system. It was enforced by a person.

Ask your team: If our most experienced person was not involved in the review process for a quarter, would the quality of experiment plans stay the same? If the answer requires a pause, quality is not in the system. It is in the individual. And the system will not enforce what the individual used to insist on.

The stakeholder relationships. The person who manages upward, who knows which executives care about which metrics, who has earned trust with the CFO by presenting honest results, those relationships do not transfer automatically to a successor. The next person starts from zero, and the programme's credibility resets with them.

Why This Keeps Happening

It keeps happening because the alternative requires investment that most organisations do not make. Capturing knowledge in a structured, searchable way takes time. Building governance into templates and workflows takes design effort. Making the programme's history accessible to anyone rather than dependent on a specific person requires infrastructure, not just documentation. Most teams know this. They have talked about building a knowledge base. They have planned to document past learnings. But the day-to-day pressure to run the next test always wins, and the documentation project gets deferred quarter after quarter until it is too late.

Ask your team: How long have we been planning to improve our knowledge management? Has it happened? If the answer is more than two quarters of planning without execution, the problem will be solved reactively after a departure rather than proactively before one. Reactive is always more expensive.

What to Look For Right Now

You do not need to wait for a resignation to assess the risk. Run this check today. Pick a product area. Ask your team to produce a complete history of experimentation in that area: every test, every result, every learning, every decision. Without asking anyone verbally. From systems only. If the answer comes back in under thirty minutes with a complete, coherent record, your programme has institutional memory that does not depend on individuals. If the answer takes days, involves asking multiple people, produces an incomplete picture with gaps nobody can explain, or requires the programme lead to personally reconstruct the history, you have your answer. The programme's knowledge is stored in people. People leave. And when they do, the knowledge leaves with them.

The uncomfortable question: If I had to hire a replacement for this role, what would I give them on day one to get them up to speed? Is that material ready right now, or would we have to create it after the person gave notice? If the onboarding material does not exist and would take weeks to assemble, the programme is one resignation away from starting over.

What to Do About It

This is not solved by asking the team to document more. Documentation is important, but unstructured documentation, scattered across tools and files, is only marginally better than no documentation. The person who created it can navigate it. Everyone else cannot. What solves it is infrastructure that captures knowledge as a natural byproduct of doing the work. When an experiment is completed, the system requires a learning to be recorded in a structured format that is searchable by anyone. When a decision is made, it is logged against the experiment it relates to and the objective it serves. When a new team member joins, they can query the programme's full history by product area, objective, or theme without relying on a colleague's memory. This is not glamorous work. It does not produce a visible deliverable that leadership can point to in a quarterly review. But it is the difference between a programme that compounds knowledge over years and a programme that resets every time someone changes roles. The question for any leader is simple: is this programme built to outlast its current team, or does it depend on the specific people running it today? If it depends on the people, it is more fragile than it appears, and the cost of that fragility will become apparent at the worst possible moment.