Blog / fractional cto
What if your only IT person quit tomorrow?
Most small companies depend on one person who knows how everything works. Here is how to find out what would leave with them, and what to fix first.
Every few months I get a version of the same call. Someone has resigned, or is off sick, or has quietly stopped answering email, and now nobody can get into the system that sends the invoices.
The person is almost never the villain in that story. Usually they are the most conscientious individual in the building. They built things that worked, they kept them working for years, and nobody ever asked them to write any of it down.
The two-week test
Do this before you need it. Pick the person your systems lean on hardest. It might be an employee, it might be a contractor you have used for a decade, it might be your nephew. Now assume they are unreachable for two weeks, starting this morning.
What breaks first?
Most owners get three or four items into that list before the answer becomes "I would have to ask him." That moment is the real result of the test. Not the list itself, but the point where the list stops.
What actually walks out the door
Passwords are the part everyone worries about, and the easiest part to fix. If that is where your gap is, start with who owns your business accounts and work through it methodically.
The expensive loss is the reasoning. Why the backup job runs at 2 a.m. instead of midnight. Which of the two wireless networks the payment terminals sit on, and why moving them caused a bad afternoon in 2023. That the accounting server cannot be updated until the software vendor ships their next release, and that the interim fix is a scheduled restart nobody has touched in three years.
Then there are the relationships. The escalation contact at your internet provider. The name of the one person at the software vendor who returns calls. The electrician who knows which conduit runs where. None of that lives in a password manager.
And the automation. Every long-serving technical person leaves behind a handful of scripts, mail rules and scheduled tasks that quietly hold something together. Those tend to surface about six weeks after the person leaves, in the form of a report that stopped arriving and nobody noticed.
How to ask without insulting anyone
Owners stall here because asking someone to document their work sounds like preparing to replace them. Say the other thing instead, which happens to be true: this is what lets them take a real holiday, hand off the boring parts, and stop being phoned on a Sunday.
Then make it small. An hour a week, on the clock, aimed at one system at a time. No templates, no project. Plain language, written for a competent stranger rather than for you.
The test of whether it worked is not whether a document exists. It is whether someone who has never seen your network could follow it, find the equipment, log in, and get the thing running again. If the document says "restore from the usual backup," it is not finished.
Start with whatever would hurt most in the first forty-eight hours. For most businesses that is one of four things: getting paid, getting orders out, getting into email, or getting the phones answered. Everything else can wait a week.
When it is a vendor rather than an employee
Same shape, different conversation. A vendor who will not hand over documentation, admin credentials, or a straightforward description of what they built is telling you something about the relationship, and it is worth hearing early rather than during a crisis.
You are entitled to know how your own systems work. Ask for a written handover as a normal part of the annual review, not as an accusation. If they resist, you have learned something useful for very little money. I have written before about taking over a half-finished project, and the pattern is always the same: the cost of the rescue is mostly the cost of figuring out what is there.
Start this month
Three steps, none of which need a budget. Write down the two-week test and the point at which your answers ran out. Make a list of every account, service and piece of equipment that only one person can reach. Pick the single system whose failure would cost you the most this week, and get one page written about it.
That is usually enough to turn a genuine business risk into an ordinary maintenance item.
If you would rather have someone else run the test and ask the awkward questions, that is a good fit for an outside read. I do this as a short assessment or as ongoing fractional CTO work depending on how deep the dependency goes, and engagements are quoted as a fixed fee, hourly, or a monthly retainer. I am vendor-neutral and I do not resell anything, so the answer you get is about your business rather than about a product. Get in touch if you want a second set of eyes on it.