Stack OverflowWhat precautions should you take when a senior employee leaves?
[+36] [16] Mahin
[2009-09-29 06:40:54]
[ security training access-control user-management ]

EDIT : I agree one should check the reasons, why a senior level employee is leaving. But I am interested in knowing the official/management/technical/legal steps one should take after its decided that he is leaving, so that the life after him is smooth.

What are the steps management should take when a senior programmer/team lead leaves your company.

Some of them which I have thought about are :

  1. If He used to manage hosting and domains stuff, change passwords of domain control panels and hosting panels.

  2. If your published web sites have maintenance account and he is aware of credentials of that account then change this details also.

  3. Suspend mail account for some time and forward all eMails of that account to some ex-employee account. After some time close that account.

What are the other things one should check. I am expecting the answer to be a general check list one should follow. It should include both technical scenarios and management scenarios.

Notable Suggestions so far :

Best Regards, Mahin Gupta

EDIT : Now offered a bounty on it to get more detailed responses and practical suggestions.

(1) It all depends on the trust relationship you had with your employee. My vote for the check list would be: [ ] discuss the reasons for leaving, stay in good relationship - mfloryan
(3) @mfx : Agreed with the point to stay in good relatuionship, but if we think practically this is not possible always. And I dont think in professional world where our clients make sure we sign legal documents with them in terms of data security and uptime, it is good thing to lave things unsecured or vulnerable to ex-employee-threat. - Mahin
@ Mahin "but if we think practically this is not possible always" On your these wording, I would say some thing is always better then nothing, Bad relationship would lead to nothing. And regarding source code , If he is really senior and deserve this word he do not need source copy of source code , he can buid it by him self :) - Satbir
How has this question avoided closure and deletion? - John Saunders
[+26] [2009-09-29 16:13:17] Satbir

I would say when any senior people leave your company, you must:

  1. Give a warm farewell so that they have a +ve picture of your organization, and in the future they may come back happily.

  2. Respect their decisions, Do not take it personally :)

  3. Speak good words about his contribution to your company

  4. Last but not least: see if something is lacking in your organization that is causing senior personnel to leave. Senior people do not often switch jobs.

These process you can include in revealing an employee.

Most important is KT (Knowledge Transfer), Choose an employee who will hold responsibilities and schedule proper knowledge transfer sessions.

  1. NDA (Non Disclosure Agreement)
  2. Clearance from Accounts
  3. Clearance from Finance
  4. Clearance from Security

@SSS : I agree one should check the reasons, why a senior level employee is leaving. But I am interested in knowing the official/management/technical/legal steps one should take after its decided that he is leaving, so that the life after him is more smooth. I think my question title is wrong. Should i edit my question to include this info ? - Mahin
(1) +1 for knowledge transfer. I've seen this skipped or done poorly too many times. - tsilb
(1) +1 See if really somethings lacks in your organization due to which senior is leaving you - Ram
[+16] [2009-10-02 19:47:08] Seth

Depending on how senior / what position, you might spend some time convincing him not to take the rest of the engineering staff with him.

I've seen it happen plenty of times. A popular engineer is off to start a new business or moving to a competitor. Your other engineers see an opportunity and/or agree with his reasons for leaving and follow him.

Suddenly you have no engineering staff. Oops.

(2) +1 : I have seen it happening so many times. - Mahin
And it's usually caused by said company being complete douchebags to their employees. Sometimes it's just not possible to stop the hemorrage. I've seen entire departments of developers quit a job, go do helpdesk for a year, and then start up a competing business, and do it better. - Chris Kaminski
[+15] [2009-10-02 17:59:13] jjclarkson

Part on good terms

You don't want to burn bridges here. Often if there are bad feelings on leaving, just the knowledge that you tried to take care of them on their way out the door is comforting to them and will protect you from a backlash.

Get as much input as you can

Most people will not want to say anything negative. However knowing that they won't be back, they may be willing to share things they weren't before because of it.

Don't get surprised

