Revolutionising the productivity of the knowledge worker - part 1, the division of knowledge labour

This week I would like to upcycle a series of blog posts from 5 years ago about "revolutionising the productivity of the knowledge worker" - a challenge set for us by Peter Drucker

Image from wikimedia commons

Peter Drucker famously said 

‘‘The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the manual worker in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and knowledge workers". 

That is the big challenge to the Knowledge Managers of this world - to increase the productivity of knowledge workers by a factor of 50. The good news is that we are half way there. The bad news is that we have a long way still to go.

I already provided a summary of this task in a previous blog post, but would like to amplify, here and over the next few days, on the four factors which we, as Knowledge Managers, can influence. And the first of these is the division of knowledge labour.

The manual worker equivalent

The division of labour was a huge step in improving manual worker productivity. This involved dividing manual work into tasks, as in an assembly line process, and the recognition that the manual worker did not need to make everything. They would have their task, work on their component, and others would make the rest.

My grandfather was a village blacksmith. He was a craftsman - he could make a set of wrought-iron gates, for example, which were a work of art. He would start with iron bars, and do all the work himself. The result was excellent quality, but it took a very very long time.

Nowadays iron gates are made in a factory. The quality may be less (though they are definitely fit for purpose, and in some cases factory quality is better than craftsman quality), but the cost is far less, and the productiviy is massively higher.

As Wikipedia says, referring to Adam Smith's famous example of the pin factory - 

"Previously, in a society where production was dominated by handcrafted goods, one man would perform all the activities required during the production process, while Smith described how the work was divided into a set of simple tasks, which would be performed by specialized workers. The result of labor division in Smith’s example resulted in productivity increasing by 24,000 percent (sic), i.e. that the same number of workers made 240 times as many pins as they had been producing before the introduction of labor division"

Division of knowledge labour

The knowledge equivalent of a craftsman is an expert. Much as a craftsman such as my grandfather would make the whole object himself, from raw materials, so an expert would hold all the knowledge in their head, from first principles to the final decision.  Many decades ago, if you needed knowledge to be applied, you called the expert. You got good results, the quality of decisions was good, but it may take a long time to find and deploy the expert.

Just as the transition from a craftsman economy to a manufacturing economy involves the division of labour, so different people make different parts, so the transition from an expert economy to a knowledge economy involves the division of knowledge, so that different people know different parts. 

The division of knowledge is the recognition that knowledge can be more effectively deployed and managed within a community or network, rather than held by an expert, and the division of knowledge work is the effective use of networked knowledge workers. Leaving knowledge in expert heads is seen as inefficient and ineffective.

In many organisations, this shift has happened. Knowledge work has become divided - people know as much as they need to know and no more, confident that they can find any extra knowledge when needed.  Juniors perform tasks, with the help of KM, which in the past were the domain of experts.  New hires answer customer queries, junior GPs address topics that used to be the purview of specialists, young lawyers do the work that partners used to do.  From being the "font of all knowledge," the experts become the "stewards of knowledge" on behalf of the community.

Division of intellectual labour is "work in progress" for KM - a movement that has started, but maybe can develop even further. By dividing the knowledge work, we avoid the need to rely on experts for every decisions, and massively improve the productivity of the knowledge workers, provided they have access to the knowledge needed for their component of knowledge work. How that knowledge is provided will be covered in tomorrow's post.

Division of knowledge labour massively increases productivity, but cannot be accomplished without Knowledge Management.

Why, in KM, the best generals should not be on the battle field.

Your best performers are far too important to be working on projects - they should be teaching others to work on projects.

Image from Creazilla
under creative commons licence

Several times in my career I have been met with the objection that Knowledge Management will not work because the top experts - the people who hold most of the knowledge - are too busy to take part in KM. They are working full-time on the toughest projects or working with the most demanding clients. The theory is that the highest priority project should have the best people working on it. 

If the organisation has aspirations for growth or improvement, then that is a waste of knowledge. The expert can only be in one place, on one project or with one client, but their knowledge is needed in every place, on every project and by every client. 

 KM needs to offer them a new role (which should be seen as an opportunity rather than a threat) - to be the stewards and sharers of knowledge, rather than the sole holders. Their role is to make the organisation knowledgeable, not jut to be knowledgeable themselves. 

The best generals should be in the war college, not on the battlefield. Your best expert on disarming bombs should not be disarming bombs, but teaching others to do so safely. Knowledge needs to be spread as much as (or even more than) it needs to be concentrated.

We can see this approach in Shell, where the best experts become internal technical consultants, or in Rolls Royce, where the best experts are given a "Fellow" role. You can also see this approach in the Customer Service world, as illustrated in this article. 

In KM, the best generals should not be on the battlefield.

The role of the expert should not be to dedicate their knowledge to the toughest project, but to make sure that every project can apply their hard-won knowledge and experience.

The expert - dumber than the crowd/machine?

What happens in a world where the crowd, or the machine, is smarter than the expert?

The excellent book Think Twice: Harnessing the Power of Counterintuition by Michael Mauboussin, was that "as networks harness the wisdom of crowds, the ability of experts to add value in their predictions is steadily declining. This is the expert squeeze".

The book uses the diagram above to show that where prediction is needed, the Expert is often beaten by AI, and  never  better than a collective view.

Does this mean "the death of the expert"? In the new connected world, do the experts have a role, or are they squeezed out?

