Capturing tribal knowledge before your senior tech retires

Every service company has someone who knows things nobody wrote down. Which building has the shut-off in the wrong closet. Which customer will call the owner if a tech arrives after four. That the rooftop unit at the medical centre has a factory board revision that behaves differently from every other one in the fleet.

That knowledge is a real asset and it does not appear on any balance sheet. It also has an expiry date, which is the day that person retires, quits, or goes to a competitor.

Why the obvious approach fails

The instinct is to sit the senior tech down and have them write it all out. This almost never works, for reasons worth being honest about:

• It is unpaid, unbilled work at the end of a long day, competing with going home.
• They cannot enumerate it. Expertise is largely tacit — it surfaces when a situation triggers it, not when someone asks "what do you know?"
• The output is a document nobody opens. A 40-page binder is not reachable from a crawlspace.
• It signals what it looks like it signals. Being asked to write down everything you know reads as being made redundant, and people slow down accordingly.

Capture at the moment of work instead

The realistic version is to improve what already gets written during the job, then make it findable. Your techs are already producing job notes. In most shops those notes are thin because nobody has ever read one back to them, and because the field is a box on a form rather than a question.

Two changes that cost nothing:

1. Ask a specific question instead of providing a blank box. "What would the next tech need to know before walking in?" produces markedly better notes than "Notes".
2. Close the loop out loud. When a note saves someone a return trip, say so in front of the team and name who wrote it. Notes get written when writing them is visibly worth something.

Then do a structured debrief, not an open one

For a tech who is genuinely leaving, an open-ended interview produces nothing. A structured one, anchored to real accounts, produces a great deal — because expertise surfaces in response to a specific situation.

Pull their last two years of jobs, take the top twenty accounts by revenue or by trouble, and walk them account by account with four questions:

• What is unusual about this site that is not written anywhere?
• What went wrong here before, and what actually fixed it?
• Who do you call there, and who do you avoid?
• What would you tell a tech going there for the first time?

Record it and have someone else transcribe it into the job records for those accounts. An hour a week for a month, done against a real list, beats any amount of "please document your knowledge".

The findability half, which is usually the real problem

Most companies have far more written down than they think. It is in ten years of ticket notes, closeout PDFs, and email. The problem is rarely that nobody wrote it — it is that retrieving it takes longer than re-deriving it, so nobody bothers.

A practical test: pick a site your team last visited two years ago and time how long it takes a technician to find out what was done. If it is more than a minute, the knowledge is technically retained and functionally lost, and every future visit is paying to rediscover it.

What is worth keeping, and what is not

Not everything deserves capture. Skill does not transfer through documents — how to braze well is learned by brazing. What transfers well is anything site-specific, customer-specific, or equipment-specific:

• Site quirks: access, keys, shut-offs, the panel that is mislabelled.
• Equipment history: what has failed here before and what was tried.
• Customer context: who authorises work, what they care about, past disputes.
• Workarounds: the model with the known board issue and the fix that holds.
• Supply intelligence: who actually stocks the part locally.

That list is deliberately narrow. Attempting to document craft is how these projects die; documenting facts about places and machines is achievable and is where the value is anyway.