The System Only Dave Understands
When one person is the only one who understands a system your firm runs on, a handover document will not capture what they know. Use the ninety days before they leave to watch the system run, hand it to someone else, and make the riskiest piece safe.
Every firm has a Dave. He built the system everyone depends on, he is the only one who knows why it works, and he has just told you he retires in ninety days.
Ninety days is enough to get what he knows out of his head, if you spend it watching the system run instead of waiting for a handover document.
Dave is the reason the system still runs. Twelve years ago he wrote it, or inherited it from the person who did, and every year since he has kept it alive: a fix here, a workaround there, a job that has to run before the bank file goes out, a quarterly report he corrects before anyone reads it. None of it is written down, because Dave was always there.
Engineers call this the bus factor: how many people would have to be hit by a bus before a project stops. For Dave’s system the answer is one. No risk register lists it. It shows up the week after Dave’s farewell lunch, when month-end runs and something quietly does not happen.
What Dave knows that the code doesn’t say
The code tells you what the system does. It doesn’t tell you why, or what Dave does around it.
- The nightly job that must finish before the payment file is sent, and what he does on the nights it doesn’t.
- The client whose account carries a flag nobody remembers setting, and the reason it must never be removed.
- The field that holds two different things, depending on which office entered the record.
- The password to the vendor’s portal, which is in his head and nowhere else.
- The report that comes out wrong at quarter-end, and the three cells he fixes by hand.
Each is small. Together they are the system, and the screens and the database are where it lives.
Why a handover document misses it
The first instinct is to ask Dave for a handover document. He will write one in good faith, covering everything he thinks of. The knowledge that matters is what he uses without thinking, and nobody documents a step they no longer notice taking.
The reliable way to get it out is to watch the system run through every cycle it has, asking why at every step. Ninety days holds two or three month-ends, which is enough if you use every one.
The ninety days, month by month
Days 1 to 30: Watch it run
The next month-end: every job, every report, every manual fix
Sit someone beside Dave for the next month-end to see the work rather than the code: every scheduled job, every file that goes out, every time he opens something and changes it by hand. They write each one down as it happens, with the question it raises.
Days 1 to 30: Write down what the code can't say
As the notes come in: the exceptions, the fixes, the reasons
Turn the notes into a record of the system as it runs: what happens, in what order, what breaks if a step is skipped, and why each workaround exists. Someone other than Dave writes it, and Dave checks it. It is complete when he reads it and has nothing to add.
Days 31 to 60: Someone else runs it
The next month-end, with Dave watching
Someone else runs the next month-end, with Dave in the room saying nothing unless it is about to go wrong. Every time he has to step in marks a gap in the record, found while he is still there to fill it.
Days 61 to 90: Make the riskiest piece safe
Automate the fix, check the output, move the keys
Automate the manual fix he makes every quarter. Put automated checks around the piece that breaks most, so a test catches a mistake before a client does. Move every credential into the firm’s own accounts.
Day 91: A system that doesn't need Dave
And a roadmap for the rest
The same system, now one the firm understands, runs without him and can be changed safely. A written roadmap says which piece to modernize first, and why. Dave’s last day is a farewell lunch and nothing more.
None of this is a rewrite. Ninety days is too short to rebuild a system that took twelve years to become what it is, and long enough to understand one. Any rebuild comes after, piece by piece, from a roadmap based on what the ninety days found rather than what anyone remembered.
Make the most of Dave while he is here
This plan works with Dave. Pay him to teach, and give him the time to do it properly instead of squeezing it around his day job. Ask whether he would take a few hours a month of consulting after he leaves, for the questions nobody can predict.
The worst outcome is a quiet one: Dave leaves, the system keeps running, and nobody notices it has stopped being understood until the first thing goes wrong and there is no one to ask.
Who is your Dave, and what happens the week after he leaves?
Book Free Assessment