We have addressed this issue already on this blog (for example here and here) where we recognise that a Community of Practice will ideally always contain more knowledge and experience than any one expert. This results in a shift in the expert's role. From being the "font of all knowledge" they become the "stewards of knowledge". Stewardship is different from ownership - a steward maintains and nurtures something that is not theirs, for the benefit of others.

The exerts can take on a Knowledge Management role that involves becoming a Practice Owner or Practice Steward for their domain of practice, and playing a coaching an supporting role in the relevant Community of Practice.  They also share their own knowledge through coaching, training, and contributions to the Community, and take technical roles on difficult and challenging pieces of work where they can apply, with wisdom, the knowledge of the community. 

The point which the diagram above does not make, is that the Expert becomes a critical part of the collective. Without the experts taking part in the collective, the collective can become "the blind leading the blind".   We have seen this in one large organisation, with huge communities in which the experts take no part as they are "too busy". Not only are questions in the communities not answered (or answered with platitudes), the experts deride the communities as having no relevance. 

Similarly the expert can be squeezed out by AI - but only to an extent. remember, the AI algorithm has to come from somewhere, and generally it comes from the expert themselves. A knowledge engineer, will work with the expert to expose and codify their knowledge, and to convert it into a machine-readable algorithm. The AI can then reproduce the decision making process of the expert, mking decisions faster and more reliably that the expert ever could, based on a range of data the expert could not handle. 

However the expert still has a role - to monitor teh algorithm, to fill in the gaps where the algorithm does not yet work, to interpret the insights and correlations which the AI identifies, and to understand the "Why" behind the algorithm. AI becomes a tool for the expert as much as a replacement for the expert.

So let us recognise the new world, where the crowd or the machine can be smarter than any single expert, and make sure the experts are given a new role within the crowd or with the machine, and can feel themselves to be stewards of the knowledge within the collective organisation.

4 reasons not to make the deep experts the main knowledge providers

In the UK we call them "the boffins" - the deepest subject matter experts. However there are 4 reasons not to ask the boffins to write the knowledge base content.

Image from wikipedia

We can view Knowledge Management as the mechanism or system by which we provide knowledge to the customer-facing or revenue-generating knowledge user.

Often you find the deep technical experts are given a role in this "knowledge supply chain"; perhaps the knowledge owner role, collating and providing specialist knowledge content for the front line knowledge workers.

However there are four reasons why we need to treat the boffins with caution (and please be aware that this blog post uses caricature and stereotypes to make a point).

Firstly, the boffins take their own knowledge for granted. They suffer from the "curse of knowledge" - they know so much about the topic that they assume others know a lot as well.  They use shorthand, the make fuzzy statements - they say "of course you need to apply just the right amount of factor X here, and not too much - remember the case of old Figgy back in '96 when we added too much - ha ha ha!" If you dont know what the "right amount of Factor X is, or have never heard of old Figgy, then this advice is useless.


Secondly, they talk in code. They use jargon, acronyms, and obscure phrases which are useful to the boffin - they describe the nuances of the topic -  but the novice or mid-level user may not know what they mean. So where the boffin might write "check the PSN level from the transposer and make sure this is within limits", the user might find this more usefully written as "check dial number 2 (see diagram). If the reading is below 20, do X. If it is above 20, do Y".


Thirdly they can think systemically to a degree that less experienced people cannot. The boffin thinks about causes, while the novice may see symptoms. If an exhausted catalyst creates an error E20 message on the control room screen, for example, the novice needs to find content labelled "E20 error", not "Exhausted catalyst".


Finally the boffins go into too much detail. In one organisation I worked with, they had a specialist unit providing advice in response to front line requests. However the feedback from the front line was that this advice was almost useless. Instead of simple practical advice, they get a long academic treatise saying "on the one hand this, but on the other hand that, and if we consider the work of professor X  ....".  Better to document the simple answer that is right 95% of the time, and provide a contact number to call the boffin if you find yourself in the other 5%.

The knowledge supply chain has, ultimately, to inform the front line worker, in terms they can understand, of what their best courses of action should be. Knowledge has to be practical and actionable and usable, rather than theoretical and abstract. When you design your Knowledge Management Framework, you need to ensure that the knowledge providers and knowledge owners are well versed in the context in which the knowledge will be used, so that they can translate it into pragmatic and actionable terms.

It is fantastic when the knowledge owner has a deep understanding of, and love for, their topic, but in the knowledge supply chain the knowledge product they create has to be fit for use by their customer, the knowledge worker.

Maybe the boffin is best used as a supply of tacit knowledge for unusual or extreme cases, and the content for the majority of the knowledge base should be written by an experienced user instead.

How to recruit the experts in support of KM

The Experts can sometimes be resistant to KM, seeing it as a threat or a burden, with little personal reward. How can we address this?

Image from wikimedia commons

Many clients we speak to are having real problems recruiting the expert knowledge holders to the concept of Knowledge Management. Even in those companies where knowledge holders are few, and knowledge seekers are many, the experienced subject matter experts are often reluctant to become involved with KM.

The reason is, that because knowledge is scarce, they are busy "doing the job", and have no time to teach others or to share their knowledge. The fewer experienced practitioners the company has, the busier they are in actually performing the work.

Many experienced staff enjoy their expertise, and they see KM as a distraction or an added burden. They often feel that KM "is not my job".

