Sharing Research Artefacts Across a Team
Why a good signal, backtest, or dataset transformation built by one researcher so often stays trapped on that researcher's laptop — and what it takes to actually make it reusable by the rest of the team.
A researcher spends three weeks building a genuinely useful transformation of a messy dataset, or a well-validated volatility estimator, or a clean backtesting harness for a particular strategy family. It works well, it's used in one project, and then — unless something specific happens next — it effectively disappears, because it never left that researcher's personal environment in a form anyone else could pick up.
The idea
Research artefacts — reusable code, cleaned datasets, trained models, standard analyses — decay in usefulness the moment they exist only inside one person's working directory, under filenames only they understand, with dependencies only installed on their machine. Sharing an artefact isn't the same as sending someone the file; it means the artefact has a stable location the rest of the team knows to check, a description of what it does and what its known limitations are, and enough packaging (clear inputs and outputs, no hidden hard-coded paths) that another researcher can actually use it without needing to ask the original author.
The barrier to this is rarely technical — most teams have somewhere artefacts could live, whether that's a shared code library or an internal wiki. The barrier is that packaging something for reuse takes real extra time beyond what's needed to finish the original project, and that time has no deadline forcing it to happen, unlike the original deadline-driven research itself. It's the same underlying dynamic as research debt: a shortcut that costs nothing visible today and costs the whole team real time later, paid by whoever independently reinvents the same thing months afterward because they didn't know it already existed.
A concrete example
A researcher builds a careful adjustment for corporate actions — handling splits, dividends, and symbol changes correctly — as part of one project, buried inside that project's private codebase. Eight months later, a different researcher on the same team, working on an unrelated signal, discovers a corporate-actions bug in their own results and spends a week rebuilding essentially the same adjustment logic from scratch, unaware it already existed. When a team member later notices the duplication and moves the original logic into a shared internal library with a short README, three more projects over the following year use it directly, at zero additional cost to any of them.
What this means in practice
Treating "package this for the team" as an explicit, budgeted step at the end of any research project — not an optional nice-to-have squeezed in if time allows — is what actually gets artefacts shared rather than merely built. A short internal registry or index of what already exists, even an informal one, also matters: a well-packaged artefact nobody knows to look for provides almost as little value as one that was never shared at all.
A research artefact isn't shared just because it technically could be found — sharing means a stable location, clear documentation of what it does and its limitations, and packaging that lets someone else use it without asking the original author. Skipping this step is a form of research debt paid later, usually by a colleague reinventing the same work.
Further reading
- Sculley et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS (2015)