How to Prepare for a Team Member’s Departure

The end is coming. It may be next week or it may be next year but soon it’s going to happen: someone in your organization is going to leave. There’s a lot to be done when someone leaves, but being prepared in advance can make the process a lot easier.

There’s a lot of HR and training needed when someone leaves the company, but this is the software development blog, so let’s talk about the software. Handling the transition of a member of the IT staff can go smoothly or poorly, and it’s all in how you prepare.


Preparation starts far before anyone tenders their resignation. Any organization uses many systems and has accounts: an MSDN login; a Github account; user accounts on various servers; an admin user in the ticketing system. Make sure that none of these are tied to a person. Instead, use an organization address or login (e.g., “Administrator” or “”).

  • Always use a corporate email address for accounts. It’s easy to forward email from that corporate account to the appropriate individuals, and when one person leaves then it’s far easier to change the forwarding than to change the email address on the account. This also means that other people who need to access the account can use the password reset functionality or other emailed services, even when the original account holder is on vacation or gone.
  • Use individual SSH keys. This sounds like the inverse of the advice above, but it makes managing servers a lot easier! If each person has an SSH key they use to access systems, then adding that individual to the system and removing them from the system is a simple matter of putting their key in the hosts allow or deny list. Again, make sure that systems (i.e., machines) have their own keys, and not a person’s key.
  • Keep passwords in a central location. All account passwords should be accessible to more than one person. Password vaults are good for this, but a private document on a shared drive (or Google docs) will do in a pinch.
  • Ensure that passwords and other account information are in configurations, not hardcoded in software. This is a good development practice anyway; it makes deployments and running across multiple environments substantially easier. It also means that changing a password does not require a redeployment or a new build of the software.

Once you’ve set yourself up for success, you can practice accessing systems while someone is on vacation. After all, vacation is a form of leaving — just a temporary one!

When the day arrives and someone leaves permanently, you’ll lean on your infrastructure to handle that event. It doesn’t matter whether the person is leaving under good circumstances or bad; you should still take these steps to protect the company and the (now ex-) employee. In most cases, the departing employee isn’t intending to do anything nefarious, but it’s much safer to protect everyone involved. You don’t want that rare angry employee to do something! It’s also fair to the departing employee; they don’t want to be (erroneously) blamed for anything that happens!

The day someone leaves, do the following:

  • Roll passwords. Change all the passwords for accounts. This includes updating SSH allow lists and keys, and changing all the passwords for the accounts that person could access.
  • Check mailing lists. The person was probably on mailing lists and should be removed from those lists. This also applies to auto-forwards from those company accounts.
  • Close or forward the person’s accounts. Just to be on the safe side, make the person’s account read-only and disable access to everything, but don’t delete it yet. Give it a few weeks, and then go back and delete it once you’re sure you don’t need it. The same is true for the person’s email account. Don’t delete it; just disable login and auto-forward it to the appropriate person (usually the departing employee’s boss).

Leaving happens. Make sure it goes as smoothly as possible.

Image: Courtesy of Larry West/Flickr (Creative Commons)

2 Responses to “How to Prepare for a Team Member’s Departure”

  1. I think it’s important to put together documentation that explains from high-level to low-level the work that I do. This helps me put into perspective my role(s) and how it fits in the grander scheme of things.

    Starting a new job means (re)learning things together with details that pertain to the post one is filling in. Having access to documentation that the predecessor put together explaining their work adds another source of information that can supplement what the manager and/or coworkers provide.

    But I think this depends on what practices that team one joins has and also whether the corporate environment sees business continuity as important as disaster recovery. People leaving a company is a form of disaster.

  2. Two anecdotes:

    Programmer submits resignation. His final two weeks though are spent “doing stuff” rather than turning stuff over. The Friday after he is gone, when reports are being run, Finance calls looking for one of the reports he used to run for them every Friday. No one, even Finance, knows anything about the report.

    Programmer is told to leave the company. He is watched like a hawk whilst packing personal belongings. He is escorted from building. Next day his coworkers are asked to visit other departments to determine what the now-gone-guy was working on. More than 1 year later now-gone-guy is contacted and asked if he knows where code is that he wrote because nothing remains of the contents of his office, or any of the systems on which he worked. More than one year after that the boss who got-rid-of-now-gone-guy leaves “for personal reasons”. More time passes and new manager contacts now-gone-guy asking about location of source code, and perhaps now-gone-guy has copies of programs?