"I am an experienced boiler-maker/salesman/brewer/application designer" they say; "my skills are in huge demand. Why should I take time out to share my knowledge? That's not my job"

Make KM "the job of the expert"

The answer to this, of course, is to make Knowledge Management (or at least a component of knowledge management) the expert's job, and to give them time and space to do this job..

You can't expect busy people, in demand from all over the organisation, to add to their burdens with work that isn't in their job description. But if their knowledge is vital to company performance, then acting as a steward of the knowledge of the organisation needs to be in their job description. It needs to be recognised as part of their job, and they need to be given the space, the resources, the assistance, and (if necessary) the training to allow them to share their knowledge with the next generation - the apprentice generation.

The old career progression from past centuries was Apprentice - Journeyman - Master.

Knowledge Companies need to rediscover this progression, so that the Masters (of both sexes) - the Subject Matter Experts - can see their role as Teaching as well as Doing, and as passing on their skills to those who need them, through the tools of KM (wikis, community forums, peer assists etc) as well as through the traditional tools of apprenticeship (coaching, mentoring, training).

The pinnacle of an expert's career is to be a Master (or as Rolls Royce calls them, a Fellow). Mastery, or Fellowship, is an honour, and with that honour comes responsibility; responsibility for knowledge. This includes being the Practice Owner for their domain of practice and responsible for the documented knowledge, playing a coaching role in the relevant Community of Practice, partly responsible for the community of apprentices.

We need to rediscover this Mastership role, so we can fully reinstate the experts in their rightful place.

Why leaving knowledge in people's heads is not a great strategy

The default approach to managing knowledge which many companies use, is to keep knowledge in people’s heads, and to move the knowledge where it is needed by moving the people, not by transferring the knowledge. 

Homer Simpson's head by SOCIALisBETTER on Flickr

In this old model, knowledge is owned and held by the experts and the experienced people. Knowledge is imported to projects by assigning experienced people as members of the project team.
Knowledge is transferred from site to site by transferring staff, and by using company experts who fly around the world from project to project, solving problems. Knowledge is stored for the long term in the heads of the experts.

This is a very traditional model, but it has many major failings, and cannot be considered to be effective knowledge management.  Imagine if you managed your finances in this way! Imagine if the only way to fund a project was to transfer a rich person onto the project team, or to fly individual millionaires around the world to inject funds into the projects they liked!


The major drawbacks of this default ‘knowledge in the heads’ approach are as follows:

• Experienced people can only be on one project at a time, whereas knowledge management can spread that experience to many projects. 

• Knowledge cannot be transferred until people are available for transfer. 

• Experts who fly in and fly out often do not gain a good appreciation of how things are done, and where the good practices lie. In particular, teams in projects may hide their failings from the company experts, in order to be seen in a good light. 

• The burn-out potential for these experts is very high. 

• Knowledge can become almost ‘fossilised’ in the heads of the experts, who can end up applying the solutions of yesterday to the problems of today 

• Even experts forget things over time. The human brain is a very poor long-term knowledge store

• Experts have more than knowledge in their heads - they have opinions, biases, prejudices, falsehoods and false confidence, They are as prone, as the rest of us, to confirmation bias, to the illusion of confidence, and the illusion of memory.  Leaving knowledge in the heads of one or two Experts falls right into the hands of confirmation bias.

• Experts are often poor at communicating what they know, as a result of the curse of knowledge. 

• When the expert leaves, retires, has a heart attack, or is recruited by the competition, the knowledge goes with them. 

Unfortunately, for the experts and the experienced people, this can be an attractive model, and was stereotypical behaviour for specialist engineers for many years. It can be very exciting travelling the world, with everyone wanting your assistance. It is like early Hollywood movie scenes with the US Cavalry riding over the horizon to save the wagon train at the last minute. Knowledge management, however, would make sure that the wagon train did not get into trouble in the first place. As one experienced engineer said recently, ‘If you could fly off to some problem project, save the day and be a hero, or sit behind your desk and capture knowledge, what would you do?’

However if that engineer's knowledge had been more widely available, perhaps the project would not have become a problem in the first place.

Don't keep the knowledge in a few heads, spread it through the organisation instead.  Build communities of practice to store and share the knowledge. Document what you can in accessible, findable and digestible content. Change the role of the expert, from being the knowledge hodler, to becoming the facilitator and steward of the knowledge framework on their particular topic - ensuring that the organisation is knowledgeable, rather than being knowledgeable themselves.

If you are serious about knowledge, then don't leave it only in the heads of experts. 

Why beginners and experts behave differently in KM

Experts and beginners behave differently in Knowledge Management systems. Here's why.

Great Meadows Fishing Day by U. S. Fish and Wildlife Service, on Flickr

Confucius said "Shall I tell you what true knowledge is? When you know, to know that you know, and when you do not know, to know that you do not know—that is true knowledge". So the true expert is the person who knows what they know, and what they don't know.

Before you get that true knowledge, before you become an expert, you don't know what you know and you don't know what you don't know.  That's a description of a beginner, or a novice; beginners do not yet know the level of their ignorance.

In knowledge management terms, that means you have to treat the beginners and the experts differently. Experts, and budding experts, will become fully involved in Communities of Practice - gaining knowledge through discussions and through questions., When they need knowledge, they will ask for it and receive answers. Their questions are clear and focused, because they know what they don't know. They won't tend to use the Knowledge Base so much, as they already know what they know, and are looking to "fill in the gaps" in their knowledge that probably aren't in the knowledge base.

