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?

  • 1
    Truck Number! huh, I'm sure it use to be called Bus Number. I guess its the same principle...
    – Darknight
    Jan 5, 2011 at 11:04
  • 11
    change passwords Jan 5, 2011 at 11:28
  • 6
    @kirk.burleson: Did you follow the link? If not, why not? If so, what specific question do you have?
    – S.Lott
    Jan 5, 2011 at 12:14
  • 4
    Having just left a long term position (5 years) on Dec31, my previous employer did just about the opposite of all the advice here. The primary focus my boss wanted me to complete was a deliverable with no "brain dump" nor documentation.
    – Tangurena
    Jan 5, 2011 at 14:16
  • 1

6 Answers 6


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.

  • 7
    +1, every line he writes is a line that someone else will have to deal with. It's far better to just have him spend the remaining time bringing everyone else up to speed. Ideally, the last week is spent just answering questions that people might have as they complete the transition.
    – Tim Post
    Jan 5, 2011 at 9:25
  • 2
    Also, diagramming can sometimes be more useful than written docs, either way, I agree with Tim, coaching others directly is often more useful.
    – ocodo
    Jan 5, 2011 at 12:40
  • Having been the key developer leaving, this is the course of action I took. I had to make sure the team I was leaving was going to be capable of delivering the product. My last two weeks were very busy but in the end it really helped. Jan 5, 2011 at 13:31
  • 1
    I'm not sure if "stop coding completely" is an absolute must... in some cases, it's preferable that something is completed instead of left in a half-done state where it is very hard for the next developer to continue
    – user281377
    Jan 5, 2011 at 14:25
  • 2
    If I knew I was going to die in a week, i certainly wouldn't spend that time writing up documentation!
    – TGnat
    Aug 10, 2012 at 13:43

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...


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.

  • 7
    I'm not happy with your annotation to #2, because other responsibilities (e.g. family) can make it necessary to go home at a fixed time for quite a lot of people, whether or not they are to blame for the broken built. The only one who must stay within the company is the build itself, obviously, so I don't argue against testing (no sane person would), just against the ramifications.
    – user281377
    Jan 5, 2011 at 12:59
  • 3
    A broken build is a bad thing, but it can be fixed tomorrow.
    – user281377
    Jan 5, 2011 at 21:21
  • 1
    @ammoQ: While it's true in some sense -- everything can be done tomorrow -- it sets a dreadful precedent of slipping schedules and missing deliverables. All it takes is a tiny bit of care and planning to be sure that the build is not broken and does not have to be left broken. Leaving a broken build for 1 day can easily become 2 days which can devolve into "it never works correctly, but we ship it anyway." Better to demand planning that allow sloppiness.
    – S.Lott
    Jan 5, 2011 at 21:42
  • 1
    Anyway, a "nobody goes home" policy is hard to accept for anyone who actually has a life.
    – user281377
    Jan 5, 2011 at 22:38
  • 2
    "No one goes home if the build is broken" only ensures that no one ever pushes code except first thing in the morning.
    – Kyralessa
    Aug 10, 2012 at 14:01

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.

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.


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.

  • Specifically, this is a really good reason to do a lot of pair programming.
    – catfood
    Mar 10, 2014 at 14:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.