May be we let them go, may be they’ve found something else and may be their time has come and they’re retiring. In any case, your organization is left with an open void that needs to be filled as soon as possible. The sooner and the better you’ll fill it with somebody else – the smaller would be the amount of time and energy swallowed by that void. In order to do that you not only have to find someone fitting for the job, but also imbue them with all the knowledge needed to start delivering. And as I’ve already written, it’s not always an easy task because some types of knowledge are harder to transfer than others.
Let’s discuss a few tips that will help you to succeed at this task anyway.
- First of all, standardize the file management inside your Team.
There are people who prefer Cloud technologies and there are people who see them as a nuisance. Among people who use them there are different preferences for the exact type of software. Some employees track their projects with a simple table in Excel and some utilize dedicated Project Management software. Someone names the working folder “Time Management Worksheets” and someone else prefers to call the same folder “TM1- a2”. Developers tend to leave personal markings inside the code that could not be understood by anyone else. I can continue, but by now I think you got the point. No matter how many types of information circle inside your organization – they should be managed uniformly! This will give you a very simple advantage if your employee had to leave abruptly without performing a formal transition to his successor. Any other employee would be able to navigate the files left in the system because they would be stored consistently by everyone. This way a new employee will not get lost in a multitude of files, folders and servers or misguided by arbitrary codenames.
- Secondly, during and after the orientation, ask your new employee if there is anything else he would like to know.
You may think you’ve included everything that’s needed in the orientation, but your new guy may think otherwise. Most system processes are generic and are not always suited to the specific ways of learning a person may prefer. There could be a need to add something which was not considered crucial as well as explaining what may have seemed obvious. This is especially true when the leaving employee worked on the project for a long time – he knows it so well that it’s hard for him to imagine a need to explain it to somebody. There is also an additional benefit to check on how the orientation is proceeding – some raised issues may be formalized as an integral part of the lore for future orientations. Ultimately, it’s in your best interest that the knowledge is transferred without loosing anything, so there is no shame in customizing your orientation to a specific employee.
- And third, orientation should include actually doing something and not just instruction.
There is a limit for how much new information a person may swallow before the brain shuts itself down to prevent overload. Even when given time to read technical documents, a person will encounter another problem – new information will just erase the previously learnt one. This happens because historically humans evolved to remember only important things, and those things usually were connected to their everyday activities. This means that when your new employee is undergoing an orientation, you should let him try everything that was shown, preferably for several times. The main benefit here is not just to give him hands-on experience with the job, but to correct possible mistakes on the spot. This is an excellent example of overcoming the barrier of “untrasferable knowledge” I talked about in my previous post – by simple instruction you may give your new employee a general understanding of what needs to be done but not how to do it properly. Only by letting him or her try something and then showing how to it better you will enable a direct knowledge transfer between the previous employee and the new one. This type of interaction has much better chances to transfer not just the technical knowledge, but some other important things such as problem-solving strategies, equipment perks, thumbrules and all kinds of functional tips.
A very important method of knowledge transfer I would also like to mention is “War stories“ – an informal mentioning of different real-life situations that happened in the workplace and of how they were overcome. The density and the volume of useful information delivered by such stories by far exceed any kind of formal instruction.
There are many other possible strategies of knowledge retention you may utilize in your organization, but no matter what you do, remember your final goal – decrease the negative impact of constantly changing human resources on your projects.