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 if
- they get feedback that helps them to learn more, if they receive recognition for
- their expertise and suport, and
- 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:
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
