Thoughts on an Active Community of Practice Engine

In my last post on how organizations should look at employee knowledge, I suggested that we need new kinds of tools — other than word processors — for helping people contribute to the organizational knowledge base. I didn’t say how I thought such tools could work, so in this post, I’m making some suggestions. The lens through which I look at the corporate knowledge base is that of a community of practice. To me, the knowledge base isn’t the 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.

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 to the smaller group which transfers to a sense of loyalty to the larger organization.

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, and maybe a way to conduct online discussions, and then we wait for the magic to happen. >>Crickets chirping….<< Well, why doesn’t the magic happen? Why don’t online communities just “work?” At first, sometimes they do work 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
  • 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 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 be executable code running 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., many collaboration platforms have a native capability to launch a discussion) or specially written wizards to supply capabilities and guidance that the platform lacks.

I admit I leave a lot to the imagination, but this is a blog post, not a functional spec or technical design. 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, IMHO, are three ideas. First, the idea that communities of practice need guidance and an operating model in order to succeed. Second, the idea that software agents can supply this guidance as an overlay to an existing collaboration platform. And third, the idea that 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?

Don’t Mine Knowledge, Cultivate It

Departure today from the technical how-to topics I have been blogging on. This time I’m waxing poetic on why I think organizations that depend on “knowledge work” have the wrong attitude and approach toward knowledge. I’m moved to write about this by a recent professional experience that struck a chord from my consulting past during which “knowledge management” was something you could say without apologizing (well, in certain crowds, anyway). Regardless of the heading you put this under and how buzzword compliant that heading is, the basic situation is the same for most of us knowledge workers:

• Our success depends upon what we know and what we can learn that others know
• Our employers/clients expect us to have a lot of this knowledge stuff already, but they also expect us to have clever (and inexpensive) ways of getting more of it
• Nobody has the faintest clue what knowledge really is and how to get more of it.

OK, the gauntlet is down. I make this claim because in the 25 years that I have been working in and around software products and systems that help people do their jobs better, I haven’t seen anyone — except knowledge management consultants — pay attention to this valuable asset called knowledge. Pretty much everyone is all over the idea of information, which they think is a synonym for knowledge. But I don’t think people really get the knowledge thing.

What separates knowledge from information is so basic it feels silly to write it down — knowledge is what people — breathing humans — know. I realize that was a tautology; let me try to get out of that doghouse. What makes something knowledge is your experiences and the way you have connected these to the facts and figures you understand. The facts and figures are not knowledge — they’re just information. Data. You combine that data with your experiences to produce a bit of knowledge. Here’s an example that Bostonians will appreciate given that June in Boston this year was so wet, cool, and murky it was how you imagine the forests to be when you read a Tolkien novel. Anyhow, if I have the info that it’s the middle of June in Boston and this morning it’s cold enough for me to wear a fleece pullover, I have a good hunch it’ll rain today. I don’t have the information on the future of my local weather, I have the knowledge that if you get nasty cold in Boston in June, that’s not customary — something is happening, and from my experience, that something is likely to be rain. I know to carry an umbrella or wear a hat.

So who cares whether knowledge and information are the same or different? Did you ever fly in a plane? If so, you should care about the difference. What every dial and lever in that cockpit means and what it controls is nothing more than a large body of information. If I were armed with that information (the manuals are carried on every airplane), would you feel comfortable letting me fly that plane? Didn’t think so. Even if I had a week to read all the manuals first? Um…nope. And why not? Because flying a plane depends on so much more than the assembled facts and figures of how a plane operates. OK, so why should an insurance business or a telecommunications carrier or a retail chain care about knowledge? They send a lot of their people to training — doesn’t this give the employees what they need to know to do their jobs?

Only a little — and only temporarily. Training classes have a notoriously low rate of retention (ask any instructional design maven), AND, 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 takes more than classroom learning. You need 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; what they know goes beyond the mechanics of the ordinary. Experts can operate in the realm of what will happen or what should be the case or what mustn’t be done. And doesn’t every knowledge intensive business want as many employees as possible to perform like experts?

This knowledge stuff is valuable — in more extreme cases, it can keep people alive, and in ordinary cases, it can help you acquire customers and retain them; lack of it can certainly help you lose them. So why don’t businesses approach knowledge the right way? Some confuse knowledge with information, and those businesses think they are doing the right thing. They run training and they cram binders with factoids (and you can even take the course materials away on a USB memory stick!). Other businesses see that, despite the need to impart information to their workers, this alone won’t result in expert or near-expert performance. These businesses do see the need to harness their workers’ knowledge, but sadly, they usually look for it 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. Documents are most often about info, not knowledge. Did you ever turn to the Encyclopedia Brittanica to solve a thorny problem or make a tough decision?

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 because they are over-worked and under-motivated. And even if they were 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? The whole enterprise search industry depends on this attitude. But 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.