The only way to do a handover

Over the years I’ve seen a few people quit their job, and typically as soon as they hand in their notice, panic sets in as the person’s replacement is identified and a handover is done.

And how is a handover done? Essentially by pair programming. It doesn’t matter whether it’s a role that involves writing code or whether it’s a role that involves handling clients, or even making coffee. The handover is done by having two people sit at one desk for a period of time.

I say typically, because of course there are times when it’s handled differently.

I’m sure that when I leave my current role (or any role for that matter), there will be an element of handover that needs to be done – me explaining to people as many of those unwritten things that I can think of, in the fear (their fear, not mine) that after I’ve gone, things will fall apart because they can’t get at the information that I store in my head.

Luckily, I often can’t get at the information in my head either.

Don’t chuckle, I’m serious. And if you’re serious about your work, you’ll know that you can’t get at all the information in your head when you need it either. Otherwise you wouldn’t make project plans, or to-do lists, or write anything down. It would all just be there, able to be accessed whenever you needed it.

But the answer isn’t just to write everything down. Nor is it to store it in a database. :) I think the answer is to write handover documents for everything you do as you do it. I don’t mean documenting every line of code, or every decision you make. That can be useful, but it doesn’t actually help when someone tries to do your job for a while. What you need is something which describes all those things that you do. Like an expert system. The “I’ve found a problem with this… where do I start looking?” kind of documentation. All that information you have (yes, in your head) that makes you the best person to do your job.

I know that skills can’t be written into a document. I’m not talking about skills. And in fact, you should be able to assume that the person who’s reading your documentation is skilled at what they do. So you probably wouldn’t need to explain why a particular control was used somewhere, but you do need to make notes of any quirks that you have come across with that control before. Not something that might get put into official project documentation (although it should), but definitely something that your successor would need to know.

So in my opinion (and of course your mileage may vary), the ONLY way to do a handover is to just give your successor a pile of handover documents and then wait for the questions. Every time there’s a question, your handover documents aren’t complete. You amend the document so that the answer to that question is in there, and the handover continues. As soon as you need to sit at the same desk, you have a problem. You’re passing on information that is in your head – using a medium (speech) which does not record easily.

Obviously this documentation needs to be kept up-to-date. Yes, I know this is a nightmare for all kinds of reasons, but if your documentation is suitable for a handover, then you need to be able to find it easily and make sure that anything that anyone may need to know to do your job is written in there. If you tweak something, write down why you tweaked it, so that someone else doesn’t untweak it. Or so that they can tweak it in a similar way another time. 

When I left my previous job, my successor didn’t remain at the company long after I left. So anything that I had told him didn’t remain either. The only thing that was left was stuff that had been written down. The company survived, and continues still today, but clearly the handover could’ve been done differently.

So why not practise your handover? If nothing else, you’ll be able to go on holiday without getting a phone-call. But hopefully when your boss realises that you are replaceable, they’ll sack you. I mean, promote you. Give you new responsibility without worrying that you’ll keep getting called back to do your old job. If you’re not replaceable, you’re not promotable. Of course, you might not get it right first time. You may find that you do a handover and that your documentation isn’t up to scratch, to the point that you get questions and need to amend those documents. Once those documents are done though, and you find that the people under you can cope just fine without you, then you can afford to get hit by that bus, or go on a holiday, without feeling like anyone needs to call you. And perhaps when you come back, areas of higher responsibility may have fallen your way.

5 thoughts on “The only way to do a handover”

  1. The same applies for promotion and not just with handover. If you share information with colleagues freely (as I know you do) then not only is handover a much simpler and smaller task, but your value as a knowledgable and capable employee is obvious at all times. Coupled with the documentation of howtos or knowledgebases identifying small but useful aspects of daily work this makes you an easy target for promotion. Conversely, the guy who hides all ‘the secrets’ is seen as such and because nobody understands what he does and nobody else can do his job, he’s kept exactly where he is. Often these people are actually incompetent, one of the ‘qualities’ they are trying to hide.

  2. I agree with what you say in general, but I feel that really does not solve the problem fully. Even though you document what you do, the chances are high that you miss the tiny little points that you consider are not important, obvious or already known by the new guy. These are the exact points that you would miss during a verbal handover or a typical semi-documented handover.
    So, in my opinion, it has to be a combination of all those that would be used. All or most (depending the situation) of the hand-over methods such as documentation, peer working, verbal, emails, casual chats, sharing all the info available, introducing to all possible contact points etc. have to be done.
    I personally had the same experience that you have had. When I left the previous employer, they allocated a new person quickly, but the new person left after few months! Due to the panic, they could not find the best match for the role, but sent the available one directly to the deep-end, obviously the pressure and the ask would have been too much. So, this proves that apart from all the above mentioned methods, it is important to find the best match for the role even though there can be practical situations which are truly difficult.

  3. But that’s why you should practise. And anything that you find needs to be communicated outside the documentation should then be added to the documentation so that everything is known.

    Wikis can help here too, of course.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>