Monday, 29 April 2013

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:
  1. 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).
       
  2. 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.
      
  3. 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:
  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.).

1 comment:

kmonadollaraday said...

Johannes - I'm only going to agree with you 75% here :-)
Any knowledge product is only as snapshot as it is done at a fixed time and doesn't capture everything, especially not the tacit knowledge hidden behind the product - end of assignment reports and exit interviews are not different in this regard.
I think common mistakes often made in developing systems for handover notes, exit interviews etc. are i) the belief you can "download" someone's knowledge ii) a focus is preserving history for posterity so the more you collect the better (and the idea that you don't know what it will be used for but you are sure it will come in handy later).

For me there is some benefit in these end of assignment exercises if we have realistic expectations about what can be done with them, and we support them properly. DPKO for example has a fairly robust system for these - but recording and passing on knowledge this way is also part of their organizational culture.
My own thoughts on this:
1. Everyone should leave decent handover notes to their successor or bosses on leaving. The aim of this is quite tactical - simply to be able to pass over the key facts, contacts, reference material and tips that make taking over the work from someone else easier. It doesn't mean getting down all the insights and nuances, just making sure the most important stuff is documented. This seems obvious but we generally do a poor job at this in the UN because for most organizations its not mandatory and we don't have standards for how to do it.
2. There is a role for some kind of more strategic end of assignment reporting that tries to capture key lessons that could both inform the successor and also feed back into organizational policy or help people in similar posting elsewhere. In DPKO, senior officials (heads of missions , senior staff or people in a critical assignment) complete end of assignment reports which are used to help improve mission management. They don't try to capture everything, just the key policy recommendations. This works because the system is mandatory and has management support, but is also selective in what it collects. There is also a commitment to review the reports and consider their implication on policy.
I think you are right to say that if there isn't a focus on who will use the report and why and some sort of organizational commitment to make use of the material collected then you might be wasting your time.
I agree with all your other suggestions in terms of making knowledge transfer an ongoing activity through blogging and peer-exchange rather than something you do right at the end. In fact I'd suggest that if you are going to do a handover note of some sort you should start collecting material for it when you start your assignment, not just when you end it. I'd also add that instead of having a single handover note and a brief meeting when people change jobs, it would be good if we were more willing to be "on call" to help our successors, and that our successors would be more willing to ask us why we did what we did (even if they decide to take a different path).

Incidentally we tried unsuccessfully to create a system for end of assignment reports in UNICEF. The effort failed probably because of some of the issues above http://kmonadollaraday.wordpress.com/2011/10/17/km-triple-fail-no-faire/
The RC issues group is now looking at creating a similar system for departing RCs - I'm hoping that the right lessons from the success of DPKO and the failure in UNICEF will be learned - I hope someone wrote them down :-)