Exit interviews, knowledge databases and other attempts to trap sun rays in a glass jar

This month, I was asked how organizations could introduce a standard process by which all colleagues leaving their job will be requested to document their knowledge, including tools and documents they developed, in a database, so it can be accessed and researched by all colleagues for further reference.

I feel the notion of “capturing knowledge in databases” keeps coming up from time to time like a haunting ghost that you never really get rid of. It important to take it seriously, because it is often a reflection of a deeper misconception in organizations of how knowledge sharing dynamics work, and therefore what knowledge management can (and cannot) achieve.

The truth is that exit interviews and so-called “knowledge databases” are probably among the worst tools one can turn to when choosing a knowledge management approach. To me they are akin to the attempt of trapping sun rays in a glass jar. Let’s look a bit closer at the dynamics that are at play:

While exit interviews and handover notes are indeed established items in the canon of known KM tools, their track record in KM practice has been rather poor. The reason for this, I believe, is that any attempt to “record” knowledge in documents in case someone else might need it in the future, is bound to fail on two fronts:

There is no incentive for the person tasked with recording to do so. People are most motivated to share knowledge 

1. if they get feedback that helps them to learn more, if they receive recognition for their expertise and support; and 
2. if they see a direct impact of what their knowledge contributes to.

None of these incentives are present in the “end of job“ situation. Hence, the maximum we usually get out of leaving staff is a brief handover note that gives an overview over the most critical follow up items and ongoing processes along with necessary next steps, contacts, and maybe an archive folder with all important documents (and getting that is already a success)

Any knowledge captured in documents and databases is just a snapshot, and will both lack context and become increasingly irrelevant with every month that goes by. Databases work well for historical statistical records of past transactions or for policies which don’t change much over time. But for contextual knowledge on how to do things best in different situations, databases don’t work. Because first, they lack the context of the situation a particular experience was made in, and second, they are detached from the actual person making the experience (databases in their nature focus on data and records, not on the people that collect them and have the actual knowledge).

It is for the reasons above that KM in the last 12 years has moved away from attempts to record explicit knowledge in databases for potential future occasions. Instead, the goal has shifted towards fostering continuous interactions between people, as a way to enable just-in-time and in-context interactions. KM’s good track record in facilitating Communities of Practices in which individuals ask questions when they occur, and receive responses from individuals just-in-time and adapted to a given context, is a reflection of this approach. The social media wave since 2006 has taken this even a step further by putting social interactions among colleagues at the center of the knowledge sharing and capturing process. What public and corporate social media platforms (even though they are technically also a databases) are capturing are not mere data records that were uploaded just in case someone needs them, but records of people’s interactions where someone shared something because it was important at that particular time. That record is then indeed searchable and can become a knowledge archive over time. But this cannot be achieved by mandating a staff member to sit down at the end of their assignment and document all they know. Instead, this only works if the staff member engaged throughout his/her assignment in a process of sharing, exchanging and discussion knowledge with peers throughout the assignment.

The situation where knowledge capture does indeed make sense is in context of specific projects or initiatives. There are several standard KM processes to do this, two of which stand out for me:

1. After Action Review: This well-known KM method is applied at certain milestones during and at the end of a project or activity. Participants are being asked four questions: “What was supposed to happen?”, “What did actually happen?”, “Why was there a difference?” and “What can we learn from this for the next project?” It’s a rather informal and brief exercise (anything between 20 min and ½ day) that allows people involved in an activity to step back, reflect, and adjust their action for the next step

2. Knowledge Systematization: This is a more elaborate process (which can sometimes be a project in itself) in which a key project is selected that suitable to serve as a template for how to do similar projects. Through a series of facilitated workshops and reflection exercises, the end goal of this process is to produce a number products that capture the best practices, lessons, tools and template that can be derived from the project, and that can be used to inform similar projects in the future.

It is important to note that both these processes for knowledge capture focus not on a particular staff member, but rather on a specific project/initiative/activity, and the entire team involved in it. They rely on action to be taken during and at the end of a project, not at the end of an individual staff member’s assignment. However, if you have a key project that the leaving staff member was involved with, it might be a good idea to arrange for a knowledge systematization process while that staff member is still in the organization, as s/he will obviously be able to contribute a lot of insights that might otherwise be lost forever.

In addition to the two methodologies above the following action points might be a way forward for someone posing the original question raised in the beginning:

1. Rather than asking, “What do we need to extract from the departing staff member that the successor needs to know?” we can just ask “What do newly joining team members with a particular function need to know?”. We can create a briefing packages that help with onboarding new staff members, to which all team members add important pieces, standards, templates, tools, processes and resources. This could be the first piece that anyone joining a team should read.
2. We can try nurturing a blogging culture in our offices, encouraging senior as well as junior staff to formulate their current work, their thoughts on a topic or a recap of a recent event/workshop/training in the form of short and informal blog posts. A group of practitioners on a particular topic can be encouraged to “work out loud”, and in the process will create an environment of discussion, opportunities, learning and innovation.
3. Back-to-office-reports and debriefings can be done in the form of easy-to-read blog posts, rather than dry and cumbersome forms and reports.
4. We can introduce regular brown-bag lunches for learning, in which staff present an issue/project/training/process/skill they know about to their peers.
5. We can virtual spaces for peer-to-peer teams and larger communities on specific issues important to your office (and beyond). Those usually need someone to lead and facilitate them, to support the participants with resources and follow up for discussions. This is also a great opportunity to keep former staff engaged, by giving them access to these dedicated spaces beyond their assignment.
6. We can try hooking staff in our office up with staff of other offices who have similar issues. This can happen through mentoring approaches at any point in an assignment, and by cultivating staff’s participation in regional and global networks where they can get help on their questions from peers in the organization.

What’s important to keep in mind is that whatever knowledge management mechanism we try to apply, we need to be able to answer the question “what’s in it for me” for those who are supposed to use the mechanism. Policies themselves don’t work. Staff need to have a reason to participate voluntarily (seeing leaders championing an approach, receiving recognition for oneself, getting access to learning opportunities, etc.).