Nancy Dixon: Profiles in Knowledge

Originally published on June 21, 2018

42 min readOct 9, 2018

This is the 23rd article in the Profiles in Knowledge series featuring thought leaders in knowledge management. Nancy Dixon is a leading consultant, writer, and speaker. She wrote one of the essential KM books, Common Knowledge: How Companies Thrive by Sharing What They Know.

I have known Nancy for a long time, and have great respect for her expertise in conversational techniques and her skill as a facilitator. We have enjoyed spending time together at many KMWorld, APQC, Midwest KM Symposium, SIKM Leaders Community, and Columbia University events. We have both been guest lecturers in Columbia’s IKNS program.

Profiles

1. LinkedIn

I work with organizations to create conversations where knowledge transfer/sharing happens, where knowledge is created, where innovation arises. I believe trust is the bridge on which knowledge travels between people so I focus on ways to create trust and a safe space for conversation, whether online or face-to-face.

I help groups in organizations have more productive conversations to address on-going problems or to more effectively share their knowledge, whether those conversations are in a team meeting, a conference setting or the retrospect of a project. The key is not a better meeting agenda, it is in creating an environment where members feel safe to offer ideas or lay out concerns. I design gatherings where trust is prevalent.

I work with managers who want to open up the conversation in their unit and who are ready to involve their employees in problem solving. If you are planning a meeting in which you want the organization dialogue to provide new answers, then you need more than a facilitator. You need a conversation Architect, that is, someone who can strategically design the format, space, time, and environment to achieve the results you want.

How to design the space
How to configure the size of groups
How to frame the issue so it is open for new ideas
How to build a culture of trust
How to harvest what is learned or created

My work takes me around the world and I love the travel. I have come to know China, Singapore, Hong Kong, England, the Netherlands, Sweden, and many parts of the African content.

2. Common Knowledge Associates

A lot of people talk about “knowledge sharing” but that’s only half the task. It doesn’t make any difference how much knowledge is shared, if nobody uses it! So I focus on knowledge transfer, which includes both ends of the exchange — the knowledge originator and the receiver. In order to design those processes, I’ve had to learn a lot about the science of learning, because both ends of the transfer require learning.

Originally, I got interested in learning because I had a young son who was dyslexic. I could tell he was a capable learner, but not the way the schools wanted him to learn. I had to figure out how to help him get the knowledge he needed using very different methods than the public school offered. So I did graduate study in neurology, psychology, and learning theory. I had the opportunity to learn first-hand from some of the greats, Chris Argyris, David Bohm, Reg Revans, Don Schon, and Karl Weick. They helped me gain an in-depth knowledge of how, not just individuals, but groups and organizations learn.

Organizational Learning became my life’s work, first as a researcher and professor at the University of Texas, then later at the George Washington University and for the last fifteen years as a consultant using that knowledge to help organizations build effective knowledge transfer processes. And to this day how groups learn and transfer knowledge remains a totally fascinating subject for me!

Focusing on knowledge transfer I get to wear a lot of different hats:

Frequently I’m asked to design a knowledge transfer strategy for an organization,
Often I facilitate knowledge transfer meetings between two teams or between an expert and those that need that expertise,
I’m asked to conduct knowledge assessments to find out what knowledge is the most critical for an organization to focus on.
One of my favorite requests is when I’m asked to design retreats and conferences where the leaders want to take advantage of all the knowledge in the room, in order to address a difficult issue the organization is facing.

Examples:

At heart I’m a writer and have written eight books and over 80 articles about how to make transfer happen in organizations. I’m also a runner, a biker, a committed yoga practitioner, a mother of two and a grandmother of three. I have the great privilege of living in one of the most exciting cities in the US — Austin, Texas — the live music capital of the world!

3. Salzburg Global Seminar

Dr. Nancy Dixon is a former academic turned consultant. Before starting her own company in 2000, Common Knowledge Associates, she was a tenured professor and Department Chair of Administrative Sciences at the George Washington University, and before that a professor at the University of Texas. She has a passionate interest in creating conversations that exploit the collective knowledge of an organization in order to address difficult organizational issues and to spur innovation. Her research has focused on how to create psychologically safe environments for both large and small group conversations. In her consulting practice she facilitates small and large scale learning events that involve cross-boundary stakeholders who are facing complex issues. She helps organizations move beyond a series of presentations to engage people in active learning processes. She has worked with a wide range of corporate, government and non-profit organizations, including Huawai Technologies Ltd., Bose, ConocoPhillips, Ecopetrol, Netherlands Railroad, the US Army, the Defense Intelligence Agency, USAID, United Way World Wide, The World Bank Group and NASA.

Her facilitation skills and processes are able to bring together disparate groups and individuals so that they can find common ground and achieve breakthroughs in performance.

4. KM4Dev

5. Lucidea’s Lens

Background

Education

Ph.D. North Texas State University, Denton, Texas
M.A. East Texas State University, Commerce, Texas
B.A. University of Kansas, Lawrence, Kansas

Experience

2000 to present Principal, Common Knowledge Associates
2012 to present Adjunct Professor, Department of Industrial and Systems Engineering, The Hong Kong Polytechnic University
1992–2000 Professor, Administrative Sciences Program, The Graduate School of Arts and Sciences, The George Washington University, Washington, DC
1997–2000 Director Administrative Sciences Program, The Graduate School of Arts and Sciences, The George Washington University, Washington, DC
1988–1992 Associate Professor, Human Resource Development School of Education, The George Washington University, Washington DC
1980–1988 Assistant Professor, Human Resource Development, College of Education, The University of Texas at Austin, Austin, Texas
1979–2009 Consultant to corporations, not-for-profit and government on organizational learning and knowledge management
1983–84 Internal Consultant, Tandem Computer Company, Cupertino, California

