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.
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.).
