Even when you have a world-class engineering team, there isn’t much you can do to prevent turnover. In fact, the best engineering managers remain prepared for the day when a developer accepts a new job opportunity or decides to start his or her own company. But that preparedness goes far beyond a short-list of people to reach out to whenever you need to backfill a role. The bulk of your work involves ensuring that information isn’t lost, projects ship on time, and the rest of the team doesn’t feel overwhelmed. To keep the rest of your team on track, here are a few things engineering managers should do as soon as they receive a resignation from one of their employees. Schedule Time to Create a Transition Plan Even though employment laws in the United States don’t require you to give your two weeks notice, developers that want to leave on a positive note will do so anyway. In the very likely event that your departing employee stays for two to three weeks, take advantage of this and create a transition plan with that person. Immediately after a programmer submits his or her resignation, schedule a meeting to outline their current projects, the challenges they’ve faced in completing them, and the work that has been completed over the last few months. To prevent duplicate work and create new documentation issues, ask your developer to bring as much information as possible. From there, work with that person to fill in any remaining knowledge gaps. At first, it might make sense to notify the rest of the team before you do anything else. While you should alert the group as soon as possible, having the transition plan in place before you make the announcement will enable you to answer their follow-up questions about the departure more easily. Notify the Team and Key Stakeholders Again, once you’ve outlined a transition plan, don’t wait until your next team meeting to share the news. Schedule a separate time as soon as possible, and make sure to be explicit in your invitation about what you want to discuss. Use this time to review the departing developer’s timeline, as well as the transition plan that you created. Be clear about who will be taking on this person’s responsibilities, and leave time for the developer to answer any questions that his or her peers might have for them. This will prevent any documentation issues going forward. But if a developer isn’t leaving on good terms and isn’t in attendance for this meeting, don’t avoid questions about that accelerated timeline. At the same time, resist the urge to get too deep into the details surrounding that person’s transition. Schedule Shadowing Sessions Before the Employee Departs Anat Lechner, a clinical associate professor of management and organizations at NYU Stern, told the Harvard Business Review that transferring knowledge is one of the more difficult and critical components of employee turnover. Not only will you need to replace this person, but your existing team will also feel overburdened in the meantime. Typically, shadowing is an essential piece of software engineering training for new hires. But Lechner says that this concept should also be applied when a developer chooses to move on. “During the exiting employee’s notice period, set up an ‘extensive shadowing mechanism’ so that those taking over his responsibilities can absorb what they need to,” Lechner says. “[The toughest part] is transferring the sticky knowledge—the things an employee knows that can’t necessarily be shown on an Excel spreadsheet.” As a developer prepares to leave, ask that person to walk his or her colleagues through the code they were writing. What are the nuances to their projects that can’t be seen in the code itself? What are the mistakes that he or she has made along the way? The answers to these questions can make life much more comfortable for any programmer who’s taking over a project from a former teammate. Want to share knowledge without repeating information time and again? Find out how Stack Overflow for Teams can help.
3 Things That You Should Do When a Developer Resigns