The novices, on the other hand, will not take part in the community discussions, although they may "lurk" - read the conversations but without taking part. Because they don't know what they don't know, they don't know what questions to ask. When they do ask questions, they tend to be general and basic rather than specific and targeted. However the beginner will find the knowledge base - the wikis, the FAQs - very useful, because it gives them the full picture. It shows them all aspects of the knowledge, so they can understand the full range of the things they don't know.

The demographics of the workforce determines which knowledge management tools to focus on. A company with large numbers of experienced staff will get huge value from communities of practice, and from question-led discussions among the experts and budding experts. A company with large numbers of new staff and inexperienced staff may get more benefit from building FAQs, knowledge bases and wikis. 

What is the KM role of the Company Experts?

In a fully developed Knowledge Management framework, the company experts have a key part to play.

The experts are one of your core stakeholder groups in KM, and your change management approach needs to explicity address these people.  For many years they may have acted as sole sources of much of the knowledge, and their personal status may be tied up with their own knowledge. KM needs to offer them a new role, which can be seen as an opportunity rather than a threat.

The technical experts in many knowledge management organisations tend to have a three-fold role:

• Acting as a source of expert opinion for others, and for the identification and development of technical practices and procedures;
• Maintaining guidelines and best practices, and validating lessons;
• Building effective learning communities.

In other words, they are accountable for:

• Developing and sharing their own tacit knowledge;
• Ownership or stewardship of the explicit knowledge in their subject matter area;
• Creation of the network that stewards the tacit knowledge in their subject matter area.

These new roles allow the Experts to become the stewards of knowledge, rather than the sole holders. Make sure these new roles are made explicit and built into their job descriptions.

Finding an answer in the Long Tail of Knowledge

When looking for knowledge, let's not just rely on finding the experts.

We know that actually only a small percentage of knowledge in an organisation can be accessed through documents, and that most of it is in the heads of people. We know that if we can "find the people who know", then we can access that tacit knowledge through asking them questions.


One common approach to "finding the people that know" is to build an Expert Locator System. You think - "Who are the experts in the organisation? Can we make an index of the experts, so that people can find them, and ask them for advice?"

However Expertise is not always synonymous with Expert, and certainly Experience is not synonymous with Expert.  The Experts hold only a small percentage of teh organisational knowledge and experience.

Much knowledge lies in the Long Tail

Consider the graph above - a plot of the years experience in an imaginary company. We see red bars and blue bars - the red bars are the Experts, who have 35, 32, 28, 27 and 25 years of experience - a total of 17 years. The blue bars are the workers. They individually have fewer years of experience, but there are a lot of them, and their collective experience adds up to 1187 years of experience - 8 times more than the experts. So if you need an answer to a problem, and if you want to tap into the experience of others, where is that relevant experience likely to sit? 8 times out of 9 (in this example) it will sit it the Long Tail of experience, not in the Short Head of the Experts.

Does this happen in practice? Do we get answers from less experienced workers rather than from more experienced experts? I think in real life - where knowledge exists in context, where contexts vary widely, and where many staff see knowledge in many contexts, then this happens quite a lot. Here is a story from a real company.

"I had written a report on the success of a particular operation in my business in the USA, and I made this report because one of my managers asked me to do this to support a decision. I was able to document some of our information from the last 4 year to help this decision. This is was a significant thing for my team, but it turned out to be significant for other teams as well. I saw a question through the web system asking "what has been the success of this operation in the company?". This was a question from a team in Africa, and it was a close enough scenario to the scenario for which I had written my report. You feel the Power - you feel the power of knowledge and the value that it might represent when you receive a response "Thank you very much for your reply, because this actually helped us to make a decision". It was an incredible experience to answer a question in the forum, with only 2 1/2 years experience in the company, and already being able to advice the whole world on the things we do and how we do it". 

The answer was in the Long Tail, with a junior engineer. The context was similar, the knowledge was transferred, and time and money were saved.

So when you create your systems for tapping into tacit knowledge - your Expertise Locators, your "Ask a question" functionality - do not fall into the trap of involving only the few Company Experts. Remember the long tail, which may contain nearly 90% of the experience and knowledge, and include those guys as well.

Ask an expert, or ask a community?

There are two common approaches to answering requests for knowledge - asking an expert, or asking a community of practice. I prefer the latter, and here's why.

Image from an excellent blog by John Hand,
also discussing expertise location vs
knowledge networking

There are two major components to any Knowledge Management Framework, which we call Connect and Collect, and which deal with Conversation and Content. Connect involves connecting people who have a need for knowledge with others who have that knowledge, so they can discuss and converse, and so exchange knowledge which may not yet have been documented as content.

But which people do you connect?  Again there are two approaches - connecting people with experts, and connecting people with communities of practice.

The former is the focus of a growing discipline of expertise finding, with software that trawls social media (for example) to find the people who seem to say the smartest things, and so to divert questions to these assumed experts. The latter is the focus of traditional communities of practice, where questions are asked in open forum, to be answered by anyone with knowledge to offer.

Each of these systems has advantages and disadvantages.

Advantages and disadvantages of expert finder systems

In a situation where there is a small number of experts servicing a body of people with very limited knowledge (for example in a Customer Support system) it makes sense to connect the questioner with a single expert. They can give a quick and reliable answer, and there is no need to involve others in the conversation.

