HTM's Tribal Knowledge Problem: Your Knowledge Base Is a Phone Number
Every HTM department has one. Maybe three. The person whose phone rings when a tech is standing in front of a device that will not behave.
The call takes four minutes. The senior tech asks two questions, says check the connector behind the panel before you pull the board, and the problem is solved. The younger tech gets the machine back in service and closes the work order: "Replaced board, tested OK."
That four-minute call was the most valuable thing that happened in your department that day. And it is gone. Never in the CMMS, never in a manual, never in a training module. It moved from one head to another and left no trace.
This is what people mean when they say HTM runs on tribal knowledge. It is not a figure of speech. Your real knowledge base is a small number of phone numbers, and everybody knows which ones.
Where does HTM knowledge actually live?
Not in your records. Look at the systems a new BMET is handed on day one and ask what each one teaches.
The CMMS holds thousands of work orders. Open a hundred for your most troublesome asset type and read them the way a new hire would. They will tell you a board was replaced. They will not tell you what was checked first, what ruled out the obvious cause, or what the false lead was.
Service manuals are better, but they sit somewhere else. Across HTM programs we hear the same structure: manuals live in a separate subscription repository, some documents are private to the institution, and none of it is connected to the work order the technician is standing in front of. Finding the right procedure is a separate errand from doing the job.
That leaves the phone. So the phone is what gets used.
Worth saying plainly: the technicians are not the failure here. Nobody becomes a biomed because they love typing. Work order documentation was built to prove a job was completed, for compliance and for history. It was never built to teach anybody anything, and it does the job it was designed for.
Why is this worse in HTM than in other fields?
Because of the arithmetic on both ends.
The experience side is leaving. AAMI's demographic survey of more than 7,000 HTM professionals found that 47% of staff are 50 or older, and among managers it is closer to six in ten.
The replacement side is not keeping up. The Bureau of Labor Statistics projects about 7,300 openings a year for medical equipment repairers, while the academic pipeline shrinks: at least 30 BMET programs have closed in the past five years, leaving 23 states without a BMET-specific pathway.
So the people who answer the phone are retiring, and the people who call them are arriving faster than they can be taught. The retirement side of this got a full treatment in 24x7 recently. This piece is about the other half: not the knowledge that leaves at a retirement party, but the knowledge that evaporates every day, on every call nobody recorded.
Why do knowledge bases and wikis fail in HTM?
Most departments have tried. A shared drive. A SharePoint site. A wiki. A "lessons learned" folder somebody set up with real enthusiasm in 2019 and nobody has opened since.
They fail for one structural reason: they ask for a second job.
Writing a knowledge base article is work you do after the work. It competes with the next six open work orders, and it loses every time. That is not apathy, it is arithmetic. Documentation already eats roughly a fifth of a technician's day in our field observations across HTM teams, about 15 minutes per work order across five or six jobs. Asking for a thoughtful write up on top of that is asking for a twenty-fifth hour.
And notice which jobs suffer most. Multiple service organizations tell us the same thing: repair work orders carry the most inconsistent notes of any job type, and technicians spend more time typing on a repair than on a PM. The corrective work, where all the interesting reasoning lives, is exactly where the record is thinnest and the typing burden is highest.
Don't failure codes solve this?
They solve a real and different problem, and it is worth being precise about which.
In a recent public exchange on LinkedIn, Binseng Wang described the practice from his own ISO career: every technician trained and required to assign a failure cause code to every work order before it could be closed, with free text discouraged as hard to interpret. He points to the Law of Large Numbers. Judge averages and medians across many work orders, not individual entries.
He is right that codes are what make work comparable. You cannot benchmark free text.
But a code answers "what failed." The question the tech on the phone is asking is "how did you find it." Those are different fields, and only one of them exists.
There is a second wrinkle. Averaging across a large sample washes out random error, not systematic error. If a code gets picked at the end of a shift, from memory, because it was the closest option in a dropdown, the same wrong code gets picked the same way a thousand times. More data does not fix that. The two things are not in competition: rich capture is how a code gets assigned correctly, and the code is how the captured work becomes comparable.
What can a department actually do about it?
None of this requires new headcount.
Name the phone numbers. Ask your team who they call when they are stuck. You will get two or three names. That list is your real knowledge base, and it is also your single point of failure. Write down what each of those people is the go-to for, and you have a map of exactly what your department loses and when.
Capture the doing, not the summary. The phone call disappears because documenting it is a separate act from the work. Every fix that operates after the moment, templates, mandatory fields, audits, wikis, is trying to recover detail that was already gone.
That last one is what Leera AI is built for. Technicians talk while they work, hands free, and complete documentation writes itself into the CMMS. The reasoning gets recorded because saying it out loud is already part of the job, not a task waiting at the end of the shift. What a senior tech would have said on the phone ends up in the record instead of in the air.
Your best technicians will retire. What they know does not have to.
FAQ
What is tribal knowledge in healthcare technology management? The undocumented expertise that lives in experienced technicians' heads: which model throws a phantom alarm when a latch wears, which dead zones are network problems rather than device problems, what to check first on an intermittent fault. It moves verbally between people and rarely appears in the CMMS or any manual.
Why don't work orders capture troubleshooting knowledge? Because they were not designed to. A work order exists to prove a job was completed, for compliance and asset history. It records the outcome, not the path. Add that most documentation is written from memory at the end of a shift, and the reasoning is gone before anyone sits down to type.
How do you capture tribal knowledge before a technician retires? Scheduled retirements are the easy case, because you know the date. Sit the departing tech down with your ten most troublesome assets and record what fails, what to check in what order, and what the false leads are. The harder case is the knowledge that leaves daily, in phone calls and hallway conversations, which only capture at the point of work will reach.
Does AI documentation replace experienced BMETs? No, and the technicians we work with are clear about why. The record has to belong to the person who carries the liability for it. One service leader put it plainly: if the AI wrote it, I did not mean it. The tech narrates, reviews, and owns the record. AI removes the typing, not the judgment.
Dima Okhrimchuk is the founder of Leera AI, a voice-first AI copilot for healthcare technology management teams.