Posts

1. Twitter

2. LinkedIn

3. SIKM Leaders Community

KM Solutions: I think too many KM programs get set up without a clear understanding about what specific problem KM is supposed to solve. Starting with the problem is always the right step. That was my initial discovery that I wrote about in Common Knowledge — what kind of knowledge is involved: tacit, implicit, or explicit? Is the task it serves the same every time it is implemented, or is it in a different context each time? This cube shows the possibilities.

4. Blog

The early thinking about how we should manage this knowledge asset, was to use technology, taking advantage of the growing capability of intranets. There was an effort to collect all the important knowledge that an organization possessed into one database. The analogy was of a warehouse or a library. People were to put knowledge in the warehouse and those that needed it could take the knowledge out and use it. And much like the contents of a real warehouse, knowledge was thought of as stable. That is, you could put knowledge in the warehouse today and get it out in six months or even two years later without any degradation of its value. In this first era of knowledge management, knowledge repositories were the strategy of choice and they contained best practices and lessons learned as well as technical documents.

Repositories were so ubiquitous that in many organizations the term “knowledge repository” was synonymous with “knowledge management.” And since IT necessarily built the repositories, KM was frequently placed under the IT department.

There was one further assumption, which was that employees would seek out the captured knowledge and use it. But of course, in many organizations people did not readily submit knowledge nor were they inclined to take it out of the warehouse. Managers determined they would have to incentivize employees to get them to use the knowledge. Lots of schemes were put in place, from offering frequent flyer points for input to requiring teams to go through the database for ideas before starting a new project — and checking a box in the project plan to prove they had looked the ideas over.

For the most part these databases, even with incentives in place, did not produce much improvement. Front line workers had little interest in putting things in or taking things out.

Ten Big Ideas of Knowledge Management

Connection before Content
Circles Connect
Knowledge is Both Created and Shared in Conversation
Asking Opens the Door to Knowledge
Small Groups as the Unit of Learning
Learn in Small Groups — Integrate Knowledge in Large Groups
We Learn When We Talk
Learning From Experience Requires Deliberate Reflection
Different Types of Knowledge Need to Be Shared in Different Ways
Knowledge Sharing is Sustained by Reciprocity

5. AOK STAR Series Dialogue, June 2003: The Creation and Reuse of Project Knowledge

Introduction

Capturing and re-using lessons learned from project teams is an idea that organizations find very attractive, but have found extremely difficult to make work.

The idea is appealing because projects are costly and lessons learned from other projects could, potentially, improve quality as well as save time and dollars. In the hopes of achieving that goal many organizations have purchased software-based “Knowledge Management” systems. While this technology offers remarkable capability, it seldom works as anticipated. The over-riding difficulty is that the lessons that populate most databases are mundane and of questionable value to users. Too often lessons learned databases are filled with homilies such as:

The most critical task is for the team to get its priorities straight before it begins
The team has to remain flexible to meet changing conditions
It is important to keep partner organizations well informed.

Though such lessons may be accurate reflections of what a team has learned, often from its own painful experience, few people find it helpful to read such abstract advice.

These organizations have made considerable investments in technology, but have failed to make concomitant investments in what the systems access. It is, however, possible to wrap around the technology, the systematic implementation of a social process necessary to construct lessons learned that are of value to others.

Social processes are the development of relationships, reflective conversations, probing questions, and in-depth interactions that are the backbone of knowledge sharing.

The idea that a lessons learned database must be married to social processes is not new, almost every description of knowledge management acknowledges that need. Unfortunately there has been a scarcity of solutions offered about how to actually make that marriage happen. Drawing on five years of work with organizations implementing knowledge management I describe here, a systematic way to link social processes with a lessons learned database to make the lessons relevant and to get them into the hands of team members who can re-use them.

I have designed this system for teams that are working on projects that are of considerable significance in terms of dollars or outcomes. The meetings and interactions I outline take time, so the outcome must be worth the time expenditure. Figure 1 illustrates the two considerations that make the process worth the effort. First, if the context is continually shifting due to changing technology, new markets, economic fluctuations, and innovations, then there is a critical need to continually learn from what project teams are doing in the field. Secondly, if the dollar cost of projects is high then a single lesson from another team can make a competitive difference.

To implement the approach outlined here takes considerably more time than what has become the norm for lessons learned which is one team member spending 3–4 hours at a desk writing up the project to send into the database. While leaving this chore to one person is certainly low cost, it is not surprising that there is little ROI. The true cost is the time wasted by 30 or 100 people who retrieve lessons learned that yields little useful help. Wasted time, poor morale and disillusionment in the system, are but a few of the consequences of a system that does not take the user into account. In thinking about the issues of knowledge creation and re-use, it is useful to have a way to differentiate the players involved. I will refer to the team that conducted the project, as the “originating team,” and the team that might make use of what the originating team learned, as the “re-use team.”

A basic premise of this system is that the originating team needs to gain the perspective of potential re-use teams.

Knowledge creation and re-use is illustrated in Figure 2. Knowledge is created on the right hand side and re-use occurs on the left. The right side of this figure represents the supply side of knowledge, that is, how knowledge is created in an organization. On the left is the “demand” part of a supply and demand equation. Without demand the supplies just sit there. Unfortunately, this is what happens with too many databases that are filled with lessons learned — there is very little demand. The demand side shows a systematic process that supports the active seeking of knowledge and assists the translation to facilitate its use. Knowledge creation and re-use is a circular process. There certainly can be no re-use without the creation of knowledge and likewise there is no need for knowledge creation unless the intent is to re-use what was learned. Starting my description of the system on either side would seem to diminish the importance of the other in this chicken or egg configuration. But given the need to make I start I will do so with the supply side.

