Let’s Stop Mining Knowledge and Start Cultivating It

I’m heartened by my friend and colleague Marc Anderson’s summary of the recent Australian SharePoint Conference. Knowledge Management was reportedly an important theme there, and from what I can glean, the speakers get it. In the thirty years that I have been working in and around software that helps people do their jobs better, I haven’t seen anyone who understands where this valuable asset called knowledge comes from and how an organization can take advantage of it.

When it starts to click for an organization that this knowledge stuff is valuable, someone gets the idea to create a knowledge repository. Initially, it holds training materials. Sadly, a lot of class content is information, not knowledge. People get more training on how to work the customer service computer program (“hit F5 after you enter the phone number”) than they do on how to provide good customer service (“let an angry caller tell his story before interrupting to ask the phone number”). To do most “knowledge worker” jobs well requires enough experience to have seen some of the exceptional cases; you need to develop some intuition about what will happen based on your decisions and actions. This is what makes the hot shots hot; experts can operate in the realm of what will happen or what should be the case or what mustn’t be done. What they know goes beyond the ordinary mechanics of what we encode in documents.

Businesses usually look for employee knowledge in the wrong place. If knowledge is what people know, then the right place to find it is in people’s HEADS. You are pretty unlikely to find it in their documents, spreadsheets, and PowerPoint presentations. But that’s exactly where most organizations think knowledge resides — the “K: drive,” that shared place where we store all our files. This isn’t impossible — a person can put his wisdom down in writing — it’s just improbable.

This notion that all these documents we business folk keep cranking out constitute the institutional knowledge base is not only wrong, it breeds two assumptions that throw us further off the scent from being able to capture the real knowledge:
Mistaken Assumption #1: A continuous supply of knowledge is a given

Mistaken Assumption #2: Knowledge is something to be mined

A bounteous knowledge supply is not a given because knowledge has to come from people, and people don’t usually commit their knowledge to writing. Even if they feel moved to do it, there’s no home for their knowledge in what corporations traditionally and mistakenly think of as the knowledge base. Valuable knowledge walks out the door at 6:00 every day because people have nowhere to put it, and the contribution method — cranking out a document — is too difficult.

Because businesses think the document dumping ground is a knowledge base, they are led to their second faulty point of view, which is that knowledge is something to be mined. Hey, there’s a lot of dreck on the K: drive, so if there are any nuggets of wisdom in there, you’re gonna need to do some mining, right? Mining is the wrong point of view. It implies a scarce supply of something valuable trapped inside a nearly endless supply of something worthless. Sound like your company’s shared drive?

What we need to do is cultivate knowledge, not mine it. But how do you get at what people are carrying around in their heads? We know from the explosion of the web that there are a lot of would-be content contributors out there. It’s no longer a hope or wish that if you give people a way to contribute what they know, many of them will do it freely. We need to make it easy, though. And we need to stop being afraid of it — some organizations legislate this sort of behavior out of existence. Here’s what I think are the essentials:

  • Provide new kinds of tools so people can easily capture and contribute their insights without having to slog through the process of writing a document
  • Give people tools that connect them either to the knowledge they are looking for or to like-minded collaborators
  • Take active steps to stimulate the flow of ideas between collaborators so that insights and innovations can occur

I see this as a self-reinforcing loop: capture what people know (both their long-standing know-how and their newly-formed “Eureka!” moments), connect people to knowledge and to each other, stimulate the creation and flow of ideas, and repeat from the top. With this loop in place, you really can have a knowledge repository rather than a file archive. And with more know-how and less dreck in the repository, employees stand a much better chance of latching onto an insight that will improve their performance and make an actual difference for their organization.

How could this work? To me, a knowledge base isn’t even the right goal; it’s a side effect of helping would-be collaborators find each other and interact. Let people query each other, help each other, teach each other, lecture each other, cite each other, rewrite each other — collaborations take many forms — and give them an online home in which to do it, and you’ll have laid the foundation for the organization’s knowledge repository. You start by letting communities of practice form and thrive.

When I say “community of practice,” I’m thinking of any set of people who wish to collaborate, seek advice, compare notes, and stay abreast of relevant events or knowledge in their field because they do the same job or have the same expertise. Members of a community of practice (COP):

  • May be colleagues, but are not necessarily
  • May be geographically close, but need not be
  • May know most other members, but often don’t
  • May know others who should be members, but often haven’t discovered those people yet
  • Want to interact and collaborate, but don’t necessarily know how best to do this
  • May have an online “home” in which to operate, but often don’t

