Stepping Higher - Reflections on the Knowledge Age

I was recently reviewing a number of texts which my organization collected from past projects and initiatives (some through an internal mandatory monitoring tool, others gathered as part of After Action Reviews or Lessons Learned Papers), which all meant to capture ‘lessons learned’ from specific experiences. And while these texts were not wrong per se, I realized that there seems to be a fundamental misconception what constitutes a good lesson, and what doesn’t. Here are a few typical examples of what we often collect as part of such lessons learned exercises: “Ensure that the [Team] Manager has excellent leadership, project and team management skills, understanding of programming and experience working in [the subject matter].” “Project outputs must be compatible towards project goals. Throughout the project there is a need for careful identification of project goals and outputs to ensure that they are compatible with each other. This can be only ensured through a consultativ...

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