acm - an acm publication

Articles

Common knowledge
an interview with Nancy Dixon

Ubiquity, Volume 2000 Issue April, April 1 - April 30, 2000 | BY John Gehl 

|

Full citation in the ACM Digital Library



UBIQUITY: Let's start with the obvious question: what do you mean by "common knowledge"?

NANCY M. DIXON: In my research I took a look at some companies that I thought were exemplary at this business of sharing knowledge, and what I discovered was that there is one kind of knowledge that is more competitive in the organization than other kinds of knowledge. The competitive knowledge is that which the organization has learned out of its own experience.

UBIQUITY: An example?

DIXON: An example would be if Merck were to introduce a new drug into the diabetes market it would have acquired, by hard experience, some knowledge about how it can go about doing that same kind of thing again. In a sense it can be contrasted with book knowledge, or knowledge you'd learn by going through a course, or knowledge you'd learn by bringing in an expert; in other words, it's knowledge that's developed internally as part of the common enterprise of the organization -- and thus I adopted the name "common knowledge" as something that is common to a particular organization.

UBIQUITY: And you say this kind of knowledge is a condition for competitiveness?

DIXON: Definitely. I profoundly believe that common knowledge gives a company a better shot at being competitive than the knowledge that is to be gotten from a book or course knowledge, because book or course knowledge is actually available not only to your organization but to your competitors. So it's not special. But common knowledge -- which your own organization develops internally is, in fact, unique.

UBIQUITY: Where do companies or other organizations normally go wrong? What do they fail to understand about knowledge?

DIXON: That it's everywhere, throughout the organization. We need to abandon the idea that knowledge is something that's held exclusively by a very small group of experts.

UBIQUITY: Explain how or where that is done.

DIXON: Well, many companies try to identify so-called "best practices," and of course that expression has now become a common slogan in organizations. They try to find the very best practice in the organization and then send that out to everybody else -- to others who the notion is aren't doing their jobs quite as well.

It makes a cute little rhyme ("Find the best and send it to the rest"), but the rhyme is better than the idea, and I'm happy to say that the "best practices" approach seems to be going away. Granted, finding and emulating "best practices" sounds like a wonderful idea -- but unfortunately it really isn't.

UBIQUITY: And why not?

DIXON: Because it's not the way things actually work. What I'm now seeing is more an acknowledgment that many, many people in the organization -- in fact, most people in the organization -- have some knowledge that they've learned through doing their own work, or their team has learned through doing its own work, or the division has learned through doing its own work. All of these different kinds of knowledge would be valuable to some other part of the organization -- not just so-called "best practices." And I think this insight is leading to quite a big change in organizations. Instead of worrying about finding "experts" and capturing their "best" thinking, what we really need to do is make generally available what many people have learned. You asked me what companies do wrong, and I think one thing they often do wrong is hold too tight to the idea that they've got to find out what the single "best" thing is, and then convince others to do it.

UBIQUITY: And you're saying there often isn't any single "best" way? Is that right? And if it is, what's the real harm done?

DIXON: That's right, and the harm done is that when you start trying to say what's "best," you automatically invite others to put up this "NOT INVENTED HERE" wall, which is not very productive at all. When everyone is sharing with everyone else the Not Invented here walls don't go up.

UBIQUITY: You've been talking about knowledge throughout the breadth of the organization, but what about knowledge at different depths within the organization? Specifically, do you find much knowledge of importance at the lowest level of an organization?

DIXON: Very definitely. In fact, I would say that where the knowledge is the most important is at what, in England, they say is "at the coal face," where the work is actually being done, by people who get their hands and faces dirty. Knowledge gotten at the coal face seems to be the knowledge that's the most critical knowledge. And interestingly, in organizations, that seems to be the knowledge that's primarily shared -- knowledge that comes from the coal face. So "coal face" knowledge would be the knowledge that nurses have developed in doing their nursing tasks; or the knowledge that production engineers in a Ford factory have developed by working at their task of trying to get production costs out of assembling cars; or the knowledge that salesmen have learned from working with clients. And so forth. It's knowledge from the front line.

UBIQUITY: You've covered a lot of different companies and industries. Do you see any particularly important differences among industries?

DIXON: I have found that what would work in one company is very likely not to work in another company -- that for the most part you can't just take something from one company and stick it into another. The fact is that some industries or some companies have knowledge that's considerably different than other companies. For instance, a high proportion of the knowledge you need at Ford Motor is knowledge that is very procedural in nature and can be written down in standards and operational guidelines. Well, that kind of procedural knowledge is a very different sort of a knowledge than the knowledge you would need if you're trying to figure out how can we speed up the product development cycle, which isn't something that you can do procedurally because it differs so from product team to product team.

