Why "knowledge sharing" cannot replace "knowledge management"

Can we use the term “knowledge sharing” as better replacement for the term “Knowledge Management? There are two good reasons not to do so.

image from Wikimedia Commons

The terminology debate continues to rumble on in the KM world, with many people preferring the term “knowledge sharing” over the term “knowledge management”. This is partly due to a distrust of the concept of management, or use of the “management” term especially when used in conjunction with the word Knowledge.

As Tom Davenport wrote in his article “Does Management mean Command and Control?”

“I have a problem with overly simplistic characterizations of knowledge management, and management more generally. …. The term “management” is apparently a synonym for “command and control,” and we know that’s bad. “Command and control” is top-down, mean and nasty, and headed for extinction; “sharing” is bottom-up, nice and friendly, and the wave of the future. Maybe the Yale School of Management, for example, should become the Yale School of Sharing”. (However)…if your organization really cares about creating, distributing (I’m sorry–“sharing”), and applying knowledge, you need to manage it”.

But irrespective of whether you think Management equates to Command and Control or not, there are still 2 good reasons why you cannot replace “Knowledge Management” with “Knowledge Sharing”.

Firstly, sharing is not the end of the process of knowledge transfer and application.

There is a common misconception that sharing is the be-all and end-all; that people should first Capture and then Share their knowledge (and Sharing is often taken as meaning posting a document into a repository), and that this constitutes an effective transfer of knowledge.

However KM does not work like that. KM is not about one person with knowledge making it available to others; transferring knowledge as if you were transferring a can of beans from one person to another as in the image above. Knowledge is not transferred, it is co-created.

Once knowledge is shared, as a post on a discussion forum, a lesson in a lesson management system or a comment on a wiki, then it can be questioned, tested, combined with knowledge from other sources, and synthesised into new and better knowledge through discussion and dialogue. After sharing comes synthesis.

And after synthesis comes re-use. Even if knowledge is captured, and shared, and synthesised into up-to-date, valuable reference material, it still adds no value unless someone looks for it, finds it, and re-uses it.

All to often a “knowledge sharing” approach is strong on capture of knowledge, strong on some form of sharing (usually by publishing in a public repository), but weak or absent on synthesis and re-use.

Secondly, sharing deals only with supply and not with demand.

The common approached to knowledge sharing, and to the development of a “knowledge sharing culture” tend to focus only on the supply of knowledge. They assume knowledge will be captured and shared, creating a constant supply of new knowledge, and that this is enough.

But it is not enough.

To make any exchange work, you need demand as well as supply.  In parallel with knowledge sharing you need knowledge seeking, and in parallel with a knowledge sharing culture you need a knowledge seeking and re-use culture. A constant supply of new knowledge is a waste of time unless there is a constant demand for new knowledge.

In fact knowledge seeking is actually a better place to start than knowledge sharing (even though both are needed as part of a Knowledge Management Framework). Seeking stimulates sharing, and as McKinsey found, “direct requests for help between colleagues drive 75 to 90 percent of all the help exchanged within organizations“.

You could draw the whole knowledge cycle from a seeking point of view if you want – starting with seeking, then finding, reviewing, synthesising with existing knowledge, and applying, rather than starting with capture and sharing – which can give you a different way to look at KM.

Knowledge Management is therefore much more than knowledge sharing.

Knowledge Management includes Knowledge Sharing, as well as Knowledge Creation, Knowledge Capture, Knowledge Synthesis, Knowledge re-use, Knowledge seeking, Knowledge finding, and so on. To focus only on Knowledge Sharing is to underestimate the topic, and runs the risk of creating only a partial solution.

Beware of a focus only Knowledge Sharing. Focus on Knowledge Management instead.

View Original Source (nickmilton.com) Here.

Knowledge Management in the corporate Code of Conduct – Example

One powerful enabler for Knowledge Management is a clear statement from senior management. Here is an example.

Medco Energi is a publicly listed Indonesian oil and gas company, founded in 1980. Winners of a MAKE award in 2007, they have had a KM program in place for many years, led and supported by my Knoco Indonesia colleague, Sapta.

Medco Energi has done something quite unusual in terms of Knowledge Management Governance, which is to put Knowledge Management within their “Good Corporate Guidelines and Code of Conduct”  document, dated 2014. 

Within the Code of Conduct we can find the following:

Knowledge Management Knowledge management is a set of proactive activities with the aim of supporting the organization in developing, integrating, disseminating and implementing its knowledge. 

Knowledge management is a continuous process to understand the organization’s need for knowledge, the location of knowledge, as well as the process for improving knowledge. The goal of knowledge management is to increase the organization’s ability to perform its key processes effectively.  

Knowledge management requires commitment to advance the organization’s effectiveness, in addition to improve opportunities for its members. 

Thie current focus seems to be on sharing knowledge externally, as the code of conduct goes on to demonstrate, with the following guidelines on external knowledge sharing:

