Firstly, we recognize the situation we've put ourselves into. Allowing one employee to hold us hostage was a problem that sneaked up over several years. We've since been pushing for everyone to better document their processes, and share knowledge across the org where appropriate. However, as we're a very small company, hiring multiple employees dedicated to the same job isn't feasible even in ideal circumstances.
Now, the issue at hand.
There is an employee at my company whom we want to terminate.
Our biggest concern is knowledge transfer and off-boarding processes (e.g. revoking VPN credentials when they're the only one with access). We're also mildly concerned about malicious behavior if the employee learns we intend to imminently terminate them.
We've identified several courses of action, but all seem to have significant drawbacks:
- Hire a replacement now, let the employee bring them up to speed, then terminate the problematic employee.
- Because there isn't a lot of work for admins here, even under the guise of reducing bus factor (which we recognize must be done long term regardless), they would find it highly suspicious and likely block training of the new hire.
- Terminate the employee immediately, then search for a replacement.
- This leaves us exposed technically until we find a replacement, which historically hasn't been a quick process. On boarding the new hire would be difficult with the lack of system documentation. We have other technical staff with some knowledge of the network, but they're not admins.
- Set a task to explicitly document everything, then terminate them.
- This ask is reasonable as it's something we've been pushing for a bit now. The company would still be at risk until a new hire arrives, but would at least give them and existing staff something to work off.
- Hire a contracting firm to work with the employee for knowledge transfer (under the guise to the employee of reducing bus factor), then terminate the employee.
- This provides some first hand knowledge transfer, the firm would know how to deal with system issues that do arise, and would be able to transfer knowledge back to the new hire. However this is expensive, and it may involve some dishonesty to the firm to get them to participate.
- Terminate the employee, have other technical staff take over in the interim.
- This isn't ideal given the other technical staff are a little distributed, and aren't admins themselves. Combined with a lack of documentation it's not ideal.
- We could do this with proper knowledge transfer from the problematic employee to an existing technical employee. It still wouldn't make up for missing core admin skills, but would help get us through the hiring period, and on-boarding of a new hire.
- Hold out until our system is in its back in a stable state, then terminate the employee, and pray the product is much more hands off than it used to be while a replacement is found.
- The big issue here is having everyone continue to work with the employee for another 6-12+ months. This is a liability not just in terms of company morale and productivity, but in continued incidents caused by them and completing their work with potentially bad practices. Documentation should be significantly better at this point as well.
Is there another angle or other points we haven't considered? Right now it feels like there's no clean path forward. All options are a mix of drawbacks between expensive, slow, and leaving us vulnerable (to normal problems and malicious behavior). We're leaning towards the last option and putting up with them for a while more for the sake of keeping the system alive until their part of the improvement project is complete, however the idea of having to work with them for another 6 months or more is not sitting well with many of the staff.