"Jerry is on vacation this week?"
"Do you have his number?"
We’ve all been there.
There is a guy at work. He does something specific. Nobody is completely sure what his job title is, what his qualifications are, or where the official procedure lives.
But Jerry knows the network.
Problems?
We call Jerry.
Jerry’s actual job?
Not sure.
Jerry’s qualifications?
Also unclear.
Jerry is just Jerry.
He is there.
He fixes the thing.
Jerry not at work today?
Uh oh.
Jerry is on vacation this week?
Does anyone have his cell number?
This is common in smaller offices all over the country.
It is also not a good thing.
Jerry may be useful. Jerry may be competent. Jerry may even enjoy being the person who knows the thing.
But if the process only works because Jerry is physically present, then the process does not really exist.
The organization has not built a system.
It has stored a system inside Jerry.
If the answer to a broken process is “call Jerry,” then Jerry is not supporting the system.
Jerry is the system.
Do you have his number?
Every office has a moment.
That moment when someone finally stops nodding along and asks the forbidden question:
“Wait. Who actually knows how this works?”
The answer is usually Jerry.
Jerry Looks Like a Solution
At first, Jerry seems like proof that the office is lucky.
Something breaks. Jerry fixes it.
Someone is confused. Jerry explains it.
A password fails, a screen freezes, a printer starts making noises that suggest a minor haunting, and Jerry knows which button to press, which cable to wiggle, or which undocumented workaround still works.
Everyone relaxes because Jerry is here.
That is the trap.
Jerry is useful, but Jerry is also evidence.
He is the person everyone trusts when the official process fails. He knows the workaround, remembers the hidden screen, and understands which parts of the procedure are real and which parts are decorative wallpaper.
That is useful.
It is also dangerous.
Jerry is not dangerous because he is bad at his job. Usually, the opposite is true. Jerry is dangerous because everyone has learned to route failure through him.
The printer does not need to be understandable because Jerry understands it. The password system does not need to be documented because Jerry remembers the workaround. The network does not need a clean map because Jerry knows which closet has the box with the blinking lights.
That feels efficient until Jerry is not there.
That absence reveals the truth. The organization was not relying on a process. It was relying on a person.
Knowledge stored in one person is useful, but fragile. It becomes infrastructure only when it can survive absence, transfer, error, and time. A process that cannot be taught is not really a process. It is a performance. A procedure that exists only in someone’s memory is not documentation. It is dependency.
Jerry is usually the reason the problem has remained survivable. He learned the work because someone had to. He remembered the workaround because no one documented it. He kept the old system breathing because replacing it was always too expensive, too slow, or too inconvenient.
The failure is not that Jerry knows the thing. The failure is that no one else does.
A system that cannot survive Jerry’s absence is not a system. It is a dependency with a name tag.