However this assumes that the knowledge can be answered reliably by a single person, that the system reliably identifies the experts from their published material, that the question can be accurately analysed, tagged and linked to a single expert, and that the expert does not become overloaded by questions.

There are some big issues in that last sentence. Identifying expertise from publications tends to recognise the prolific publishers and overlooks the more introverted experts. Also questions are rarely easily tagged, and often you need to "question the question" to find out what the real problem is.

Advantages and disadvantages of communities of practice

Communities of practice seem less efficient, in that a single question may go to many people, some of whom do not have the expertise to answer. Also the question may receive incorrect answers from people with limited knowledge.

In practice these disadvantages are also advantages. In a situation where knowledge is in fact scattered and diffuse, then only the network can provide the answer, as components of the answer may need to be supplied by different people. This will be the case where communities contain many experienced practitioners rather than a few,as in a technical area within a large multinational, or a sector network in a consulting firm.

In contexts like this, communities of practice may access "the long tail of knowledge" and pick up crucial piece of knowledge from unexpected places. See for example the story of the Polymath project, where crucial steps in knowledge were provided by non-experts.

Any non-experts who offer incorrect knowledge are usually rapidly corrected, which provides the spin-off benefit of removing wrong knowledge from the community.  The fact that others in the community can see the discussion taking place in open forum allows them either to contribute their knowledge, or (if they are a novice) to lurk, listen and learn. This apparent wastefulness - involving people who take no part in the conversation - in fact raises the knowledge of the whole organisation.

For these reasons, in settings other than Customer Support, I much prefer communities of practice to expert finder systems. The apparent messiness and inefficiencies of communities of practice are in fact their strength.

The T-shaped expert

Te concept of the T-shaped manager is well known. What about the T-shaped expert?

I blogged about the concept of the T-shaped manager, an idea introduced by Hansen and von Oetringer which describes the value of managers being both accountable for the success of their own department, and for the shared success of their peers. There are many cases of value delivered through this approach, and it drives, and relies upon, excellent Knowledge Management.

We can take a similar approach when it comes to the role of the company experts.  

I will contrast two approaches to the use of experts, the I-shaped approach, and the T-shaped approach. 

The I-shaped expert.

Companies with I-shaped experts put them onto the toughest projects, where their skills are most needed. The expert is fully engaged with this tough project, their focus is blinkered, they look only downward at their work like the blue I in the picture. Their pay and their satisfaction come from making the project a success. If other people need to learn from the expert, the expert is usually too busy to help them. 

I know many organisations that take this approach. This is a pre-KM approach, where the company assumes that knowledge is only available to a project when the knowledgeable person is on the team; an approach which does not decouple the knowledge and the person. 

The T-shaped expert

Companies with T-shaped experts give them wider roles. They call them "global consultants", "technical authorities" or "practice owners". The expert still helps solve the big problems on the big projects, but as an advisor rather than a full-time project member. Therefore they still look "downward" to project work.  This is the vertical shaft of the red T in the picture.

However the wider accountability is for developing, building and protecting the knowledge and capability of the organisation in their area of practice. They do this by

• Acting as owner or sponsor for the knowledge base; maintaining guidelines and best practices, and validating company knowledge and lessons 
• Building effective learning communities; either as community leader or community sponsor.

Here they look across the whole company, which is represented by the horizontal arms of the T.

The T-shaped expert is a cornerstone of Knowledge Management. And of course they need T-shaped incentives to match their T-shaped accountability. 

The expert - dumber than the crowd?

Yesterday brought another fascinating blog post from the Farnham Street blog, entitled "The Expert Squeeze". 

The premise of the blog post, based on the book Think Twice: Harnessing the Power of Counterintuition by Michael Mauboussin, was that "as networks harness the wisdom of crowds, the ability of experts to add value in their predictions is steadily declining. This is the expert squeeze".

The blog uses the diagram above to show that where prediction is needed, the Expert is often beaten by expert systems, and  never  better than a collective view.

Does this mean "the death of the expert"? In the new connected world, do the experts have a role, or are they squeezed out?

We have addressed this issue already on this blog (for example here and here) where we recognise that a Community of Practice will ideally always contain more knowledge and experience than any one expert. This results in a shift in the expert's role. From being the "font of all knowledge" they become the "stewards of knowledge". Stewardship is different from ownership - a steward maintains and nurtures something that is not theirs, for the benefit of others.

The exerts can take on a Knowledge Management role that involves becoming a Practice Owner or Practice Steward for their domain of practice, and playing a coaching an supporting role in the relevant Community of Practice.  They also share their own knowledge through coaching, training, and contributions to the Community, and take technical roles on difficult and challenging pieces of work where they can apply, with wisdom, the knowledge of the community. 

The point which the diagram above does not make, is that the Expert becomes a critical part of the collective. Without the experts taking part in the collective, the collective can become "the blind leading the blind".   We have seen this in one large organisation, with huge communities in which the experts take no part as they are "too busy". Not only are questions in the communities not answered (or answered with platitudes), the experts deride the communities as having no relevance. 

So let us recognise the new world, where the crowd can be smarter than any single expert. so long as the experts are given a new role within the crowd, and feel themselves to be stewards of the knowledge within the collective. 

Recruiting the experts to your KM initiative

---

Remember the ancient approach to Knowledge Management, of Master and Apprentice? Throughout the middle ages, and into the early industrial age, the Masters were the knowledge holders, and Apprenticeship was the system of transferring that knowledge to a new generation of practitioners of a skill. The Masters saw themselves not just as doers, but also as Teachers.

