More data on the health of KM (revised)

Is KM dying, alive and well, or on life support? Let's bring some data into the debate (this post updated based on further data).

The debate about the health of KM is a perennial topic, with people variously claiming "KM is dead", "KM is alive and well" or "KM is on life support".  The item commonly missing in these claims is hard data; people instead going on their impressions, or on the bold claim of a replacement for KM that overthrows its older rival.

I have tried my best to bring some hard data into it, such as the apparent accelerating start-up rate of organisations, taken from the Knoco survey data (the counter-argument to which might be that more recent entrants to the KM game are more likely to have responded to the survey).

Here are some more data.

3 years ago I did a survey within LinkedIn, looking at the number of people in different countries with "Knowledge" in their job title (or or Conocimiento, or Connaissance, or Kennis, etc etc depending on language). From this I concluded that there are probably about 32,000 knowledge managers in the world, with the greatest concentration in Switzerland and the Netherlands, and the lowest concentration in Russia and Brazil.

This survey is easy to repeat, and to compare the number of people now with Knowledge or its equivalent in their job title, with the number of people then. The results for the top 10 countries in terms of search results are shown in the figure above and the table below.

	total K people 2014	total K people 2017
USA	10483	12494
UK	3431	3989
India	3244	4228
Canada	1736	2000
Netherlands	1656	1988
Australia	1105	1388
Spain	820	788
France	803	1000
Brazil	733	988

In every case the number of people with a Knowledge job title has increased, but about 26%.

However the number of people from those countries on linkedin has also increased (thanks to Mahomed Nazir for pointing this out).

If we look at the number of people with Knowledge in their job title as a percentage of LinkedIn users, then things change, as the population of LinkedIn has grown a lot over the last few years.  The figures below represent the number of people from a particular country with Knowledge or its translation in their job title, per million LinkedIn unsers from that country.

	K people per million LinkedIn users 2014	total K people per million LinkedIn users 2017
USA	101	97
UK	214	181
India	130	101
Canada	174	157
Netherlands	325	331
Australia	184	174
Spain	128	143
France	97	107
Brazil	41	33

Here some countries have seen a fall in the percentage of people with a Knowledge job title, others have seen a rise. On average, numbers have fallen by 6%.

So in conclusion, over the last 3 years, the number of people with Knowledge etc as a job title on LinkedIn has increased by 26%, but this becomes a 6% decline in percentage terms if you allow for the overall population growth of LinkedIn.

 Is this the death of KM? Unlikely.

Could it be a slow decline? Possibly. 

I think we need to collect more data like this over a longer time period, and see if any trends continue.

"KM is all about change" - up to a point, and then it isn't

Knowledge Management is only a change management exercise, until a certain point is reached. After that, it is about not changing.

It is an accepted fact that introducing KM is all about change.

You are bringing in  new processes, new roles, new technologies and new governance, that will enable, drive and support new ways of working, new behaviours, and new attitudes to knowledge. You are asking people not only to change the way they work, but also they way they think, In particular you are asking them to start to treat knowledge as a collective asset, not a personal asset.

So your KM program has all the trappings of a change management program - a vision, champions, a communication strategy, publicity for the strong perfomers, and so on.

However if you are successful, you come to a point where KM is institutionalised in the organisational frameworks. That's when you need to stop changing.

Once KM is institutionalised, it is easy to take your eye off the ball, and think that the job has been done. However it is all too easy for the organisation to change back, to lose sight of the value KM brings and to start to revert back to how it was. The role of the KM team, once the KM change has been made, is to embed that change so that there will be no reversion.

Now your KM program has all the trappings of an established discipline - a policy, accountabilities, governance, standards, metrics and reporting, sanctions against the people who refuse to do KM, and so on.

And if you are successful with this, then KM can become internalised within the culture for the long term, and thats where the benefits will be greatest.

So Yes, KM is a change program, until it becomes a "don't change back" program.

Process ownership and process owners in KM

The people who own the processes in an organisation are responsible for a big chunk of corporate memory. But who are these people?

Perhaps we ought to start with defining what process ownership actually means.

Process ownership is a key component of many management approaches such as business process improvement, six sigma, and Lean manufacturing, and there are many definitions available in the literature.  The definition below is a simplified version

