Managing Knowledge Across Boundaries

[Based on Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge Across Boundaries by Paul R. Carlile]

Communication can be seen as the process of transferring knowledge. Effective communication requires an effective understanding of knowledge management through various knowledge boundaries. Here I will describe three knowledge boundaries: syntactic, semantic and pragmatic. These three boundaries are explained through increasing magnitude of difference, dependence and novelty. Understanding of these concepts allows an organization to better manage knowledge specifically in the new product development process and, arguably, in any circumstance. This saves time and money while ensuring accuracy and satisfaction.

At each boundary there is some level of difference, dependence and novelty. Difference is a difference in the amount of knowledge and/or type of knowledge. Dependence is the connection of different knowledge to accomplish a task. Novelty is how different the knowledge is from what is currently known. For example, a front-end and back-end engineer will have a difference in what programming languages they know, their knowledge is dependent on each other to create a web site and there will be some novelty as they move between different projects that have different requirements. These three parameters would change in magnitude were we looking at a back-end engineer and marketer.

The fist major boundary is syntactic. In short, this is the language (defined broadly) that each person speaks. Every role in an organization has its own jargon and common lexicon, even more if cultural differences are involved. Syntactic boundaries make knowledge transfer difficult as there is no common lexicon. Thus, to solve syntactic boundaries, a common lexicon must be developed. This is not to be underestimated; it may take more effort than it initially may seem. For our engineer and marketer, they need to develop a common set of words to communicate with each other.

This leads us to the next boundary: semantic. Having a common lexicon is a great first step but now there must be a common understanding to avoid misinterpretation. Semantic boundaries focus on translating knowledge. Here it is crucial to make implicit knowledge explicit. “It is not just a matter of translating different meanings, but of negotiating interests and making trade-offs between actors.” To solve semantic boundaries, common meanings and interpretations must be developed. The engineer and marketer must develop a common understanding of their lexicon – this can require making new agreements. Essentially, this is exploring meaning. Boundary spanners can act to mediate people in conflict here – spanners can be people, activities or processes.

Lastly, the pragmatic boundary. Sometimes a common lexicon and understanding is still not enough because of conflicting interests between people. Pragmatic boundaries look at how shared meaning is transformed into the actual product/service. To solve pragmatic boundaries practical and political effort is needed. Here the engineer and marketer must work through their specific interests in the project to create a common interest. Boundary objects such as prototypes, drawings and wikis can be helpful because they are malleable enough to change but solid enough to define a direction.

Any activity in an organization with more than one person has these knowledge boundaries. A clear understanding of syntactic, semantic and pragmatic knowledge boundaries allow for effective communication, correct outcomes and satisfied people; this is an iterative process that will get better the more a team works together.

If you don’t understand the relevance of this topic, see the infamous ‘how not to design a swing’ cartoon.