THE BEAD MAKER -- Apprentice Watches the Master
Originally uploaded by Okinawa Soba

Has that ancient model survived to the knowledge age?

Many clients we speak to are having real problems recruiting the knowledge holders to the concept of Knowledge Management. Even in those companies where knowledge holders are few, and knowledge seekers are many, the experienced subject matter experts are often reluctant to become involved with KM.

The reason is, that because knowledge is scarce, they are busy "doing the job", and have no time to teach or to share their knowledge. The fewer experienced practitioners the company has, the busier they are in actually performing the work.

Many experienced staff enjoy their expertise, and they see KM as a distraction or an added burden. They often feel that KM "is not my job".

"I am an experienced boiler-maker/salesman/brewer/application designer" they say; "my skills are in huge demand. Why should I take time out to share my knowledge? That's not my job"

Make KM "the job of the expert"

The answer to this, of course, is to make Knowledge Management (or at least a component of knowledge management) the expert's job.

You can't expect busy people, in demand from all over the organisation, to add to their burdens with work that isn't in their job description. But if their knowledge is vital to company performance, then acting as a steward of the knowledge of the organisation needs to be in their job description. It needs to be recognised as part of their job, and they need to be given the space, the resources, the assistance, and (if necessary) the training to allow them to share their knowledge with the next generation - the apprentice generation.

The old career progression was Apprentice - Journeyman - Master.

Knowledge Companies need to rediscover this progression, so that the Masters (of both sexes) - the Subject Matter Experts - can see their role as Teaching as well as Doing, and as passing on their skills to those who need them, through the tools of KM (wikis, community forums, peer assists etc) as well as through the traditional tools of apprenticeship (coaching, mentoring, training).

The New Role of the expert is two-fold - to be the Practice Owner for their domain of practice, and to play a coaching role in the relevant Community of Practice.

We need to rediscover this Mastership role, so we can fully reinstate the experts in their rightful place.

What's wrong with keeping knowledge in people's heads?

---

The default approach to managing knowledge which many companies use, is to keep knowledge in people’s heads, and to move the knowledge where it is needed by moving the people, not by transferring the knowledge. 

Three wise monkeys by Anderson Mancini on Flickr

In this old model, knowledge is owned and held by the experts and the experienced people. Knowledge is imported to projects by assigning experienced people as members of the project team.

Knowledge is transferred from site to site by transferring staff, and by using company experts who fly around the world from project to project, solving problems.

This is a very traditional model, but it has many major failings, and cannot be considered to be effective knowledge management.

Imagine if you managed your finances in this way! Imagine if the only way to fund a project was to transfer a rich person onto the project team, or to fly individual millionaires around the world to inject funds into the projects they liked!

The major drawbacks of this default ‘knowledge in the heads’ approach are as follows:

• Experienced people can only be on one project at a time, whereas knowledge management can spread that experience to many projects. 
• Knowledge cannot be transferred until people are available for transfer. 
• Experts who fly in and fly out often do not gain a good appreciation of how things are done, and where the good practices lie. In particular, teams in projects may hide their failings from the company experts, in order to be seen in a good light. 
• The burn-out potential for these experts is very high. 
• Knowledge can become almost ‘fossilised’ in the heads of the experts, who can end up applying the solutions of yesterday to the problems of today 
• Even experts forget things over time. The human brain is a very poor long-term knowledge store
• When the expert leaves, retires, has a heart attack, or is recruited by the competition, the knowledge goes with them. 

Unfortunately, for the experts and the experienced people, this can be an attractive model, and was stereotypical behaviour for specialist engineers for many years. It can be very exciting travelling the world, with everyone wanting your assistance.

It is like early Hollywood movie scenes with the US Cavalry riding over the horizon to save the wagon train at the last minute. Knowledge management, however, would make sure that the wagon train did not get into trouble in the first place. As one experienced engineer said recently, ‘If you could fly off to some problem project, save the day and be a hero, or sit behind your desk and capture knowledge, what would you do?’

However if that engineer's knowledge had been more widely available, perhaps the project would not have become a problem in the first place.

Don't keep the knowledge in a few heads, spread it through the organisation instead.

Three styles of Knowledge flow - centre-out, out and in, or multiflow

---

There are three common styles of knowledge flow that you can see in organisations. We can call them centre-out, out and in, and multiflow.

In our picture here, the red dots are the central group of experts, the white dots are the knowledge users or knowledge workers, and the white arrows are the flow of knowledge.

In the centre-out model, the knowledge is created by the experts in the centre, and "pushed out" to the knowledge workers, in the form of doctrine, work instructions and policies. The centre owns the knowledge - they are the Knowers - while the knowledge workers apply the knowledge - they are the Doers.

In the out-and-in model the knowledge is managed by the experts in the centre. Knowledge is gathered from the knowledge workers, synthesised and validated in the centre, and transferred back out to the workers. There are feedback loops such as lesson learning systems which mean that the central knowledge is always tested against reality and updated regularly. The centre stewards the knowledge and validates it, while the knowledge workers both apply and improve the knowledge.

In the multiflow model, the knowledge flows between expert and worker, worker and worker, worker and expert. Knowledge is created, updated and validated by all parts of the system, and is available realtime. The knowledge is managed and owned by the Community of Practice, while the centre manages and stewards, not so much the knowledge itself, but the knowledge-creating and knowledge-validating system.

