May 22, 2006

A Storytelling Story

Pretty much everyone interested in knowledge management knows that storytelling can be an effective knowledge-sharing technique, largely because it conveys context, causal relationships, and emotional content more effectively than most other modes of communication.

Here’s one little story about storytelling that suggests some of the benefits.

For six years, NASA Jet Propulsion Laboratory librarian Teresa Bailey has been overseeing monthly storytelling sessions at JPL’s library that often attract fifty or more listeners. Some stories have focused on fairly narrow technical or scientific issues (for instance, “Discovery of Sulfur Dioxide on Jupiter’s Satellite Io”). Other stories have dealt with particular missions (“The True Story Behind the Mars Pathfinder Success”), with more general learning from experience (“How Spacecraft Fail”), and with the organization itself (“Jet Propulsion Laboratory—The Early Years”).

What do people get from these stories? Some pick up bits of wisdom they can apply to their own work—do’s and don’t’s of planning and design, maybe a technical insight that helps solve a problem. Some are inspired by stories of success. Most gain a greater sense of connection with the organization, because they hear about what colleagues have been doing, because the stories express values and aims that tellers and listeners share, and because they are participating in a communal experience. I believe building trust and relationships is a more important effect of organizational storytelling than knowledge transfer.

Knowledge managers seldom talk about what stories do for their tellers. In fact, the benefits of telling a story can be profound. Shaping stories helps people make sense of experiences they’ve had. Telling them to a receptive audience not only provides heartening evidence that colleagues find your work interesting and valuable, it remind the tellers how much they care about what they do. Describing her scientist and engineer storytellers, Bailey says, “They don’t even know how passionate they are about their work until they start talking about it.”

The person who learns most from the story is often the one who tells it.

Posted by Don Cohen at 12:35 PM | Permalink | TrackBacks (0)

January 09, 2006

The Knowledge Technology Trap

Again and again during the two dozen interviews I’ve conducted to figure out what we’ve learned from a decade of knowledge management experiences, practitioners said, “Knowledge management projects focused mainly on technology will fail,” or words to that effect. No surprise there. From the early days of KM, thoughtful commentators talked about the human and organizational elements of knowledge work and the need to balance technology, process, and culture. Everyone heard stories of failed technology-driven projects—“knowledge bases” ignored by intended users, unreliable and abandoned expertise locators.

But some of the same practitioners who expressed this supposedly obvious truth said that the point had to be made again and again to prevent their organizations from falling back into the mistake of depending on technology to make knowledge sharing happen. Companies still invest in mainly technological fixes to knowledge problems and, when those fail, they do it again, pinning their hopes on some improvement or other in the software.


Part of the answer is that the human element is complicated and subtle. When you buy hardware and software, you at least know what you’re getting for your money. Investments in relationships and behaviors are harder to see and measure. Also, and despite all the talk about the old factory-model of the organization dying away and the importance of “our people” in the knowledge age, I think many leaders still want to think of their organizations as efficient machines and people as part of the equipment who “should” adjust themselves to the rest of the mechanism without pampering or a lot of talk about “culture.”

In the U.S. at least, a sheer love of technology may be an even more important factor. We have a long history of believing that the next technological marvel will eliminate drudgery or hunger, cure disease, make us happy. The social, political, and environmental problems of the last half century may have weakened our faith in redemption by technology, but the longing for simple, mechanical solutions remains strong. It’s reflected not just in the love of technology, but in the belief underlying the whole self-help industry—the idea that a pill, a mantra, or a machine can make us slim, beautiful, rich, and happy.

This persistent search for the silver bullet (or the silver bullet point) is a kind of tribute to American optimism, the belief that we can make ourselves, our companies, and the world better if we find the magic formula. Too bad it’s not true.

Posted by Don Cohen at 11:19 AM | Permalink | Comments (3) | TrackBacks (0)

December 21, 2005

Think You’re Thinking Outside the Box? Sorry.

There are a lot of business-language clichés I’d be happy never to hear again. I don’t care for the phrases that confuse people with computer technology (“Let’s talk about that off-line.” “I don’t have the bandwidth to take that on.”). Or the tendency to use a ponderous phrase when one straightforward word will do (saying “in the July timeframe” instead of “in July”). Or those ugly “-ize” verbs (“incentivize;” “operationalize;” “productize”).

