What my newborn son is teaching me about KM

Why knowledge capture and transfer practices should align with the way people share knowledge in everyday life.

My newborn son is the most adorable, precious thing I have ever seen (except for, of course, my daughter). Since every child is unique, as a parent there is always a lot to learn. Thankfully, the community of parents with relevant experience to share is large. It is probably also one of the most vibrant communities of practice in the world, with almost every member more than willing to share their insights and experiences. No lurkers here!

Where there is no shortage of opinions, there usually also is no shortage of different opinions. How to stop a baby from crying? Pick him up!... No way, put him down! Should you wake the baby for a feeding after a while if he is sleeping? Definitely!... No, let him sleep, and try to get some rest when you can!

Clearly, what works for one does not for another. This can make for some entertaining back and forth between equally experienced and well-meaning sets of parents. On the surface, it would also seem to create somewhat of a dilemma for the beneficiary of the knowledge being shared: Which advice to follow?

However, in practice, this potential dilemma typically resolves itself naturally before it even really emerges. This is because in any complex situation (anything more than "how do I get the TV screen to show the Xbox?"), people don't treat advice they receive as a recipe, but rather as an input that is to be interpreted and adapted through the lens of their own specific challenge, context, and perspective to create a new, unique output. Any potentially conflicting advice is contextualized and made sense of seamlessly: A "third way" emerges, their own solution that incorporates elements deemed relevant from what was suggested by others and discards the rest. Who was "right" or "wrong" is irrelevant, what matters is what I can use to make part of "what works for me", no matter its source(s).

This process of input adaptation is part of the natural flow of knowledge sharing between people, whether it is at home talking about newborns, or at the office talking about large scale projects, costly product development cycles, or challenging service delivery engagements. "Tell me about your experience, give me some recommendations, but at the end of the day, I know my "baby" best and will make my own decision."

Said differently, the value of experience-based recommendations (knowledge sharing) does NOT lie in telling people what to do, but in enabling them to see their situation or challenge in a new light --to think differently about what they are about to do. This in turn will help them make better decisions, come up with better solutions, and achieve better outcomes than they would have without the benefit of the shared knowledge.

However, KM practices supporting knowledge transfer across organizations haven't in all cases been aligned accordingly in terms of their methods and deliverables.

Imagine a KMer tasked with supporting the capture and transfer of critical knowledge from and to a group of 10, 20, or even a 100 or more projects. The KMer goes to work: A significant number of knowledge capture interviews, After Action Reviews, and facilitated community discussions later, the KMer's efforts will have yielded a tremendous amount of valuable content, including a large number of perspectives and approaches on how to solve challenges across all of these projects, some unique and some similar.

Now, what to do with these multiple insights on "what works" to make them useful and transferable to others?

One possible approach would be to analyze the collected content to find common themes. This approach takes knowledge from the specific to the generalized: What can I say that would be true not just about one of these projects, but for all or most of them? What are the effective practices or common pitfalls shared among them?

While this method can produce results that are interesting to some audiences, in the realm of peer-to-peer knowledge sharing its value will likely remain minimal. Why? This approach is likely to result mostly in high level conclusions that to front line practitioners may appear to be "vanilla" at best. They may very well be true, but at the same time do very little to capture their imagination or actually help them make positive changes in their jobs: "Communicating early and often is critical"... "Careful planning leads to better execution"... "Extensive turnover in team membership can hurt project results"... If you've read one of these lessons learned reports, you have read them all.

When "lessons learned" reports have limited or no impact in terms of helping practitioners improve performance, they are fundamentally failing to meet what was the objective of the knowledge sharing exercise in the first place. One of the principle causes will have been that the final, generalized format in which the knowledge is presented to those who might reuse it does not align with the natural way they like to receive and adapt knowledge for their own purposes.

For knowledge captured from multiple experiences to be actionable to others, it can't be taken from the specific to the generalized. As everyday life show us, it must instead be taken from the specific to the contextualized. Rather than be analyzed "upward" to find common denominators, each of the many captured experiences should be explored "downward", to understand the unique actions and circumstances that lie beneath it, drive it. It is not about trying to describe what works every time --reality is just too complex for that--, but about defining what works when for each individually shared experience. This is what will then allow others to effectively make sense of them and adapt them for reuse within their own situation.

In order to produce documented knowledge that can meet this standard, knowledge capture practitioners need to look beyond documenting a simple description of "what works" and focus on gathering details on how, with whom, when, where, and why something worked. If you want to understand why and how something works, you will need to identify the key drivers and critical context of the suggested practice. Everything else is irrelevant.

Critical drivers of a solution are those actions that need to be taken to make it work. Critical context refers to the conditions that need to exist for the drivers --and thus the solution-- to "make sense", to be the best fit to solve a specific challenge. If these conditions do not match or relate well to your situation, you may be better off trying a different solution.

Everything else being irrelevant may sound a bit harsh, but basically refers to contextual elements that may be true --or other actions that may have been taken-- without having a direct impact on the effectiveness of the drivers that make the solution work. Therefore, for purposes of presenting the experiences for reuse by others, they should be left out, or at least clearly be secondary.

It is important to remember that what is irrelevant in one experience (for example: the rank of the person taking an action) may be part of the critical context or a key driver in the next, and vice versa. It is the job of the knowledge capture professional to explore each experience and each recommendation to identify and correctly classify each of these elements.

This way, each individual solution becomes a story, unique in content but consistent in structure and format. The many stories will combine to paint a complete picture reflective of the complex situations and experiences they represent.

Knowledge seekers should then be able to quickly and easily explore the stories most relevant to them to help them think differently about their challenge and define their own path forward.

For this to work well, the presentation of these stories themselves should be as close as possible to the natural way we like to share and receive knowledge --in conversation. Short written paragraphs that avoid too much technical jargon can work, videos or audio could be better. No form of documentation will match the effectiveness of in person peer-to-peer exchanges, as I described here, but when organizational realities call for knowledge to be documented, KMers should seek the format that most closely approximates the real thing.

If the collection of collected stories is becoming too large to be explored effectively by its users, consider using taxonomy and online tools to effectively categorize and display the knowledge and enable quick and easy discovery by users through navigation and search.

First and foremost, though, ensure your knowledge capture and transfer methods recognize that what needs capturing is the type of content that fits with the way people exchange knowledge naturally. That requires contextualization, not generalization. This is true whether you are talking about the most complex professional challenges or about raising the cutest baby boy (and girl!) ever.

Want to read more? You can check out some of my other posts here:

1. Knowledge Capture: SMEs only?

2. KM and OD: Organizational BFFs?

3. Knowledge: to document or not to document?

4. The 7 Essential Qualities for KMers

5. The Final Four Essential Qualities for KMers

6. Why Sitting at the Kids' Table is Killing KM

7. Change the conversation: Seven steps to get operational buy-in for KM

8. The 1st mistake KM programs make

9. What my newborn son is teaching me about KM