Supply Side

Supply A — Sensemaking What did we REALLY learn?

The first and certainly the most critical step in making lessons meaningful is that the originating team, themselves, figure out what they have learned. Sensemaking is the basic process through which team members create shared meaning. It requires that the team come together to thoroughly and systematically work through what they have learned in a no-holds-barred, face-to-face dialogue. To make “sense” the team must take into account their actions, external events, decisions made, costs, and outcomes achieved, both intended and unintended. The world that teams function within is complex with multiple variables impacting the outcome of their work. It requires the whole team, talking together, to make enough sense to learn from their experience. The meeting is facilitated by a neutral professional who is able to listen for assumptions of which the team may unaware and who has the skills to probe for the reasoning behind the team’s actions.

Sensemaking is a knowledge creation process, in that the team members grow new understanding through engaging in the discussion — understanding greater than that which they brought into the room. Each team member leaves the meeting with a broader and more accurate mental picture of the relationship between the team’s actions and the outcomes achieved. Without this critical discussion each team member will certainly develop and retain the learning from his/her specialty, but has no way to verify, correct, or expand that understanding to reflect the reality and the complexity of the outcomes that the team has achieved — whether positive or negative. In other words, the multiple perspectives of team members provide correction to the cognitive errors to which all humans are subject.

The purpose of the sensemaking meeting is to develop knowledge that can guide the future actions of the originating project team as a unit. But it also serves to guide the future action of each individual team member as they move on to other teams, working on new projects. The sensemaking meeting begins the spread of the lessons learned from the project by providing each team member with a fuller and more accurate understanding of the relationship between the team’s actions and outcomes.

The target audience of the sensemaking meeting is the originating team itself — the team that has lived this experience. This is not a meeting intended to generate reports for others about what was learned or accomplished. There are two reasons for keeping the focus of this meeting on those who were involved. First, learning requires team members be open, honest, and self-critical. If team members anticipate that what they say will embarrass them or others, they will, quite naturally, guard what they say, speak in abstractions and fail to raise difficult issues — all of which decreases the potential for their own learning. Secondly, most of the notes, flip charts, and even minutes produced in a sensemaking meeting are of little utility unless you were there. In Common Knowledge I used the US Army’s After Action Review as an example of sensemaking, referencing the Army’s policy of no reports and no retribution. I referred to this kind of meeting as Serial Transfer, implying it is transfer that occurs within a team for the benefit of that team’s future actions.

The sensemaking process in this design is initiated at the end of a project. For projects that last months or even years, it is essential to have interim sensemaking meetings, as well as the comprehensive sensemaking meeting at the end of the project. Such meetings should occur at natural phases of the project or at regularly scheduled times. Far too much is lost or mis-remembered if months have gone by without the team making sense of what they are learning. The knowledge gained from interim meetings needs to be kept for use at the final sensemaking meeting.

The sensemaking meeting is necessary preparation for the next step, translation.

A team cannot determine what and how they should share with others, until they know what it is that they have learned.

Supply B — Translation What will be of the most value to others from what we learned?

The idea of the translation of lessons learned is perhaps most easily understood through an analogy to the early versions of computer manuals — the ones written by the same technicians that built the machines — the manuals were nearly useless. It often seemed like the reader had to know nearly as much as the technicians who wrote them, to get a question answered. Computer manuals have greatly improved over the years, and the greatest improvement has been that someone else writes the manuals — someone who thinks like a customer, not a hardware engineer. The same kind of translation problem shows up in most of the lessons that populate lessons learned databases — they are written from the perspective of the people who lived the experience, rather than the perspective of the potential user.

The second step is a translation meeting that is held to figure out how a re-use team might reason about what has been learned by the originating team. The meeting brings together a few members of the originating project team with a few colleagues from other projects who take the role of potential users. The goal of this meeting is not to persuade their colleagues to use the lessons, but rather to listen carefully to determine what re-use teams would need to know about this project and its lessons if they were to make use of the knowledge — it is a listening task. A facilitator can help to create the context for listening as well as help to focus the questions.

The originating team members, having taken part in the earlier sensemaking meeting, are able to tell the “whole story” of the project, rather than only the part they have themselves experienced. Even so, they will not have answers for all the issues raised in the translation meeting, but of course for the translation meeting, answering is not the critical task, rather, it is learning from their colleagues what the re-use issues are. After the meeting the originating team members have the opportunity to return to their colleagues to gain the further understanding needed to produce user-focused knowledge.

It is an interesting phenomenon that the originating team members in the process of explaining the project to others, also learn. As the old adage goes, “to really understand something, you have to teach it.” For example, the originating team members learn from the potential re-use members about the assumptions they were making of which they were unaware; they learn that others interpret the words and phrases they use very differently; and they even learn what does not need to be said. There is both a process for drawing these insights out of the meeting and skills needed to probe the questions of the questioners.

Ideally, those who come to help in the translation are drawn from the community of practice that the originating team is embedded within. Even when such a community is not formalized, project team members know others who would be interested in what they have been doing on the project. Offering and receiving this kind of help builds the community and increases the probability that these colleagues will contact each other in the future to share their thinking and ideas. A sharing culture is built by many such small acts of sharing that go on among people who are facing similar problems and tasks.

The translation meeting is also a part of the spread process, as was the earlier sensemaking meeting. The spread occurs when those who have come from other projects incorporate the ideas they have absorbed in the translation meeting back into their own projects, and when they talk about what they have learned to colleagues who are working on yet other projects. It is in this gradual and incremental way that innovative ideas are spread within a community.

Supply C — Spread — How to share what was learned with others?