I take it as a given that organizations benefit by allowing COPs to form, operate, record their knowledge, and thrive. Without meaning to make any political commentary, I can certainly imagine organizational structures and philosophies that would find all this fraternization dangerous. I probably can’t convince those folks of my point of view. My target is people who see that communities of practice develop new knowledge and facilitate knowledge transfer within the organization; that COP knowledge can foster innovation and can identify specialties the organization didn’t know it had; and that COP members derive a sense of belonging which makes them happier employees.

So why am I convinced we need new tools for COP practitioners? It’s because the usual suspects let us down. We give people a mailing list, a shared drive for posting files, or maybe something more sophisticated like SharePoint, and then we wait for the magic to happen. Chirp, chirp, chirp…. Well, why doesn’t the magic happen? Why don’t online communities just “work?” Sometimes they do at first if a few motivated and communicative members keep the community alive with questions and content, but the mavens don’t necessarily know valuable ways to encourage participation and attract new blood. Tired of the lukewarm community response to their efforts, the mavens move on or fade into a passive role.

Online communities are still new to us. At least we act as if they are. We don’t inherently know how to operate them. Lacking a model for success, online COPs usually fizzle. Technology can help solve this problem, but not the static kind of technology that just sits there and waits for people to use it. What we need is an active engine that drives and guides participation.

What if a community of practice operated on a software platform that “knew” what to do? What if the platform:

  • Coached members on how to play the necessary roles to keep the COP vibrant?
  • Solicited participation from members?
  • Suggested actions for keeping the community going and the content fresh?
  • Provided tools and instructions for carrying out its suggestions?

To make this just a little less abstract, here are some things I think an active COP engine could do:

  • Maintain a list of key activities that someone in the community should perform, e.g.: ask a question, contribute a document or a link to content, run a survey, organize an event, launch a discussion topic, run a conference call or meeting, comment on existing content, rate existing content, propose a new content area
  • Remind practitioners periodically to perform a key activity that has not been done in a while
  • Seek participation from members, e.g., postings to discussions, answers to questions, comments and ratings on content, etc.
  • Seek missing metadata, e.g., questions need answers, meetings need agendas and minutes, discussion topics need resolutions, etc.
  • Seek fresh content in weak or stale areas

The active COP engine itself would probably run on the same server as whatever collaboration platform was in use. There’s no reason to write a new collaboration platform; many exist that provide decent functions and can be extended. The COP engine could use the same underlying database as the collaboration platform for its metadata and any other data it needed to store. It could also use the local messaging capability, e.g., email server, for communicating its guidance and reminders out to the user community. The following figure, in addition to illustrating why I got poor grades in art class, also diagrams a (very) high level hypothetical architecture.

Ideally, the engine’s behavior would be largely data-driven, or said less geekily, a configuration file would tell the engine what to do. For example, you could configure the engine to know that a given activity (run a survey) should be carried out by a particular role (perhaps any user could run one, or maybe you’d decide that only administrators should be able to run surveys) with a given frequency (monthly). You could also specify a set of tools to give the user as aids in carrying out the activity; the tools could be native platform capabilities (e.g., launching a discussion) or specially written wizards to supply capabilities and guidance that the platform lacks.

I admit I leave a lot to the imagination; this is not a functional spec or technical design. But I’m not proposing anything technically difficult or groundbreaking here — agents that “do stuff” are not even close to a new idea. And of course you’d have to devise ways to keep the engine from being an obtrusive pain in the neck or a disrespected amusement (remember the smiling paper clip in Word?) The potential flies in the ointment are addressable without needing any breakthroughs in the field of computer science, though. Worth some consideration are three ideas:

  • Communities of practice need guidance and an operating model in order to succeed.
  • Software agents can supply this guidance as an overlay to an existing collaboration platform.
  • You needn’t work so hard at building the corporate knowledge base; thriving communities of practice will leave one behind as an artifact of their activities.

I’m champing at the bit to build this. Anyone have funding?

Show your support

Clapping shows how much you appreciated Peter Sterpe’s story.