What actions to take when people leave the team? [duplicate]

Question

Recently one of our key engineers resigned. This engineer has co-authored a major component of our application. We are not hitting Truck number yet though, but we're getting close :)

Before the guy waltzes off, we want to take actions necessary to recover from this loss as smoothly as possible and eventually 'grow' the rest of the team to competently cover the parts he authored.

More about the context: the domain the component covers and the code are no rocket science but still a lot of non-trivial stuff. Some team members can already cover a lot of this but those have a lot on their plates.

These are the actions that come to my mind:

1. Improve tests and test coverage - especially for the non-trivial stuff,
2. Update high level documents,
3. Document any 'funny stuff' the code does (we had to do some heavy duct-taping),
4. Add / update code documentation - have everything with 'public' visibility documented.

Finally the questions:

What do you think are the actions to take in this situation? What have you done in such situations? What did or did not work well for you?

Answer 1

I ask him to stop coding completely and devote his time:

• coaching others
• review his comments in code (to adapt them to the situation)
• and write a document he would have written if he knew he would leave in a week.

I try to put priority in modules he owned to make other developer work with them.

Remember after he left, it's too late to do coaching or ask him questions (in good conditions).

When he leaves, take that opportunity to ask him how he think you could improve your organization. Former employees have nothing to lose and their feedback is honest and then always valuable.

Answer 2

You seemed to have covered the key points:

• Update/create important documentation on the component/system you have been putting off.
• Note down common pitfalls, gotchas, etc that they may know but the team doesn't
• Improve tests for difficult/complex sections that are missing them.

Other things they may be helpful:

• Have someone partner with them to do a "brain dump" during the end. This is much quicker, but less precise, then documentation when you are out of time.
• Try to be on good terms with the leaving employee, you might need to hire them back for a few hours in a consulting role outside of hours (if you really get stuck).

At least, this is what I have learnt after watching my former employers lose 3 of their 4 key technical staff in my first 2 years there...

Answer 3

As a contractor for 30 years, I've left teams dozens of times.

Sometimes I get called back. Sometimes not.

The folks that had to call me back did not -- somehow -- understand that I was a contractor and was leaving. This, BTW, was generally manifest early in the project. Some organizations have low turnover -- people have worked together for years and have yellow post-it notes with critical system information posted in the cubicles and there is no written documentation that's correct.

The folks that did not call me back were, perhaps, unhappy and deleted all my code. Who knows?

However, organizations that made a habit of the following were happy.

1. Bug Tracking. This is critical. There shouldn't be "TODO:" comments in the code. These are feature requests or potential bugs that should be formally tracked. All the duct tape and band-aids must be formally and completely documented as bug fixes or future enhancements.

2. Testing. Also critical. If the build is broken, no one goes home.

3. Keeping Requirements, Design and Deployment Documentation Current. This requires active, constant reviews and walkthroughs. It requires an organization that expects and manages turnover. No one should have the same job for more than a few years. Shuffle, reshuffle, and re-reshuffle until the documentation makes this painless.

4. Tracking objectives and deliverables. If you're not actively managing the code being produced, you don't know what people are working on and you don't know what's half-finished or what's half-broken. ("FOB" Flat On Back. i.e., "OOT", On the Operating Table. Also, Undergoing Surgery. We used to say "tits up", but had to stop when some engineers objected to this. Too colorful. And they're right, it's inappropriate.)

   This will allow you to stop them from writing new code just before they leave.

The bottom-line is that you need a 360-degree view of what the team has going in (requirements) what the team has coming out (tested, documented code) and what the team has in process (new code, fixes).

If you have that view, an individual person on the team can be replaced.

Answer 4

Some more tipps in addition to what already has been said:

1. Let him write a status summary about everything he has been working on. What is definitely done, what "should" work, what is half-done, what is untouched.
2. Let him document all sideline tasks he might be (informally) responsible for; like checking the log files of a customer's server once a month. In a perfect world, all those tasks would be already documented, but in real life, something might have creeped in.
3. It's crititical to find out if this is the beginning of a mass exodus. Maybe something is going wrong in the project and others are likely to follow soon. If so, you want to counteract while possible.
4. If the engineer has direct contact to your client, let him document who his contact persons are and what their position is. Your existing records might not be accurate in that regard, and not knowing those people might lead to embarrasing situations.
5. If the engineer has VPN access to your customer's servers, make sure you know who they are; make sure his account is suspended and a new account for the replacement is created in time.

Answer 5

When I first changed position in the first company I worked for I made a spreadsheet that contained a list of all work I'd done in rows, and columns for:

• the project/product it was for
• the specific area of the project
• the business/project manager
• the complexity of the work
• who it was being handed to
• whether it was handed over, to be handed over or didn't need to be
• the date it was handed over
• the name of any documents for it (which were stored in an accompanying articles.zip)
• any comment on it

This was updated over the course of the handover (and filtered and sorted for priorities) and eventually became a legend and archive of all my work and a TODO list for any documentation/discussions that were needed, and people to make sure are happy with handovers.

I gave to my old manager so they (or anyone else) could get my work/documents without having to ask me.

I was asked for blank copies of it a lot and it became the informal de facto handover document for any handovers.

Although, when I left as a developer, I was still scheduled into coding until my last hour (and was late for my leaving do for it), so definitely agree with Pierre on stopping any new work to make sure the handover goes well.

Answer 6

Consider doing all those things on any major project in the future. It's what my company is doing after learning their lesson the hard way.

There are always at least two pairs of eyes on any code project. That way the effect of someone leaving is always limited.

And always keeping your tests/documentation up to date goes a long way too.