If you don't know all that that person did while they were in your employ, you could easily get caught with your pants down later. Are they available to help out if there are questions later? Is there some manual process that they are a part of that needs to be passed on?

Keep everything for a time

You need to make sure you can get documents, emails, and other communications before and after they leave. Their replacement should have complete access and an understanding of the departing person's methods.

Compensate them

If there is no reason not to, you should reward a departing person for their many years of service. Write them letters of recommendation (even if they already have a new job lined up). Celebrate the part of their career you had them. And provide a good severance package. Say goodbye, and keep the door open.

Security measures Have a checklist of procedures to follow through on when an employee leaves. It may require an effort from several people to take all the steps. So have a procedure in place for making sure all changes are made quickly.

  • Obtain all company property, laptops, keys, etc.
  • Redirect Email
  • Redirect voicemail
  • Change passwords
  • Deactivate accounts, credit cards, IDs

[+13] [2009-09-29 17:05:03] HLGEM [ACCEPTED]

If he gives the standard two weeks notice, use that time wisely to train someone else. Any new dev that must happen then, have it done by the new guy not the guy leaving with the guy leaving looking over his shoulder and providing advice. Ask him to create a document of things he thinks you should know, especially if you don;t havea an immediate replacement. Have him write it from the poitn of view of what he would want to know if he was coming in to take the job. A senior professional leaving will probably do that anyway, but it's helpful to ask for one. If he's been working on a project that no one else is working on, make sure you know where the files are stored in your source control system. Make sure he checks everything in now and then any checkout will only be done by the replacement.

Emails, copy off his email account to a pst.file (this assumes Outlook), Make this file available to his replacement (you can link to multiple pst files, I had this on one of my previous jobs and it was hugely invaluable). There is a lot of work documented in emails that the replacement probably was not a "copy to" on. Very useful to be able to research what happened in the past. Same thing with past projects if they are in some type of project management/bugtracking system. You might want to find a way to make all the old projects available to the new guy through your database backend. Amazing how often in life you need to refer to this stuff. If he gets a new request that says something like, this is simliar to request 1234, you want the new guy to be able to read request 1234. IF someone says, I told Jack about this in an email back last July, you want to have a chance to find that email.

Copy the hard drive of his computer to a network location and have someone senior go through and see if there are any files on it that someone else might need. Needs to be someone senior if he had any supervisory responsibilities as he might have drafts of performance reviews or other sensitive issues there.

