Documentation: Getting Critical Knowledge Out of Dave's Head Before It's Too Late
The documentation crisis we explored in this week's podcast episode has generated some properly concerning emails from listeners. Too many businesses are sitting on knowledge time bombs.
It's the nightmare scenario that keeps business owners awake at 3am.
Dave's gone. Quit, sick, won the lottery, hit by a bus. Doesn't matter why. Dave's not available, and suddenly nobody knows how anything works.
The admin passwords? In Dave's head. The custom configurations? Dave's head. The weird workaround for the printer server? Dave's head. The contact details for that critical supplier? You guessed it.
When Dave leaves, they take your entire IT infrastructure with them.
The Documentation Disaster
I've seen businesses paralysed for days because only Dave knew how specific systems worked. Not because Dave was being secretive or territorial. Because Dave never had time to document everything properly.
When you're constantly firefighting, documentation is the first thing that gets dropped. There's always another printer to fix, another user to help, another system to patch. Writing down how things work feels like a luxury when you're drowning in urgent tasks.
But here's the brutal truth: undocumented systems are ticking time bombs.
The Real Cost of No Documentation
That engineering company I mentioned earlier? Three days offline because Dave's custom network setup was completely undocumented. The "five-minute server restart" became a three-day archaeological dig through Dave's brain patterns.
£25,000 in lost productivity. Angry customers. Staff sitting around with nothing to do. All because critical knowledge lived in exactly one place: Dave's head.
And Dave wasn't even being difficult. Dave had actually left detailed documentation as an encrypted attachment to her resignation email. The company owner just didn't know how to open it.
What Needs Documenting (Immediately)
Passwords and Access Credentials Not just the main ones. Everything. Wi-Fi passwords, admin accounts, service credentials, API keys, that random password for the door entry system that somehow got connected to the network.
System Configurations How is everything connected? What are the custom settings? Why did Dave configure things this specific way? What happens if you change this particular setting?
Vendor Relationships Who do you call when things break? What are the contract numbers? Who's the account manager? What's covered under warranty and what isn't?
Procedures and Processes How do you add a new user? How do you set up a new laptop? What's the backup procedure? How do you restore from backup? What happens during a power failure?
Emergency Contacts and Procedures Who do you call first when everything goes wrong? What's the escalation path? Where are the important numbers? What information do you need to give them?
The Documentation Problem
"Just get Dave to write it all down" sounds simple. But Dave's already working 60-hour weeks keeping everything running. When exactly is Dave supposed to find time for comprehensive documentation?
You've created an impossible situation. Dave needs to document everything, but Dave can't stop dealing with daily crises long enough to document anything. It's like asking someone to build a parachute while falling out of a plane.
The Solution: Get Help
I've seen businesses bring in temporary technical scribes. Someone technically skilled who can observe Dave, record processes, and create proper documentation. It works, but Dave has to approve this person and trust them with sensitive information.
Another approach: bring in an MSP to shadow Dave for a week. They document everything while providing backup support. Dave gets help with daily tasks while knowledge gets properly recorded.
The key is giving Dave the resource to get documentation done without adding to Dave's workload.
The Documentation Framework
Start With The Basics:
Network topology (what connects to what)
User accounts and permissions
Critical application configurations
Backup and restore procedures
Then Add Detail:
Step-by-step procedures for common tasks
Troubleshooting guides for known issues
Vendor contact information and contracts
Emergency response procedures
Make It Accessible: Not just for Dave. Anyone with appropriate permissions should be able to find and understand critical information. If only Dave can interpret the documentation, you're back to square one.
The Password Management Crisis
Dave's got admin passwords for everything stored in their head, on sticky notes, or in some personal system that makes sense only to Dave.
Implement proper password management immediately. Business-grade password managers like 1Password Business or Bitwarden Business. Shared vaults for system credentials, individual vaults for personal work accounts.
When Dave leaves, you're not scrambling to reset every password in the business.
The Knowledge Transfer Process
While Dave's Still There: Get everything documented properly. Use screen recording software to capture procedures. Have Dave explain their thinking while performing routine tasks.
Create Redundancy: Train at least one other person on critical procedures. Not to replace Dave, but to provide backup when Dave's unavailable.
Test the Documentation: Can someone else follow Dave's procedures and get the same result? If not, the documentation isn't good enough.
The Harsh Reality
Most businesses wait until Dave's gone before realising how much critical knowledge walked out the door with them. By then, it's too late.
The documentation that could have prevented a crisis becomes a costly forensic investigation into how Dave used to do things.
The Business Continuity Test
Here's a simple test: pick a critical system. Can someone other than Dave restart it, troubleshoot basic problems, and contact support if needed?
If the answer is no, you've identified a business continuity risk. Multiply that by every system Dave manages, and you'll understand the scale of your documentation problem.
The Psychological Barrier
Dave might resist documentation efforts. Not out of malice, but because admitting that knowledge needs to be shared feels like admitting you might leave. Or that you're not indispensable.
Handle this sensitively. Frame documentation as business resilience, not Dave replacement. Make it clear that Dave's expertise is valued and that documentation enhances rather than threatens their position.
Action Items:
Audit what's undocumented (list every system only Dave understands)
Implement password management (business-grade solution with shared vaults)
Schedule documentation time (either reduce Dave's other tasks or bring in help)
Create step-by-step procedures (for every routine task Dave performs)
Test the documentation (have someone else follow Dave's instructions)
Don't wait until Dave's gone to realise how much you depended on what was in their head. Start documenting now, while Dave's still available to explain why things work the way they do.
Next Week: Speaking of people with access to critical systems and information, we'll be diving deep into insider threats. Because sometimes the biggest security risk isn't hackers breaking in – it's the people you've already let inside. The statistics on insider incidents will properly shock you.