A process owner can be defined as the person accountable for maintaining the definition, and the quality of a particular process.  They don’t have to operate the process themselves, but they need to make sure that the people who do operate the process have access to the documentation they need to operate the process in the (currently identified) best possible way.  

You can write a similar definition for Practice ownership, and in many ways the terms Process and Practice are used interchangeably in this blog post.

Why are processes important in KM?

Think about learning, and about corporate memory.

When a baby learns, they take stimuli and inputs from the outside world, compare these to existing mental models and responses held in their memory, and update these models and responses over time. 

But where is the memory of an organisation? You can’t rely totally on the memory of the employees to be the totality of the memory of the organisation, as employees come and go, and the human memory is, after all, a fragile and fickle thing, prone to many flaws.  In addition to this human organisational memory, we can make a strong case for organisational structures, operating procedures, practices and processes also forming a core component of organisational memory. 

Processes, practices and procedures are built up over time, and represent the company view of “how we do things”. Employees follow the processes, and repeat “how things are done”. The processes hold and propagate the patterns for behaviour, and for the way work is conducted. If the organisation is to learn, these processes must evolve over time.

The concept of evolving processes as representing corporate memory is recognised by many learning organisations. 

• One of the learning professionals in the UK Military said to me “what is doctrine, if not the record of lessons learned?” (Doctrine is the military term for Process)
• The head of Common Process at BP explained Common Process as being "the accumulated and embedded knowledge of how to operate".

But while a baby "owns" her own memory and can update this unconsciously as new knowledge is gained, a corporate process requires conscious update, and needs someone - the process owner - to perform this update task.

Exactly who owns the process, depends really on the maturity of the process, as well as on the structure of your own organisation.  Some example process owners are listed below.

Technical authorities.

The technical authority role is used in many engineering organisations, for example NASA, to ensure that all operational decisions are made with reference to technical engineering knowledge and expertise.  Technical authorities might be individuals such as the chief engineer, the chief electrical engineer, or the head of marketing. They are generally the owners or custodians of internal standards and policies, and so can be considered to be a process owner when a process is fully defined by an internal standard.

When a process has been standardised, that generally implies that it is very well understood, and unlikely to change very much.  Changes to standards are rare, and caused only by major deviations from normal operations.  It therefore makes sense only to give process ownership to the technical authorities in the case of mature and well established processes, and even with these stanardised processes, there may be a need for additional knowledge of how the standards are best applied.

Subject matter experts.

The subject matter expert (SME) doesn’t necessarily have any Line Authority in an organisation, but has intellectual authority based on their expertise.  The subject matter expert is the company-designated person in the organisation who has the greatest expertise in a specific technical topic.  It therefore makes sense for them to be the process owner for their topic, because, in theory at least, they know more than anybody else about that particular topic.  It makes sense for the SME to be the Process Owner for any process which is mature enough, and well defined enough, for a single person to grasp it in its entirety.

Community of practice leader

Communities of practice can also take process or practice ownership.  The leader of the community of practice is the person who coordinates community activity, and should also make sure that community knowledge is compiled and documented.  It makes sense for the community of practice leader to be the process owner, when the process knowledge is dispersed within the community rather than being held by any one person.  This will be the case when a process is relatively new, is being widely applied in the organisation, and where knowledge about the process is still evolving.  So rather than a subject matter expert being able to hold all the knowledge in their own head, the community of practice owns the process, and the ownership role is coordinated by the community of practice leader.  There may often be cases where the community of practice can themselves keep the process up to date, perhaps through use of a wiki or other collaborative tool.  The community of practice leader, in this case, acts as the coordinator and editor.

Research and development team

Sometimes the process is very new.  Sometimes the process is only recently been identified, and is in the process of being developed through a program of trials.  Here the R&D staff own the process, and use the R&D program to define the process. I have been working with one research organisation who divides their areas of practice into "research fields", and each of these research fields has an owner, who acts as process owner for this - as yet very immature - field of knowledge.

So we can see an evolution in process ownership as a topic matures - owned originally by research field owners, then communities, then SMEs, and finally by Technical Authorities, as shown in the picture accompanying this blog post.

The point, however, is that there needs to be ownership at every stage of the maturity of the topic, to ensure the corporate memory is maintained and update.

What's wrong with this KM picture?

There is a common diagram in use in the KM world, which has at least 3 major flaws, so apply it with caution.

