Capturing Knowledge from Retired Strategies
Why a firm should write down what it learned from a strategy before shutting it down and archiving the code — otherwise the same dead end tends to get rediscovered, expensively, a few years later.
A strategy gets shut down — its edge decayed, a regime shift broke its assumptions, or it simply never made enough money to justify the capital it used. The code gets archived, the model is removed from the inventory, and everyone moves on to the next idea. What usually doesn't happen, and should, is anyone writing down why it stopped working and what a future researcher should know before trying something similar. Two years later, a new hire proposes almost the same idea, spends three months rebuilding it, and rediscovers the same flaw the hard way.
Knowledge capture is the discipline of closing that loop. When a strategy is retired, someone — usually the researcher who owned it, sometimes with input from risk or the reviewer who signed off on it originally — writes a short retrospective: what the strategy tried to do, why it eventually stopped working, whether the failure was in the idea itself or in how it was implemented, and what a related idea would need to do differently to avoid the same fate. This isn't the same as the model document written at launch; it's the after-action version, written with the benefit of having watched the strategy actually run.
The value compounds across a firm's history. A research team that has been operating for a decade and never captured this knowledge is, in effect, starting from partial amnesia every time someone has a new idea — nobody remembers that a similar signal was tried in 2019 and failed for a specific, well-understood reason. A firm that does capture it builds a genuine institutional memory: a library of things that didn't work and why, which is at least as valuable as the library of things that did, because it saves the much larger cost of researcher time spent re-treading the same ground.
The habit is easy to skip because retiring a strategy already feels like a loss, and writing a retrospective about it can feel like dwelling on a failure rather than moving on. Treating it instead as a routine, required step — as automatic as archiving the code — is what makes the practice actually stick rather than depending on individual researchers' discipline.
Retiring a strategy without writing down why it stopped working means the same dead end is likely to be rediscovered later, at real cost in researcher time. A short, required retrospective at retirement — what failed, why, and what to watch for next time — turns individual failures into institutional memory.
The retrospective is easy to skip precisely because it feels like documenting a failure rather than a success. Firms that only write things down when a strategy works end up with a library that's systematically missing the lessons that would save the most time.
Further reading
- Federal Reserve SR 11-7, Guidance on Model Risk Management