How do you go about training a replacement? [closed]

Question

I recently asked about leaving a position and got a lot of great answers. One of the common threads was that being around to train the new person would be expected and could go a long way.

Now considering that (I think) most people don't stay at a company for a long time after they've given notice, and it will take time for the company to interview/hire one - that leaves for a short amount of time to get someone up to speed.

I've also never trained anyone before. I did a bunch of tutoring in University and College, but teaching a language/technology is far different from training someone to replace you on your job.

So the question is: how do you go about training someone to replace you in a, potentially, short amount of time?

Answer 1

Simply speaking it is impossible to fully train a new person. The knowledge of 2-3 years can not be passed to new person in 1-2 weeks. It is the responsibility of the new person to take interest and learn by himself most of the things.
According to me you should distribute the time like this :-
Sharing the documents and explaining them - 30%
This will include explaining the high level, low level designs and classes etc.

Sharing the code and explaining it - 70%
This means going through the important part of the code.

In between you will have to give time to the new person, to learn the things and come up with the doubts. Your main aim should be to make the person independent, that he/she should understand what part of the code does what. You can not explain each and everything, and even if you explain it won't be much useful. The new person will have a limited capacity to understand the new system. So don't bombard with lot of things. Just explain important things.

Answer 2

Point them at the wiki

You do have one, don't you? And I'm sure you have a few team members who act as code librarians during the code reviews so that common code can be introduced (either into the company code library or to replace the custom code that the developer has just knocked together).

No? Ah. Well, you've got a problem then.

Depending on how much time you've got, you'll need to follow one of these plans, in order of the level of crisis:

1. Aargh! I'm leaving this afternoon

If the new guy is highly experienced in your problem domain, then just point him at the wiki and show him how to get to the relevant code in your SCM. Buy him a beer, offer your phone number if you're feeling generous and toddle off to your leaving party.

If he's not so experienced, introduce him to other members of the team who should be his primary points of contact to get an idea of how it all fits together. That's about all you've got time for.

2. Got all week, but there's a lot of tidying up

Get your replacement to shadow you for the first day so you can assess their skills and try to get them doing your job as quickly as possible. Let them see how you tackle a problem, and then gradually hand over so that they are solving it and you are acting as a consultant. Build out from the core operations you do every day to the less frequent ones. Make up problems if you can. Pair program if you're able to. Get them to keep track of what you've told them in a wiki or some other networked text-based resource so they can refer to it later, and eventually turn it into proper documentation.

3. It's the junior developer who's taking over

They'll already have the domain knowledge and know how the team works. Start allocating them your tasks and working to build their knowledge about unfamiliar systems and processes. Concentrate on helping them get the basics down pat, with the more advanced stuff coming later as you get time.

Provide basic telephone support

Assuming that you're leaving on good terms with the company, offer to provide them with some telephone support so they know that you're not leaving them in the lurch. If they start ringing at every hour asking bone-headed questions that could be found on the wiki then mention your competitive consultancy rates. Otherwise, the odd call here and there allows them to pick your brains and you to stay in touch with them, which could be handy when the next round of jobs comes up.

Answer 3

Stop coding immediately. Let the new guy do your day-to-day job and be there to answer his questions.

There is no better way to learn than doing.

Answer 4

Depending on the complexity of what you are doing training someone after you give notice can be a lost cause, and even without complexity there are an increasing number of places that just walk you out as soon as you give notice (make sure you have what is yours before giving notice), so it is often better to train your replacement(s) before you give notice. A made-up upcoming vacation or surgery is a good excuse if you need it, but assuming you are working in a team you should be able to work that sort of stuff in a bit as you go and pass it off as keeping them in the loop.

If you have already pulled the trigger and have a final date then making them aware of where to look for various things is probably the #1 thing that will help them get working. When you are showing them the projects and what does what you need to make certain they have some idea of the workflow through the systems and where in the larger projects the important bits are. You wont have time to give them much detail, but you can probably get them to a point that they know what code to pull up when they need to start sorting through a problem.

Answer 5

You tend to quickly finish what you're doing or at least get it to some stopping point. Then the documentation/brain dump starts. I've been at places where the new hire wasn't familiar with some of the technology (Had to maintain an ASP site.). Had about enough time to explain where all the code was and how to update the site (Finding the production server itself was not hard because it sat under my desk; if that gives a little indication why I left.).

Answer 6

Assuming your company doenst hire an absolute dud as your replacement then one of the key things is the domain of the applications that are being handed over. It might be a big assumption to make but you can't teach someone how to code good in a couple of weeks - they either have that down or don't, so the key thing is the domain imo.