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

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.