The first model seems very old fashioned nowadays, and the third model seems much more attractive, and is becoming more common (see for example the use of Wikis to develop Army doctrine).

However in reality all three models may be needed simultaneously in any one organisation, to deal with different types or different levels of knowledge.

There may be mandatory knowledge, such as knowledge of company law, or knowledge of policies such as anti-money-laundering or anti-corruption policies, which has to be mandated and controlled from the centre.

There may be strategic knowledge, driven by company strategy, which can certainly be tested in the business, with clear (and welcome!) feedback, but which needs to be owned and coordinated centrally and strategically.

There may be operational and tactical knowledge which is owned by the Communities of Practice, and handled within wikis and blogs and discussion forums (and indeed the Army wikis mentioned above were specifically for tactical knowledge).

So it is not as simple as saying "model 1 is old fashioned and rigid and Bad, model 3 is free and liberated and modern and cool and Good".

It is, as is so often the case in Knowledge Management, a case of determining which model is most appropriate for which knowledge.

Knowledge Transfer, seeing is believing

---

I heard a sad but instructive story this week.  The moral of the story is about the credibility of knowledge, and how seeing knowledge for yourself, in context, establishes the necessary credibility for re-use.

This organisation had an effective approach to knowledge sharing.  They would identifying those parts of the business which had knowledge to share (the “supplier” business units), and they would set up knowledge visits from the other business units to come and see for themselves what the supplier business unit had to offer.  The people who came on these learning visits were the operators, the foreman, and the knowledge workers.  They could watch how the supplier business unit did things, they could identify new knowledge and new practices that they could use, and they could see for themselves how things were done.(They could also suggest, and sometimes demonstrate, better practices they used at their own sites, so that knowledge transfer was two-way).

This approach worked.  Because the people coming on the visits were the people who would apply the knowledge, and because they could see that knowledge in context, they could go home convinced that they had seen a new and better way to do things.  Seeing was believing.  Knowledge was transferred, best practices reapplied, and significant cost savings resulted.

Then management changed the system.  They believed that transferring knowledge in this way was expensive, as each knowledge transfer involved sending somebody to another country.  Cost pressure meant that there was a restriction on travel budgets, and they decided to do things a different way.  Instead of sending the operators, the foremen and the knowledge workers, they decided to send a few company experts instead.  The theory was that the experts would then come back and spread the knowledge around the other operating units, delivering knowledge transfer more cheaply.

What happened was that because the operators and knowledge workers had not personally seen the knowledge in use, the suggestions that the experts brought back lacked credibility.  The experts found it very difficult to get people to reuse knowledge which they had not personally seen in use.  Because they hadn't seen, they didn't believe, or at least they didn't trust.  The rate of knowledge reuse dropped.

Eventually the entire system was cancelled.  Now the different operating units work in silos, with no sharing and reuse of best practice.

The moral of the story, of course, is that if you wish to transfer knowledge to somebody, then you should involve them first-hand in the transfer wherever possible.  It’s very difficult for experts to transfer knowledge on someone else’s behalf.  Seeing is believing, and seeing first-hand is important.  Certainly this may require an investment in travel, but the investment pays for itself in improved performance.  Trying to save some of the money risks losing all of the value, and the key people to involve in the knowledge transfer are the knowledge workers themselves.

Communities and the long (knowledge) tail

---

There is a tendency in many companies to see Knowledge as being the province of the Experts.

As a result, they set up expert centres to look after the knowledge, and expert networks to share knowledge between experts around the organisation.

However one of the big culture shifts within Knowledge Management is the recognition that Knowledge is the province of all Knowledge Workers, not just the experts. Expert networks will access only a small part of the knowledge of the organisation, the remainder will be held by the non-expert Knowledge Workers.

Take the example shown in the graph here. The graph represents 50 workers within an organisation, with varying levels of experience from 30 years to 1 year. Initially the company decides that they will share knowledge by setting up a small network between the four experts - those with 15 or more years of experience (the red bars). Between them, these experts have 88 years of experience.

After a while, the company decides to replace the expert network with a full community of practice, where all 50 of the knowledge workers take an active role. The total years of experience within the community is now 274 - more than three times the experience than that held by the experts alone.

The value of this added experience comes when it is applied to knowledge in the work context. Knowledge is contextual - the application of knowledge changes on where it is applied, and when, and to what. The larger community has seen many more contexts, and the person who gives the advice is not necessarily the person with the longest experience, but the person with the most relevant context. Maybe that person has only been in the company a year or two, but if they have had relevant experience within that short time, they can answer the question, offer the advice, and add real value.

This is the concept of the long tail of knowledge.

The "long tail" is a term that has has gained popularity in recent times as describing the retailing strategy of selling a large number of unique items with relatively small quantities sold of each – usually in addition to selling fewer popular items in large quantities. The long tail of knowledge is a knowledge sharing strategy of offering a huge amount of knowledge transfer opportunities, with relatively small numbers of each particular question/answer exchange. It allows niche knowledge to be sought and found, provided the community of practice is large enough and broad enough.

Large online communities of practice allow access to the Long Tail.

Small expert groups access only the short head.

Roles in the Knowledge Management organisation

---

A fully mature KM organisation will contain several recognised KM positions in order to ensure and facilitator the creation, transfer and re-use of knowledge. Some of these are listed below. Sometimes several of these roles are combined into a single position.

