Most engineering businesses have more knowledge than they realise.
Manuals. Drawings. Service reports. Commissioning notes. Technical conversations. Experienced engineers who have spent decades solving problems.
The knowledge exists. The problem is that much of it is incredibly difficult to access. And some of the most valuable parts have never been written down at all.
After more than thirty years working in engineering, I've come to believe that one of the industry's greatest challenges isn't creating knowledge.
It's transferring experience.
There is an important difference.
Information Isn't Experience
Give two engineers the same technical manual and they don't suddenly have the same capability. The information is identical. Their interpretation of it isn't.
An inexperienced engineer might look at a faulty machine and begin testing possibilities. An experienced engineer can often look at the same symptoms and immediately rule half of them out.
They know where to begin.
Not because the answer appeared in a manual. Because they've seen something similar before. Perhaps ten years ago. Perhaps on a completely different machine. Perhaps they once made a mistake that taught them exactly what not to do.
That's experience. And it's incredibly difficult to document.
A manual might tell you which terminals connect to a sensor. Experience tells you which terminal to check first.
A wiring diagram shows how a circuit was designed. Experience recognises that somebody modified it fifteen years ago.
A service report tells you which component was replaced. Experience explains why the engineer suspected that component in the first place.
Information tells you what. Experience begins to explain why.
The Knowledge Inside People's Heads
For most of engineering history, experience has naturally lived inside people.
That's why apprenticeship has always been so powerful. A younger engineer works beside someone experienced. They watch. Ask questions. Make mistakes. Listen to stories.
Gradually, knowledge becomes understanding. Understanding becomes judgement. And eventually judgement becomes experience of their own.
There is nothing wrong with that model. In many ways, it's still one of the best ways to develop engineers.
The problem is scale.
An experienced engineer can only mentor so many people. They can only answer one telephone call at a time. They can only be in one place.
And eventually... they leave. They retire. They change company. Sometimes they simply forget.
When that happens, an engineering business can lose far more than an employee.
It can lose decades of accumulated judgement.
The Problem Rarely Appears Immediately
I've experienced this first-hand.
When an experienced engineer leaves, the business doesn't normally stop. The vans still go out. Jobs still get completed. Customers still call. Everything appears normal.
Then the small things begin.
Technical-support calls increase. Jobs take a little longer. Return visits become slightly more frequent. Engineers spend more time searching for information. Someone encounters an old piece of equipment and nobody quite remembers how it works.
None of these problems feels catastrophic individually. Together, they reveal something important.
The organisation knew less than it thought it did.
The knowledge hadn't belonged to the business. It had belonged to the person.
Documentation Only Solves Part of the Problem
The obvious answer is documentation. And good documentation is essential.
Engineering businesses should preserve manuals, drawings, service reports, commissioning information and technical notes.
But storing information isn't the same as preserving experience.
I learned this through years of technical-support conversations.
An engineer would ring an experienced colleague from site. "The door is doing this. What do you think?"
Within minutes, the experienced engineer might say: "Check that relay."
The engineer checks it. Fault found. Machine repaired. Everyone moves on.
The answer was transferred. The thinking wasn't.
Why that relay? Why not the controller? What part of the engineer's description pointed towards it? Which previous experience allowed three other possibilities to be dismissed?
That's the knowledge organisations repeatedly lose.
Not the answer. The reasoning behind it.
Experience Is Pattern Recognition
This becomes particularly obvious when experienced engineers encounter unfamiliar equipment.
A younger engineer might say: "I've never worked on one of these before."
An experienced engineer may never have worked on it either. But they recognise the principles.
A relay is still a relay. A normally open circuit still behaves like a normally open circuit. A sensor still has a function within the system. A motor still needs power and control.
The manufacturer may change. The terminology may change. The layout may change. The underlying engineering often doesn't.
That's why experienced engineers can sometimes solve problems on equipment they've never encountered before. They aren't remembering the machine. They're recognising the pattern.
This is one of the most important distinctions between information and experience.
Knowledge helps you understand something you've been taught. Experience helps you recognise something you've never seen before.
Businesses Are Relearning What They Already Know
This creates an enormous hidden cost.
Imagine one engineer solves an unusual fault today. Unless that experience is preserved effectively, another engineer may encounter the same fault next year and begin again.
They investigate. Test. Call somebody. Search through manuals. Eventually they reach the same conclusion. The machine gets repaired.
But the organisation has effectively paid twice to learn the same lesson.
Multiply that across hundreds of engineers, thousands of service visits and decades of operation.
Engineering organisations generate enormous amounts of experience. Very little of it compounds.
That's the problem we believe needs to change.
From Individual Memory to Engineering Memory
What if every successful diagnosis made the next diagnosis easier? What if every unusual fault became future guidance? What if every service report added to the organisation's understanding? What if the reasoning of experienced engineers could remain useful long after they retired?
That creates something different from a document library.
It creates Engineering Memory.
Engineering Memory is the collective engineering experience an organisation preserves and makes available to future engineers.
Manuals matter. Drawings matter. Service reports matter.
But so do conversations. Decisions. Troubleshooting history. Exceptions. Lessons. The small pieces of practical judgement that experienced engineers accumulate throughout a career.
For the first time, technology gives engineering businesses a realistic way to connect those things.
Where AI Fits
This is where artificial intelligence becomes interesting.
Not because AI can replace engineers. It shouldn't.
Engineering requires judgement. Responsibility. Context. Experience. And ultimately a human being must make the decision.
The opportunity is different.
AI can help organisations remember. It can make large volumes of technical information accessible. It can connect manuals with service history. It can surface previous solutions. It can help an engineer find relevant experience when they're standing beside a machine and need it.
That's the philosophy behind Tarin.
AI remembers. Engineers decide.
The technology isn't there to become the engineer. It's there to help the engineer benefit from experience that already exists.
Experience Should Compound
Every engineering business creates experience every day.
Every installation teaches something. Every breakdown teaches something. Every unusual fault teaches something. Every engineer eventually develops judgement that wasn't there when they started.
The question is whether that experience belongs only to the individual... or whether some of it becomes part of the organisation.
We believe experience should compound, not disappear.
Every repair should leave the business slightly wiser. Every generation of engineers should begin a little further ahead than the one before it.
Because engineering has never suffered from a shortage of knowledge. It has suffered from a shortage of knowledge transfer.
And for the first time, we may finally have the tools to change that.
If you'd like to see how Tarin helps engineering businesses build their Engineering Memory, book a demo.