I had a "Dave" moment last year. Dave was the only person who knew why a particular soldering jig had an extra shim, which supplier batches were safe to accept under a certain humidity condition, and which Excel macro to run to translate test outputs into the format the notified body expected. He left after 28 years with a quiet farewell and a box of tea. Three months later we were stuck in a CAPA about a recurring assembly error, trying to reconstruct decisions that had never been written down. Naja — this is avoidable, but only if you treat tribal knowledge as a deliverable.
How tribal knowledge disappears
This isn't accidental malice. It happens because organisations optimise for day‑to‑day throughput, not for explaining why things are done a certain way.
Typical patterns I see:
- A single engineer owns a niche work instruction, never updated in the QMS.
- Informal "workarounds" accumulate in personal notebooks or email threads.
- Supplier knowledge lives in the procurement person's head — "we trust Vendor X because they always send...".
- The Technical File contains the "what" (drawings, specs) but not the "why" (why that tolerance, why this supplier, why this inspection frequency).
Document and Record Control is supposed to stop this. To be fair, the requirement is clear in ISO 13485 and in MDR Annex II: technical documentation and associated processes must be controlled and available. In practice this means someone tasked with turning tacit decisions into controlled, traceable artefacts — not a passive folder called "engineering".
Why it matters — regulatory and practical
Regulators and notified bodies care about reproducibility and traceability. They will ask:
- How do you ensure consistent manufacture after key staff turnover?
- Where is the evidence that inspection criteria are adequate?
- How were non‑conforming trends investigated and closed?
Practically, lost know‑how shows up as:
- Rework and production delays while teams rediscover steps.
- Escalating CAPAs because root causes are shallow (we only fixed the symptom).
- Poor change control decisions because impact analysis lacks historical context.
- Supplier disputes when contract terms are ambiguous.
This is not theoretical. A thin Technical File that documents "measured tolerance = X" without the rationale can be vulnerable during an audit. Similarly, PMCF/PSUR activities are weaker when you lack the historical context that explains why you monitor a particular signal.
What I actually do (short, focused, pragmatic)
We can't document everything. So I prioritise and make documentation work for the people doing the work, not just for the auditor.
- Start with Document and Record Control as the first critical process. Make the output explicit: which tacit decisions must be formalised.
- Run knowledge capture sessions — short, recorded interviews with the person who owns the process. Use a template:
- What do you do step-by-step?
- Why is this step important (risk link)?
- What are acceptable exceptions?
- Which suppliers, tools, or macros are relied on?
- Who else knows this work?
- Convert the capture into controlled artefacts:
- Update SOP or work instruction (with traceability to the risk assessment and device specification).
- Add the recording or summary to the training record for successors.
- Link the change to the Design History File and Technical Documentation (Annex II).
- Use change control and CAPA as gates: any change that touches a documented area must trigger a CAPA‑driven risk assessment and traceability update.
- Reduce single‑person reliance by pairing and shadowing — not just once, but until the trainee completes a controlled task and is signed off.
Practical checklist you can action in a month
- Identify 5 "single point of failure" processes (assembly steps, supplier inspections, lab analyses).
- For each, schedule a 60–90 minute capture session with the owner and owner’s manager.
- Create one controlled SOP or annotated checklist per process. Put it under document control.
- Add a training record and a 3‑month refresher task to the QMS calendar.
- Link the SOP to the relevant risk controls in the risk management file (ISO 14971 mapping) and to the Technical File sections required by Annex II.
- Run a tabletop change control exercise: simulate a departure and walk through how the team would react.
Tools and workflow that help
You don't need a magic product, but connected workflow helps. In our QMS, tying the work instruction to the design requirement and supplier record meant that when a supplier changed, the system flagged impacted processes. That allowed us to launch a focused CAPA — automated CAPAs flagging impacted items saved us time. Traceability reduced the need to email around "Did Dave write about this?"
AI‑assisted capture (voice‑to‑text summaries) can help, but keep the loop "AI proposes, human approves" — the regulator needs reviewability and a controlled approval trail. Controlled, reviewable capture is what counts, not a dump into a shared drive.
Final thought
If you're a small QA/RA team and your backlog is mountains of "would be nice to document" items, start where the consequence is largest: sterile processes, supplier‑critical steps, and any part of the DHF that links to safety claims. Standardisation only works when it fits your process; a perfect template is useless if people won't use it.
So — how many "Daves" are on your org chart right now, and which one would create the biggest hole if they left tomorrow?
