Think about the person on your team who tuned your hardest methods. The transfer that only works because they know the DMSO run needs a slower aspiration. The reagent that foams unless you back off the blowout. The correction curve they rebuilt from scratch after a firmware update landed one March. Almost none of that is written down anywhere a colleague could find it. It lives in their experience, and one day they hand in their notice.
This is the most expensive thing a departing automation scientist takes with them, and it never shows up on an asset list. The instruments stay. The protocols still run, right up until a reagent lot changes or an update lands and a setting needs a nudge that nobody else knows how to make. What left the building was not a value in a config file. It was the reasoning behind the value.
Why the knowledge stays in one head
It is tempting to call this a discipline problem, as if people simply cannot be bothered to document their work. That is not what is happening. The knowledge stays tacit for a reason that is entirely rational in the moment: for the person who tuned the method, remembering is faster than writing it down. When you are the one who learned that this tip type over-aspirates and that this solvent needs an extra settling delay below ten microliters, your own memory is the shortest path to a working run. Documentation is overhead stacked on top of work you have already finished.
So every hard-won adjustment stays personal. The tweak that fixed a foaming issue, the late evening spent tracing a bad plate back to a changed ethanol batch, the instinct for which parameters are load-bearing and which were left at their defaults. None of it gets captured, because capturing it was never made cheaper than simply knowing it. As long as that stays true, tacit knowledge wins every time.
What captured actually has to mean
A parameter value on its own is close to useless to the next person. Aspiration speed set to 450 microliters per second tells them what you did, but not why, and the why is the entire point. Real capture answers three questions, and a value that answers only the first is barely captured at all.
- What is the setting: the concrete value, stated per instrument, per liquid class, and per volume range, not a single number pretending to hold everywhere.
- Why is it that value: the physical reason behind it, whether that is viscosity, volatility, foaming, surface tension, a firmware quirk, or a batch variation someone chased down late one evening.
- How do you know it is right: the evidence, meaning the gravimetric results, the coefficient of variation you measured, and ideally the failure you saw at the setting you rejected.
When a parameter carries all three, it stops being tribal knowledge and becomes something a new hire, an auditor, or a validation team can actually use. That is the difference between trust me, it works and here is why it works, next to the data that shows it.
Play the resignation forward
The cost of skipping this is easy to underestimate, because it stays invisible for a while. Your specialist leaves. For weeks or months nothing breaks, because the methods run exactly as they were left. Then a supplier changes a formulation, or a vendor pushes a firmware update, and a method that used to pass starts drifting. Now someone has to rediscover, by trial and error, what the previous person learned over a year. Runs fail. Samples and reagents get wasted. Timelines slip. Worst of all, nobody can say with confidence which parameters were deliberate and which were never touched, so every knob is suspect at once.
You did not lose a laptop, which you could have replaced in an afternoon. You lost the map that told you which paths had already been walked.
Make capture cheaper than remembering
Software teams solved a version of this problem long ago. Nobody sane keeps the critical configuration of a production system in one engineer's memory. It goes into version control, with a history and a reason attached to every change, so anyone can see not just the current state but how it got there and why. Liquid class parameters deserve the same treatment, because they are engineering artifacts, not personal know-how.
- Treat the value, the reason, and the evidence as one record: if the why and the proof do not travel with the number, you have only postponed the rediscovery.
- Attach the reason to every change, not just the final value: a parameter with no rationale is one the next person is afraid to touch and afraid to trust.
- Keep a real version history: a shared drive full of files named lc_DMSO_final_FINAL_v2_fixed is a record of panic, not provenance, and it cannot tell you which version produced a given plate.
- Lower the cost of capturing below the cost of remembering: if writing it down is slower than holding it in your head, no policy will save you, because people take the faster path under deadline.
None of this makes the parameters harder to change. It makes them safe to change, because the next person inherits your reasoning along with your numbers. The habit worth building, long before anyone hands in their notice, is storing them that way from the start.
When your best automation scientist leaves, the hardest thing to replace should be their judgment on the next problem, not their memory of the ones they already solved.