A developer leaving the company or getting fired in the middle of a project leaves the project managers asking the same question – How do I onboard another developer to keep up with the project’s pace?
The basics of onboarding a new developer
There are learning programs or development initiatives designed to help new employees get used to the organization, its working culture, job, and technology stack. Followed accurately and you won’t be banging your head in random corners not knowing how to make the new employee get on to the project on time.
Some might be familiar with the word orientation, but that’s a small part of the onboarding. Similarly, Knowledge Transfer is one step in the books of the standard onboarding process.
A weak onboarding process is the number one reason of employees quitting their jobs in the first three months. Given the importance of the onboarding process and your requirement to hire a new developer to quickly take over the on-going project, you don’t want to go wrong with that.
It will be too soon to make judgments on the new developer in the team if the said developer screws up on the first few days of the job. Remember, it’s the company’s job to make the employee comfortable first and then the employee responds back.
Knowledge Transfer is possible when the developer leaves on a good note and the replacement arrived before the actual farewell of the ex-developer. If a call of an hour or two can be arranged then that can serve both well. The outgoing developer can help get the new developer up to speed and provide feedback to the rest of the team about their capabilities to handle things going forward. The idea of this knowledge domain transfer is that the outgoing developer can share the necessary project details and status. The new developer can ask questions to clear any doubts and this way you’ve reduced idle time on the project.
Onboarding new developer in an unprecedented way
The above is the best-case scenario. Now, let’s assume that the old developer was fired due to inefficiency or breaking the company bylaws which forced an instant exit. Knowledge Transfer can’t happen. Someone you fired or leaves angry wouldn’t want to show up to train the replacement. Moreover, you wouldn’t want them back either.
The code is new to the new developer. So, you only have one option. The developer has to take control of where the previous developer left off. The process revolves around checking someone else’s old code, which is always a little challenge for any developer. The new developer has to learn the logic and standards of the code and replicate the same further in the project.
Once the new developer runs a scan on the code, the next big question is: Should they recode the whole project from scratch (because working on old code is frustrating or the code is bad) or, should they pick from where the old developer left (because the code is a good and personal preference of working on a fresh code rather than the old code might hamper the project)?
Greasing the onboarding process for a smooth transition of the new developer
Safety First: If the developer left on the bad note, change all the passwords he/she had access to.
The new employee is a guest on the first day. So, treat them like one. Given a warm, emotional, and technical welcome - the buddy-system is good for handling the emotional aspect. Assign a buddy or a team member to the new employee for making introductions and familiarizing them with the company environment. It would be better if you assign a buddy from the same team from where the old developer left as they both will be working together on the same project. It’s important you give them their time and space to connect with each other.
For a technical welcome, make new accounts on the communication channels you use in-house and introduce the technology stack you operate.
Do not pitch for examining the ex-developer’s code on the very first day. Don’t push to start on that. Nobody would want to examine someone else’s code on the first day of the job. Give the new arrivals the time to process the information, culture, and everything else. It’s all-new for the developer. You need them in their best shape to give the best results. Making them unhappy on their first day doesn’t take you in that direction.
Meanwhile, the new developer digests the new environment it’s time for you to do some homework before the second day. Evaluate where you went wrong with the previous developer. Where are things now and what needs to happen to get the boat to the other side of the river? How is productivity getting affected? How can you improve it now? The evaluation is to make sure that those mistakes are not repeated with this developer. That’s a standard improvement procedure – Not to repeat the same mistakes.
Begin with clearly stating the project goals and tasks at hand. Every detail of the project, the client’s chat, current situation, the block the project is facing, and the company’s standard coding procedures whatever the new arrivals need to know, unwrap it on the table. If they have worked on similar coding patterns before, Bravo! Time saved. But if they have come from a totally different coding planet, they might need some time to adjust to the new pattern. You could reduce this ‘mingling with new coding procedure’ while setting the requirements of the job post. Highlight some of the coding procedures in the job requirement and also look for the same in the applicant’s project descriptions in the portfolio. Hiring someone who has worked on similar projects in scope to yours will increase ramp up time.
Remember to keep up with the Emotional Quotient of the new developer. Let them enjoy their stay here and work at ease. The right onboarding process isn’t over in a day.
What if I am hiring a freelancer Or an Agency?
Hiring a freelancer or an agency does change the work relationship dynamics between you and the developer. The complete orientation phase and in-house onboarding activities aren’t the same. But, there’s still Knowledge Transfer and tech-stack learning to ease the communication because it is on these channels you are going to communicate with the freelancer.
You might want to get tracking software, but the freelancer might accuse you of micromanaging. A rough estimate on the tasks, deadlines, milestones of the project is a decent way to get things going.
In the hiring process, video-interviewing is a good option to know their personality better. A detailed job description will land you the right developer that will spend less time getting along with your company’s coding standards. Discuss all the proximities of the job prior to hiring. Keeping it clear beforehand won’t land you in trouble later.
In a Nutshell
Hiring a developer in the middle of a project can be a nightmare. No project manager wants that. But, sometimes, this is the only way to stay productive for the sake of the project. If you take the first few steps good with your new developer, you reach an increased retention rate and save the project as well.
