There’s a person on almost every IT team who just knows things.
They know why the integration between the CRM and the billing system behaves strangely on the last day of the month. They know which server can’t be patched yet because of a dependency no one properly documented. They know that when a particular error code appears, you don’t follow the runbook; you call Dave.
This person is invaluable. They’re also a ticking clock.
What is institutional knowledge, and why is it dangerous?
Institutional knowledge is the informal expertise that lives inside people’s heads rather than in documented systems. It builds up naturally over time in any IT environment. A workaround gets implemented under pressure and never properly written up. A vendor issue gets resolved through a conversation that no one thought to log. A configuration decision gets made for good reasons that were never recorded anywhere.
None of this feels dangerous in the moment. In fact, it often feels like efficiency. Why document everything when the person sitting next to you knows the answer?
The problem is that IT environments are in constant flux. People get promoted. People leave. Teams grow. And every time one of those things happens, a piece of that invisible knowledge either walks out the door or gets stretched too thin trying to cover too many gaps.
What this actually looks like in IT
It’s worth being concrete about what institutional knowledge looks like in practice, because it rarely announces itself. It tends to accumulate in a handful of recurring places:
Undocumented workarounds. A specific script gets run manually every Sunday night to prevent a downstream reporting failure. It’s not in any runbook. The engineer who wrote it left eighteen months ago. The person currently running it learned it from them informally and isn’t entirely sure why it works.
Vendor and integration quirks. The API connection between two SaaS platforms occasionally drops authentication tokens under a specific load condition. The fix takes thirty seconds if you know it, and hours to diagnose if you don’t. That fix exists in one engineer’s head, not in the documentation.
Patch and update exceptions. Certain servers can’t be updated on the standard cycle because of a dependency introduced years ago during a rushed migration. No ticket captures this. It’s kept alive purely through institutional memory, and each time a new team member nearly triggers the issue, someone catches it in the nick of time.
Access and permission logic. In many environments, the actual permission structure in production diverges significantly from what the diagrams show. Shadow admin accounts, legacy groups, role exceptions granted during incidents, someone knows how these work. The org chart doesn’t.
Read the full blog here.
Written by Oded Moshe, SysAid.