Losing a programmer, what steps to take?

Question

One of the programmers on our team is leaving for greener pastures. We will be going from 6 to 5. What steps should we take to ensure our development process continues to run smoothly, potentially while integrating in new blood.

We are currently working on a short release cycle with iterative development. Design - code - review. The person leaving was the most senior dev on the team, and would often give lots of feedback to the rest of the team, especially during the design phase.

Answer 1

You can find another senior developer who is generous with feedback to his coworkers. Good luck.

Answer 2

There are few things you can do (in that order):

• Reevaluate your estimates, based on the experience of the remaining team members and the work items load balance
• Come up with a prioritized list of things you might have to cut
• Seek a suitable replacement (as aggressive as possible)
• Start a discussion with your company management on potential compensation package changes that would allow you to retain valuable human assets like the leaving guy

Update: Use this as an opportunity to build up your team. Throw a goodbye party for the guy that's leaving and make sure both he and the team are aware that his contributions were valued. :-) (And if you don't have a budget, just talk to the team members and you all chip in to get him out for a drink or two)

Answer 3

I agree with Franci, with a modest modification to priorities:

Start a discussion with your company management...

Yes. By all means. Today. If your best is leaving, your second best probably isn't far behind. Talk with the remaining developers. Are they happy? Are you sure? Are they just talking nice to you out of respect for your authority but have mysterious "doctor's appointments" that crop up? If you were a member of the team, would you be looking?

Answer 4

Pair-programming is a useful technique for mitigating the problems created by the departure of a skilled employee because it spreads knowledge. It's also useful for mentoring new employees.

Answer 5

Avoid specialization in the first place. If you have more than 0 days for transition, it's a luxury. People get sick, die, run away, get arrested, get fired, etc., every day. So continuity of the project needs to assume that sooner or later, someone will unexpectedly stop coming to work. I know of a case where a guy was arrested at his desk, lead away in handcuffs, and his PC was immediately taken to a lab for forensic investigation. Not much time for knowledge transfer there.

Code reviews, design reviews, and problem ticket/research rotation will familarize the entire team with all aspects of the system.