There is a person in your company who knows why the PLM system is configured the way it is. They set up the workflows, they know which of the rules were deliberate and which were workarounds for a problem in 2019, and they are the one people message when something behaves unexpectedly. It is usually not their job title. It became their job because they were good at it and nobody else volunteered.
Everyone knows this arrangement is a risk. It gets mentioned in passing, usually with a joke about not letting them get hit by a bus. Then it stays exactly as it is, until the day they hand in their notice and the joke stops being funny.
How one person ends up holding the system
Nobody designs this. It assembles itself over years, and each step is individually sensible.
During the implementation, one engineer takes more interest than the others. They ask the integrator good questions and learn how the configuration works. After go-live they become the internal contact, because they are the only person who can answer without escalating.
Over the next few years they make hundreds of small decisions. A workflow gets adjusted, a permission gets granted, a numbering rule gets an exception for one product family. Each change is small enough that documenting it would take longer than making it, so it does not get documented.
The system now works because of an accumulated body of judgement that exists in one head. Not because it was designed to, but because that is what happens when a system is maintained without a maintenance process.
The tell is a specific kind of sentence. “Ask Marko, he knows why that one is different.”
If a colleague can answer a question about the system but cannot point you to where the answer is written, the knowledge is in a person rather than in the organization.
What actually happens in the notice period
The reflex response is to arrange a handover. Someone else is nominated, meetings get booked, and the departing person is asked to write down what they know. This fails for a reason that has nothing to do with willingness.
A company gave four weeks and treated it seriously. The departing administrator wrote a document. Two colleagues attended sessions. Everyone was cooperative and the document ran to thirty pages.
It covered the things the administrator could think of: how to add a user, how to run a backup, where the licence server is. Those things were already the easy parts.
What it did not cover were the things they no longer knew they knew. Why the change workflow skips a step for one product family. Which of the six similar-looking part types is the one that must be used for purchased components. Why a particular attribute is mandatory and what breaks downstream if it is left empty.
Those questions did not come up in the handover because nobody knew to ask them. They came up over the following eight months, one at a time, each as a small crisis with no available answer.
This is the core difficulty. You cannot hand over knowledge you have stopped being aware of holding. Expertise becomes invisible to the person who has it, which is exactly what makes it valuable and exactly what makes it impossible to transfer on a deadline.
Three things that are lost, and they are not equal
| What is lost | Example | How recoverable |
|---|---|---|
| Procedures | How to add a user, run a backup, restart a service | Easily. Documented in a handover, or worked out from the manual. |
| Configuration reasoning | Why this workflow has an exception, why this attribute is mandatory | With difficulty. Requires reconstructing intent from behaviour. |
| Judgement | Knowing which requests to accommodate and which will cause problems later | Not at all. It is rebuilt over years by the next person. |
Handovers concentrate almost entirely on the first row, because it is the only one that can be written down in four weeks. The second row is where most of the operational value sits, and the third row is why the successor spends their first year being cautious about changes they do not fully understand.
What the successor inherits
The person who takes over is usually a capable engineer who now has two jobs. They learn the system by encountering problems, which means their knowledge grows in the order that things break rather than in any structured way.
Their most common behaviour in the first year is avoidance. Faced with a configuration they do not understand, the safe choice is to leave it alone and route around it. That is rational, and it means the system stops evolving. Requests get answered with a workaround instead of a configuration change.
Two years later, that accumulation of avoided changes is what people describe when they say the system no longer fits how they work.
Why the situation persists
Every company that has this dependency knows about it. The reason it does not get fixed is not ignorance. It is that fixing it has no deadline.
Documenting the configuration is work with no visible output. Nothing improves the day it is finished. It competes for the administrator’s time against requests that have people waiting, and it loses every week, entirely reasonably.
There is also a quieter reason that rarely gets said. Being the only person who understands a critical system creates a form of security. That is a human response, not a failing, and pretending it does not exist makes the conversation harder. The people in this position are often the ones who most want it resolved, because they are also the ones who cannot take two consecutive weeks of leave without checking messages.
The useful framing is not “we depend too much on one person”. That sounds like criticism of them.
It is “one person has been carrying something that should have been an organizational responsibility, and it is not fair to them either.”
What removes the dependency
Four things, in descending order of how quickly they can be done.
1. Document the configuration reasoning, not the procedures
Procedures are in the manual. What is not anywhere is why your configuration differs from the standard. Every deviation, with the reason it exists and what breaks if it is reversed. This is the highest-value document in the entire system and it usually does not exist.
The practical way to produce it is not to ask someone to write it from memory. It is to walk through the configuration systematically with them, asking why about each deviation, and write down the answers as they surface.
2. Build a runbook for what actually recurs
Not everything. The dozen things that come up monthly: user provisioning, permission changes, the check that runs before an upgrade, what to do when a specific integration fails. Written to be followed by someone who does not understand the system yet.
3. Test a restore
Backups usually run. Whether they restore into a working environment is a separate question that is often unverified. This belongs on the list because it is the single item most likely to be discovered as a problem at the worst moment.
4. Move the dependency outside the company
The structural fix. Administration handled by a team rather than a person means the knowledge lives with an organization that has a reason to document it, and departures are their problem to absorb rather than yours.
This is what managed services is for, and it is worth being clear about what it does and does not solve. It removes the single point of failure and it makes documentation someone’s contractual obligation. It does not replace having someone internal who understands your own processes, and any provider suggesting otherwise is overselling.
The version of this that is not a crisis
Everything above is easier to do when nobody has resigned. The same work, done under a notice period, is compressed into weeks, competing with a departing person’s remaining tasks and their reduced interest in the outcome.
The cost is the same either way. The difference is whether you spend it deliberately or under pressure, and whether the person doing the documenting is still motivated to do it well.
A reasonable trigger to act on: if the answer to “how long until it caused a problem” is measured in days rather than months, the dependency is worth addressing this quarter rather than eventually.
Our administrator is not planning to leave. Is this urgent?
Not urgent, and that is the point. Nobody plans to leave until they do, and the work is considerably cheaper and better done when there is no deadline. The reasonable time to address it is when you notice the dependency rather than when it becomes a problem.
Will they see this as a lack of trust?
It depends entirely on how it is raised. Framed as reducing risk to the company, it can read as questioning their reliability. Framed as making it possible for them to take leave without their phone, and as recognition that they have been carrying something that was never formally theirs, it usually lands well. In practice most people in this position are relieved.
Can we just hire a second administrator?
It works if the volume of work justifies a second full-time role, which in most mid-sized companies it does not. What tends to happen is that the second person handles overflow and the original person retains all the judgement, so the dependency stays where it was.
How long does documenting the configuration take?
For a typical single-site installation, a few days of structured walkthrough with the administrator, plus writing time. The constraint is their availability rather than the volume of material. Doing it in short sessions over a few weeks works better than trying to complete it in one block.
What if the person has already left?
Then the reasoning has to be reconstructed from the configuration itself, which is slower but entirely possible. An assessment of the current environment produces the same documentation, derived from what the system does rather than from what someone remembers. It is more expensive than doing it beforehand, and considerably cheaper than the next two years of cautious avoidance.
How long until it caused a problem?
If the honest answer is days, that is worth knowing before it is tested. An assessment produces the documentation that does not currently exist, and it is yours regardless of what you do next.