Three Ways Of Learning

Methods of acquiring knowledge can be classified into two major categories:

• 1. Learning from experience
• 2. Learning from what someone else tells you

The second method can be further subdivided into:

• 2a. Learning which requires social interaction
• 2b. Learning which does not require social interaction

In The Organisational Workplace

These three methods of acquiring knowledge are not always completely separated, for example you can read about riding bicycles (2b) but then you still have to actually get on a bike and ride it (1), and you may have someone standing by giving you further advice on how to ride it (2a).

However, in the workplace, the separation of learning into each of these three categories is usually more complete.

Assuming in the first instance that you, the worker, are not on some type of apprenticeship, or internship, then for the most part you are not being paid to learn from experience.

And when it comes to learning something you need to know in order to do your job, everyone's time is considered precious.

So either you can learn what you need to know without social interaction, because it is available in document form, eg on the office intranet, or, it isn't available, so you need to find someone to tell you. When you find this someone, the relevant social interaction will be concentrated on communicating what needs to be communicated, and the other person won't want to spend time watching you trying to learn from experience, or watching you read documentation on the intranet.

Desocialization

Given the dichotomy between learning that requires social interaction, and learning which does not require social interaction, we can categorise knowledge to be learned as either socialized or desocialized.

Knowledge Management

Knowledge Management is defined (in Wikipedia) as the process of capturing, developing, sharing, and effectively using organisational knowledge (Wikipedia cites a source, but what appears to be an online version of that source does not contain that definition, or even the term "Knowledge Management").

This definition, by itself, doesn't necessarily rule out social processes of Knowledge Management, ie:

• Knowledge is "captured" when the learner learns by social interaction with the person who already has the knowledge.
• Knowledge is "developed" when someone who knows something acquired via social interaction extends that knowledge further as a result of their own working experience.
• Knowledge is "shared" via social interaction.
• Knowledge is "used effectively" when people who acquire knowledge via social interaction use that knowledge to do their jobs.

Nevertheless, implicit in most discussions of Knowledge Management, and certainly in most advertisements for Knowledge Management Tools, is that Knowledge Management requires the capturing, development and sharing of information via non-social interactions, in particular, in the simplest case, by writing knowledge down, into a document, and putting that document somewhere, ie on the office intranet.

"Trapped Inside People's Heads"

The worst case of Knowledge Management failure is when some item of knowledge is only known to one person. The only way to do a task requiring that knowledge is for that person to do it. If the person gets sick, goes on holiday, dies, retires or gets another job, the organization is screwed.

A lesser case of Knowledge Management failure is where a number of people in the organisation do "know" the thing in question, but, no one has ever written it down.

If enough people know something, then the so-called "bus-factor" (ie how many people have to get run over by a bus in order to prevent stuff getting done) is larger, and the risk of total loss is reduced.

But, it is still problematic if the only way to acquire certain knowledge is via social interaction. And most Knowledge Management "Initiatives" necessarily include the assumption that the Management of Knowledge should be separated from "inside people's heads", which implies that:

Knowledge Management = The Desocialization of Knowledge

The Benefits of Desocialization

If "bus-factor" is the only motivation for the sharing of knowledge, then purely socialized knowledge sharing can, in principle, be sufficient.

But there are reasons why the full desocialization of knowledge is beneficial:

• Fully desocialized organizational knowledge is properly owned and controlled by the organization, and not by any social grouping of people within the organization.
• Social transmission of knowledge can be cheaper in the short term (because no writing effort is required), but non-social transmission is cheaper in the long term, because, once the writing has been done, it requires effort from only one person (ie the reader).
• Full desocialized information is immediately available to everyone in the organization (subject to restrictions on the distribution of 'need-to-know' information etc). Desocialization enables greater cross-fertilisation between ideas and knowledge from people in different areas of an organisation.
• Some people are less inclined (or able) to engage in social interaction, and sometimes these are the people that have better technical skills in certain areas. Desocialization of knowledge helps those people to make better use of the skills that they have.

Obliviousness to the Socialization of Knowledge

There are various reasons why people in an organization are oblivious to the socialized nature of organisational knowledge, and the consequent failure to desocialize. In many cases desocialization is not regarded as an important or significant goal, with perhaps an occasional observation that it would be nice if someone sometimes wrote important things down, just in case too many people go on holiday all at once.

Here are some factors that may prevent or create resistance to attempts to desocialize organizational knowledge:

• Social interaction is a normal and important element of human existence. Categorising a necessity for social interaction as a bad thing is almost like saying that social interaction is a bad thing.
• Even in the workplace, some types of communication are much more effective when "face-to-face", and in those situations, forcing reliance on email, wikis and ticket systems can make things much harder than they need to be.
• In our personal lives, much of the knowledge that we share with people we know is knowledge that will never be written down (and in some cases shouldn't be written down).
• Actually writing stuff down is hard work, and writing stuff down well enough that it can be easily read and understood by people you don't know is even harder.
• Writing stuff down takes time, and you're not getting paid to do that kind of writing.
• When, as a worker, you need to learn something that requires social interaction, then you will go and find someone who can tell you what you need to know. And once you've done that, there's no need for you to write it down, because now it's in your head, and you know it. (Or if you do write it down, it might only be scribbled notes for your own personal benefit, to remind you of any details which you might forget.)
• Depending on the type of knowledge, and the subject of that knowledge, there may be no convenient tools for writing down what you know, and there may be no obvious "place" to put any documentation that you happen to write. Also, when there appears to be a conflict between any existing documentation and what appears to be the current state of socialized knowledge, there may be no straightforward process to highlight such conflicts and resolve them.
• Some knowledge is so essential to the workings of the organization that the social propagation of that knowledge is a high priority, and anyone who needs to have that knowledge will engage in whatever social interactions are required to acquire it. It's hard for anyone involved to imagine a situation where the knowledge in question won't be socially propagated to whoever needs to know it, so there's little motivation to go to the trouble of writing it down properly.

Corollaries to the Equivalence of "Knowledge Management" and "Knowledge Desocialization"

• Every time that someone in the organization socially interacts with someone else because they need to know something, an opportunity to detect and fix a failure in Knowledge Management has been lost.
• If certain things can only ever be known by asking one of a certain group of people, then a chronic Knowledge Management failure is occurring.
• An effective way to detect and mitigate Knowledge Management failures could be to follow every work-related social interaction in an organisation with a post-mortem, ie to ask the question "Why did I have to engage in a social interaction to find out what I needed to know?" (or conversely, "Why did that other person have to socially interact with me in order to find out what he/she needed to know?").

Appendix: Software Source Code and Database Schemas

Software Source Code

Software source code seems, on first look, to be something that is very desocialized, because, by its very nature, it is written down.

However, the primary audience for software source code is the computer system that is going to run the software. Just because the computer system can read the source doesn't mean that any person can read the source code.

Other developers are only a secondary audience for the source code, and source code can very easily enter a state where it cannot be read very easily by someone encountering it for the first time, even if that person is an experienced software developer.

Some software enters a state where no one understands the source code, in which case you have already achieved a bus-factor of zero, which is not a good thing.

More commonly there might be one developer who understands, from his/her experience of the software, most of what is going on. So this developer can be tasked with improvements, bug fixes, etc.

If other developers need to work on the software, most likely those developers will consult, via social interaction, with the current developer who "knows" the software.

In this situation, the requirement for social interaction implies the existence of socialized knowledge, ie knowledge which has not been desocialized, which therefore constitutes a failure of Knowledge Management.

In other words, even though writing the source code involved writing a whole lot of stuff down, it was not written down in a way that enabled the desocialization of knowledge about the software application. The names of classes, variables and methods may not have been chosen to be descriptive enough and/or there were things which should have been written as comments but which weren't.

In many cases it's not just the implementation of the software which fails to be desocialized: often the requirements of the software have not been documented sufficiently, so social interaction is required to understand what the software is actually for. (Indeed sometimes one can understand how certain software works more easily than one can understand its purpose: "The program seems to be reporting the number of hoojamaflips wrongly" "Oh, I can see there is a one-off error in the accumulation logic - I can deploy a fix tomorrow. By the way, what is a hoojamaflip?" "Call Doug in the Purchasing Department – he knows that a hoojamaflip is.")

Database Schemas

Database schemas are somewhat, but not exactly, like software application source code.

Most database schemas are not that large, if considered in written form, and compared to the amount of source code that might exist, for example, in a business Java application.

Nevertheless, database schemas can come into that category of information which is vitally important to the operation of the organization, and yet there are fundamental facts about the database which have never been written down.

A common problem with software source code is that objects in the software are given names, and these names later turn out to be less than ideal. Unfortunately the costs and risks associated with changing those names discourage attempts by developers to change them, and as a result the source code is full of names of things that don't quite mean what they say.

This problem is even worse with databases, since an organizational database can be used by so many different applications that things like table names and column names can never be changed, no matter how misleading or non-descriptive they may be.

Unlike most modern programming languages, databases often lack features for adding "comments". Or, if there are such features, they are risky to use. For example, comments can be added to the live production database. But this requires the executions of SQL against that same live production database with a database user that has write access. Due to the extreme importance of the live production database, SQL statements cannot be executed via a database user with write access without sign-off from three levels of management. Documentation may be "important", but of course it's never as important as up-time of the live production database.

In practice, the existence of "comment" features in SQL databases is a distraction, and the best solution to Knowledge Management for Databases is to have a tool which maintains information about each and every element of a database schema in some location other than the database itself (and which limits its interaction with the database to queries which help determine the list of things for which documentation is or might be required).