The output of the translation meeting is used to re-format the knowledge, originally produced in the sensemaking meeting, into a useful product for the benefit of re-use teams.

One of the members of the translation team now takes on the task of formatting the lessons into a usable product. Often this product is a written document that will be sent to a lessons learned database. However the product may take a different format, a presentation at a conference, a videotape, or an up-coming peer assist. This is not a trivial task; it may require conversations with other members of the originating team to clear up a point or to obtain a needed document. It may require adding more context or discussing unresolved issues. Almost always it means adding examples and stories to make the actions more concrete for the re-use team. It is more than a writing task; it is a task that requires thinking like the customer.

One of the challenges is how to embed the hopes, values, and emotions that were a part of the project in a written product. First person stories, in the language of the people that lived the experience, are helpful and so are pictures and brief video and audio clips. With the increased home use of digital cameras and video recorders, there is little technical difficulty in obtaining such clips. They do, however, still require considerable extra time and effort.

For some projects it is useful for the format to be constructed as modules so that lessons related to different parts of the organization can be routed to appropriate people. For example, there may be specific lessons related to communication or measurement.

Each product that is completed has assigned to it the names of two or three “ambassadors,” team members who are willing to make themselves available to others to talk about the project. The best ambassadors are people who have been in on both the sensemaking and the translation meetings, so they can carry the whole story. Ambassadors are available for presentations, to answer questions by phone, to meet with new teams for assistance, in other words, to advance the spread of the knowledge from this project.

The product that has been formatted is placed in a database so that others can find it on an as needed basis. However, placing it in a database alone does not constitute spread. Spread is the movement of knowledge from person to person and that happens primarily through relationships.

There are two readily available sets of relationships that have been established through the steps of this process. The first are those colleagues who came to the translation meeting. The completed product can be sent (emailed) to them with a personal note asking them to forward it on to a few people who they feel could benefit from it.

The second group are the members of the originating team those who were a part of the originating sensemaking meeting. Again the request is made for each to send the product on to a couple of people for whom it seems a good fit. Returning the product to the originators serves a second purpose, it honors their contribution to the project and it assures them that the final product does not embarrass them — both are useful, to be assured and to be appreciated.

For both of these efforts the key is not to send the product to as many people as possible but to send it to the few people who the sender believes are likely to be interested in it. Potential users are much more likely to take the time to look at lessons learned that come from someone who knows them and whom they believe has their interest at heart. It is the personal recommendations of trusted colleagues that piques the interest of others in a lessons learned.

This is the way a piece of juicy gossip spreads. It spreads when the gossiper calls someone who is acquainted with the central character of the story and who would therefore be interested in hearing it — gossip is targeted not broadcast.

Spread begins between members of the sensemaking team, it grows through the translation team’s interaction with other projects and it enlarges farther yet when the product is sent to a targeted group. Placing it in the database with appropriate keywords is a still further element of the spread.

The spread of what has been learned travels primarily between trusted colleagues.

Demand Side

Demand A Scanning Who has had recent experience that might relate to our project

Knowledge sharing begins with a request, not with an answer or a solution. I could have started this paper with the Demand A by describing a team that is asking for knowledge and been more chronologically correct. No matter how much knowledge is presented at conferences, held in databases, or emailed to colleagues, knowledge won’t be re-used unless a team has a need, something they are struggling with.

Managers sometimes tell me that people in their organization have a problem with sharing knowledge; but when I look closely at what is happening, more often than not, the problem that I see is that people are not “asking.” The organization has an “asking problem” not a sharing problem. When people ask, the sharing problem becomes moot.

Most organizations have an “asking problem” not a “sharing problem.”

How organizations talk about “asking” is critical. When company officials admonish professionals, “Don’t be afraid to ask for help” their words actually work against asking. It is not “help” that is required because professionals, working on projects, are already skilled and competent otherwise they would not have been given the assignment. “Help! Help! is what Pearl, of the old silent film era, shouts while being tied to the railroad tracks. It denotes helplessness. No competent professional wants that image attached to his or her performance. What professionals do need is to be able to tap into organizational knowledge that is growing and changing — to tap into what others are learning from their on-going experience. I have labeled this step “scanning”, which connotes an active seeking for something of value.

The faster the rate of change in an industry the more critical is the need for scanning. The salient question is, “In the last few days/weeks/months, what has been learned in the field by our peers that could inform how we move forward on this project?” In one telecommunications company I worked with, before an engineer would spend hours fixing a software “bug” he had just discovered, he would call around to see if some one had already fixed it. In this industry, versions of software often overlap each other, a customer might be trying out one version, while the next version is in the final stages of development and yet a third is in the works behind the scenes. In this company, customers, developers, and researchers were all finding and fixing errors, so without constantly checking with each other to see if the error had already been found and fixed an enormous amount of time would have been wasted. Telecommunications is probably at the extreme end of the change curve, but no industry is immune to changing customer demands, technology, regulations, competitor in-roads, and new markets that mean new ways to accomplish tasks are being invented in the field. A team scans by asking, “What has already been learned that we can take advantage of?”

Substituting the term “scanning” for “help” is not sufficient to make “asking” happen of course. It is also necessary to have a process, such as described in this paper, in place to legitimize and facilitate the asking. That process begins with the scanning meeting.

There are many avenues that team members can use to tap into the knowledge of the organization.

Locating peers who would have useful knowledge through the organization’s “yellow pages” software.
Asking the leader of the community for the names of teams who have done something innovative
Searching the Lessons Learned Database with keywords
Contacting colleagues met through translation meetings

