First off, for as much as possible you need to switch over to something like Windows Active Directory or using LDAP* for internal permissions. That way, users get permissions based on a central repository, don't know other users passwords, and you can audit who is able to - and who did - access what.
I'll assume you aren't in a regulated industry (if you are, you're in real trouble). Even then, your company's current setup shares all the passwords with Dropbox, anyone who has access to Dropbox data or backups, and potentially with any company that later merges with or acquires Dropbox. This may or may not be an argument anyone cares about.
Changing passwords is a big deal, and any time anyone leaves, you SHOULD be changing passwords - why does someone not employed or under contract have access to corporate resources? It's even worse if they left under less than amicable circumstances.
After you're done with the AD or LDAP integration, there will still be systems that aren't integrated. For those, I'm a big KeePass** fan. Employees can have a "personal" KeePass file, which is their primary, and holds person-specific accounts - which should be used as much as possible, so they can be disabled when people leave and so actions can be audited
You SHOULD monitor for, and take serious action when you see employees sharing passwords. This is a very common practice in small unregulated companies, and it causes problems later (audits failed, clients asking hard questions on their own audits, future regulation, and again the cost of changing every password any ex-employee knows).
If your employer really loves Dropbox, there is KeePass integration available, as well as FTP, SFTP, etc. integration.
- Ask them what their plan is for times Dropbox is inaccessible (being DDoS'd) or suddenly goes out of business (if Enron, Lehmen Brothers, and Lavabit can vanish overnight, so can Dropbox)
Employees may also have shared KeePass files if absolutely required - it does a good job of handling a few people opening and modifying the same .kbdx file simultaneously, merging the updates, or you can use the Synchronize command. The passwords and keyfiles used to open these shared KeePass files should be kept to as few people as possible, the contents should be kept as minimal as possible, and you again change passwords and keyfiles whenever someone that knows them leaves.
- Again, set up individual accounts at every point that can be done. When you have to investigate something (call it a production problem, or maybe fraud), this is critical.
- For any shared KeePass databases, use both a randomly generated keyfile if management agrees to it, but also long (35 character or more) passwords generated randomly by KeePass itself; employees keep the shared passwords in their personal KeePass database, and the passwords MUST be so long and random that it's honestly burdensome for employees to hand-type them.
- That way, there's no incentive to write it down; it takes forever and it's a pain to type anyway.
- High ASCII characters can also be used, like the copyright symbol or accented characters, making it even more difficult for employees to get in the habit of using shared superuser accounts without going through their own KeePass document.
*For a linux example, see the question "how do I configure my RHEL5 or RHEL6 system to use ldap for authentication?"
** When you set up your KeePass database, or afterwards if someone else does, make sure to go into File, Database Settings, and click the button for the "one second" number of rounds. Increase it from there as you see fit, but just doing that even on a very slow machine increases your security significantly - I usually use millions to tens of millions of rounds, since a second or five doesn't matter compared to the speed savings of the auto-type feature.