How much information can possible be transfered when and employee is about to leave.

A member of my team, as of a month ago, had a new project put on him. He received a brain dump from the original 2 developers. I was spun up on this project as of 2 weeks ago. My team remember has announced his resignation and will be leaving in 2 weeks. How much of the originally knowledge will I be able to obtain? Any sources would be appreciated.

  • This question may actually be better suited to Project Management SE. – IDrinkandIKnowThings Feb 23 '15 at 15:04
  • 1
    I'm voting to close this question as off-topic because it is not about navigating the workplace but about project management. – IDrinkandIKnowThings Feb 23 '15 at 15:05
  • I don't think this is particularly project management related, but I do think that there are a wide variety of possible answers to this based on different circumstances. – Telastyn Feb 23 '15 at 15:20
  • I'm voting to close this question as off-topic because how much someone can expect to remember is mot about navigating the workplace. – jmoreno Feb 23 '15 at 15:45

No one can tell you what you can learn. That's far more conditioned by your learning style and background than by the circumstances.

Learning by doing is far more effective than learning by listening. So, the best thing you can do is to get the new people to try to do some work on the thing while the old person is still there to answer their questions.

The second best thing you can do is to take notes and video of any 'dumping' so that you can go back over it later.

Of course, in retrospect, the firm should have made spent the time to have enough internal documentation to avoid this issue in the first place.


So you are trying to get a brain dump from someone who a month ago got a brain dump from the actual team?

I have led teams taking over a number of projects/systems over the years. From experience I would suggest that the person in the middle will have only retained things that they have had to directly deal with (so say any production issues, changes/new work undertaken etc). For anything else I would say if it wasn't documented by the original developers it's best to count it as lost knowledge.

I would get the middle person to start outlining and documenting everything they can, and look for any big gaps as soon as you can before they leave.

  • I would also find out from the manager if they'd be willing to get one of the original team members in for a day or 2 as a "consultant" to help bring you up to speed. – Voxwoman Feb 23 '15 at 13:05
  • @Voxwoman - I'm working on the basis that the original developers are long gone, if they are still in the company, you'd just get them to redo the original handover (ideally to more than just the OP in case user2097159 leaves/gets hit by a bus as well). – The Wandering Dev Manager Feb 23 '15 at 13:12
  • I get that. Sometimes, however, if the former employees left on good terms (and not too long ago), they may be amenable to helping out their replacements - for a fee, of course. – Voxwoman Feb 23 '15 at 13:15
  • Absolutely, but I my thought would be if that was the case it wouldn't be necessary to ask a question on stackexchange... – The Wandering Dev Manager Feb 23 '15 at 13:18
  • @TheWanderingDevManager The original developers are well gone. – user2097159 Feb 23 '15 at 13:56

This is one reason why complete and current documentation on every aspect of a project is important. If the documentation process becomes part of the project life-cycle instead of another chore, the amount of information lost in a transition like this is minimized. Many companies see this documentation as a time sink that costs money and team members see it as an extra task that often times will never be looked at. For this reason documentation of a project is often minimized to that which is required to complete the project. But this is a mistake.

The act of documenting provides time to think and catch failures before the work has been put in and costs more to fix. And with good documentation it is much easier to bring in a new team member to augment or replace existing staff. Any time someone leaves there is a loss of knowledge about the project. But the better the project was documented the less of this knowledge is completely lost, and the more of it is able to be communicated easily and more likely it is to be retained by the new staff.


Have done this several times (both handing-off and receiving), I can say that doing this smoothly requires some amount of planning and as well as tact.

As ReallyTired indicated, fully documented process and systems are vital, but that is something that must be done all the time throughout the life of the projects. Rushing it in the 2 week departure is a waste of time and too little too late. Moreover, the 2 weeks left is far better spent interacting with the person leaving rather than having them write documents in their cube non-stop.

I have found a few things to be effective:

  • Assign somebody to "shadow" the person leaving. Have them coach their basic day-to-day tasks to a capable and motivated person who will ask good questions and not be reluctant to practice even the most simple stuff just to get a feel for it.

  • If the job requires some relatively simple repetitive tasks, have the person who is leaving capture those tasks in screencasts. A narrated screencast can communicate a lot more nuance for the effort than a word doc for basic operational stuff.

  • Recognize that not everything is going to get transferred. Unless the departure and transfer is planned ahead for months, it just isn't possible. You have to triage. Focus on a small number of key skills to transfer really well rather than pushing to cover as much as humanly possible.

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