All of these avenues are ways to locate knowledge within the team’s community of practice. Communities of practice are made up of employees who work on similar tasks, using similar tools and who face similar problems. A community may be very loosely structured, with employees only coming in contact with each other at company meetings or professional conferences. However, increasingly, communities of practice are structured more intentionally with an identified leader, a librarian, and scheduled meetings or conference calls among members. Some communities of practice are spread across geographical areas and some more localized, some have hundreds of members and some a mere handful. Whether the community is loosely or more intentionally structured, it is the container of the organization’s tacit knowledge about a specific topic. And it is to this community that the re-use team must turn to find the knowledge that will be of interest to them.

Scanning starts with a team meeting to identify potentially useful knowledge across the organization. For example, a team might ask, “Who has worked with this contractor before? On this particular problem? With this technology? In this country? With this size of data set?” The team members will have ideas about who might have useful knowledge within the community because they will have been the recipients of lessons learned that other teams have produced through their sensemaking meetings. And they will themselves have served on translation teams in the Supply side of this process. So the re-use team does not start their scanning with a blank slate. In a community that has been actively translating and spreading lessons learned, re-use team members may be adequately apprised of potentially useful knowledge to begin the process of contacting them.

Emailing colleagues to ask “Does anybody know..?” has become a familiar practice in organizations. Often it is used as a way to quickly obtain the answer to a specific, explicit question, for example, “Does anybody know which part to use to repair the pump on the S-34B?” It serves equally well as a first step in the search to locate tacit knowledge. Although email is a poor conveyer of tacit knowledge, a “Does anybody know.? “ message can identify who might hold such knowledge, “We are looking for someone who has worked with client X.” A follow-up phone call can then help the team decide if that source has knowledge that is potentially useful to the team.

Many communities of practice have a “leader.” This is the person in the community who is a “connector.” It is a member of the community who knows who knows. Leaders, may not themselves be acknowledged experts, but they know what different project teams are working, what problems they have faced, and what solutions they have come up with. In some communities the leader is an acknowledged role, appointed or chosen by the members. In other communities leaders are members who find themselves in positions that give them access to what is happening (a purchasing agent who buys rotating equipment served this role in one community) in still other situations people who are just natural “connectors” find themselves playing that role. The re-use team that is scanning for knowledge can ask the leader, “Who has done something similar?” If the leader does not know, he or she probably knows who would know!

Teams can search the Database that contains the products derived from the Supply side. Searching with keywords or free text, the team can locate lessons written by other teams. Reviewing these lessons can help the team determine whether the originating team will be able to provide them useful tacit knowledge. It has, after all, been developed with potential re-use teams in mind.

The initial scanning using the team’s own resources, email inquires, the community of practice leader and the database yields a list of potential knowledge sources that are related to various topics the re-use team will be addressing. However, each of these scanning tools only gets the team the identification of a possible source of knowledge. It does not serve up the knowledge, for that the team will need the sixth step of this process, translation.

Demand B — Peer Assist How can we “mine” what others have learned?

Peer Assist can be thought of as another translation task, similar to the one on the supply side. In that previous translation meeting the task was for the originating group to translate what they had learned for the benefit of potential re-use teams. The translation task on the demand side calls for the originating team to again translate, but this time the translation assignment is very different — now they are called upon to translate what they know for use in a specific context.

This is accomplished in a meeting between the re-use team and the originating team. The re-use team, having identified an originating team that they believe could inform their project, invite the team to a meeting — often for a day or two. Such meetings do not usually involve the whole originating team, more commonly it is two or three members who attend, often those who were selected as ambassadors. The meeting is held at a mutually agreed upon location, typically at the site of the re-use team where documents and people are readily accessible. But I have also seen such meetings held before a conference that both teams might be attending.

The re-use team is working in a different context than was the originating team, with different players, and maybe even different goals. The re-use team is asking the originating team to reach deep into their experience to pull out those ideas that fit the re-use situation, perhaps shaping that knowledge into a construct that even they have never put together before, a construct tailored to the re-use situation. They are asking the originating team to share tacit knowledge that goes far beyond the explicit knowledge they have already written up and placed in the database. Dave Snowden is fond of reminding us that “We don’t know what we know until we need it.” That is a viable description of what goes on in a translation meeting. An originating team may not know they have the answer to a particular question, until they are faced with it in this meeting.

An originating team could, of course, come to the meeting and simply make a presentation about what they originally learned, but if they did so, much of what they presented would not be applicable to the re-use situation. And even for that portion that was applicable, the re-use team would still have to translate it to fit their situation. A fundamental question for knowledge sharing is, who makes the translation, the originating team or the re-use team? From my experience, it is both more effective and more efficient for the originating team to do the translating. Effective because the pool of knowledge the originating team is drawing upon is larger and richer than what they can present; efficient because they can offer “just in time” knowledge. So this meeting is about engaging the originating team in that very complex translation task.

A fundamental question for knowledge sharing is, who makes the translation, the originating team or the re-use team?

To accomplish the translation the originating team will have to understand a considerable amount about what the re-use team is trying to accomplish. That will require an in-depth dialogue between the two groups that involves:

The originating team building a comprehensive picture of the situation the re-use team faces, including the technological challenges, the political issues, the resource constraints, the time frame, and the cultural issues. One of the most off-putting things we as human beings do to each other is to offer advice before we understand the problem. Premature advice comes out as, “Why don’t you just..?” which demeans both the complexity of the situation and the competence of the players and inevitably reduces trust between the two teams.
Understanding the questions and issues the re-use team has framed. The re-use team will come to the meeting prepared with some specific issues they want to explore and questions they want to ask. The originating team will need to spend the time to understand the thinking behind the questions as a crucial step to answering them.
Understanding what the re-use team does not know that it does not know. The most effective knowledge conversations address the unasked, as well as the asked question. In my work with project teams who are attempting to obtain knowledge from their peers, gaining these unexpected nuggets is one of the most useful and valued parts of the exchange. A facilitator, trained in the skills of inquiry and advocacy, can be very useful to the joint meeting. The facilitator can help each group listen to the other as well as listen for assumptions that could be usefully explored.

