Tribal Knowledge in Enterprise Operations: When One Person Is the Process
Tribal Knowledge in Enterprise Operations: When One Person Is the Process
There is a process in your organisation that one person understands completely and nobody else understands at all. It works. It has worked for years. It does not appear on a risk register, because nothing has gone wrong with it.
Tribal knowledge is the term for this: operational understanding that lives in people rather than in any system or document. It is not a sign of a badly run organisation. It forms naturally in every enterprise that has been operating long enough for expertise to accumulate, and in normal conditions it is efficient. The person who knows makes fast, correct decisions without consulting anything.
The difficulty is that the condition is invisible while everything is stable, and it becomes expensive at precisely the moments when the organisation is trying to change something.
The moment it surfaces
Key-person dependency rarely announces itself through a departure. More often it is discovered during a project.
An automation programme reaches a process and stalls, because the analyst cannot get a complete description of how it works. The interviews produce a flow with gaps at exactly the points that matter, which are the exceptions, the judgement calls and the conditions under which the normal path does not apply. The one person who can close those gaps has a diary, and the project now runs at the speed of that diary.
The same discovery happens during an audit, during a system migration, and during any attempt to move work between locations or teams. In each case the organisation learns that a process it considered documented is documented at the level of the happy path, and that the operationally important part was never written down because the person who handles it never needed to write it down.
This is what Nikola means when he says you cannot automate what you do not understand. The constraint is not technical. The constraint is that the knowledge required to specify the automation exists in one head, and extracting it is slower and more delicate than anyone plans for.
Why it forms
Three mechanisms produce tribal knowledge, and none of them involves anybody behaving badly.
Exceptions accumulate faster than documentation. The documented process covers the standard case. Over years, the person handling the work builds a mental library of edge cases, each learned once and applied thereafter without conscious thought. Nobody documents an exception at the moment they resolve it, because at that moment it is a one-off.
Expertise is rewarded and transfer is not. The person who resolves difficult cases quickly is valuable, visible and busy. Time spent writing down how they do it produces no immediate operational benefit and comes out of the capacity that made them valuable. Organisations routinely ask for knowledge transfer without funding the hours it requires, which means it happens in the gaps, which means it does not happen.
Systems fill the gaps invisibly. Where a process crosses systems that do not integrate, a person becomes the connective tissue, carrying context from one system to the next. That carried context is entirely undocumented by definition, because no system holds it. It is the most operationally critical and least visible category of tribal knowledge in most enterprises.
Four signs it is present
The condition is diagnosable before it becomes a problem.
A process slows noticeably when a particular person is on leave, and the slowdown is treated as normal rather than investigated.
Questions about how a process works are routed to a person by name rather than to a document or system. When new joiners are told to “ask Marko about the reconciliation,” the reconciliation process is Marko.
The documented process describes a flow that is visibly simpler than the work observed. Where the model has three decision points and the observed work has eleven, the missing eight live in someone’s judgement.
Estimates for automating or migrating a process come back with unusually wide ranges, or with a dependency on one named individual’s availability. Delivery teams can feel undocumented complexity before they can describe it.
Why documentation projects usually fail to fix it
The standard response is to commission documentation. It produces disappointing results for reasons worth understanding before repeating the attempt.
Interviewing an expert about their process captures what they can articulate, which is systematically less than what they know. Expertise becomes automatic, and automatic knowledge is hard to retrieve on demand. Asked how they handle a case, a practitioner describes the general approach. The specific triggers that tell them which approach applies are frequently invisible even to them.
The output also tends to be a static document, which begins decaying immediately and shares the trajectory of every other process repository that goes dormant after the project ends. A document that captured tribal knowledge in 2024 and was never maintained is a description of how a process used to work, and it carries false confidence because the organisation believes the risk was addressed.
And a documentation exercise conducted as a risk-mitigation activity has no operational consumer. Nobody reads it in the course of doing the work, so nobody notices when it becomes wrong.
What actually transfers process knowledge
The approaches that work share a property: the knowledge is captured as a by-product of doing something else useful, rather than as a standalone exercise.
Observation over interview. Sitting with the person while they work surfaces the decision points they do not mention, because the case arrives and they handle it. What looked like one step turns out to be four. This is the core of discovery work and it is why discovery is conducted in the operational environment rather than in a meeting room.
Capture the exceptions first. The happy path is usually already documented and is rarely where the dependency sits. The value is in the conditions under which the normal path does not apply, what the person does instead, and how they recognise which situation they are in. That is the content nobody writes down and everybody needs.
Externalise the decision logic explicitly. Where the expertise is a set of rules the person applies, those rules can be represented in a form that is both readable and executable. Decision Model and Notation exists for this: decision tables that a business analyst can read, an engine can execute, and an auditor can inspect. Converting judgement into an explicit table is also the fastest way to discover that two experts have been applying different rules to the same case.
Give the captured knowledge a job. Knowledge captured into a system that people use daily stays current, because errors are noticed by the people doing the work. Knowledge captured into a document produced for a risk register does not. This is the single largest determinant of whether a transfer effort holds.
Run the process without the expert, deliberately, while the expert is still there. The most reliable test of whether knowledge has transferred is a controlled attempt to operate without the person, with them available to correct what goes wrong. It surfaces the remaining gaps while the correction is still cheap, which is the opposite of the usual sequence.
Explore our services for how discovery, design and automation delivery sequence in practice.
Automation as the forcing function
There is a useful reframing available here, and it changes how the work gets funded.
Knowledge transfer as a standalone initiative competes for budget against things with clearer returns, and it generally loses. Framed as risk mitigation it is a cost with no visible benefit until something goes wrong, which is a difficult case to make in a quarterly review.
Automation and process improvement projects, by contrast, are funded on operational returns and they require the same knowledge as an input. A discovery phase conducted properly produces a documented process, explicit decision logic, and identified ownership, because the automation cannot be specified without them. The knowledge transfer happens as a consequence of work that was justified on other grounds.
This is why the sequence matters more than the intention. An organisation that starts with the automation question and does discovery properly ends up with its tribal knowledge externalised. An organisation that starts with a documentation initiative frequently ends up with neither, because the documentation has no operational consumer and decays. The same logic explains why process mining alone does not produce operational change: the discovery layer has to be connected to something that acts on it.
The question worth asking
Most enterprises cannot eliminate tribal knowledge, and attempting to would be a poor use of effort. Expertise concentrating in experienced people is how organisations work.
The narrower and more useful question is which concentrations carry consequence. For a process with regulatory exposure, direct revenue impact, customer-facing commitments or safety implications, a single point of knowledge is an operational risk that belongs on a register. For a process that is internal, low-volume and tolerant of a slow week, it is simply how the work is organised.
That distinction is answerable in an afternoon by an operations leadership team, and answering it is worth more than most of the documentation projects it might replace. The exercise identifies a small set of processes where the concentration genuinely matters, and that set is where discovery and externalisation effort should go first.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed. 75% of DNA client engagements last five years or more.
Book a meeting to discuss where process knowledge is concentrated in your operation and what it would take to externalise it.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently Asked Questions
There is a process in your organisation that one person understands completely and nobody else understands at all. It works. It has worked for years. It does not appear on a risk register, because nothing has gone wrong with it.
Tribal knowledge is the term for this: operational understanding that lives in people rather than in any system or document. It is not a sign of a badly run organisation. It forms naturally in every enterprise that has been operating long enough for expertise to accumulate, and in normal conditions it is efficient. The person who knows makes fast, correct decisions without consulting anything.
The difficulty is that the condition is invisible while everything is stable, and it becomes expensive at precisely the moments when the organisation is trying to change something.
The moment it surfaces
Key-person dependency rarely announces itself through a departure. More often it is discovered during a project.
An automation programme reaches a process and stalls, because the analyst cannot get a complete description of how it works. The interviews produce a flow with gaps at exactly the points that matter, which are the exceptions, the judgement calls and the conditions under which the normal path does not apply. The one person who can close those gaps has a diary, and the project now runs at the speed of that diary.
The same discovery happens during an audit, during a system migration, and during any attempt to move work between locations or teams. In each case the organisation learns that a process it considered documented is documented at the level of the happy path, and that the operationally important part was never written down because the person who handles it never needed to write it down.
This is what Nikola means when he says you cannot automate what you do not understand. The constraint is not technical. The constraint is that the knowledge required to specify the automation exists in one head, and extracting it is slower and more delicate than anyone plans for.
Why it forms
Three mechanisms produce tribal knowledge, and none of them involves anybody behaving badly.
Exceptions accumulate faster than documentation. The documented process covers the standard case. Over years, the person handling the work builds a mental library of edge cases, each learned once and applied thereafter without conscious thought. Nobody documents an exception at the moment they resolve it, because at that moment it is a one-off.
Expertise is rewarded and transfer is not. The person who resolves difficult cases quickly is valuable, visible and busy. Time spent writing down how they do it produces no immediate operational benefit and comes out of the capacity that made them valuable. Organisations routinely ask for knowledge transfer without funding the hours it requires, which means it happens in the gaps, which means it does not happen.
Systems fill the gaps invisibly. Where a process crosses systems that do not integrate, a person becomes the connective tissue, carrying context from one system to the next. That carried context is entirely undocumented by definition, because no system holds it. It is the most operationally critical and least visible category of tribal knowledge in most enterprises.
Four signs it is present
The condition is diagnosable before it becomes a problem.
A process slows noticeably when a particular person is on leave, and the slowdown is treated as normal rather than investigated.
Questions about how a process works are routed to a person by name rather than to a document or system. When new joiners are told to “ask Marko about the reconciliation,” the reconciliation process is Marko.
The documented process describes a flow that is visibly simpler than the work observed. Where the model has three decision points and the observed work has eleven, the missing eight live in someone’s judgement.
Estimates for automating or migrating a process come back with unusually wide ranges, or with a dependency on one named individual’s availability. Delivery teams can feel undocumented complexity before they can describe it.
Why documentation projects usually fail to fix it
The standard response is to commission documentation. It produces disappointing results for reasons worth understanding before repeating the attempt.
Interviewing an expert about their process captures what they can articulate, which is systematically less than what they know. Expertise becomes automatic, and automatic knowledge is hard to retrieve on demand. Asked how they handle a case, a practitioner describes the general approach. The specific triggers that tell them which approach applies are frequently invisible even to them.
The output also tends to be a static document, which begins decaying immediately and shares the trajectory of every other process repository that goes dormant after the project ends. A document that captured tribal knowledge in 2024 and was never maintained is a description of how a process used to work, and it carries false confidence because the organisation believes the risk was addressed.
And a documentation exercise conducted as a risk-mitigation activity has no operational consumer. Nobody reads it in the course of doing the work, so nobody notices when it becomes wrong.
What actually transfers process knowledge
The approaches that work share a property: the knowledge is captured as a by-product of doing something else useful, rather than as a standalone exercise.
Observation over interview. Sitting with the person while they work surfaces the decision points they do not mention, because the case arrives and they handle it. What looked like one step turns out to be four. This is the core of discovery work and it is why discovery is conducted in the operational environment rather than in a meeting room.
Capture the exceptions first. The happy path is usually already documented and is rarely where the dependency sits. The value is in the conditions under which the normal path does not apply, what the person does instead, and how they recognise which situation they are in. That is the content nobody writes down and everybody needs.
Externalise the decision logic explicitly. Where the expertise is a set of rules the person applies, those rules can be represented in a form that is both readable and executable. Decision Model and Notation exists for this: decision tables that a business analyst can read, an engine can execute, and an auditor can inspect. Converting judgement into an explicit table is also the fastest way to discover that two experts have been applying different rules to the same case.
Give the captured knowledge a job. Knowledge captured into a system that people use daily stays current, because errors are noticed by the people doing the work. Knowledge captured into a document produced for a risk register does not. This is the single largest determinant of whether a transfer effort holds.
Run the process without the expert, deliberately, while the expert is still there. The most reliable test of whether knowledge has transferred is a controlled attempt to operate without the person, with them available to correct what goes wrong. It surfaces the remaining gaps while the correction is still cheap, which is the opposite of the usual sequence.
Explore our services for how discovery, design and automation delivery sequence in practice.
Automation as the forcing function
There is a useful reframing available here, and it changes how the work gets funded.
Knowledge transfer as a standalone initiative competes for budget against things with clearer returns, and it generally loses. Framed as risk mitigation it is a cost with no visible benefit until something goes wrong, which is a difficult case to make in a quarterly review.
Automation and process improvement projects, by contrast, are funded on operational returns and they require the same knowledge as an input. A discovery phase conducted properly produces a documented process, explicit decision logic, and identified ownership, because the automation cannot be specified without them. The knowledge transfer happens as a consequence of work that was justified on other grounds.
This is why the sequence matters more than the intention. An organisation that starts with the automation question and does discovery properly ends up with its tribal knowledge externalised. An organisation that starts with a documentation initiative frequently ends up with neither, because the documentation has no operational consumer and decays. The same logic explains why process mining alone does not produce operational change: the discovery layer has to be connected to something that acts on it.
The question worth asking
Most enterprises cannot eliminate tribal knowledge, and attempting to would be a poor use of effort. Expertise concentrating in experienced people is how organisations work.
The narrower and more useful question is which concentrations carry consequence. For a process with regulatory exposure, direct revenue impact, customer-facing commitments or safety implications, a single point of knowledge is an operational risk that belongs on a register. For a process that is internal, low-volume and tolerant of a slow week, it is simply how the work is organised.
That distinction is answerable in an afternoon by an operations leadership team, and answering it is worth more than most of the documentation projects it might replace. The exercise identifies a small set of processes where the concentration genuinely matters, and that set is where discovery and externalisation effort should go first.
DNA works vendor-neutrally across ARIS, Camunda, ServiceNow, SAP Signavio and Power Automate, and recommends what is best for the client rather than what is licensed. 75% of DNA client engagements last five years or more.
Book a meeting to discuss where process knowledge is concentrated in your operation and what it would take to externalise it.
About DNA Automation Consulting
DNA Automation Consulting is an EU-based BPM consultancy specialising in process discovery, BPMN design, and automation delivery for enterprise clients in banking, insurance, energy, telecom, and manufacturing. 75% of client engagements last five years or more.
Founded by Ante Gudelj and Nikola Dlaka. Clients include Proximus, Equinor, Merck, and NEXI.
Frequently Asked Questions
Written by:
Ante Gudelj
Managing Partner
Share with friends:
What is tribal knowledge in a business context?
Tribal knowledge is operational understanding held by individuals rather than recorded in any system or document. It typically covers exceptions, judgement calls, workarounds and the conditions under which the standard process does not apply. It forms naturally in any organisation where expertise accumulates, and it becomes a constraint when the organisation tries to automate, audit, migrate or scale the work.
How do you identify key-person risk in a process?
Four indicators recur: a process visibly slows when one person is unavailable, questions about the process are routed to a person by name rather than to a document, the documented flow is markedly simpler than the observed work, and delivery estimates for changing the process depend on one individual’s availability. Any of these suggests the operational knowledge sits outside the documented process.
Why do documentation projects fail to capture tribal knowledge?
Because interviews capture what an expert can articulate, which is less than what they know once expertise has become automatic. The output is also usually a static document with no operational consumer, so it decays without anyone noticing and creates false confidence that the risk was addressed. Observation during real work, and capture into systems people use daily, hold up better.
Is tribal knowledge always a problem?
No. Expertise concentrating in experienced people is normal and often efficient. It becomes a problem where the process carries regulatory exposure, direct revenue impact, customer-facing commitments or safety implications, and where the loss of one person would materially disrupt operations. The useful exercise is separating the concentrations that carry consequence from the ones that do not.
How does process automation help with knowledge transfer?
A properly conducted discovery phase requires the same inputs that knowledge transfer requires: a documented flow including exceptions, explicit decision logic, and identified ownership. An automation project cannot be specified without them, so the externalisation happens as a consequence of work funded on operational returns rather than as a standalone initiative competing for budget against measurable projects.
What is tribal knowledge in a business context?
Tribal knowledge is operational understanding held by individuals rather than recorded in any system or document. It typically covers exceptions, judgement calls, workarounds and the conditions under which the standard process does not apply. It forms naturally in any organisation where expertise accumulates, and it becomes a constraint when the organisation tries to automate, audit, migrate or scale the work.
How do you identify key-person risk in a process?
Four indicators recur: a process visibly slows when one person is unavailable, questions about the process are routed to a person by name rather than to a document, the documented flow is markedly simpler than the observed work, and delivery estimates for changing the process depend on one individual’s availability. Any of these suggests the operational knowledge sits outside the documented process.
Why do documentation projects fail to capture tribal knowledge?
Because interviews capture what an expert can articulate, which is less than what they know once expertise has become automatic. The output is also usually a static document with no operational consumer, so it decays without anyone noticing and creates false confidence that the risk was addressed. Observation during real work, and capture into systems people use daily, hold up better.
Is tribal knowledge always a problem?
No. Expertise concentrating in experienced people is normal and often efficient. It becomes a problem where the process carries regulatory exposure, direct revenue impact, customer-facing commitments or safety implications, and where the loss of one person would materially disrupt operations. The useful exercise is separating the concentrations that carry consequence from the ones that do not.
How does process automation help with knowledge transfer?
A properly conducted discovery phase requires the same inputs that knowledge transfer requires: a documented flow including exceptions, explicit decision logic, and identified ownership. An automation project cannot be specified without them, so the externalisation happens as a consequence of work funded on operational returns rather than as a standalone initiative competing for budget against measurable projects.
What is tribal knowledge in a business context?
Tribal knowledge is operational understanding held by individuals rather than recorded in any system or document. It typically covers exceptions, judgement calls, workarounds and the conditions under which the standard process does not apply. It forms naturally in any organisation where expertise accumulates, and it becomes a constraint when the organisation tries to automate, audit, migrate or scale the work.
How do you identify key-person risk in a process?
Four indicators recur: a process visibly slows when one person is unavailable, questions about the process are routed to a person by name rather than to a document, the documented flow is markedly simpler than the observed work, and delivery estimates for changing the process depend on one individual’s availability. Any of these suggests the operational knowledge sits outside the documented process.
Why do documentation projects fail to capture tribal knowledge?
Because interviews capture what an expert can articulate, which is less than what they know once expertise has become automatic. The output is also usually a static document with no operational consumer, so it decays without anyone noticing and creates false confidence that the risk was addressed. Observation during real work, and capture into systems people use daily, hold up better.
Is tribal knowledge always a problem?
No. Expertise concentrating in experienced people is normal and often efficient. It becomes a problem where the process carries regulatory exposure, direct revenue impact, customer-facing commitments or safety implications, and where the loss of one person would materially disrupt operations. The useful exercise is separating the concentrations that carry consequence from the ones that do not.
How does process automation help with knowledge transfer?
A properly conducted discovery phase requires the same inputs that knowledge transfer requires: a documented flow including exceptions, explicit decision logic, and identified ownership. An automation project cannot be specified without them, so the externalisation happens as a consequence of work funded on operational returns rather than as a standalone initiative competing for budget against measurable projects.