Documentation that survives a key person leaving
At a lot of companies, IT runs mainly because one person keeps it all in their head. That works fine until that person goes on holiday, takes another job, or simply doesn't pick up the phone. I document how your IT actually works - not how it's supposed to work according to a diagram from 2019.
Where the problem comes from
Plenty of small and mid-sized companies run critical infrastructure on the knowledge of one or two people. Where a server's access leads, why a particular firewall rule is set up the way it is, what happens when a specific service goes down - one person knows all of it, and none of it is written down anywhere else.
As long as that person is around, nobody minds. The problem shows up the moment they leave - on sick leave, to a new employer, or in a dispute with the company. That's when it becomes clear the knowledge left with them, and the company doesn't actually know how its own systems work.
Where this hurts the most
Missing documentation shows up in practice mainly in these situations:
- A key person leaving. Planned or sudden - the new person spends weeks instead of days piecing together how the system works.
- Switching IT providers. The new provider has nothing to build on and spends the first months just figuring out what they're actually managing.
- An outage in the middle of the night. Nobody else knows how to restart the system or where to even look, so everyone waits for the one person who does.
- A security audit. The auditor asks about architecture and access rights, and the answer is "we'll need to look that up."
- A planned change or migration. Nobody dares touch anything because nobody knows exactly what's connected to what.
Documentation isn't paperwork for an auditor. It's insurance against the company becoming hostage to one person - whether that's by their choice or not.
How I approach it
Mapping the environment
I go through the infrastructure, access rights, connections between systems, and key operational processes - typically through interviews with the people running it today.
Structured documentation
I write up what runs where, how the systems connect, who has access to what, and what to do in case of an outage - in plain language, not a technical dump only insiders can read.
Knowledge transfer
If a specific person is leaving, I organize handover sessions that capture the things that would never make it into a document on their own.
A process for keeping it current
I set up a simple process for updating the documentation with every major change - so the work doesn't go stale within a year.
What you get
- Infrastructure that isn't dependent on one person - a new hire or provider gets up to speed in days, not weeks.
- Audit-ready material prepared in advance, not scrambled together the day before an inspection.
- Faster response to outages, because the fix is written down, not stuck in one person's head.
- Peace of mind through staff changes - a key person leaving stops being an operational risk.
When it makes sense
- A key IT person is planning to leave, or you're considering leaving yourself.
- You're about to switch IT providers or bring management in-house.
- A security audit is coming up and documentation is missing or out of date.
- The company is growing and relying on one person is no longer sustainable.
Frequently asked questions
Our admin is leaving in a month. Can we still make it work?
It depends on the size of the environment, but the sooner we start, the more we can capture directly from them - that part is irreplaceable. Partial documentation is still far better than none.
We have no existing documentation, starting from zero. Is that a problem?
No, that's a common starting point. Documentation can be built entirely from interviews with the people running the systems today, combined with reviewing the infrastructure itself.
Who keeps the documentation up to date afterward?
Ideally your own team - which is why the engagement includes setting up a simple process for updating the documentation with every major change, rather than leaving you with a one-off document that goes stale within a year.
What format will the documentation be in?
Whatever the company actually uses and will keep maintaining - typically a structured text format or a wiki, not a closed format tied to a single vendor's tool.
Is a key person leaving soon?
Thirty minutes, no strings attached. We'll figure out what needs to be captured first and how much time you realistically have.
Book a free consultation →