The dialogue serves another essential purpose, it establishes a relationship of trust and respect between the two teams. A team or an individual cannot accept or make use of the knowledge of others absent of a trust relationship. Anytime others are offering us advice or opinions, we not only listen to the content, we also listen for motivation, depth of understanding, and competence. For example, we are continuously making judgments about the extent to which the other is just showing off, exaggerating, trying to win a point, unaware of certain aspects of the situation, has our best interest at heart, etc. Our inferences about such things inspires our trust or rouses our caution. These are appropriate judgments to be making when the knowledge being discussed has the potential to significantly alter our course of action and they are at the heart of trust between the two teams.

A relationship of trust creates the foundation for an on-going dialogue. I have been speaking of peer assist as though it involves one meeting — one conversation. But in fact, the interaction between the originating team and the re-use team often involves many conversations in many formats, over the weeks and months of the project. Some of those conversations may occur between two individuals, some may be over the phone and others face to face, depending upon the need. I know of an oil exploration team working in, what was for them, very deep water, that met with the same originating team three times; at the beginning of the project to help them get a handle on the scope of the task they were facing; then nine months later, when they had collected considerable data, to assist them in looking at what new issues that data raised; and again at the end to help them think through what they had learned.

As in this example, peer assists between the originating team and the re-use team might occur at different stages and in response to new issues that arise during the course of the project. Different originating teams may be useful at different points in a project. Many different formats for the peer assist are possible, for example, a software company I have worked with has a policy of bringing together a few people from several different completed projects to talk with a new team at the start of their project.

I am often asked if a peer assist could be held by telephone conference call or by videoconference. My answer is never very welcome, in part, because it is not what the questioner wanted to hear and, in part, because the answer is complex. There are three considerations. First, trust is formed through face-to-face encounters. Once formed, trust is like a full bucket. It is possible to dip into it by holding virtual meetings and conversations — but after a few months the bucket will have to be replenished or trust will have vanished. Some virtual mediums appear to draw more heavily on trust than do others. Email, for example is particularly costly — it has probably caused more misunderstanding and hurt feelings than any communication medium humans have managed to invent.

A second consideration is the type of content being requested. Explicit knowledge travels well virtually, tacit knowledge does not. Explicit knowledge, e.g., “What was the author of that book you recommended?” or “Could you send me the survey instrument you developed?” requires little trust to make the request and the knowledge itself can be easily transferred through email, fax, or a voice message. Tacit knowledge, e.g., “What approach have you found useful with customer X?” requires a synchronous conversation based in a trust relationship in order to transfer knowledge effectively. If a trust relationship has been established, then a virtual, synchronous exchange can effectively carry the knowledge for a period of time before the trust bucket needs to be refilled.

A third consideration is the amount of learning the originating team gains from the exchange. Even though the re-use team initiates the exchange, in the course of the peer assist it becomes reciprocal, with both teams learning from each other. One of the major reasons members of the originating team are willing to take the time to come to a peer assist is that they realize they will add to their own knowledge through the experience. When teams meet virtually, the learning of the originating team is greatly reduced. There is only so long that you can stay on a conference call — so people hold back many things they would normally ask or offer. What gets sacrificed in teleconference peer assists is the learning for the originating team. This loss is significant in the short term, but even more significant in the long term. If originating teams consistently receive little back for their effort, the practice will die away. In the end any effective knowledge sharing system depends on reciprocity.

Demand C Adaptation How shall we revise our project to take into account what others have learned?

Having held the peer assist, the re-use team is now faced with the task of deciding how to use what has been learned from the originating team. This is a task of adaptation not adoption. It would be extremely rare for a re-use team to be able to do exactly what another team has done. Adoption happens only if processes, which occur frequently within the same context, are standardized across settings. In Common Knowledge I described the excellent use Ford manufacturing makes of repeatable processes. In an assembly plant workers put the tires on vehicles coming off the line 500 times a day. Putting on tires is a standardized process. If a clever team finds a quicker way to do it, what they have learned can easily be adopted in other Ford factories. However, project work is too context dependent to follow a prescribed sequence, so it is adaptation of what others have learned that is called for.

Managers sometimes tell me that a team won’t use someone else’s knowledge without changing it or making it their own. Often this is confided in almost derogatory terms as though the manager believes it is just exaggerated pride or inflexibility on the part of the re-use team — or an example of the “not-invented-here” syndrome, that causes them to adapt rather than adopt. However, in my experience, managers do a disservice to employees when they expect other’s knowledge to just be accepted and used. That expectation discounts the existing knowledge of employees and is perceived by employees as discounting their knowledge.

Rather than discounting the re-use team’s existing knowledge, managers need to provide the time and support for the adaptation of borrowed ideas. That may involve providing the time and costs for things like site visits, two groups working together for a period of time, and even personnel exchanges between re-use and originating groups. It also involves accepting the reality of “worse before better” change. Any time a team tries something new there is a learning curve and nearly always performance initially suffers as teams unlearn old and re-learn new skills. What teams need during this period is encouragement to stay with it. Many new ideas fail because the initial poor results cause teams to revert to the familiar, even when the familiar was not obtaining the desired results.

