Knowledge transfer and best practices for developers rotation
There’s lots going on in IT, and even more “temptation” for the developers: new technologies, innovative projects and job offers bombings on LinkedIn every morning. Oftentimes, those are young people we’re talking about, hungry for new challenges and new… jobs. Most programmers aren’t used to spending years and years on end working at one company, so even if you provide the greatest employment experience, you have to take into account people leaving you, by law. As an ex-developer myself I know from experience that the reason for making a job switch isn’t necessarily a bad project or a better financial opportunity, but simply the need for new challenges (and you can only fight that so long).
While it seems like it’s nothing you want for yourself or your company, it doesn’t mean all that’s left to do is to sit down and cry. In fact, this inevitable situation, instead of hindering the project, could potentially move it forward quite a bit. You can turn it into an opportunity for fixing up any issues that’ve been creeping up or an educational experience for the rest of the team. It’s also a great training for the bigger challenges that await you in the also-ever-changing IT industry.
So, let’s get down to business and discuss the practical steps you can take to make this transition the smoothest one possible.
How to be prepared for any developer’s potential departure?
There’s a great reminder that comes with each decision to part ways, and that is to update all work on an ongoing basis. If you run a state of the art schedule of tests, documentation etc., the transition will be almost pain-free. Otherwise, the cost of fixing a bug grows exponentially with each stage of the software’s lifecycle. Established and followed production processes together with diversification of decision-making power turn the project into a well-oiled machine, able to run even amidst any HR turmoils.
It’s also a good practice to avoid constricting people to narrow roles and scopes of responsibility. Don’t have the team lead make all the decisions, teach juniors how to perform code review, etc. That way the project won’t be hanging on each individual and their availability. It’s great not only for the company, but also for each employee themselves, as it incentivises them to grow professionally at a faster pace. The agile project management methodology also falls very much in line with that notion, as does our teal organization model. They both assume a joint responsibility for the project and the entire company, meaning it is easier for everybody to get involved in the transition, rather than remove themselves from the situation in search of convenience and familiarity.
The second important issue is the job ad – you should always have it on hand, prepared and ready to go as soon as you get the news, to ensure near perfect continuity as much as possible. If you put it off until the inevitable happens, you’ll be scrambling to create it and looking for the right places to post it, rather than focusing on the knowledge transfer process. It’s also a great idea to have it looked over and potentially edited by the employee that’s leaving, as they know their job and tasks best. It might even be one of the first things to get done once you receive the news.
What to do when a developer decides to leave the project?
Over the years, benefiting from the experience gathered, we’ve designed a project handover / knowledge transfer process that works really well for us. Here it is in detail, step by step. Feel free to take what (or all) you need from it.
Know the reasons
The first thing to do once you get the bad (?) news is to get to the bottom of things. Treat this as a unique opportunity to learn more about your organization and what goes on outside your sight’s reach. If you make the time and effort to talk to the person without any heated emotions, you might find out that eg. there’s something wrong going on in the project (and act on that knowledge to prevent any other potential shifts).
This is also the time when things still can be undone. When you know the real reasons for the departure, there's a possibility to fix things. We've had this situation happen several times at Code Poets, where after a deep conversation we were able to make arrangements that satisfied both parties and allowed us to continue our collaboration to this day, with mutual contentment.
Often, the reason at hand is of financial nature. After all, there’s even a saying in the industry that goes along the lines of: “What’s the easiest way to get a raise? Get a new job”. If that’s the case, learning about the employee’s expectations and the salaries on the market is on you. The changes are so dynamic, that you may have just overlooked them. On the other side of the coin, if the explanation doesn’t have anything to do with finances, don’t offer a raise. It can’t end up well – the person will remain unhappy thinking that they stayed only for the money… only to eventually leave anyway. Fix the problem, don't just cover it with shiny pennies.
As you can see, it is an extremely important step that’s sadly often overlooked at companies where the manager lets his hurt feelings or simply rush take over and doesn’t fight for the relationship the way they would with a client. It’s really worth it to apply yourself and schedule even several meetings depending on the situation (does the employee have a new offer already or not yet, etc.?). Even if you ultimately part ways, there are other details to negotiate in some cases, such as the notice period. All that counts (and will count as the company’s costs), so be wise.
Analyze the tasks and set the priorities
If the decision is final, it is time to join forces with the employee and their project leader to analyze all their responsibilities and the project’s goals. Sort them according to their importance and urgency. Pin-point longer tasks that the person has just started working on (or had plans to) – it most likely makes more sense for them to drop it at this point, as the developer who replaces them in the project will want to do things their own way and it will probably be just wasted effort. Same applies to any side- or internal things they may have been involved in. In such a time, it just doesn’t make sense to spread oneself thin.
The priority (and time) should be set on the knowledge transfer process as well as wrapping up the short-term tasks. Anything else should either be delegated or put on hold – all to ensure the continuity of the development in the project.
Go over the technical documentation
It is extremely important to ensure that everything is updated before the employee in question leaves, especially when talking about senior and architect roles, responsible for the big picture. Make sure to carve out sufficient time in the notice period for any necessary edits if that’s not the case.
Apart from the technical documentation, there might be processes the person was involved in or responsible for. Write. Them. Down. :) It is not enough to share them during a meeting or rely on other team members to carry on this knowledge to the newly-hired specialist. If you don’t have a handbook for all your practices, processes and procedures, the time to start it is now.
Open the recruitment process
You have your ad ready for any final touches, so share it with the employee, learn their opinion and implement potential changes. Ideally, all of that will be done by your HR specialist/department, as a part of a well-oiled and ongoing process. If you had the position open permanently, now is the time to reach out to any candidates and intensify the recruitment actions. Make sure everyone is on the same page when it comes to all your HR priorities.
Organize knowledge transfer sessions
Most likely there’ll be a few of them, so make sure to schedule them in advance to accommodate the calendars of everyone involved. In an ideal scenario, the notice period and recruitment agility will have the leaving and incoming specialist meet and they’ll be able to get involved in the sessions and work together. If that’s not the case, the meetings should be attended by the team member who’ll act as “a buddy” to the new-hire and collaborate with them during their first weeks at the company. All the documentation prepared beforehand should make these sessions a breeze.
Have regular check-ins
It’s a great idea to monitor the progress regularly. You may have made too many plans or maybe the priorities have changed due to external circumstances – whatever it is, there’s no reason not to approach this whole process in an agile way. Schedule short weekly or bi-weekly meetings to see where things are and make changes in the plans accordingly. This will help you avoid the stressful rush of the employee’s last days at work or prepare better for any shortcomings in the shift and navigate their consequences respectively.
Your last check-in should include a summary of all your efforts alongside a checked list. If there’s something that didn’t make it and you still consider it important, have the employee help you decide what to do with the task to cut your losses as low as possible.
Say your thank-you’s
Make sure to part in good spirits. Any change is stressful so if at any point a party in this has acted a little unprofessional, now is the time to fix it. Don’t think that since you won’t be working together anymore, there’s no need for kindness – if it isn’t simply in your nature, at least remember that the world always ends up smaller than we think. All business relationships are worth taking care of and you never know when and under what circumstances you might meet again.
If you’ve decided to hire them in the past and you’re not the one initiating the good-bye, chances are you’re happy with their work and respect them as a specialist. Just make sure to express that.
All in all, rather than being in denial, it is a really good idea to accept the inevitable changes in your team and prepare for them. That way there’s a chance that the project will hardly feel them at all. No matter how good the developer, projects rarely fail just because they leave – with good practices in place, replacing them shouldn't be too hard. After all, software houses do it all the time and still manage to score raving reviews from their customers. In fact, any change has the potential to bring many more (positive) ones. Each time something shifts in the project, everyone can take a step back and evaluate their role and responsibilities to make it more efficient.
Interested in learning more about how we deal with our (very, very low) turnover at Code Poets? Want to chat about your project? I’m here for you!