Imparting knowledge through storytelling, Part 1 of a two-part article
This is the first of a two-part series in which author Tom Reamy discusses the need for organizations to create a "knowledge architecture" that captures the knowledge transmitted through storytelling.
By Tom Reamy
There has been an ongoing interest in storytelling as a component in knowledge management over the last few years, but it has never really become a major focus. Storytelling has been touted as the best way to make the leap from information to knowledge, and as the best way to capture and transfer tacit knowledge.
However, the idea causes some real disquiet among practical businesspeople, information specialists and even many in knowledge management. The image of a group of businesspeople squatting around a campfire swapping stories is scary on a number of levels: Ripped and dirty suits and dresses, setting off fire alarms, poking people with sticks, and finally, huge amounts of wasted time as really bad storytelling executives unload their fears and anxieties.
In addition to this type of comedic disquiet, there is another problem with the use of stories in knowledge management, which is, the knowledge embedded in stories is difficult to codify in such a way as to capture the richness and multiplicity of stories without losing the immediacy and power of the storytelling experience.
There also seems to be a huge disjunction between theory and practice when it comes to storytelling in a corporate environment. On the one hand, the use of stories is flourishing. It is practical and direct. However, the theory of the use of stories in corporations seems to be languishing between a deep academic theory that is unanchored in the practical reality of business and a strategic view of KM that looks askance at any attempt to capture and/or codify the living, breathing reality of actual storytelling in day-to-day business. The net result is that storytelling is divorced from any systematic foundation that would give it both a dimension of rigor and practicality.
I would like to suggest that one answer to both the fears of semi-mystical storytelling rituals taking over the board room and the difficulty of truly capturing and representing the deep knowledge within stories is to create a rich and powerful knowledge architecture. This knowledge architecture must be organizationally powerful enough to overcome the flaky image of storytelling circles and, at the same time, rich and flexible enough to represent the multidimensional nature of stories, allowing the knowledge in stories to be captured and indexed and made reusable across multiple contexts,
This article will look at the issues and some approaches to creating such a knowledge architecture for stories. We will start with looking at why knowledge management should incorporate storytelling and how stories are being used in corporations. We will then look at what knowledge architecture is and how it can be applied to storytelling, what benefits can be expected and how to create meta-stories. Finally, we will look at some possible future directions that a good knowledge architecture can enable.
Why should KM incorporate storytelling?
Humans have been telling stories as not only a form of entertainment, but as a way to make sense of the world for a very long time--probably almost as long as they have had language. So it is not a surprise that we continue to use this powerful medium in the corporate environment. What is a surprise is how little we have incorporated storytelling into knowledge management, although with the efforts of such projects as the IBM (ibm.com) Story Project and the new work at IBM’s Cynefin Centre for Organisational Complexity under David Snowden, that is changing somewhat.
We know that storytelling is going on throughout the enterprise. But what is it about stories that we don’t need to launch a program to get people to tell stories and we can’t get them to stop telling stories even if we wanted to
Stories are a fundamental form of knowledge
First, stories are a fundamental means that humans use to structure the world. Our brains seem to be wired to easily and almost automatically organize information into stories. Listen to small children play and you hear the most wonderful stories being created, all without the benefit of major skills acquisition programs. Storytelling seems to develop along with language skills and perhaps even before a sense of causality fully develops.
However, stories are not just for entertainment or children. Stories select events on the basis of importance and fit with other events. We then combine those events into an ordered and at least partially causal chain to explain and/or give meaning to the world around us and ourselves and our place in that world.
Stories also support chunking of facts and events in ways that correspond to how our brains are designed both for paying attention and for remembering.
Since storytelling represents a significant form of knowledge, knowledge management needs to come to grips with the nature of storytelling and how storytelling is being used within the enterprise.
Storytelling is used throughout all businesses
A second reason that knowledge management needs to deal with storytelling is that there is one certainty when it comes to business, whether you like it or not: Storytelling is going on in every business, every department, every team. Storytelling is not only natural, it is being used right now throughout your enterprise and it is being used heavily, probably more heavily than any other information or knowledge sharing channel you have.
If we don’t understand the activity and nature of storytelling and if we don’t understand what stories are being told in our enterprise, then we run the risk of creating a corporate environment that not only doesn’t support knowledge transmission through stories, but could stifle or distort the use of stories in our environment.
True, people will tell stories given any chance at all, but the question is, what kind of stories will they tell? Will those stories get to the right people? Will those stories be used in ways that improve your culture or create an undercurrent of negativity? Will those stories teach new employees what they need to know or mire them down in the practices of the past?
Stories are particularly suited to knowledge management instead of information management. While there are numerous variations in story type and use, they do share some common characteristics. One of the most important characteristic is that stories exist in the realm of knowledge, not information.
First, stories convey not information, but meaning and knowledge. The information they contain is seamlessly incorporated into the story through the use of context. And since stories create clusters or chunks of information, they are easier to pay attention to and to remember. It may be harder to codify knowledge than information, but it is easier for humans to remember knowledge rather than strings of unrelated bits of information.
Second, stories are particularly good at transmitting tacit knowledge. Indeed, given the difficulty in capturing and making explicit the tacit knowledge residing in your internal experts, stories seem to be the one way that we not only can, but easily do, capture and transmit tacit knowledge.
Third, listeners react to stories differently (and better) than to charts and logical arguments. Stories provide their own context which makes them more believable. In addition, people tend to hear stories in a more receptive mode, according to some research. It has been suggested that the cognitive processes underlying story hearing are different. Stories are told within their own context, but the interaction between teller and listener is not one of transmission of information, but rather, the story becomes the means through which listeners create their own context, interpreting and filling in blanks and links of the story.
KM can improve and be improved by storytelling
Knowledge management offers a number of advantages for storytelling. First, it places storytelling within the context of knowledge management, thereby providing a framework of legitimacy. Second, research into the rich store of corporate stories can lead to better story schemas than many found in the current research. Adding the corporate context with its practical orientation can focus the organization of story elements in ways that often seem lacking in the academic literature.
Lastly, knowledge management can be improved by incorporating stories that are great examples of knowledge and the transfer of knowledge. Currently, there is a lot of information management in knowledge management, and a focus on the embodied knowledge within stories is a good way to enrich the architectures in knowledge management to include elements that go way beyond simple reference library systems.
What is knowledge architecture?
Before we look at what a knowledge architecture needs to be to come to grips with something as hard to codify as stories, I should say a little bit about what knowledge architecture is. (For a more complete discussion of knowledge architecture see my article, "From Information Architecture to Knowledge Architecture" in Intranet Professional, September/October 2001.)
The simple answer is that knowledge is information plus various kinds of contexts and so knowledge architecture starts with information architecture (organization, navigating, labeling and retrieval of information) and adds different types of intellectual, personal and social contexts.
A context is something that gives meaning and depth to information. Rather than try to define context further, let me tell you a story. Recently, I was at a doctor’s office and the doctor came out and told a young woman that since she had changed her appointment from the following day to today that he wasn’t able to get her charts. He repeated that information and waited for a reaction from the young woman who, since she didn’t have the context that would give meaning to that piece of information, remained silent. She didn’t know if the doctor’s information meant the doctor wouldn’t see her, if the appointment could be held but wouldn’t be as productive, or if she needed to do something. The doctor knew the context, which was twofold: Not having a chart meant that the doctor would be less effective and that he would have to work harder to elicit information from her.
The doctor transmitted the necessary information but not the necessary knowledge, and the result was a complete lack of understanding. I can only hope that the doctor was better at communicating context in the actual interview. Perhaps if the doctor had a button that she could click on (Explain, or More Info, or What Does That Mean?), the woman would have understood. In other words, if there had only been a knowledge architecture supporting the interaction.
Knowledge architecture then is the attempt to create an intellectual infrastructure that can support the organization and retrieval of not just information but sets of related contexts around information--contexts that change over time and with different dimensions of applications. Knowledge architecture deals with a richer, more multidimensional intellectual universe of discourse and through that richer universe, must deal with the shifting chaotic world of applied information, i.e., contexts of actions.
Knowledge architecture for stories
In the case of stories then, knowledge architecture has two primary tasks. One is to create the intellectual infrastructure for deconstructing, capturing, indexing, organizing and retrieving stories and elements of stories in a variety of applications and in a variety of communities within the enterprise.
We will look at some of the specifics of how to create that infrastructure in a later section, but in order to create the infrastructure reasonably well we need to understand how stories are being used in a corporate environment. And the answer is, of course, in a wide variety of ways.
One of the most basic ways that stories are used is in informal education and training. Stories are typically used to present the finer points of an area. They are not particularly good at transmitting the details and low level procedures that new employees need to learn, but once that basic context is learned, stories provide guidance and lessons in the advanced or more sophisticated application of those basics.
In other words, standard training tends to impart information, while the training embedded in stories tends to impart knowledge. For example, knowing which resources a call support person should use in answering simple questions is part of basic training, while knowing when to not look in those resources, but instead ask the real expert who sits in the other room, is the kind of knowledge that is often taught by a story.
Second, stories are the foundation for many formal and informal communities that form within an enterprise. The act of sharing stories creates the knowledge flow that makes a community alive and valuable. And the store of stories that are created become the foundation or context within which and from which, the community looks at the world.
Stories represent and/or contain the values and informal rules by which a community is organized. These community stories create an impact immeasurably greater and richer than a corporate or departmental newsletter. They use emotion and can engage listeners, individually and communally, in ways that mission statements will never equal.
A third use of storytelling can be particularly valuable and it is what Stephen Denning of the World Bank (worldbank.org) calls springboard stories in his book of the same name. Springboard stories are stories used to create a new paradigm or to not only introduce new ideas, but get people on board and actively promote the new idea. Denning argues that one reason stories are particularly suited to getting people to accept new ideas is the different way people react to stories vs. charts and logical arguments.
There are certainly many more uses of stories in a corporate environment and, indeed, one task in the construction of a knowledge architecture for stories is exploring, identifying and categorizing all the different kinds of uses of stories.
In addition, there are a lot of different kinds of stories. There are anecdotes, myths, fables and metaphors. There are cautionary tales (horror stories), success stories, lessons learned and hero stories, puzzle or detective stories, bonding stories and attack stories or propaganda. You can find examples of all of them in a corporate environment, so if you are going to try to create a knowledge architecture for stories, it will need to be flexible and rich.
However, a good knowledge architecture should also create a powerful infrastructure for supporting face-to-face storytelling. This can include rewards for tellers of good stories. Is it really too much of a stretch to imagine “a very good storyteller who functions as an important informal source of education and training within his or her department” as part of a performance review?
Another way that knowledge architecture can support all kinds of storytelling, face-to-face and virtual, is to work with education and training to develop storytelling skills and story understanding skills. In addition, capturing stories is not simply a matter of recording them. The skills of story crafting or story creation are also valuable and can be rewarded and they can also be used by a central KM group to create vivid and artistic and effective stories.
This means, not only knowledge architects categorizing and structuring the information contained in stories, but also performing such roles as knowledge facilitators or knowledge managers, and knowledge engineers. Those additional roles would be used to support face-to-face storytelling in communities and to facilitate the capture of those stories.
Should we create an architecture for capturing and retrieving stories?
Given the dynamic nature of stories and storytelling in the corporate environment, it is clear that the more traditional reference library approach of information architecture is not sufficient to do it justice. So whether we call it knowledge architecture or information architecture on steroids, it needs new and innovative thinking to come to grips with the universe of stories.
However, there are a number of authors and speakers who argue that even if we can create an architecture to support capturing and retrieving stories that we shouldn’t. They argue that the whole attempt is misguided and will kill the very thing it tries to support, that the attempt to codify stories will kill their impact, their magic, the very things that make storytelling so powerful. Captured stories become static and lifeless.
However, on the other side of the question, I offer another story. Recently I watched the movie, "The African Queen," and just as I did the first time, the second time, and who knows how many other times, I was thrilled, uplifted and damn if I didn’t get all teary-eyed one more time. Static and lifeless? I don’t think so.
It is true that once you record a story or make a movie of a story, one component of the story becomes static, but storytelling is not simply or even primarily a transmission from one person to another. One reason stories are so powerful is that they are common creations of teller and listener and the components that listeners bring to storytelling they can and will bring to reconstructed storytelling.
One final point has to do with the relationship of face-to-face and virtual stories. Some authors suggest that as you move away from face-to-face, you lose the power and impact of stories and gain nothing in return. However, that is not necessarily the case.
For example, deconstructed stories may even be easier to remember and have as great or even greater an impact. Some experiments with stories as well as earlier cognitive studies suggest that sometimes abstract qualities are more powerful, much like studies on birds that found that chicks responded more strongly to cartoon beaks than to their own mother’s beak.
Tom Reamy is chief knowledge architect for KAPS Group (kapsgroup), a group of knowledge architecture consultants), e-mail email@example.com.