Note that, in this list, I am assuming that the KM organisation is in place, so do not include any task force, or KM implementation team. I have not given names to these roles - each company seems to use a different set of names (some examples are given). Not all roles are required in every organisation - many are optional. Each company will need to do their own knowledge management organisational design - look at the list below as a series of options, not a template.

• There is one role, to monitor, champion and support Knowledge Management for the entire organisation. This can be referred to as the Chief Knowledge Officer, and this role is described here

• The CKO can lead a small team to help with the support activity. The role of that team is described here.

• There is often a senior management role to which the CKO reports, who provides steer, high level support and resource to Knowledge Management, This could  be known as the management sponsor for KM.

• This sponsor could be supported by a high level steering team. The role of this team is described here.

• There can be a similar role in each business division, to monitor, champion and support Knowledge Management within that division. The Samsung version of this role is described here - they call it a Knowledge manager role, other companies call it KM Champion. In Legal firms, this role is often taken by paralegals. Our view of this role is here. 

• In the US Army, there is a role within each operational  unit, which is less about championing KM, and more about acting as the conduit for lessons. This role is described here, and is called the Lessons Learned Integrator.

• In project-based organisations, that run major capital projects, there may be a KM-specific role within the project itself, to monitor, champion and support Project-related KM activities (learning Before, During and after).

The Communities of Practice, or Social networks also require roles, with a whole variety of names (here are 32 options). These include the following.

• The role that facilitates communication between community members on a day to day basis. This could be known as the community facilitator or moderator role.

• The role that takes ownership of the health and effectiveness of the community, and delivery of its purpose and aims. This could be known as the community leader or network leader. In smaller communities, the community leader is the same person as the facilitator.

• The management role which gives direction, steer and high level support to the community or network. This could be known as the community sponsor.

• A series of roles who support the leader, sometimes known as the community or network Core Team.

Often linked with the community are the roles associated with documented knowledge, with knowledge bases, or with areas of knowledge.

• The role who takes ownership for an area of technical knowledge, ensuring that it is well supported, well documented, that the training is in place, that the organisational capability is in place, and that knowledge on this topic is well managed. This role can be known as the practice owner, process owner, functional chief, subject matter expert, knowledge owner, technical authority, or many other names. This role is often combined with network leader, and is described here and here.

• The role of "go to" person for a topic, though without the weight of accountability described above. These are the subject matter experts in the organisation.

• People who are accountable for specific areas of online content - the content owners.

• People who are accountable for managing the entire content of knowledge bases - the cyberarians or librarians (see here).

There are other specialist roles which certain organisations may need, including the following.

• A role, or set of roles, for managing the Lesson Learned process.  This could be known as the Lessons team, or (in the case of the British Army), the Lessons exploitation centre. These roles ensure lessons are collected, validated, actioned, acted on, and closed out. They are accountable for, and report on, the effectiveness of lessons learning.

• A role for collecting observations and converting these into lessons. This is sometimes referred to as an Analyst role, and is often seen in military and government organisations.

• A field role, for collecting observations and lessons, through personal observation or through interviewing or facilitating meetings such as AARs. This role can be known as a Learning Engineer, a Learning Historian, an Operational Learning team, etc.
• A role for facilitating knowledge management meeting processes, such as Peer Assist, After Action Review, and Retrospect. 

Have I forgotten any? Are there additional KM roles in your organisation?

The three-fold role of the Technical Experts in KM

---

The technical experts in many knowledge management organisations tend to have a three-fold role

• Acting as a source of expert opinion for the identification and development of technical practices and procedures.
• Maintaining guidelines and best practices, and validating federal lessons
• Building effective learning communities

In other words, they are accountable for

• Use of their own tacit knowledge
• Ownership or stewardship of the explicit knowledge in their subject matter area
• Creation of the network that stewards the tacit knowledge in their subject matter area

What do you do with your Best Experts?

---

What does your company do with the Best Experts?

In some organisations, the best experts - the most experienced and most knowledgeable staff - are put full-time on the top projects. The theory is that the highest priority project should have the best people working on it.

To me, that's a waste of knowledge. It would be like finding your best general, and putting them in a tank in the toughest battle, on the theory that "they have the most knowledge, let them fight the hardest fight".

As Knowledge Management professionals, we know that there are other ways to get knowledge into a project than by employing the people full-time, and we also know that the more knowledge a person holds, the more she or he is of value to ALL projects. There comes a time when an expert transitions from being a Doer, to being a Teacher; from being an individual who applies their knowledge to do a good job, to an individual who shares their knowledge, and develops the knowledge of others, so that everyone in the organisation can do a better job.

You see this model in many companies. In BP, the most experienced staff become Network Leaders, who have joint accountability for maintaining the knowledge base, and the knowledge assets, and for building the learning networks and communities of practice (they also consult to the most important projects, on a  part time basis). ConocoPhillips have a similar model. In SABMiller, experts from all operating hubs work within “Centers of excellence” who maintain company standards and Best Practice. In Shell, the role of global consultant is the pinnacle of the technical ladder, where the expert consults to many projects, and plays a key role in the Communities of Practice and in developing content for the Shell Wiki.

In each of these companies, the expert has a far greater impact on developing the capability of the organisation, than if they were full-time in an all-consuming project on the far side of the world.

If you Can, Do. If you Know, Teach.