Over the last two months I’ve been working my way through a handover process as I prepared to leave the company where I’ve been working for the last eight years. This got me thinking a lot about what is a handover and how can it best be executed…
What is a handover?
The traditional view of a handover is where the employee who is leaving directly trains their replacement(s) in all the aspects of their job. However, for me this raises a number of questions and concerns:
- Why is the knowledge and experience of the leaver not already spread among multiple people in the company? Running with silos of knowledge owned by a single employee is a high risk strategy: that employee may suddenly be taken critically ill or suffer a serious accident.
- Why is much of the knowledge and experience of the leaver not already documented in diagrams, playbooks or procedures? Having details stored only in employees’ heads and in their rough form notes prevents the easy transfer and preservation of that knowledge and experience.
- What if there aren’t any direct replacements to handover to? It may have been impossible to recruit a replacement in time or the department may be restructuring and the leaver’s role may no longer exist going forward.
- What if the replacement has a different set of skills, experience and perspective on how to undertake the role? There may be better ways to do the job that the leaver hasn’t explored and just indoctrinating the replacement to do exactly what the leaver did is likely not the most effective approach to move forward with.
Clearly this traditional approach of taking someone new and just showing them how to do your job isn’t effective. So, is there a better approach and what should it be? Having gone through the process, my definition of an effective handover is now:
To ensure that knowledge and experience are preserved and communicated in such a way that they are accessible to everyone within an organisation, even those that arrive after the source of that knowledge and experience has departed.
Therefore, by definition this suggests that handover is more about producing durable materials and resources (as well as conducting direct knowledge transfer between individuals).
Types of knowledge and experience
While working through how best to communicate and preserve my knowledge and experience it became very obvious that this information was divided into two very clear categories:
- Explicit knowledge and experience - that which is clear and without vagueness or ambiguity.
- Implicit knowledge and experience - that which is understood but not described clearly or directly, and often using implication and assumption.
How these two types of knowledge and experience are identified and dealt with in a handover are very different.
Explicit knowledge and experience
Ideally in a well functioning engineering team this explicit knowledge should already be captured and widely used, so there should be a minimal need for handover in this area.
Examples of how this explicit knowledge is captured include things like:
- Having architecture diagrams and descriptions that are kept up-to-date as the system landscape changes.
- Having a record of key architectural decisions, why they were made and what alternatives were considered.
- Having documented processes where these are necessary. Examples of these include:
- Processes for onboarding new team members
- Definitions of done
- Process for releasing code to production
- Escalation processes for any production incidents
- Having Engineering Guides and Playbooks that detail things like how to configure systems, housekeeping tasks, build pipelines and so forth.
- Readme files in code repositories that detail what they do, how to build and use them, key dependencies etc.
If these are not already available then the first stage of handover work should always be to ensure that any of this explicit knowledge that the leaver is holding is captured. This likely involves a fair bit of document writing, updating knowledge bases and so forth. It’s also wise going forward to ensure mechanisms are in place within the team to ensure that this situation doesn’t occur in the future!
There is also great value to just surfacing and sharing this explicit knowledge. Some members of the team may not be aware of certain topics, others may have forgotten. There may also be team members who perhaps learn better from verbal communication and interactive sessions than from reading documents.
I found great value in being able to do interactive handover sessions, drawing on whiteboards, looking through code and so forth. This provides the team with good context on each subject which they can now use as a primer for diving into the more detailed information captured in the diagrams and documents.
An additional benefit I found when doing interactive sessions was that often a question or discussion topic would arise that I realised wasn’t already captured somewhere. This then highlighted the need to go back and improve on the store of knowledge, to ensure that assumptions or omissions became part of this explicit information set.
With hindsight there would have been great value to recording these interactive sessions and including them within the explicit knowledge set as well so that people not yet part of the team could utilise them as part of their onboarding process.
Implicit knowledge and experience
This part of the handover process is much more challenging. Most people, after working in a job for a long time, will have things that they just ‘know’ without realising that other team members may not ‘know’ the same things.
Some examples of this implicit knowledge and experience include:
- Handling a support issue and being immediately able to point to the cause of the problem.
- Seeing a particular error line in a log and being able to go to the exact module and piece of code that is the likely root cause of this issue.
- Getting a vague requirement from a customer and immediately understanding exactly what it is they are asking for, because someone asked the exact same thing in the past.
- Doing an admin task that seems so trivial that it just never occurred to write it down anywhere.
- Subconsciously following a process from the past that may not have been effectively communicated to newer team members.
The big question I focussed on as part of my handover was how to actually identify this implicit knowledge. In the end I came up with two specific techniques that I felt worked well for me:
The first approach was a forensic analysis of emails and our issue tracking system. I found great value in the ‘sent mail’ folder looking for conversations that I might have contributed ideas or opinions in. The history of tickets in the issue tracking system was also incredibly useful. In particular I focussed on tickets raised by support and internal defect tickets; those where I had collaborated but not directly owned were a particularly good source of implicit knowledge.
The second approach was much more of a meditative one. Firstly I spent time thinking over all of the tasks that I carry out on a day-to-day basis, with a focus on both periodic and adhoc items. Replaying questions from the support team was also very useful. Secondly I made a list of all the projects that I had worked on and did the same exercise, thinking over any previous admin, support work and conversations with customers.
A small number of items that came up from these approaches were clearly explicit knowledge that just wasn’t captured, so this was added to the appropriate places. The remainder were very much things that were known, but vague and rather undefined. Clearly people should be aware of and have a ‘starter’ should it become necessary to work on them. However none of these additional items were clear enough to make explicit or significant enough to require dedicated interactive handover work.
Capturing these implicit items was where Playbooks really came into their own. For each identified item I was able to create a section that considered:
- How does the item get noticed, reported or spotted?
- Are there any particular times or schedules that are appicabvle to the item?
- What are the symptoms that might point to the item? How might these manifest themselves?
- Has this item or question occurred in the past? How was it resolved then?
- What resources or information are needed to investigate or diagnose?
- Where should someone start looking?
- What are the possible answers or solutions? Have any been considered or discounted in the past?
- Are there any new processes that could be documented?
- What further information would be useful to capture so that implicit items could be converted into more explicit knowledge?
At the end of the process I was able to provide a Playbook of ‘starters’ to help future team members who encounter similar or closely related items from having to start from scratch.
Conclusions
A quality handover should include three elements: make sure all explicit knowledge and experience is captured; carry out interactive sessions to provide context and an entry point to this explicit content (ideally record them and add them to the content); and identify implicit knowledge and experience as record this as Playbook ‘starters’ that are available for team members to build on in the future.
My handover process was also a welcome reminder to make sure that explicit knowledge and experience is captured and updated continually. Don’t leave it until someone is leaving the team before you start generating diagrams, documenting processes and creating Playbooks for important activities.
