What to do when you are on the receiving end of a 2 week notice

Posted on

One of the things I hate the most about my job is having to deal with losing good people on the team. I run a small organization (currently 10 people including myself) and there's very limited redundancy in terms of responsibilities, roles, and skill set. Losing one individual often means that I lose a significant portion of the team's collective knowledge. It's painful when all I have is 4 software engineers on the team and one of them turns in his resignation letter. Or when all I have is 2 QA engineers and I realize that I'll be at 50% QA capacity for the foreseeable future. Just a few weeks ago, my one and only system administrator on the team told me he would be leaving the company in 2 weeks and when I found out, it just about ruined the rest of the week for me. Of course, I'm well aware of the fact that everyone on my team will eventually leave the company at some point but... it still comes as a surprise (the bad kind) to me when I'm the receiving end of a 2-week notice. Nowadays it appears that having tech employees stick around for more than 2 years is considered a long time.

Since stepping into my role as the VP of Technology roughly 2 years ago, I've had 4 people resign voluntarily and with each occurrence, I'd like to think that I've gotten better at dealing with departing team members. Here is a list of things I would recommend when someone on your team has turned in the dreaded resignation letter. I would like to note that the items I'm listing here might not be as relevant if you're running a larger organization where there is (maybe or maybe not) a lot of shared responsibilities among employees.

Confirm the finality of the decision

When your team member turns in her resignation letter to you, don't simply accept that she will no longer be with the team in 2 weeks. It's not always the case that people have another job lined up and that they have to absolutely stop working for you in 2 weeks. For instance, last year November, someone on my team informed me that he would like to resign. He was doing solid work for me and was the only database administrator in my organization. Plus, I was pretty certain that it was going to take me several weeks (maybe months) to find another person of his caliber. After a little bit of probing he told me he didn't have another job lined up and made it clear that the reason for his resignation was not because he didn't enjoy working at the company. After a little bit of going back & forth, we decided that he was going to work for me as a part-time contractor working 10 hours a week. We kept him on for 5 months and my gosh, looking back, I am so glad we had him for those 5 months even if he was only working 10 hours a week. He played a crucial role in our ability to successfully to migrate to AWS in production and really could not have done it without his help. I was able to hire a full-time replacement for this individual towards the tail end of his contract and everything has turned out well so far.

Tell others right away

Share the news of the departing employee with your team right away. And if there are others in the company who could possibly be impacted by your departing employee, let them know right away as well. Throughout my career I've seen several managers be lazy with this piece here. Bad idea.

Carefully plan departing employee's remaining time with the team

Work with the employee to re-plan the remaining time that this person has left at the company. Every single thing that the employee was planning to work on for the next 2 weeks should be put into question. I'll talk more about this down below.

Knowledge sharing & documentation.

The last 2 weeks of this employee's time absolutely needs to be focused on this individual sharing as much of his knowledge as possible with others on the team. Knowledge sharing should be done via documentation as much as possible and at least 1 other person on the team (perhaps yourself) should be verifying that knowledge sharing is thorough enough. The last thing you want is for this individual to spend 2 weeks in documentation misery and for someone to realize many weeks & months later (after the employee has left the company) that there are significant gaps in the documentation.

Designate at least one individual on your team who is now going to be responsible for doing much (as much as possible) of what the departing individual had been doing. Make sure that this individual isn't simply watching over the shoulders of the work that the soon-to-be departing employee is performing. The person being trained/ramped up should be the person doing the actual work and typing away. I don't know about you, but I don't learn very well when I'm merely watching someone else do the work. It's way more efficient and effective to learn when you're actually doing the work yourself.

Look for additional opportunities for team members

While losing a valuable team member might be bad news for you, it might be good news for someone on your team who is looking for additional opportunities. Keep this in mind when you're figuring out who's going to be taking over the responsibilities of the departing employee. Soon after I joined Cappex in 2012, there came about a rather sudden void in tech leadership. I'm sure this void was painful for the company and especially painful to senior management at the time. I, on the other hand, took advantage of this opportunity and did a lot of "CTO" things during those few months, which provided me with some amazing opportunities that I had been wanting for a long time. Without the experience back then, it's highly unlikely that I would be in my tech leadership role today.

Stick to simple tasks only

Do not let your soon-to-be departing employee work on something that may be the root cause of that very "thing" (module/service/function/etc) breaking sometime after she leaves the company. Don't let her work on things that are in state of flux. Don't let her work on things that others will soon be building on top of. Don't let her work on even mildly complex things. Don't let her work on business critical features. Even if you think that you you must break one of these "rules" - I challenge you to find a way to not go down that route. But if you ABSOLUTELY MUST - make sure someone else on your team is intimately familiar with the work that she is doing. Losing a valued team member is always risky. Don't add to the risk factor by having the departing individual work on something risky.

End on good terms

I care a lot about how my departing team member's final 2 weeks with the company are spent. I want the departing team member to feel good about me, the team, and the company during these last 2 weeks. I try to make the employee's remaining time with the company as stress-free as possible. I try to make sure his accomplishments during his time with the company are recognized by others on the team and the company. I get a "good bye & good luck!" card and ask everyone on the team to sign it. I organize a lunch outing in honor of the departing employee. One of the main reasons why I do all these things is because I want things to end on good terms. And I want things to end on good terms because there's a small chance that I may need to reach out to the employee weeks or months down the road and ask for some help. While it's rare that I (or others on my team) have had to reach out to the departed employee to ask a question I'm completely stuck on, it has happened before and it probably will again in the future. If things between the departing employee and the company end on bad terms, the odds that this person will help answer a question or two down the road are severely diminished.

Get moving on recruiting & hiring ASAP

If you run a small team like I do, it's very possible that the departing employee is the only person on the team, or perhaps in the entire company, that has the in-depth skill set and the experience to be able to effectively interview and assess her replacement. And if that's the case, you're going to want to get moving on finding her replacement as quickly as possible so that the departing employee can work with you on conducting your initial round of interviews. While I feel confident about my ability to assess software engineer candidates, I'm not nearly as confident in my ability to assess system administrator and database administrator candidates. As such, I've had to lean on my departing sys admin and DBA employees to help me with the process of finding their replacement and every time I've done this, I've found it to be very helpful.

Closing thoughts

Even though there's a large part of me that wishes that everyone on my team would stick around forever (well, at least as long as I'm around to manage them) some employee turnover is good & healthy for an organization. Yes, having to deal with departing team member is often painful & time intensive as a manager. However, keep in mind that new employees bring new insights, ideas, and ways to go about solving problems that often add so much value to the team. Even as I'm writing this blog post, I'm reminded of numerous positive things that have come out of employee turnover.

And by the way, I'm still looking to fill that open sys admin position. Please reach out to me if you're interested!

comments powered by Disqus
© 2020 Junho Park
This website is built on Ruby on Rails with Bootstrap and Sass. The blog is powered by Postmarkdown. The opinions expressed here are my own.