If your disaster recovery plan includes calling Bob because he's the only person who knows how something works, congratulations.
Bob is now critical infrastructure. 😄
We spend a lot of time in IT thinking about redundancy.
Redundant power. Redundant internet connections. Redundant storage. Backups. Failover. High availability.
But sometimes we overlook one of the biggest single points of failure in an organization: knowledge.
Who knows how that old application works?
Who has the vendor contact?
Who remembers why that firewall rule exists?
Who knows which service account that integration uses?
Who knows the strange sequence of steps required to bring a system back online?
If the answer is one person's name, you don't really have redundancy.
Good documentation isn't busywork. It's part of the infrastructure.
And just like infrastructure, it has to be maintained. A five-year-old network diagram or an outdated recovery procedure can sometimes be worse than having nothing at all because it gives you confidence in information that is no longer accurate.
I've also learned that documentation doesn't have to be perfect to be valuable. A current diagram, a short recovery checklist, a list of dependencies, or a few notes explaining why something was configured a certain way can save hours when something goes wrong.
The goal isn't to document every mouse click.
The goal is to make sure the organization doesn't lose the ability to operate because one person is unavailable.
So here's a question worth asking your IT team:
If one person disappeared from the organization tomorrow, what system would suddenly become much harder to support?
Whatever your answer is, that's probably a good place to start documenting.