Imagine your office manager hands in their notice on a Monday morning. By Friday, you’ve started to discover what she actually knew. The login for the phone system. The name of the contact at your internet provider. The workaround for the accounts software that crashes every time someone tries to run a month-end report. The folder on her desktop — the one she always meant to document properly — where the passwords live.
This is not a technology problem. It is a management risk that most professional services firms carry quietly for years, until a departure — planned or otherwise — makes it visible. The firm’s IT has been running on institutional knowledge held by one or two individuals rather than on any documented system.
The financial and operational consequences are rarely catastrophic in the first week. They tend to arrive in the second and third, as the gaps compound. A system nobody else can configure. A vendor nobody else has a relationship with. A renewal missed because the reminder was going to a mailbox that has now been closed.
The First IT Issues Firms Face After Losing Key Staff
The first thing that surfaces is credentials. Somewhere in the departing person’s head — or in a notebook, or in an unshared password manager — are the admin logins for systems the firm relies on. The broadband router. The backup appliance. The cloud platform the accounts team uses.
These are not systems that break often, which is precisely why nobody else learned how to manage them. When something goes wrong, there is nobody left who knows the login.
Vendor relationships are the next casualty. Most small and mid-size professional services firms deal with suppliers through a single point of contact. That contact is often the person who set the relationship up, remembers the account details, and knows which number to call when the service goes down.
When they leave, the firm is starting from scratch with a supplier whose contract they can barely locate.
Then there are the workarounds. Every firm has them. The server that needs to be restarted in a particular order. The email rule that catches a specific type of spam the filtering system misses. The shared drive mapping that only works if you do it manually when you first log in.
These workarounds exist because they solved a real problem at some point, and the person who solved them never had time to document the fix. When they leave, the problem returns — and this time, nobody knows it was ever solved.
None of these issues is dramatic on its own. The problem is the compounding effect. The firm loses productive time, pays for emergency support it should not need, and makes decisions under pressure that a prepared firm would have made calmly.
Why Firms Still Depend on One Person for IT Knowledge
Professional services firms run on billable hours. Time that is not chargeable to a client is, in most firms, time that is at least slightly uncomfortable to spend. Documentation of internal systems does not generate revenue, win clients, or move a matter forward. So it gets deferred, year after year.
IT governance in most small and mid-size firms follows a familiar pattern. When the firm was smaller, one partner — or a particularly capable administrator — took an interest in the technology and quietly became the person others turned to. It was never a formal role. It never came with a job description or a handover process. It accumulated organically, and over time it became load-bearing without anyone noticing.
External IT providers can reinforce the problem rather than solve it. If your provider deals primarily with one contact inside the firm — answering their questions, copying them on reports, building the relationship with them — the knowledge dependency simply moves one layer out. When that contact leaves, the provider relationship has to be rebuilt from scratch on the firm’s side.
The honest version is simple. IT knowledge management has never felt urgent enough to prioritise. That changes the moment someone important hands in their notice.
How to Remove Key Person Dependency in IT
The difference between a firm that handles this well and one that does not is rarely about technology. It is about whether the IT picture lives in a documented system or in someone’s memory.
At a minimum, the firm should know where admin credentials are stored and who can access them. It should know which systems it relies on, who owns them, and when key renewals fall due. It should know how offboarding works when someone leaves, and it should have a provider relationship held at firm level rather than through one internal contact.
That does not mean pages of process documents. It means the basics are visible, shared, and recoverable. Credentials sit in a managed system, not in one person’s head or a personal tool. The asset register is current enough to be useful. Offboarding removes access, triggers knowledge transfer, and prompts vendor notifications before loose ends become security risks.
In that kind of firm, a departure is still inconvenient, but it is not destabilising. The firm does not have to rediscover how its own IT works while trying to keep normal work moving.
Key person dependency in IT is a solvable problem, and it does not require a large project to address. The starting point is a short audit: what does your firm actually rely on, and where does the knowledge about each of those things currently live? The right time to do that audit is before someone hands in their notice, not after.
Want to know how dependent your firm’s IT is on individuals rather than systems? The IT Ownership Scorecard takes 5 minutes.
