What happens when tribal knowledge leaves the tribe?

Here’s an exercise I’d suggest to any engineering leader. Imagine your five most experienced designers walked out the door tomorrow. Set aside the projects they’re managing and the workload they’d leave behind, and think only about what they know. Which decisions would suddenly become difficult, which exceptions would nobody understand, and who would everyone else start asking for help?

For most companies, the answers are uncomfortable. They’re also useful, because they show where the organization’s knowledge actually lives. In many design departments, a surprising amount of it lives in a few people, and the company doesn’t find out how much until one of them leaves.

Design automation is one of the few tools that forces that knowledge into the open. That isn’t because software is smarter than experienced people. It’s because software can’t “just know.” To automate a design process, someone has to explain every decision in it.

Documentation describes the process. Experience knows when it doesn’t apply.

Most established companies have plenty of documentation: design standards, procedures, specifications, checklists, templates and years of archived projects. It’s reasonable for management to look at all of that and conclude that the company’s knowledge has been captured.

But documentation and knowledge aren’t the same thing. A design standard might list the acceptable parameters for a component, while an experienced designer knows that one particular combination of those parameters tends to cause trouble in manufacturing. The documentation is technically correct. It just doesn’t contain the context that years of experience provide.

Some of that context isn’t a set of instructions at all. It’s pattern recognition. An experienced designer can glance at a drawing and know something is wrong before they can say why, because they’ve seen hundreds of similar cases. They also tend to know why a rule exists, which means they know when it no longer applies. Someone who only knows the rule will keep following it long after the reason for it has disappeared.

Over time, the documented process and the real one drift apart. Products change, manufacturing methods change, and people adapt faster than the manuals get updated. The official process might have six steps while experienced staff actually perform ten. Nothing breaks, so nobody notices the gap, and that gap is where tribal knowledge lives.

The knowledge that matters most lives in the exceptions

The standard case is the easy part to document. If a product has a standard configuration, or a calculation is always done the same way, it can be written down.

The exceptions are harder: the dimension just outside the normal range, two customer requirements that conflict, a configuration that technically works but causes problems on the shop floor, a request nobody has made before. These are the situations where experienced people earn their keep. A procedure might say “contact engineering.” The experienced engineer already knows what the problem is and how to solve it.

The most dangerous version of this is the dependency nobody knows exists. A designer may be making dozens of small decisions a day that no one else recognizes as decisions. The output looks consistent, so the process looks standardized, when in fact the consistency depends on one person’s judgment. When that person leaves, projects take longer, rework creeps up, and people start saying the company used to have a better way of doing things.

The warning signs are usually visible well before then:

• Everyone knows to ask one particular designer when a certain type of project comes in.
• Certain projects get noticeably harder when a specific person is on vacation.
• The process is documented, but experienced staff rarely follow it exactly as written.
• Some design decisions are explained only as “just the way we do it.”

None of these mean the organization is poorly run. More often, they’re signs of a highly experienced one. The problem is that the experience is concentrated in individuals rather than built into the company’s systems.

You can’t hand over 20 years of experience in a few weeks of meetings

Retirement itself isn’t the problem. The problem is that many companies don’t recognize how much needs to be transferred until the departure is close. Then they schedule meetings, write notes and run training sessions, and run into the biggest limitation of all: people don’t know everything they know.

Ask an experienced designer why they made a particular decision and the answer may be “the alternative causes problems” or “it just doesn’t look right.” That isn’t evasion. After thousands of repetitions, much of their expertise has become intuitive, and it was never stored anywhere formal to begin with.

The cost of losing it rarely shows up as one large expense. It arrives in small pieces: a new hire who takes longer to become productive, a design that goes through extra revisions, a manufacturing problem nobody saw coming, a customer who gets an answer that isn’t quite right. The senior people who remain absorb much of it, spending more of their time answering questions and checking work. The company hasn’t just lost one person’s capacity. It has spread the cost across everyone who’s left.

The better time to capture knowledge is while the person is still applying it, on real projects with real decisions in front of them.

Automation forces the organization to explain itself

When you try to automate a design process, you can’t write “the designer knows what to do here.” The software needs to know. So every important decision has to be examined: what conditions drive it, why one option is chosen over another, which exceptions matter and when the system should hand the decision back to a person.

In practice, this becomes a kind of organizational archaeology. You dig into a process everyone thought they understood and find layers of experience that were never recorded. Some of it turns out to be obvious once it’s explained, some is surprising, some is outdated, and some is real best practice. That discovery has value before a single line of code is written.

Take a designer who always makes the same choice when several conditions occur together. They may not think of it as a rule. Asked why, they explain that a particular geometric relationship tends to cause a manufacturing problem. Now the company knows something it didn’t know it knew, and the system can apply that rule to every relevant order instead of relying on one person to remember it on every project.

This is why experienced designers should be at the centre of an automation project, not on the receiving end of it. They become the teachers. The development team asks questions, the designer explains the reasoning, the team turns it into rules or algorithms, and the designer tests the result against real projects. Their expertise ends up shaping far more work than they could ever complete themselves.

Not everything should become software

The goal isn’t to turn every decision an experienced person makes into code. Some decisions depend on context that’s hard to quantify, on customer relationships or on preference. Those should stay with people.

It’s also a mistake to assume everything experienced staff do is best practice. Some habits persist only because nobody has questioned them. That matters, because automation makes bad processes very efficient. One designer’s wrong assumption might affect one project. The same assumption built into a system can repeat across thousands.

So a good project doesn’t simply reproduce the existing process. It examines it, separating engineering requirements from customer preferences, workarounds for constraints that no longer exist, and conventions someone set years ago. Once that’s clear, each piece of knowledge can go where it belongs: some into documentation or training, some into design standards, some into software, and some left deliberately with an experienced person.

Every correction teaches the system something

Most companies store the final result of a design: the model, the drawings and the production files. Very few store the reasoning that produced it.

An automated system can capture more of that reasoning. When the system proposes a design and the designer changes it, the difference between the two contains information. It may point to an algorithm that needs refining, a new rule to formalize or an edge case nobody had considered. Captured across hundreds of orders, those corrections show where the system is reliable and where people still need to step in. Feed them back in and the system improves, designers make fewer corrections, and the cycle repeats. Knowledge that used to vanish when a project closed becomes a source of ongoing improvement.

It changes onboarding too. A new designer has to learn two things: their profession and how your company applies it. The first comes from education and experience. The second usually comes from years of asking questions and learning from mistakes. When the company’s repeatable knowledge is built into its systems, new designers work within those rules from their first day. They still need to develop judgment, but they don’t have to rediscover everything the company already knows.

Make the knowledge belong to the company

There’s a difference between an employee knowing something and the organization knowing it. Companies often say they have decades of experience, and they do. The harder question is how much of that experience would remain if the people who built it left.

Experience becomes organizational capability only when the company has a way to retain and apply it. For repeatable decisions, design automation is one of the most effective ways to do that. A decision becomes a rule, the rule becomes part of a system, and the system applies it consistently on every order.

None of this is about eliminating tribal knowledge. Your best people should be valuable for their judgment, not because they’re the only place the company stores what it knows.

So go back to the exercise at the start. If your five most experienced designers walked out tomorrow, the drawings, the CAD files and the procedures would all still be there on Monday morning. The question is whether anyone could still tell you why they were done that way.

People will retire, change roles and move on. That part isn’t up to you. Knowledge that lives in a person retires with them, while knowledge built into your systems keeps working on every order, for every designer you hire next. You can’t keep your best people forever. You can make sure what they know outlasts them.