The compounding cost of starting from scratch every time

Part of a single argument: the engagement gap is a workload problem.

There is a specific cost that almost never appears in anyone's estimate of what engagement takes, and it is usually the largest single item: the cost of building something that already exists.

Not similar to something that exists. The same thing, built before, by a colleague, possibly more than once, and rebuilt now because nobody could find it or trust it.

A test worth running

Take two people on your team who run comparable sessions. Ask them each, independently, to prepare something on the same topic. Then compare what they produced.

Almost every team that runs this exercise is embarrassed by the result. The overlap is typically most of the material, expressed differently, at full cost to both people. Where the two versions differ, the differences are usually not improvements but accidents of who happened to write it.

That overlap is your duplication rate, and it is the clearest number available about how much of your preparation budget is being spent on work that had already been done.

Why duplication is structural rather than lazy

It is tempting to read this as a discipline problem. It is not, and treating it as one produces filing policies that nobody follows.

People rebuild because rebuilding is more predictable than searching. Searching has an uncertain payoff: you might find nothing, you might find something you cannot evaluate, you might find something almost right which is often worse than nothing. Rebuilding takes a known two hours. Under deadline pressure, a known two hours beats an uncertain twenty minutes almost every time.

This means the fix is not to exhort people to search first. It is to make searching reliably faster than rebuilding, including the time spent judging whether what you found is usable. That bar is higher than most shared drives clear.

The compounding part

Duplication is not a fixed tax. It grows, for two reasons.

The first is volume. As a team runs more sessions, the amount of existing material grows, so the proportion of any new session that could have been reused grows with it. The waste rises even if behaviour is constant.

The second is divergence. Every independent rebuild creates another version, which makes future searching harder and future evaluation slower, which makes rebuilding relatively more attractive still. The problem feeds itself. Teams that have been running sessions for five years without a shared library are usually in a worse position than teams that have been running them for one.

What reuse actually requires

Three things, and the third is the one people skip.

Contribution has to be automatic. Any library that depends on a separate act of uploading will be maintained enthusiastically for a fortnight. If saving your work is the act of contributing, the library fills itself.

Finding has to beat rebuilding. Not merely work. Beat rebuilding, on the clock, including evaluation time.

Results have to be judgeable at a glance. This is the neglected one. A filename tells you nothing about whether a session was any good. Who ran it, when, with what size of group, and how it went are what let someone decide in ten seconds instead of ten minutes. Without that, you have a searchable pile rather than a library.

The only intervention that gets cheaper

Almost everything else in this blog reduces a constant cost. Automating reminders saves the same amount every month. Simplifying joining saves the same fraction of every audience.

Reuse is the exception. Every session added to a shared library lowers the cost of the next one, which is the opposite of how preparation normally behaves. The return grows with use, and it grows fastest for the teams that run the most sessions, which are the teams under the most pressure.

That is why, of everything discussed here, this is the one to fix first. Not because it is the most broken, but because it is the only one where the fix appreciates.