I am going to be contentious again in this post, and draw attention to the failings of a very common KM model. I do this because I think we can do better, and because this model draws us into ways of thought that can cause us to miss opportunities.

This is a very common sort of picture in the KM world - a one-way learning loop with "knowledge capture" or "knowledge collection" as step 1 or step 2.  Here is a version I drew just for this blog post, but you can find many other examples.

Simple and seductive as this model is, there are three main flaws which you need to be aware of if the model is not to lead you astray.

Firstly, knowledge doesn't have to be captured, to be managed. 

As Stephen Denning pointed out recently,  there is some knowledge that can be collected or captured (he calls it precision knowledge) and some that cannot (he calls it intuitive knowledge). He concludes that "It is only in the area of precision knowledge that a knowledge collection (captured knowledge) will offer a clear guide to action".

Can you manage knowledge if it is not captured? Sure you can - you manage it through conversation - through arranging the right conversations between the right people;

• conversation within the team, for example through after action reviews
• conversation from on team to another, for example through peer assist or knowledge handover
• conversation within a community of practice, for example through knowledge exchange
• conversation from one person to another, through mentoring, coaching, knowledge interviewing

Now, in each case, there may be a case for capturing the knowledge as well, if there are other people who also need to learn, but the point is that capture is only an option, and that the capture is not the point - the point is transfer, and that the transfer will be richer than the capture, and will include the intuitive as well as the precision knowledge. 

Secondly the model is a one-way push model, with no room for Pull. 

It starts with a piece of knowledge, which needs to be captured. There is no indication in the loop that there is a need or a demand for that knowledge - only an arrow from "knowledge" to "capture".

Knowledge management is not as simple as a one-way loop. There are two driving forces for knowledge, Push and Pull, and Pull is a stronger driver. Knowledge flows most easily when it answers a need, and knowledge flow is less like bottles moving along a conveyor belt than it is like electron holes moving through a transistor. The push loop above has no place for "knowledge seeking", for example, as this is a Pull activity and the arrow would go the other way.

Thirdly the model usually has no place for co-creation of knowledge.

It usually is seen as a transaction flow from knowledge creator to knowledge re-user, but we know that these flows are not simple, and that when they work well the knowledge is not transferred like a unit - like a bolt in a piece of machinery - but changes its nature with every interaction. As people discuss what they have learned in a lesson capture meeting, they co-create the knowledge through conversation. As knowledge is stored in a wiki (for example), it is co-created through interactions in the wiki, as new insights are added and misconceptions removed. As knowledge is shared in a community of practice discussion, it changes again, growing and becoming more robust with each interaction. The knowledge user adds new knowledge to what they already know.

The danger of the model

The danger of seeing KM as a push-based flow of knowledge starting with capture was once again brought home to me recently, when talking with a young knowledge manager. Her approach to KM was to start with capture, and she was desperately trying to convince people in her organisation to submit "knowledge documents" to the knowledge base. She was failing, as people did not see the point. They did not believe in KM, they did not think publishing would have any effect, and they did not see "whats in it for me." Instead I suggested that she started to work on developing a demand for knowledge, and on setting up "knowledge conversations" such as after action review.

The role of corporate management in KM

Everyone has a role to play in KM, but what's the role of corporate management?

Copyright-free image from pxhere

I pointed out last week that corporate management is one of the stakeholders for KM, and that they have certain needs from the KM program, but with these come responsibilities. Senior management support can make or break KM success, but what role exactly do they play?

Here are the highlights.

• Managers need to endorse the knowledge management program, and be seen to be giving it their support, perhaps by drafting, endorsing and promoting a KM Policy. 
• The endorsement extends to providing resources within their part of the business - the knowledge managers, the subject matter experts, the KM team. 
• Managers need to help steer the KM program in their part of the business - to work with the knowledge management implementation team in order to help them understand which knowledge is strategic for the specific business unit or business group, in order that knowledge management activities can fully support the strategic business agenda. 
• Managers need to lead by example. Knowledge management is not something which will only be done by the junior grades - the managers need to be involved as well. 
• Managers at all levels need to take the lead in their part of the business in setting an expectation for managing knowledge. They need to make it clear what they expect to see 
• Assuming managers have set expectations as described above, they need to follow up on these expectations. The organisation will be watching closely how senior managers deal with people who shirk their KM responsibilities.
• Managers need to recognise and reward wisely, if knowledge management is to survive. It will send a very negative message if senior management reward and recognise the wrong behaviours, such as internal competition or knowledge hoarding. 
• Managers need to provide challenge to the business; to continuously improve in what they do through applying knowledge from others, and to share their knowledge in order to help others to improve. 
• Managers need to provide challenge to KM; to audit what they are doing, and continuously improve the KM Framework in support of the business.

