A lesson I learned the hard way.
There are moments in business that stay with you forever.
For me, one of those moments wasn't winning a major contract or landing a new customer. It was years ago when one day our lead engineer told us he was leaving.
Like most business owners, my first reaction was simple: "How do we keep him?"
We looked at salary, discussed his future and explored every option we could think of. We genuinely didn't want to lose him.
But he'd made his decision.
At the time, I thought we had a recruitment problem. Looking back, I couldn't have been more wrong.
We had a knowledge problem.
And it took me several months to realise just how serious that problem really was.
The strange thing was, everything seemed fine.
The jobs still came in. The vans still went out every morning. The engineers carried on doing what they always had.
Then, slowly, things began to change.
The office phone started ringing more often — not from customers, but from our own engineers. They were calling for technical advice on problems they would never have asked about before.
Jobs that had once been completed in a single visit suddenly took longer. Fault-finding became slower. Engineers spent more time discussing possible causes before they even picked up a screwdriver.
It wasn't dramatic. There wasn't one catastrophic event that made everyone stop and take notice. Instead, it was death by a thousand cuts.
An extra thirty minutes here. Another return visit there. A few more technical support calls every day. Over time, those small delays became a noticeable drop in productivity.
We even saw the effect on turnover.
That's when it finally hit me. We hadn't simply lost an engineer — we'd lost thirty years of experience.
The engineers we still had were excellent. This wasn't about competence. It wasn't about work ethic. It certainly wasn't about intelligence.
The difference was experience.
People outside engineering often imagine fault-finding is about knowing the answer. It isn't. Often, it's about knowing where to begin.
Any engineer can test every component until they eventually find the fault. An experienced engineer has already ruled out half of those possibilities before they've even opened the control panel.
That's not luck. That's pattern recognition.
It's thousands of previous breakdowns stored somewhere in the back of your mind. It's remembering the machine that behaved almost the same way ten years ago. It's knowing that one controller always develops the same fault after a power surge. It's recognising that a symptom points towards a loose earth rather than a failed circuit board.
That's the difference experience makes. They simply know where to look first.
One of the biggest misconceptions in engineering is that everything important is documented.
It isn't.
Service manuals explain how equipment was designed to work. Experienced engineers understand how equipment actually behaves after twenty years in the field.
They know about the customer who modified the machine years ago. They remember the temporary repair that quietly became permanent. They know which page of an old manual matters — and which instructions no longer reflect reality.
Modern equipment wasn't usually our biggest challenge. It was the legacy systems, the old controllers, the machines that only appeared once every few years. The equipment that existed on ageing paper manuals, faded wiring diagrams and, quite often, inside one person's memory.
Our lead engineer seemed to have an entire library stored in his head. Not because he had a photographic memory — because he'd spent decades solving problems.
This is probably my biggest regret.
Engineers would ring him from site and ask for help. Most of the time he'd solve the problem in minutes.
"Check that relay."
"Replace that sensor."
"Look at terminal X12."
The engineer on site got the answer they needed and everyone moved on.
But what we didn't capture was the thinking behind it. Why that relay? Why not the circuit board? Why did he ignore three other possible faults?
The truth is, when you're busy, nobody has time for a twenty-minute explanation. Production is stopped. Customers are waiting. You need the answer.
So the answer gets shared. The judgement doesn't.
Over the years, that judgement stayed inside one person's head. The day he left, it walked out of the door with him.
People often ask what I'd do differently.
The answer isn't complicated. I wouldn't ask him to write another manual.
I'd ask him to explain how he thinks. I'd record every troubleshooting conversation. I'd ask why he chose one route instead of another. I'd digitise every old paper manual sitting on a dusty shelf. I'd scan every wiring diagram. I'd keep every service report. I'd preserve every technical conversation.
Because that's where the real value is.
Not just in the answer. In the reasoning.
Over the years I've come to believe something quite strongly.
Most businesses insure their vans. They insure their buildings. They insure their stock. Yet one of their most valuable assets walks out of the door every evening: engineering knowledge.
And very few businesses treat it like the gold it really is.
The best engineers often don't realise how valuable their knowledge has become. To them, it feels obvious — they've seen the same faults hundreds of times. They instinctively know where to start.
What feels obvious to them is the result of decades of learning, making mistakes, solving problems and building judgement. That judgement is one of the most valuable assets any engineering business owns.
For years, I thought there wasn't a practical solution.
Even if we'd recorded those conversations, what would we have done with hundreds of hours of audio? Even if we'd scanned every manual, who was going to search thousands of pages quickly enough to help an engineer standing beside a broken machine?
The technology simply wasn't there.
Today, it is.
Modern AI can understand technical manuals, wiring diagrams, service reports, troubleshooting conversations and engineering notes. More importantly, it can connect them together. It can preserve not just documents, but context. Not just answers, but reasoning.
That's the real reason I built Tarin.
Not because I wanted to build another AI platform. Because I'd lived through what happens when decades of engineering knowledge disappear almost overnight. If we experienced that problem, I knew thousands of other engineering businesses were facing exactly the same challenge.
If there's one thing I'd encourage every engineering business to do this year, it's this:
Don't wait until someone hands in their notice.
Knowledge doesn't disappear overnight. It disappears one retirement, one resignation and one forgotten conversation at a time.
Treat your engineering knowledge like the asset it truly is. Because one day, someone will leave.
The question isn't whether they'll walk out of the door. The question is whether decades of experience will walk out with them.
And if we can stop that from happening, then businesses of every size — from five engineers to five hundred — will be better equipped to compete, grow and pass their knowledge on to the next generation.
If you'd like to see how Tarin could help you capture and preserve your team's hard-won expertise, book a demo.
Find out how AI trained on your documentation can support your team. Get started now or request a personalised demo.
AI StrategyAI doesn't need to replace your team — it needs to handle the repetitive questions that slow them down. Here's how first-line AI support actually works in practice.
Read article →
ImplementationMost AI failures aren't technology problems — they're data problems. When AI doesn't know your business, it gives plausible-sounding answers that are completely wrong.
Read article →
IndustryOff-the-shelf AI gives field engineers shallow, generic answers. Custom AI trained on your technical library delivers equipment-specific guidance that actually helps.
Read article →