Participation in Lecturing, Training, Radio and Television Broadcast 
MedcoEnergi encourages its employee to give lectures or participate in training or radio and television broadcasts. However, prior to engaging in such activity, employee must obtain the approval of his/ her Line Director if he/she use document and information relating to MedcoEnergi. The employee is permitted to receive remuneration from such activity. If an employee acts as a representative of MedcoEnergi, he/she then must report any received remuneration to his/her direct supervisor for further deliberation.  

Publishing of Articles or Books 
Every employee is permitted to publish articles in journals, daily newspapers, magazines, or other print media and/or publish reports and/or books without affecting the working time. Any profit from and copyright of publications that is not related to MedcoEnergi shall remain the property of the employee. In the case of writing, where the employee uses documents relating to MedcoEnergi, he/she must obtain the approval of his/her Line Director prior to publishing the article and the copyright of the published article or book shall become the property of MedcoEnergi.

Even with this purely external focus, it is still good to see KM as a significant Code of Conduct item.

View Original Source (nickmilton.com) Here.

Meetings about What, meetings about How

Not every meeting or every conversation involves sharing knowledge!

Image from Wikimedia commons
Very often, when we are conducting our knowledge management assessment or benchmarking exercises, or designing KM frameworks for clients, we come across a confusion. This confusion is again a linguistic confusion about knowledge.
We might ask the client “what meetings do you have, which are dedicated to knowledge-sharing?”. Often they reply something like this; “we have project meetings every week – people share knowledge with me about their progress, and I share knowledge about their goals for the coming month”.
But is this really knowledge sharing? Is “telling people something” the same as “sharing knowledge”? Are Briefing and Knowledge Transfer the same thing?
We think not.
The types of meeting described above are Project Management meetings, not Knowledge Management meetings. The difference between the two types of meeting is that the former deals with What (What has happened, What will we do) while the latter deals with How (How will we assimilate what we have learned? How will we deal with things in future?”).
Again this confusion comes back to the fact that the English Language has only one word for Knowledge while other languages have two; one for “Know-what” which deals with facts and information, and one for “know how” which deals with capabilities, learning and insights.
Knowledge Management meetings are the ones that deal with How, and which address building capability in the organisation, and transferring and building Know-how. Examples include:
  • The After Action review meeting, where teams build their know-how about how to work together effectively;
  • The Peer Assist meeting, where a team invites others to share their know-how of how to address a project or a problem;
  • The Retrospect meeting, where a team discusses and documents what they have learned about how to best deliver certain types of projects;
  • The Knowledge Exchange meeting, where people from many teams share their best approaches to certain issues, to determine the current best practice.
If the subject of the meeting is about How (what do we know or are learning about how to do something) then it’s a Knowledge Management meeting. If the subject is What (what have we done, what will we do), then it’s another sort of meeting – planning, reporting, briefing etc.

View Original Source (nickmilton.com) Here.

Why you need to place some demands on the knowledge sharer

Sharing knowledge is a two-sided process. There is a sharer and a receiver. Be careful that making knowledge easier to share does not make knowledge harder to re-use.

Image from wikimedia commons

Sharing knowledge is like passing a ball in a game of rugby, American Football or basketball. If you don’t place some demands on the thrower to throw well, it won’t work for the catcher. If you make it too undemanding to throw the ball, it can be too hard to catch the ball.  Passing the ball is a skill, and needs to be practised.

The same is true for knowledge. If you make it too simple to share knowledge, you can make it too difficult to find it and re-use it.  In knowledge transfer, the sharing part is the easier part of the transfer process. There are more barriers to understanding and re-use than there are to sharing, so if you make the burden too light on the knowledge supplier, then the burden on the knowledge user can become overwhelming.

Imagine a company that wants to make it easy for projects to share knowledge with other projects. They set up an online structure for doing this, with a simple form and a simple procedure. “We don’t want people to have to write too much” they say “because we want to make it as easy as possible for people to share knowledge”.

So what happens? People fill in the form, they put in the bare minimum, they don’t give any context, they don’t tell the story, they don’t explain the lesson. And as a result, almost none of these lessons are re-used. The feedback that they get is “these lessons are too generic and too brief to be any use”.  we have seen this happen many many times.

By making the knowledge too easy to share – by demanding too little from the knowledge supplier – you can make the whole process ineffective. 

There can be other unintended consequences as well. Another company had a situation as described above, where a new project enthusiastically filled in the knowledge transfer form with 50 lessons. However this company had put in a quality assurance system for lessons, and found that 47 of the 50 lessons were too simple, too brief and too generic to add value. So they rejected them.

The project team in question felt, quite rightly, that there was no point in spending time capturing lessons if 94% of them are going to be rejected, so they stopped sharing. They became totally demotivated when it came to any further KM activity.

 Here you can see some unintended consequences of making things simple. Simple does not equate to effective.

Our advice to this company was to introduce a facilitation role in the local Project Office, who could work with the project teams to ensure that lessons are captured with enough detail and context to be of real value. By using this approach, each lesson will be quality-controlled at source, and there should be no need to reject any lessons.

Don’t make it so simple to share knowledge, that people don’t give enough thought to what they write.

The sharer of knowledge, like the thrower of the ball, needs to ensure that the messages can be effectively passed to the receiver, and this requires a degree of attention and skill. 

View Original Source Here.

Skip to toolbar