How would you intend on changing the password through database updates? From installation to installation, the actual cryptography used for password hashing can vary depending on what's available on the server. EE2 uses
md5 depending on the server/environment. I'm not sure about EE3. To appropriately handle this situation I would suggest writing a custom add-on that can function as a micro-service API; basically you hit it's ACTion id, validate somehow, pass it a new password, and then use EE to programatically change a user's password. But for true security reasons this would only be smart if every site you need to hit is behind an SSL certificate, and even then you'd have to write a script to hit these services instead of manually copy/pasting 20 urls to hit in your browser.
Are all of these application in one data center? If all of your MySQL servers and application servers are cordoned safely, you wouldn't have to worry about MiTM attacks and not need SSL on every site, but you'd have to be connected to that network to safely transmit data (be at work, VPNed in, etc).
I don't know if EE invalidates sessions when a password is changed programatically, so the safe thing to do would be delete all sessions for that user in the databases as well.
DELETE FROM `schema`.`exp_sessions`
WHERE member_id = XXX;
It would log some people out; but that's not the end of the world.
You could just dump dummy data (through MySQL/SSH) in so the offending ex-employee loses access, but everyone else does as well until you hit each sites
forgot password functionality.
Honestly, I would not recommend the current route you are in; sharing credentials and one admin user anonimizes the work being done and makes it harder to attribute events to employees (think: who edited my entry!?). I suppose you could have a deployment system and repository for your installations to take care of tracing file editors, but content edits are lost to your one user.
I also have no idea what your employee head count is and how much user credential provisioning you'd need to do. It's possible to use the multi-site manager for serving multiple sites in one EE install; then users are shared across the system and would solve your problem. I would be interested to hear the reasoning behind this workflow for your company.
The sophisticated answer would be a custom add-on that validates specific users against a separate, secure entity such a separate EE install. Then, you just modify that one EE member in your master install and then no other EE install can validate against it if it doesn't provide the updated password. There are extension hooks for taking over member credential validation, which you would only do selectively for your "master" members, and leave each install to use native members auth for everyone else.
One last time though; remember, if you are passing un-encrypted passwords in any form, get behind SSL.