The re-use team that has engaged in a peer assist, now meet to plan their path forward. One of the marvels of an adaptation meeting is that often the new ideas the re-use team comes to agreement upon are something that the originating team would scarcely recognize as having come from them. What has happened is that between the peer assist and the follow-up planning meeting, the members of the re-use team have been assimilating what they have learned from the originating team and that has spurred yet more ideas about how to proceed forward. In the end, it is not the originating team’s ideas on which they will move forward, but the collective sense they have made of those ideas. Indeed it could not be otherwise. It is not possible for a team to effectively implement something they do not thoroughly understand and own.

Adaptation then is another form of the sensemaking meeting that was on the Supply side. The Supply side sensemaking was “reflection informed by action”, this step is “action informed by reflection”. Like that first meeting sensemaking meeting, the adaptation meeting is a conversation to create shared meaning.

The system now cycles back to the beginning. The re-use team will learn from its own implementation of the project and that new knowledge positions them as an “originating team”. To fully comprehend what they have learned they will need to hold a sensemaking meeting and a translation meeting. And they will spread what they have learned to their colleagues. They have a special debt to pay in terms of the spread because early on another team assisted them. This obligates them to let that team know how their ideas worked in this new setting, what additional things were learned, in other words to return the favor by facilitating the continued learning of the originating team. Without this thoughtful feedback, an originating team might continue to offer ideas that work only in their specialized setting, never knowing how the lessons needed to be modified to be of assistance to others or never knowing of improvements they could make to their own already successful processes.

What has been outline in Figure 2 is a reciprocal system of knowledge transfer between teams. There is a final step to be taken to grow the organization’s knowledge (Figure 3) that does not involve action on the part of the teams. As I have described the system in Figure 2, each team struggles to make sense of what they have learned, taking into account a very complex set of factors in their environment (sensemaking). Further, each asks the help of a few colleagues (translation) to help them see what they might have missed in their situation. Yet each lesson is ultimately a “sample of one” and in a sample of one, it is easy to mistakenly assume that a specific action was the cause of a specific outcome when in fact the two were unrelated. The database that has been created from the many lessons learned each team has sent in is a collection of many such “samples of one.”

The final step to grow the organization’s knowledge is the analysis of the samples within the database. There is a great deal that can be learned by looking across these samples at the underlying factors that could not be evident to any single team. Such an analysis needs to be conducted by subject matter experts who have been allocated the time to thoroughly study the lessons learned in order to look for underlying causative factors as well as consistent patterns across lessons. Experts functioning in this research capacity may need assistance from qualitative researchers to perform content analysis based on systematic coding. During their analysis they may form hypotheses that require them to return to the source of the data, the team members, to collect additional information. They may need to compare instances of successes with failures or conduct experiments to test the hypotheses they are drawing.

Once these underlying lessons have been developed from the analysis, the lessons need to be translated into an actionable format in order to become a significant part of the organization’s knowledge. Some of these actions will undoubtedly need to be addressed at the system level rather than at the team level. In fact, one of the great benefits of this type of analysis is the ability to uncover system level issues along with sufficient data from the analysis to compel management action on them.

Summary

I have outlined a knowledge creation and re-use process that an organization can implement to make use of the knowledge learned from project teams. It is also a way to fix a knowledge management system that is not working by adding to it the social processes that make it come alive.

The process begins with a team facing a problem. The team seeks knowledge from the community of practice (whether formal or informal) within the organization. The individuals and teams that make up this community continuously create knowledge because they have the flexibility to try out new ways of doing things, they are not so confined by rules or process that they must repeat what has been done in the past. The team that is seeking knowledge knows where to find useful knowledge about the topic of interest because their members are regularly invited to participate in peer assists for other teams and have been the recipients of knowledge products that other teams have developed. Through these activities they have developed a trust relationship with others in their community so that when they are in need of knowledge they feel safe in asking for it. They ask for and receive assistance in making the translation from what others have learned to their own need and finally they have the freedom to adapt not adopt, borrowing what which is useful and leaving the rest. They function within a reciprocal system where they are both receivers and givers, both originators and re-use teams.

Articles

1. Combining Virtual and Face-to-Face Work

2. Speaking Truth to Power: Nurturing a Reflective Culture at the U.S. Defense Intelligence Agency Reflections, Society for Organizational Learning, July 2011 (with Adrian Wolfberg)

3. CompanyCommand: A Professional Community That Works

4. Don’t Just Capture Knowledge — Put It to Work with Kate Pugh

5. Common Knowledge — How Companies Thrive by Sharing What They Know

“The third myth… is that the exchange of knowledge happens only in organizations that have a noncompetitive or a collaborative culture. It follows that the first thing you have to do is to fix the culture and then get people to share. But I have found that it’s the other way around. If people begin sharing ideas about issues they see as really important, the sharing itself creates a learning culture… It is a kind of chicken-or-egg issue: Which comes first, the learning culture or the exchange of knowledge? Given many organizations’ rather abysmal success rate at changing their culture, I would put my money on having the exchange impact the culture rather than waiting for the culture to change.”

6. The Oscillation Principle

7. Learning together and working apart: routines for organizational learning in virtual teams, The Learning Organization, April, 2017

8. Argyris & Revans on Holding Meaningful Conversations, Action Learning: Research & Practice the International Journal for Action Learning. Summer Issue 2014

9. Participant Skill or Skillful Design? Which Makes Conversation Effective, iKnow, May 2014, 4:1, pp. 14–18 — Blog

10. Harvesting Project Knowledge, ASK Magazine, NASA Spring (30) 2008

11. Developmental Stages of CoPs, Develop 2006

12. Functioning At The Edge Of Knowledge: A Study Of Learning Processes In New Product Development (with Marianne Doos, Lena Wilhelmson, and Thomas Backlund) Journal of Workplace Learning. (17) 8, 2005

