Dealing with Turnover

posted Wed Jun 06 21:36:46 +0000 2007 - permalink

It's bound to happen. People move on, or perhaps a decision has been made to move them on. Regardless, it can a deep impact on the moral and work of a team.

What generally occurs when a new application / project / widget is developed is that the person who developed it ends up maintaining it. This can mean that losing your most prolific developers means that you lose the know-how across multiple applications. It can be worse losing those rockstar developers who see problems and self-directedly fix them on their own, developing new processes or apps: suddenly you realize there are things there you may never have even known about, or were told casually in a hallway conversation.

It can be difficult to combat this in a busy environment, especially if the staff is skinny (i.e., not enough developers). But in general, if you have a ticket system (and you do have a ticket system, don't you?) try to get a feel for people's comfort level in sharing the maintenance and assign tickets in a round robin fashion (for particularly troublesome or sore spots in your codebase, you'll probably want to assign them to yourself first to ensure the skill level required and possibly to do some cleaning or subdivision of tasks).

If turnover occurs in the middle of a project, you'll need to assess schedule impact immediately (you have a schedule, don't you?), and negotiate the boundaries of features-to-deadlines. You don't want to turn someone leaving in the middle of a project into a full blown exodus, so handle this calmly, carefully, and deliberately -- everyone on the team will be smelling long hours coming down the pipe, so don't fulfill their worst expectations if you can help it. In addition, I'd recommend planning on bringing someone on after the project is almost done; they can be brought up to speed as you enter the deployment / maintenance phase, easing the burden on the rest of the team without distracting from the core development push.

Turnover is tough, but it's a natural part of any team and should be anticipated (it's going to happen at some point!) and couched in the best possible light when it happens -- people's minds will be necessarily elsewhere when they get set to leave, so be sure to give them a little extra prodding and code reviews before they take off. It'll help you understand the subsystems they worked on, and keep them focused on generating those precious wiki docs you'll need after they're gone.