+1 for copy eMail stuff. - Mahin
+1 for saving his emails! - Dashogun
(11) There could be some ethical issues with copying email. If there isn't prior agreement that the company has the right to read the emails this could cause problems. At a minimum the employee should probably be given a chance to scrub the email. Using work email for personal stuff you wouldn't want anyone else to read is a bad idea, but it still happens. - Mike Two
@ Mike Two : +1 for " At a minimum the employee should probably be given a chance to scrub the email." - Mahin
wow, is this really legal? - IAdapter
(3) I believe it is legal (at least in the US) for the company to read the emails that are on their computers that are only for work purposes. They are their property after all not the employee's property. Many many people have been fired for misuse of email because the company read bad things in their emails. Most companies have a written policy on email use and the storage of personal items on work computers. - HLGEM
(1) I would not give the employee a chance to scrub the emails if he was leaving on bad terms (you generally don't let an employee touch his computer when he is being fired), otherwise yes. - HLGEM
@Mike Two, I believe in the US that the default situation is that email belongs to the company, not you. Corporate email users should have no expectation of privacy. - Peter Recore
[+7] [2009-09-29 06:44:23] rahul

The one I would vote for will be to effectively transfer the responsibilities of that employee to another one without causing any potential delay in your work.

(1) @Phoenix : good one and very important one. +1 - Mahin
(1) It's not possible with a senior position. It may take months to years before a new senior gets really senior. - user151323
(2) this is good, but suggest instead that it is an opportunity to transfer the responsibilities to more than one other person. - Zac Thompson
@Zac Thompson : for using "more than one other person" - Mahin
[+5] [2009-10-02 18:27:30] Brandon

As someone who is dealing with this, I'll say that aside from the previously mentioned points, the main concern for me has been to make sure any outside clients know that the departing employee is not their main contact anymore.

A lot of clients can become frustrated if they weren't informed someone they're familiar with and comfortable with has left and now they're dealing with someone they may have never met before. Some clients don't care as long as the work gets done, but others will cause a big fuss.

Stealing/transferring clients to the new business could also be an issue, not only in IT but all businesses. - Hannson
[+4] [2009-10-02 18:11:39] Cade Roux

A lot of these suggestions regarding security should be done before any employee leaves.

For instance, the employee's company email and company account should not be used for domain registrations in the first place.,, are all accounts we would use to maintain communications. Access to those mailboxes is by a role and when an employee is removed from that role, you are done. The employee never knows those passwords and never even owns the actual account.

Similarly, service accounts should not have known passwords.

If you do have shared accounts, the passwords should be rotated early and the access to the password vault system would already be revoked by role.

All these things should be set up in the first place assuming that the role is going to change over time.

In addition:

Never neglect the exit interview/debriefing

Always complete finalizing negotiations before informing other employees - this saves a lot of embarrassment if the employee really loved his job and just wanted more money and a counter-offer kept him happy

Confirm the last day of employment so that there is no misunderstanding

Inform H/R if the employee is on H1B status, there is paperwork required to notify the government when an H1B employee leaves, this is not automatically handled by most H/R systems, where terminations are relatively simple.

[+4] [2009-10-06 17:31:26] Dean J

Knowledge transfer just prolongs the problem.

Stop having them code when they put in notice. Have them start writing documentation, and have that documentation continuously reviewed by at least two people. Pay them after they leave, if they're willing, to keep writing documentation if necessary.

If you didn't already have an non-disclosure agreement (NDA), you're very unlikely to get one from them after they've announced they're leaving. They have no reason to want to sign that document at that point. If an NDA is useful, you should have new employees sign that, not leaving ones.

Changing your passwords can't be understated.

And if you're less senior, it can't hurt to ask where they're going, and if they'd take you along. There has to be some reason they're going.

(1) Wouldn't it be easier to ask everyone to document their stuff as an ongoing process, in the inevitable event that they move on to new responsibilities or leave the company? Then it is less likely that data will be lost when your 2-week cram session begins. - BryanH
It's easy to ask, but hard to enforce good documentation. It's easy to ask of leaving developers, and they usually do a decent job of it; they know the code better than anyone, and you're better accepting documentation of older work than brand-new work that won't have a chance to be tested before they leave. - Dean J
[+3] [2009-10-05 07:38:29] Ashish P Thakker
  • If the employee is being laid off, give him enough time to find a new job.
  • If Possible be nice to him and write a recommendation letter for him ( If possible. )
  • Sit with him and know his views about the company procedures and get his suggestions. ( 99% of time, these suggestions are so true. )
  • Make sure he spends his last day on a good note, because if he is not leaving on a good note, he can easily pollute the mind of his colleagues.
  • Use his notice period to train his replacement and other people. Don't make him code new things until and unless it is very very necessary.

[+2] [2009-10-06 02:03:17] Jim

In regards to the email aspect, if you are going to keep his account open for whatever reason, check that no rules are created that forward incoming emails to an alternate address. This may apply more to positions like sales, but in any event, sensitive information might be at risk.

@Jim : +1. Good point. - Mahin
[+2] [2009-10-07 20:24:34] BryanH

With respect to the knowledge transfer:

Assume every employee will (eventually) leave -- because they will**.

With this in mind, it will be beneficial if everyone keeps process/function/workflow details and account information in a Wiki or somesuch. Then, when it comes time for the successor to 'take the reigns', there will be a foundation of knowledge ready to be consumed.

Ongoing cross-training (at least for familiarity's sake) is also a good idea.

Even with good intentions, a company needs to guard against the "SSHing/surfing to secret admin pages while drunk" syndrome, thus it is necessary to change the admin passwords where possible and limit admin-level accounts from being accessed from outside the company's network without SecureID, Citrix, or equivalent.

** Retirement, Death or voluntary/involuntary separation. Pick one.

@BryanH : +1 for Wiki. We are already on the move to implement it. - Mahin
[+1] [2009-09-29 06:53:48] FractalizeR

You just change any passwords or other access details that guy had access for. That's all. Plus, I agree with phoenix here, you transfer responsibilities to another worker.

[+1] [2009-09-29 09:36:15] harriyott

Make sure they don't have copies of source code. Hard to prove, but get them to sign something to say that they don't.

(6) The guy is leaving anyway. Why would he sign it? Would you? - Evernoob
@Evernoob : If he wants reliving letter or experience letter he should sign it. And I think its a good thing to do to make sure they do not chat you. And again normally companies have a clause stating that all the work created by employee during his employment is owned by company, so I think company has all legal and ethical rights to make him sign such legal document. - Mahin
(10) Im not convinced that this is particularly constructive. If his contract says that he isn't allowed to take it then he is breaking the law if he does. The second piece of paper does nothing to change this. In my experience if you treat people like sensible adults then they will act like sensible adults. If you treat him with suspicion he may well feel he has nothing to lose. - Jack Ryan
(3) You really can't make someone sign anything. At least in the U.S. I'm not even sure if its legal to do that with a threat hanging over their head. In most industrialized countries, in the absence of an agreement, its understood that a salaried employee does not own the code they write. If its a contractor, then the contract will specify. - Steve
@Jack : I agree with your argument saying if there exist a contract already than it does not make any sense to make him sign again. But I firmly believe that if such agreement is not there, then you should ask him to sign one. It is not about trust. It is more about securing code/data ( which may be owned by our clients, and we have signed agreement with them that we will not share/distribute/publish it in one or other manner). - Mahin
@Steve : Totally agreed with your point to check if making him sign such document is legal or not. Thanks for suggesting it. - Mahin
(2) Non-disclosure should have been part of the contract when he started - if not, it's too late now. A reminder might not go amiss in some cases, but for a senior employee, especially if it's not part of an already standardized procedure, it might easily be taken as an insult to his intelligence and integrity. - Steve314
(2) The main problem is that in most jurisdictions, for a contract to be legal both parties should benefit. A contract by a stronger party (employer) with no advantages to the weaker party (employee)? That's not going to hold up in court. - MSalters
I am an author of the code. What I have written once, I can write once more. There'll be no evidence that I have stolen my own code. You don't have to be aware of stolen code, you have to be aware of your mistakes that leads to business loss. - Viktor Jevdokimov
@MSalters: for a contract to be legal both parties should benefit. Huh? They get your sweat and you get paid. That is benefit all around. As far as your claim that a contract that grants disproportionate benefits to each party is "not going to hold up in court," I assume you've never been in the armed services. - BryanH
@BryanH: I don't think that MSalters was referring to the original employment contract, but any sort of exit contract. "Party A leaves party B's employement, party B puts constraints on party A's behaviour in its favour" has no benefit to party A, he already had a right to leave. - Charles Bailey
[+1] [2009-10-03 11:07:11] Steve314

Does that senior employee have a grudge? If not, don't panic. Your procedure should be the same as when anyone leaves who may know passwords etc - and if the company is more than a couple of people, you should have a standard procedure for it.

[0] [2009-10-06 17:41:22] JB King

Be aware that those that reported to that senior employee may soon leave too. For example, where I once worked, we had a new CTO as well as some new managers that had all worked together at a previous company and they came over together. I'd just be cautious of anyone connected to that senior person possibly going with them which also includes clients as well as minions.

[0] [2009-10-07 21:16:40] Mircea Grelus


Have an amicable talk with him to find out the reasons that he's considering leaving for. There might be a certain problem in the organisation that you weren't aware of, and people were probably reluctant to bring it up based on other reasons. Usually it is frustrating when the management doesn't realize your frustrations.

Because the person has already decided on leaving it is more likely that he'll open up now. It might be something that you can address thus decreasing further possible turnover.