When Experience Becomes a Dependency

When Experience Becomes a Dependency

What Happens When Critical Factory Knowledge Lives in People’s Heads

A factory can have the right machines, procedures and trained employees—and still depend on one person to explain how important work is done.

The problem often sounds harmless:

“Ask him. He knows.”

That sentence may represent valuable experience. It can also reveal a design gap: the system may not provide enough clarity.

A technician recognises an abnormal sound. An operator notices a machine behaving differently before an alarm appears. A maintenance engineer knows an isolation point needs extra attention. A supervisor understands how a process behaves in practice.

Experience is valuable. The question is where it adds judgement—and where it compensates for missing clarity.

1. Experience Is an Asset. Dependency Is a Design Question.

Complex manufacturing will always need experienced people. They notice variation, interpret abnormal conditions and recognise patterns that may not be fully captured in a procedure or database.

The distinction is between knowledge that genuinely requires expertise and knowledge the factory should already make accessible.

An experienced technician helping a colleague understand a difficult repair is useful knowledge transfer. Being repeatedly called to identify routine components or locate basic information is a different signal.

The second situation may mean information is missing, hard to access or disconnected from the task.

The UK Health and Safety Executive describes competence as a combination of knowledge, skills and experience, and notes that training alone is not enough. HSE guidance on training and competence.

The objective is not to remove the experienced person from the process. It is to understand why the process needs that person for routine clarity.

2. The Hidden Cost of Personal Knowledge

Consider a maintenance technician looking for a spare part. The catalogue exists. The asset record exists. Machine documentation exists. Yet the fastest route is to call an experienced technician who remembers the part number from previous breakdowns.

The task gets completed, but personal memory has connected information with action. During a shift change, machine modification or the technician's absence, the path to that information may no longer be obvious.

This can create several forms of dependency:

• Availability: Work waits for a particular person.
• Continuity: Knowledge becomes harder to access across shifts or teams.
• Consistency: Different people receive different explanations.
• Scalability: Adding people or equipment becomes harder.
• Improvement: Useful observations remain in conversation rather than becoming accessible for review.

Test for these effects when the same person is repeatedly needed to explain routine work.

The question is which knowledge belongs with the person, which belongs in the process and which should be available through the system.

3. Not All Knowledge Belongs in a Procedure

A common response to knowledge dependency is to document more. Sometimes that is appropriate. Sometimes it simply creates another document.

Start by distinguishing three forms of knowledge.

Standard knowledge includes equipment identification, routine checks, standard steps, approved specifications, SOPs and required records. It should not depend on knowing which colleague to ask.

Situational knowledge concerns changing conditions: what to check when an abnormal indication appears, how it affects the next step and when to escalate. It may need decision support, clear limits and a defined route for help.

Expert judgement involves decisions that depend on experience, technical understanding and context. Not every decision can—or should—be reduced to a fixed instruction. The organisation should recognise where expertise is required and develop it deliberately.

Each type needs a different response: standard knowledge may belong in procedures or information systems; situational knowledge may need training or escalation guidance; expert judgement should remain with competent people while being developed and transferred.

The objective is the right knowledge in the right place—not maximum documentation.

4. The Knowledge Transfer Test

A practical experiment can reveal where that boundary sits without creating a risky operational test.

Choose a routine task and a competent employee who normally performs or supervises it. Ask another competent employee, familiar with the area but not that task, to explain how they would approach it using the information normally provided.

The experienced employee observes rather than immediately filling every gap. Do not ask anyone to perform unfamiliar or safety-critical work without the required competence, authorisation and supervision. This is an information review, not an ability test.

Record what the second person cannot find or understand.

Was the equipment difficult to identify? Was an instruction missing? Was an exception known only through experience? Was the next decision dependent on a particular person? Did the process explain what should happen when conditions changed?

Map the result:

Task → Knowledge required → Where it lives → How it is accessed → What requires expertise

This is not an employee assessment. It is a way to understand knowledge continuity.

5. When Change Exposes the Gap

