Tacit and semi tacit knowledge: Overview

By Gordon Rugg and Sue Gerrard

Tacit knowledge is knowledge which, for whatever reason, is not explicitly stated. The concept of tacit knowledge is widely used, and has been applied to several very different types of knowledge, leading to potential confusion.

In this article, we describe various forms of knowledge that may be described as tacit in the broadest sense; we then discuss the underlying mechanisms involved, and the implications for handling knowledge. The approach we use derives from Gordon’s work with Neil Maiden on software requirements (Maiden & Rugg, 1996; reference at the end of this article).

In brief, the core issue can be summed up as whether people do, don’t, can’t or won’t state the knowledge. If they do state it, it is explicit knowledge, and can be accessed via any method. If people don’t, can’t or won’t state the knowledge, then it is some form of semi-tacit or strictly tacit knowledge, which can only be accessed via a limited set of methods such as observation, laddering or think-aloud. Because of the neurophysiological issues involved, interviews, questionnaires and focus groups are usually unable to access semi-tacit and tacit knowledge.

The image below shows the key issues in a nutshell; the rest of this article unpacks the issues and their implications. There are links at the end of the article to other articles on the methods mentioned in the table. The image below is copyleft; you’re welcome to use it for any non-commercial purpose, including lectures, as long as you retain the coplyleft statement as part of the image.

Knowledge that people do state explicitly is relatively straightforward to handle, though it still needs to be treated with caution because of the range of well-documented biases and shortcomings of human memory.

Knowledge that people don’t state explicitly may take several forms, caused by different mechanisms. A key point about this category is that people are perfectly willing and able to state the knowledge explicitly if asked about it. However, they are unlikely to mention this knowledge in interviews, questionnaires, or focus groups, for reasons described in more detail below.

Knowledge that people can’t state explicitly may also take several forms, caused by different mechanisms from those involved in don’t knowledge. A key point is that people are unable to access can’t knowledge, even if they are willing, and even if their lives literally depend on it, as in the case of gathering requirements for safety-critical systems.

Knowledge that people won’t state typically involves knowledge that the person involved is able to articulate; the key feature is the person’s unwillingness to articulate it. This unwillingness may be due to various reasons, including professional confidentiality, or the topic being taboo, or to conceal unethical or illegal activity. This knowledge can be accessed to some extent indirectly, via indirect observation or via projective methods.

Each of these four categories has different implications with regard to eliciting and handling the knowledge involved. Interviews, questionnaires and focus groups are able to handle do knowledge, but have only intermittent success with don’t knowledge, and are unable to handle can’t knowledge or won’t knowledge.

In the next articles in this series, we will look in more detail at the mechanisms involved in each of these four categories, and at the implications.

Conclusions and further thoughts

In this series of articles, we focus on the implications of semi-tacit and strictly tacit knowledge for eliciting knowledge from people. There are also significant implications for other areas, such as:

• How best to represent the different types of semi-tacit and strictly tacit knowledge (e.g. verbally, or schematically, or via images, or via senses other than visual)
• The interaction between these knowledge types and types of human error; for instance, compiled skills are particularly liable to causing strong but wrong errors
• Mapping these knowledge types onto techniques for teaching and learning; for instance, compiled skills will typically require at least two weeks of practice to become properly compiled, whereas incidental learning may occur within seconds.

We have addressed some of these issues in previous articles. For instance, this article looks at the mapping between types of measurement and appropriate choice of visualisation, and this article looks at how the knowledge types above map onto teaching and learning methods.

We will address these issues again in later articles. We hope you have found this article interesting and useful.

Links and references

Card sorts: A short tutorial, and an in-depth tutorial.

Laddering: A short tutorial, and a longer tutorial (PDF download).

Observation:

• An overview
• The STROBE method for making inferences about a working environment from observation.
• Identifying issues with the built environment, part 1
• Identifying issues with the built environment, part 2

Reports: An overview that includes think-aloud, critical incident technique, hard case technique, and scenarios.

Content analysis:

• A simple approach
• An overview of content analysis methods
• Visual representation of texts

Associative networks:

• A brief overview
• Implications for education
• Types of pattern matching

Requirements:

• A series about the design process
• A series about about architecture and design
• User Centred Design

Aesthetics and design:

• An overview
• A more detailed discussion l
• Beyond the Golden mean: other regularities in aesthetics

Reference to original article:

The Maiden & Rugg ACRE reference is: Maiden, N.A.M. & Rugg, G. (1996). ACRE: a framework for acquisition of requirements. Software Engineering Journal, 11(3) pp. 183-192.