But maybe my least favorite phrase is “think outside the box.” It bothers me partly because I’ve heard it used 11,580 times in the past 10 years. (I’m exaggerating, but I’ve heard it a lot.) Also because people who talk about “thinking outside the box” never will. If they could, they wouldn’t use a tired cliché to talk about originality. When advertisers parody a phrase (“Think outside the bun”), it’s time to move on.

What does any of this have to do with organizational knowledge? Well, a lot of knowledge sharing happens through language that not only communicates a certain quantity of information about something but that intrigues, inspires, and tells you that the speaker is thoughtful, knowledgeable, and alert. Good knowledge-sharing language generates energy and thoughtfulness. The dead language of clichés that you’ve heard a hundred times before puts people’s minds to sleep (and sometimes their bodies, too).

So what’s the take-away? Net-net, implementing cliché avoidance 24/7 is a win-win for speakers and listeners alike. If you disagree, let’s take it up off-line, when I’ve got some more bandwidth.

Posted by Don Cohen at 12:54 AM | Permalink | Comments (1) | TrackBacks (1)

December 03, 2005

The Backlash to Process

It was inevitable, I suppose. After several decades of largely positive palaver about the power of process, a backlash is beginning to emerge. Several journalists and bloggers have begun to argue that process is injurious to organizational health and innovation.

Erin White of the Wall Street Journal, for example, reported on September 19, 2005 that companies are beginning to become disenchanted with Six Sigma and process management—particularly where innovation and new product development processes are concerned.

On John Hagel’s blog, he and John Seely Brown argue that "for the past couple of decades, the primary focus of IT investment in the enterprise has been to standardize and automate business processes. Over the next couple of decades, the real opportunity will be to amplify practices by supporting collaboration on demand – helping people both within and across enterprises to connect more flexibly and richly with each other around real business needs."

In a somewhat silly blog entry entitled “The End of Process,” Socialtext's Ross Mayfield argues that, “Because of constant change in our environment, processes are outdated the immediately after they are designed (sic, but you get the idea).” He goes on to say that connected knowledge workers can simply organize their own groups and processes at will.

First let me say that the devotees of process don’t have much to fear.

Process isn’t going away, at least for the vast majority of situations to which it’s been applied. For any sort of structured work activity, processes are the key to efficiency, quality, and efficient use of IT. For business activities like manufacturing, order management, accounting, and customer service, to eschew process is to eschew performance.

But the process malcontents do have a purpose and a point. It’s actually healthy to have a debate about how much process orientation to have in business, and where it should be applied. The idea that the same approaches to process management worked well for all businesses and all activities within them was never a good one. Of course, it’s just as nutty to argue that we don’t need processes at all as it was to argue that process was good for everything. The hard-core “enterprise engineers” and the advocates of self-organizing work are equally unhelpful.

The backlash to process generally focuses on the negative implications for innovation. This is both wrong and valid. It’s wrong when applied to process innovation. Companies that do process management right can certainly incorporate opportunities for participation by those who do the work, and continuous innovation in the process. Just ask Toyota, which has mastered both processes and process innovation.

But process critics are valid when the focus their attack on applying process to product and service innovations. We can call these activities processes, and we can try to impose structure on them. But innovation activities in business will always be less structured than other business domains, and harder to measure and automate. If we impose too much of a process orientation on these activities and people, we’ll either drive down the level of innovation or get frustrated. Cisco, for example, is a very process-oriented firm, but it has relaxed some of its orientation to process in its new product development activities.

The key to establishing a balance, as John Seely Brown and several of his former colleagues at Xerox PARC have argued for a while, is to mix process with practice. Process is an abstract structure for how work should ideally be done; practice is the day-to-day way in which work is actually done. Process involves respect for methods, measures, and organizational attempts at improvement; practice involves respect for smart people and localized decisionmaking. Process without practice is unrealistic; practice without process is chaotic.

In structured business activities such as manufacturing, we need more process and less practice; in less structured knowledge work domains like innovation, we simply need less process and more practice. To admit that a mixture is necessary, and to work at determining the appropriate balance, is the only reasonable approach.

Extreme arguments in either direction are counterproductive at best.

Posted by Tom Davenport at 04:45 PM | Permalink | Comments (3) | TrackBacks (1)