Knowledge dependency often becomes visible when the factory changes: a machine is modified, a process is revised, a new operator joins, another shift takes responsibility, a contractor takes over maintenance or a senior employee leaves.

The formal system may be updated while practical knowledge about exceptions or escalation remains informal. The procedure, machine, employee knowledge and information system may no longer match.

A machine modification may require the work instruction, asset information, visual identification and training to be reviewed alongside the drawing. A shift handover may need details not obvious from the work order. A contractor may need site-specific knowledge that an internal team takes for granted.

Knowledge continuity is therefore not only a training issue. It also depends on how changes are communicated and how current information is maintained and made available.

6. Factory UX: Can the Workplace Carry Some of the Knowledge?

Factory UX asks whether people can see, understand and act in the workplace. It connects human interaction with physical conditions, information and equipment interfaces.

Clear machine identification can remove a question. A logical visual system can remove a search. Point-of-work instructions can reduce unnecessary reliance on memory.

The practical question is:

How much of the expert’s explanation could the workplace itself provide?

Equipment labels, visual instructions, asset identification, navigation and clear status indicators can make routine information easier to recognise.

Factory UX does not attempt to make expertise unnecessary. It makes the surrounding environment clearer so expertise is available for situations that genuinely require it.

7. Factory OS: Making Knowledge Reach the Task

Other knowledge requires more than physical visibility.

Maintenance history, approved documents, equipment records, permits, workflow status and escalation paths may exist across separate systems. The information can be available without being connected to the decision being made.

This is where Factory OS becomes relevant.

BRIGS positions Factory OS as an operational information and coordination layer around workflows, maintenance, permissions and workplace controls.

The question is not simply, “Where is the information?” It is:

Can the person reach the relevant information when the decision needs to be made?

The answer may require a digital workflow, better records, clearer permissions or combined digital, physical and procedural changes.

8. Designing for Knowledge Continuity

Once the knowledge gap is visible, the intervention should follow it.

SEE how experienced people perform the work. Observe the task, decisions, information and exceptions.

CONNECT those decisions to machines, processes, information and other roles.

DIAGNOSE whether the gap involves missing information, usability, process design, training or genuine expert judgement.

DESIGN the right support: a visual reference, revised procedure, digital record, training or clearer escalation.

IMPLEMENT the change through workplace, procedural, visual, digital or engineering improvements.

IMPROVE by checking whether the knowledge reaches the people and decisions that need it.

The goal is not to eliminate expertise, but to use it deliberately.

9. Use Experience Where Judgement Adds Value

Valuing experience is not the problem. Requiring it for routine clarity is where the design question begins.

A senior technician should be solving the difficult problem—not repeatedly supplying basic information that the system could provide.

A supervisor should apply judgement to unusual conditions—not act as the only link to an unclear process.

An experienced operator should be improving the process—not quietly becoming the process.

The central question is:

What should the person know—and what should the system already know?

That question protects the value of experience while exposing unnecessary dependency.

BRIGS Perspective: Make Knowledge Part of the Factory

At BRIGS, the objective is not to replace human expertise. It is to connect expertise to the wider factory system.

Factory UX can make knowledge clearer at the point of work. Factory OS can connect information, workflows and controls. Machine and process safety can reflect critical knowledge in engineering and operating controls. Workplace improvement can reduce conditions that create unnecessary dependence on memory.

The goal is a factory where experience strengthens the system without having to substitute for it.

A Practical Next Step With BRIGS

Start with three routine tasks commonly described as:

“Only a few people really know how to do this.”

Use a safe Knowledge Transfer Test around each one. Map the knowledge required, where it lives and how another competent person accesses it.

Classify the gap as missing information, difficult-to-use information, informal process knowledge or genuine expert judgement. This helps determine whether the response should involve Factory UX, Factory OS, process redesign, training, safety controls, workplace improvement or a combination.

A BRIGS site assessment can examine the conditions around people, equipment, information and controls.

Use experience where judgement adds value. Remove dependency where the system should already provide clarity.