"Time out" for knowledge

The concept of "Ba" in knowledge management is often assumed to represent a physical or virtual space. But what if it represents a time, rather than a space?

New Office Chair, by Brendan C, on Flickr

The term Ba was introduced, in the KM context, by professor Nonaka as a place or a shared environment that serves as a foundation for the creation of individual and collective knowledge. Nonaka and Konno talk about four Bas - one for socilaisation (face to face), one for externalisation (peer to peer), one for combination (group to group) and one for internalisation (at the work site).  The Ba is a learning environment where interactions happen.

Ba is a Japanese term and as such, fuzzy in its meaning. In the west, Ba is often identified with Space - physical or virtual - and applied to office design, or to online platforms. Westerners see Ba as physical; for example wikipedia defines Ba as

"a physical or virtual collaborative space, where participants feel safe and exchange insights."

For me, there is another dimension of Ba which is more important, more valuable and often overlooked, and that is the time dimension.

Let me explain what I mean.

We recently conducted a knowledge management assessment of a busy company, and during the assessment we were asking about the transfer of knowledge through conversation.

"Oh, we talk all the time" they said. "We have operational meetings every morning, team meetings once a week, we talk with the suppliers every week, our boss has a briefing once a day. we are always talking". 

"But what do you talk about?" we asked. It turned out that they talk about progress, about issues, about plans, but never about what has been learned, or what needs to be learned. 

"Why don't you ever talk about learning?" we asked them. 

"Oh, we are too busy for that" they said. "We used to have meetings with other teams to find out what they were doing and why, but we got too busy and stopped that". 

So there used to be "safe time" (Ba) for interactions and for learning from each other and exchanging insights, but it was not protected, and it vanished.

The issue in a busy company is not physical space; it's protected time.

What this company needs to do, and what so many busy companies need to do, is to carve out safe time for knowledge management, otherwise it will be kicked off the agenda by busy short-term work, and the long-term value of learning will be lost. They need to be able to call "time-out" to reflect and to learn. Sure, we need the physical space, but more important (in many cases) is the protected shared time, dedicated to KM.  This can be

• Scheduled Peer Assists at the start of projects
• Scheduled Knowledge Gap Analysis at the start of projects
• Scheduled and ad-hoc After Action reviews on a regular basis
• Scheduled Lesson Capture meetings from projects
• Regular community Knowledge Exchange meetings - face to face or virtual

We need the time dimension of Ba - time dedicated to talking about knowledge, when people can feel safe and exchange insights.

KM's 17 deadly sins

I found this in my archives, which comes from a Canadian Federal Government perspective in 1999.

Notice how many still ring true today - truly little has changed in nearly 2 decades.

The deadliest sins of Knowledge Management :   

1. Continuing to operate a hierarchical organisation
2. Fear
3. Placing a greater emphasis on technology than people
4. Not communicating enough on the issues
5. Not approaching Knowledge Management as a management issue
6. Not identifying the departments' most valuable holders of knowledge and key innovators
7. Reluctance to distinguish between data or information on the one hand and knowledge on the other
8. Emphasising knowledge stock to the detriment of knowledge flow
9. Viewing knowledge as existing predominantly outside the heads of individuals
10. Not understanding that a shared context is fundamental to knowledge management
11. Paying too little heed to the role and importance of tacit knowledge
12. Disentangling knowledge from IT issues
13. Downplaying thinking and reasoning
14. Focusing on the past and the present but not the future
15. Failing to recognise the importance of experimentation
16. Substituting technological contact for human interface
17. Seeking to develop direct measures of knowledge

Although the original source for this is lost in the mists of time, numbers 8 through 17 are copied directly from the 11 deadly sins quoted by Fahey and Prusak (California. Management Review, Vol. 40 No. 3,), although number 12 may be as misquote, as the original is "Disentangling knowledge from its uses", rather than "from IT issues" - both of which are a sin.