I read many interesting articles about preparing an efficient onboarding process. It is crucial to make new developers contribute to the team as soon as possible. Unfortunately, sooner or later people quit. This is also something our team should prepare for.
Most of the time, employees and contractors have a notice period which lasts usually from two weeks to three months. This might seem like enough time to transfer knowledge and duties, but my experience shows that it’s never enough.
Prepare for the offboarding period
When an experienced person brings their resignation letter, often a panic mode starts within the team. Suddenly everyone wants something and the person who quits has a really busy time.
Sometimes, ambition strikes. Knowing that the days of our current job are counted, we can fall into a mania of fixing everything. This can bring too much chaos into the team and the resulting value is not worth it. If you suddenly decide to update all libraries in the system, you can break a lot of things and drag people away from their current tasks.
There is a simple way to avoid such an “offboarding rush”. Your team should perform regular documentation updates, automate manual tasks, write tests and don’t wait too long with refactoring bad code. This should be a routine, not an exception.
You should avoid the so-called knowledge silos. It’s inevitable that developers in your team will specialize in different parts of the system, and that’s ok. However, you should foster information exchange whenever feasible. This includes proper knowledge base, commit messages, branch names, issue descriptions, chat groups/channels etc.
If you create a hack or workaround somewhere, under time pressure, then at least describe it in a visible place. Other people will be aware of that hack’s existence when you’re not around. I’ve witnessed a lot of situations when experienced people left a lot of hacks even on production servers and then just quit. Such hacks break in the least appropriate time, like a peak of a sales season.
The same goes with every manual task done by a particular person, like manual deployment, setting up repositories and so on. These should be at least documented, so that someone can take over such duties. The best way is to automate as much as possible in a clean and descriptive manner.
Easy to say, huh? But developers often postpone maintenance tasks which are not a part of the client’s requirements. If stakeholders don’t yell at you when you don’t ship unit tests on time, then… you postpone them. They won’t complain about your internal documentation either. Stakeholders aren’t interested if your workplace is clean or dirty if they get a working product. But things can break soon if you don’t clean your mess!
Make a good use of the time that’s left
When the date of somebody’s departure is set, the whole team should decide how to spend the remaining time. You can organize knowledge sharing meetings or pair programming sessions. You can sit and discuss refactoring ideas that could be realized in the future. An experienced developer might share thoughts about further product development and possible problems.
Focus on the most important and valuable activites. As I said before, don’t try to fix everything at once. Also, a person that is about to quit should not do any more tasks on his or her own. The offboarding time should be spent on supporting the team.
Be honest but polite
Quitting a job is often preceded by months or even years of frustration. There can be a lot of reasons for that, and when you finally make the decision to leave, you probably think it’s the only solution left.
In the first years of my career I made a mistake of not being honest about my work expectations, like salary or duties. Employment is all about two parties getting along with each other. You shouldn’t be afraid to talk honestly to your boss.
However, don’t burn bridges. You never know what happens in the future. Maybe you’ll meet your boss again in another company? Maybe some day you’ll receive an interesting offer from your superior?
Also, be polite and do not spread your frustration everywhere. Your team might still contain new, enthusiastic people. Don’t take their motivation away.
Be responsible
The way people quit a job tells a lot about their social skills and emotional intelligence. Also, the way a team deals with people leaving the workplace speaks a lot about its practices. We all need to be responsible, mature and polite, so we can avoid sudden stress caused by someone quitting.
Latest comments (3)
Hi Piotr,
great post. One of my favorite statements is the following:
This is so true. I have seen it way too often, that people infect motivated, young colleagues with their frustration.
Don't do that!
Thank you, glad you liked the article :)
I made that mistake of infecting young, motivated colleagues myself. That's why I mentioned it. There is a very thin line between making fun of corporate absurds and demotivating people. I think we shouldn't lie about our workplace, but we shouldn't escalate conflicts neither. Especially when we have years of experience in a particular organization and we know its structure well.
We should discuss problems in a constructive way, so other people can see light at the end of the tunnel, even if we're burnt out. And no personal attacks, of course :) This can be astonishingly hard to achieve.
Well noted. And I love the being responsible aspect of the article.