13. The Powerful Question, Management First, Emerald Group Publishing. Jan 2004 — Blog- There is a Powerful Question you can ask that will turn almost any conversation you’re having into a knowledge producing exchange. Surprisingly, this Powerful Question is not the one you ask at the start of a conversation. Rather, the Powerful Question is always asked in response to a conclusion or fact that a colleague provides.

14. The Changing Face of Knowledge, The Learning Organization. 6,5, 1999, 212–216

15. The Neglected Receiver of Knowledge Sharing, Ivey Business Journal, March/April 2002

16. Does Your Organization Have an Asking Problem, Knowledge Management Review, 7,2, 2004

Knowledge sharing begins with a request, not with a solution. No matter how much knowledge is presented at conferences, held in databases or emailed to colleagues, knowledge won’t be reused unless a team has a need, something they are struggling with.
Managers sometimes tell me that people in their organization have a problem with sharing knowledge; but more often than not, people aren’t “asking.” The organization has an asking problem, not a sharing problem. When people ask, the sharing problem becomes moot.
How organizations talk about “asking” is critical. When company officials say to professionals, “Don’t be afraid to ask for help,” their words actually work against asking. Asking for “help” denotes helplessness. No competent professional wants that image attached to his or her performance. What professionals do need is to be able to tap into organizational knowledge that is growing and changing — to tap into what others are learning from their ongoing experience. I have labeled this step “scanning,” which connotes an active seeking for something of value.

Articles by Others

Why won’t people ask questions in the open?
Book Review: Common Knowledge by Nancy Dixon by Tim Cardinal
Knowledge management not just for dummies by Harvey Schachter
A Thought-provoking Perspective of Knowledge Management by TallyFox
Nancy Dixon Explains 3rd Era Knowledge Management by James Dellow
The Three Eras of Knowledge Management — Towards the Collective Knowledge of Conversations by Luis Suarez
Is Knowledge Management Relevant? by Britt Watwood
Receiving knowledge by Jack Vinson

Presentations

1. SlideShare

1. Facilitated Knowledge Harvesting

Faciliated Knowledge Harvesting

Faciliated Knowledge Harvesting - Download as a PDF or view online for free

www.slideshare.net

2. Knowledge Harvesting

Knowledge Harvesting

Knowledge Harvesting - Download as a PDF or view online for free

www.slideshare.net

3. The Art of Creating a Trusted Space

The Art of Creating a Trusted Space

The Art of Creating a Trusted Space - Download as a PDF or view online for free

www.slideshare.net

4. KM: Where Has it Been and Where is it Going?

KM: Where Has it Been and Where is it Going? - Nancy Dixon

KM: Where Has it Been and Where is it Going? - Nancy Dixon - Download as a PDF or view online for free

www.slideshare.net

2. SIKM Leaders Community

3. Midwest KM Symposium

August 2018 — Becoming a Learning Organization One Conversation At a Time

4. KMWorld

2022 W1: KM 101
2021 W1: KM 101
2019 W4: Increasing Digital Fluencies & Knowledge Sharing
2018

2017

2015

2012 Keynote: KM Saves Lives
2010 W6: Learning From Failure, It’s Possible!
2009

5. APQC

6. Other Events

The 3 Eras of KM — China Knowledge Management Alliance Congress, Nov, 2015
Knowledge Management, Where we’ve been and where we are going — DOD Annual KM Conference, 2014
Knowledge Management, the Third Era — KM Europe, Amsterdam, Netherlands, 2013
Knowledge Sharing — Roundtable of Federal Banking Collaboration, Baltimore, Maryland, Keynote address, May 2012
KM community Meeting — Carrier One US Navy, 2010, Virginia Beach, Virginia
US Army Knowledge Management Conference, 2009, Leavenworth, Kansas
Social Media — US Army, Knowledge Management Conference, 2009, Kansas City
Three Generations of Knowledge Management — KM Asia 2008, Singapore
US Army Knowledge Management Conference, 2008, Leavenworth, Kansas
Cross Generational Knowledge Management — Army Management Symposium 2008, Fort Leavenworth, Kansas
Ways of Thinking about Knowledge Management — Army Management Symposium 2007, Fort Leavenworth, Kansas
Conversations that Shape Us — Army Management Symposium, Fort Lauderdale, FL August 2004
Conversations that Build Knowledge — Braintrust, Keynote, Phoenix AZ, February 2004
Common Mistakes in Building Knowledge Sharing Capability — Department of Navy Knowledge Management Community of Practice, Keynote, Washington DC, June 2002
Developing Your Social Capital — QIO’s Tri-Regional Conference CMS and AHQC, Keynote, St Petersburg, Florida, June 2002
Common Knowledge” Department of Public Works, Federal Government of Canada, Keynote, Toronto, Canada, May 2002
Communities of Practice: Case Study — US Army Knowledge Symposium 2002, Keynote, Kansas City, Kansas May 2002
Sharing Patient Safety Knowledge — Patient Safety Collaborative, Keynote, Las Vegas, Nevada, April 2002
Common Knowledge — AHQA Technical Conference, Keynote, Dallas Texas, January 2002
Common Knowledge: How Organizations Thrive by Sharing What They Know — US Army Knowledge Symposium 2001, Keynote, Kansas City, Kansas May 2001
Lessons Learned — Department of Energy Lessons Learned Symposium, Keynote, Kansas City, May 2001
Creating a Knowledge Sharing Culture — Third Annual PDVSA KM International Forum, Keynote, Caracas, Venezuela, October 2001
Knowledge Transfer — Ontario Society for Training and Development, Annual Conference Keynote. Toronto Canada, November 2001
Knowledge Transfer: Matching knowledge to Transfer Process — Quality Managers Network, Division of Institute for Knowledge Management, Keynote, October, 2001