UBIQUITY: You've focused on various companies that have been reasonably successful in knowledge management, but let's look on the other side of the wall. Either naming names or not naming names, can you tell us about some companies that have been terrible at it?

DIXON: There are several companies that have tried some knowledge management process and discovered it didn't work, and so just let it fade away. For instance, one of the oil companies that I have worked with -- not one that I write about in the book -- put together an enormous database in order to collect knowledge from what was going on at various refineries. And they put a lot of work into it and did a big publicity campaign on it. And that was up and running for about five, six, seven months, something like that, and then gradually people just quit putting anything in and they quit coming in and getting anything out.

And that's the biggest thing that I see happening is that companies put a process together, they get it up and running, and give it some publicity . . . and then, oops, it turns out the people just don't use it -- either for the giving part or for the getting part. I could probably name 20 companies that I've personally talked with that have had that kind of experience. So, yes: I think there's an enormous amount of that kind of thing happening.

UBIQUITY: What would you recommend as step number one for a company that has nothing in place in terms of knowledge management? Would it be, for example, the hiring of a certain kind of person?

DIXON: I think step number one is figuring out what's the most important, most critical knowledge that could be shared that would help that organization move toward a goal it is trying to achieve. Because it's not possible in an organization for people to share everything. How could we? We already are all inundated with information. So there's a real need to be strategic about what knowledge you decide to share. Now that doesn't mean you have to just choose one. Certainly there could be many sources you were going after. But you need to think carefully about what's really important and what's not.

UBIQUITY: Could you give an example?

DIXON: Sure. When Chevron, for instance, looked at their situation, they said, "All right. We spend about $5 billion a year on construction materials costs. There's an area we could cut substantially if we could share knowledge." So they strategically targeted an area. And that, I think, is step one.

And then I think step two is asking: "What's the real nature of that knowledge we need to get about the strategically targeted area? Is it knowledge that's very explicit and very routine? If so, then, we'll be able to say, 'OK, then, let's use such-and-such process to transfer it.'" But, on the other hand, if it's knowledge that is very situational, then we have to find a different process for knowledge transfer.

UBIQUITY: Well, let's say it is situational. What sort of process would then be appropriate?

DIXON: When it's situational, you have to bring into the situation itself the people who possess the knowledge you want shared. In the book I write about how British Petroleum makes use of the knowledge of "Peer Assists," who are people from other parts of the world who have experience with issues faced by a local team. They're brought in to the exploration site and shown all the data and asked questions such as: "What else might you do? How did you interpret this? What does this mean?" -- and so forth. They let the people in the situation pull the knowledge to themselves, rather than have managers try to push knowledge to them in the sense of saying: "Well here's something you ought to know." Because knowledge pushed out to people may not in fact apply in any real way to their actual situation. Managers have to be sensitive to that fact.

UBIQUITY: And, on that point, who do you think of as the person driving these kinds of effort in an organization?

DIXON: I've seen them being driven most successfully by line managers, who are often division heads or regional directors or something like that.

UBIQUITY: In Common Knowledge, you identify five different kinds of knowledge transfer processes, three of which have relatively little need for information technology, but two of which require information technology to play a central role. In the latter case, what kind of advice would you give to information technology professionals? What do they have to think about when they think about knowledge transfer?

DIXON: Integration, integration, integration. All of the successful knowledge transfer systems I describe in Common Knowledge are integrated systems, and the actual carrier of the knowledge -- whether that's e-mail or a group of co-workers working as peers or a database -- is only one single element in a much larger system that makes the transfer truly effective. Technology is fine, but it's not enough. A well-done database is fine, but it's not enough. You need face-to-face meetings, you need management concern, and you need the involvement of all the workers. Knowledge transfer is a very large puzzle, and technology is one of the pieces. It does its job only when it fits with the other pieces. And information technology professionals should never forget that.

COMMENTS

Teaching nothing means you have nothing to prove you were right, ever ever, likewise if you disagree. Please research this site (per nuclear power, law, various religions, stars, etc., as verified by site)- http://www.caringbridge.org/visit/hiddenpriorityfactor You can also view its posts on the United Nations OCHA facebook page.

��� Scott Adams, Wed, 12 Mar 2014 15:08:17 UTC

POST A COMMENT
Leave this field empty