by

Richard McDermott, PhD

Globalization is forcing many companies to accelerate both their ability to innovate and their ability to disseminate learning. Fifteen years ago Shell Oil took a bet. It bought exploration leases in the deepwater of the Gulf of Mexico. Shell knew there was oil in those fields, but did not yet have the knowledge or technology to explore and drill wells in water that deep. To use the leases before they expired, Shell needed to quickly learn how to explore and drill in deepwater. Once Shell established its leadership in deepwater development, it could only maintain its competitive edge by quickly disseminating what it learned in the Gulf of Mexico worldwide.

One very effective way to accelerate and disseminate learning is to build communities of practice on key technical topics. Communities of practice are groups of people who share ideas and insights, help each other solve problems and develop a common practice or approach to the field. Communities of practice are particularly useful where cross-functional teams are the basic structure of the organization. In those companies people have most contact with teammates from other disciplines. This increases project coordination and knowledge sharing but can isolate people from peers in their discipline or field. Communities of practice are a way to knit people together with technical peers while maintaining the focus on cross-functional teams.

There are many different kinds of communities of practice. Some are closely knit groups of specialists who informally share knowledge in unstructured discussions: scientists who regularly call on peers to help think through a problem or mechanics who share technical war stories at their morning check-in. Some are loose networks of people who only occasionally seek each other’s advice. Some try to capture and store the knowledge of their members; others simply bring people together, using little or no information technology. Some are natural outgrowths of people’s need for companionship and collaboration; others are intentionally formed. As more companies connect people across teams, disciplines, business units and geography, we are beginning to see the many forms connecting can take. With all these options how do you decide what kind of connections to build? Three dimensions can help determine the answer:

• the kind of knowledge the community shares;
• the degree of connection and identity among members; and how closely integrated sharing knowledge is with people’s everyday work.

Understanding these dimensions can help determine what kind of community to develop. All communities of practice, whether spontaneous or intentional, share both knowledge and information. All have both individual and community relationships. All integrate with peoples’ work in many different ways. But they vary a great deal in how much they focus on each of these dimensions. Some focus more on sharing tacit know-how; others on explicit information. Some build relationships among individuals; others build a common identity. Some are tightly tied into people’s everyday work; others are distinctly separate from it. By understanding these dimensions, we can determine the kind of learning community that will likely be most effective for a given situation. None of these dimensions are mutually exclusive.

There are many different kinds of knowledge; data, information, tools, procedures, know-how, understanding. Some knowledge can easily be written down or drawn and made "explicit." Tools, procedures, templates, are examples of explicit knowledge. Other knowledge is "tacit," things known by people, but not documented anywhere. The know-how, understanding, mental models, and insights of an individual or discipline are examples of tacit knowledge. Since explicit information is written down, it can be organized, distributed, and managed. Know-how, on the other hand, includes a vast store of knowledge that people don’t know they know. To become aware of this knowledge, people often need a problem or issue to draw it out. Know-how is difficult to communicate in a way that is useful to others. It rarely translates well into explicit procedures. It is often shared through war stories, observation, reflective discussions, and other person-to-person connections. Understanding which kinds of knowledge a group needs to share is key to selecting the forums, structures and systems that will be most effective.

Sharing explicit information. IBM’s systems consultants develop proposals on large systems for clients around the world. Each proposal includes descriptions of the elements of the system being recommended. To help consultants use ideas developed by peers around the world, IBM developed a set of web sites that contain an edited and organized set of proposals developed by other consultants. When a consultant needs to develop a new proposal she or he can draw from similar proposals developed by his or her peers. Since system consultants already make their knowledge explicit in the proposal, there is little extra work for individual consultants to maintain this resource. Pooling documents can easily create an information junkyard, filled with everyone’s disorganized file drawer. At IBM a small group of consultants review and edit the proposals on the web site, weeding out redundancies and organizing them so they are easy to access and use. By weeding and sorting, this group adds value to the documents and makes it more useful for consultants to get material from the web than from their own individual files. Focus on sharing information when community members need information that is already explicit and can be easily transferred from one situation to another.

Sharing tacit know-how. Frequently people on cross-functional teams need technical advice, ideas, interpretations, and reviews. To give advice and interpretations, people need to understand the context in which it will be used, think through the situation, and draw on their own tacit know-how. This typically requires person-to-person contact, whether that is face-to-face, telephone, electronic or written. One of the most powerful - and simple - things Shell’s Deepwater Division has done to share learning is to hold regular informal meetings among learning community members. These agenda-less meetings replicate the "water cooler" discussions people had when they were located in functional departments. Anyone who has a problem or issue to discuss can raise it. The meeting belongs to the community. A facilitator, who is also a member of the community, keeps the discussion focused on technical matters, and takes notes for those who cannot attend. A simple discussion template helps drive the discussion to surface underlying assumptions. These meetings have become very popular among technical staff. As one geologist said, "With so many meetings--diversity, safety, business issues, etc.--it’s great to go to a meeting to talk about rocks." Tacit knowledge can most easily be shared as people talk person-to-person about a specific problem or idea. Focus on sharing tacit knowledge when community members need to draw extensively on their own personal judgment and experience to know what to share and how to apply it.

Documenting insights. Documenting insights involves translating tacit knowledge into explicit written tips, procedures, case studies, etc. People often think that documentation is the key to effective sharing knowledge. It can be an effective way to share insights, but it is not simple and not always appropriate. Documenting insights involves more than just writing them down. It involves translating them from the context in which they were generated into the context in which they will be used. To make this translation the author needs to understand who will use the documentation, their background, issues, and level of technical sophistication, and the purpose for which the documentation will be used. Most documentation systems fail because the authors do not clearly understand the users’ context. When sharing knowledge face-to-face, people assess each other’s context and make this translation on the spot. But understanding the user’s context can involve a substantial amount of "art" and time. Writing a brief note for a colleague in your field is very different from explaining a procedure for a newcomer to the field. And colleagues are frequently more interested in the "logic" of an analysis — why you chose it, what your assumptions were — than the result or steps involved. Distinguishing the appropriate level and focus of documentation can be quite difficult. As one professional said, "I don’t know how to document what I did short of writing a book." Document ideas, insights, or procedures only when it is clear that the effort involved will be valuable to both the company and the community and when the users’ context can be clearly identified.

Sharing both tacit and explicit knowledge. Most communities of practice share both tacit know-how and explicit information and need different structures for each. Shell Deepwater’s "turbidite" community shares most knowledge in informal, face-to-face discussions. But when they find an issue that has broad implications, a subgroup develops a set of written guidelines and posts them on the community’s web page. Since the community decides what to document, it understands the context in which the guidelines will be used. Build mechanisms for sharing both tacit and explicit knowledge when the community is developing new ideas and applications on an ongoing basis.

The second dimension to consider is how strong the community’s sense of identity is. This dimension identifies how people will participate in the community and the boundaries that will hold the community together. In a strong community people interact frequently both individually and as a whole and share a common identity and purpose. This is a community of practice. In a weak community there is very little interaction, common identity, or purpose. Both extremes -- and the variations between them -- can be useful in spreading learning.

Communities of practice. Communities of practice share a common identity, history, and purpose. The Deepwater Division of Shell Oil Company organizes its cross-team learning according to discipline. Key disciplines have a full-time "practice center" manager and a senior level administrative assistant who organize the information in their knowledge base, collect documentation, link people together and host regular learning discussions. Some supplement regular informal discussions with home pages and common data libraries. Since Shell is a technology-focused company, most people already have a strong identity with their discipline. Their communities of practice are first and foremost natural networks of colleagues. Their natural affinity helps them develop the trust and rapport needed to share ideas and learn together. As one practice center manager observed, when his web site is working well, the number of phone calls he receives for technical help increases.

Build communities of practice when there is a natural sense of community identity. Most professionals learn about new tools and developments in their field not by reading journals, but by consulting their colleagues. Colleagues are not only sources of information. They are also sources of judgement about how valid and useful information will be. As communities of practitioners share ideas, they naturally tend to adopt common practices. Build communities of practice when it is important for individuals to use the latest technology or common methods.

Networks of individuals. Networks are groups of people who share a common interest, exchange ideas, and help each other. Most companies are laced with them. They often develop among people with a common background, but they can form around almost anything in the company: emerging technology, business issues, politics, or purely social interests. Networks typically have little sense of common identity. Although individuals within the network frequently meet person-to-person, the whole network rarely meets — or sees itself -- as a whole. Networks are a useful and inexpensive way to share learning across teams. Whenever someone at Texas Instruments comes up with an innovative idea, they are encouraged to write a short description of the idea and the problem it solved. This serves as an electronic card catalogue of company "Best Practices." When facing a problem, Texas Instruments’ employees are encouraged to use the "Best Practices" database to find someone who solved that problem before. Texas Instruments does not try to capture best practices. It simply links people with problems to people with solutions, expanding the natural networks that lace the company. A corporate group manages the database and a group of part-time facilitators help people write good problem statements. Networks facilitate individual collaboration, leaving it to the individuals to determine the content and form of knowledge sharing. Use networks for linking teams when you need to build knowledge around a loose, evolving focus and there is no need to develop common practices.

User groups or interest groups. There is a wide array of standard information people in most companies need: includes training schedules and manuals, procedure updates, meeting agendas, business metrics, analytic tools, lunch menus, etc. Different people usually need different parts of this body of information but each individual does not need customized directions in applying it. Nor do they typically need to discuss the information with peers to understand it. Organizing and distributing this information electronically can be very useful. Allied Signal saves $7M annually–mostly in printing and distribution costs–by publishing its procedure updates on an Intranet homepage. But a user group is not a community. They typically have little or no sense of common identity or purpose. Create web sites to broadcast common information, when you need to share relatively stable, explicit information that requires little interpretation to apply.

Documenting and sharing knowledge with other teams often feels like an imposition on "real work." The core of most teams’ work is solving problems and applying insights. It is usually hard for them to step back and document their insights for others or break to solve another team’s problem. Making documentation a requirement does not resolve this. Even when required, documentation is often seen as an afterthought and frequently does not contain the richness, subtlety, and meaning of the team’s thinking.

When sharing knowledge is naturally integrated with work. When people work together, sit close to each other, and interact with each other on a daily basis often naturally share ideas and insights without thinking of it as separate in any way from their normal work. Even somewhat limited interaction can lead to natural communities of practice. Xerox repair people formed a strong community of practice, although they only saw each other at morning check-ins. When sharing knowledge is seamlessly integrated into work, it is painlessly unobtrusive.

Building systems that shadow the work. Designing systems for sharing knowledge that have this naturalness is very hard. In most team-based organizations, communities of practice integrate people from different teams who do not see each other every day. Often they integrate people from different cities and time zones. One way to build knowledge sharing into the work is to lock documentation into people’s work tools. Cigna Property and Casualty built a decision support system that steps underwriters through the decisions they need to make to write a policy. As underwriters enter information about the potential client, the system provides information about similar clients, issues, and related decisions made by their peers, which they can use for guidance. At each step of decision-making, underwriters enter additional information, which calls up more databases, each relevant to that point in the decision process. But the information underwrites enter also populates the database. The system captures underwriters’ insights as they do their work. It is a shadow of their work. A group of "knowledge editors" analyze those insights and add them to the databases. To build this sort of system is a major undertaking. It involves redesigning work processes, jobs, organizational structures, and information systems. Build systems that shadow the work when individual work processes are very similar (everyone follows the same steps), when people need to draw insight from peers quickly, and documentation is necessary to provide those insights.

Building systems that follow the sequence of work. A less ambitious way to share ideas is to build a mechanism that follows the steps of the work process, even if it is not integrated with it. This maintains a logical connection with work, although it is separate in time and space. This can be done with both human and information systems. One community designed an informal "peer review" process that provides face-to-face input at critical points of the work process. The review meetings are informal, with no written recommendations or reports. Another community built a web site that contains analytic tools, tips on how to apply them, cost, time to run, and links to experts for help. The information is organized in the sequence of the work process, with numerous tool options for each step. Users can page through the web site like a cookbook, selecting the tools they need. The cookbook contains recommendations on which tools work best for different applications and which work well together, but decision making is up to the individual. Even when information is not fully integrated into the work, organizing it according to the sequence of work can make it more naturally useable. Build systems that follow the sequence of work when you need a common mental framework for organizing information or you need the discipline of the work process to insure that knowledge sharing happens.

Sharing insights at special events. Sometimes organizing information by work process constrains the community. Shell’s informal discipline discussions, for example, are so open-ended they do not fit into any particular part of people’s work process. When learning or documentation is separate from everyday work, its value needs to be clear and immediate. Without an immediate "payback’ it is hard to get enough participation to maintain a critical mass of information and insight. Shell’s discipline discussions have become very popular because people can raise issues critically important to them. To create interest in its knowledge sharing events, American Management Systems has made them high status, invitation-only events, kicked off by the chairman of the board, with entertainment and many "workshops" on the latest ideas. Separate the activities of learning from everyday work when learning is far ranging and the value of participation is clear.

Using these dimensions, you can determine what kind of community of practice to build. If you are working with a group that that needs to share tacit knowledge, has a strong sense of identity, and needs to integrate new knowledge tightly with their work, you might want to have a brief morning face-to-face meeting and many opportunities to link together one-on-one during the day, through the telephone, email or "same time" software. If your needs to share explicit information (documents already written), has a low senses of community identity, and little need to immediately integrate new knowledge in their work, you might create a set of community databases with a small group of community members responsible for managing it. Using these criteria, you can structure many different kinds of communities of practice.

However you structure your communities of practice, a few other guidelines can help:

• Build communities on strategically important topics. Organizations frequently cast "too wide a net" and ask teams to share or document too much information. As a result, they end up building stockpiles of underutilized information–information junkyards. To leverage knowledge effectively, communities of practice need to understand what knowledge is strategically important to the business.

• Build enough background context for people to understand each other. Sharing insights is not simply a matter of transmitting information from one person to another. To be useful, information needs to be translated from the context in which it was developed to the context in which it will be applied. What one person considers valuable to share depends on their own experience, goals, problems and mental frameworks. What another person considers valuable to apply depends on their experience, goals, problems, and mental frameworks. A mismatch between these two contexts is probably the single biggest reason ideas and insights are rejected. Even when sharing simple information, like a procedure, people often need to build a shared context to understand how to use it.

• Use both human and information systems to share insights. Sharing insights is essentially a person-to-person activity. Building the human community of people sharing insights is critical to effectiveness. It is in the human interaction that people build enough common context to understand each other, enough trust to be willing to share ideas, and enough spark to draw out the "tacit" knowledge others have, the lessons they forgot they learned. Once that human community is established, then electronic tools can provide useful ways for them to continue the connection.

• Use multiple forums for sharing knowledge. Most communities of practice have many different kinds of knowledge to share. Since data, information, and know-how travel best in different medium, most communities of practice need multiple ways to connect and share knowledge. Even when a single form of communication dominates a community’s interaction, keep other forum active and available. When a community relies too much on a single medium, it tends to get clogged with inappropriate information–meetings with long rounds of information sharing rather than collective problem solving or web pages full of individual discussions.

• Help people "pull" insights from each other when they need it, rather than "pushing" it out to them. Most of us have had the experience of sitting through long discussions that were not immediately relevant. Even when there are gems of insights in these discussions, they are hard to pull out and remember. Most of us learn best when faced with a problem and need ideas to solve it, when we "pull" information currently relevant. Whether using person-to-person forums or information technology, knowledge sharing should be designed to respond to pull rather than push information out to people.

• Communities of practice live within an organizational culture. If the organization values learning and sharing knowledge, it will provide a rich ground for growing communities of practice. But that means managers need to give people the time and encouragement to reflect, share ideas with other teams and think through the implications of other teams’ ideas.

• Build on the natural energy for learning. Whether the culture supports it or not, communities of practice arise in most organizations. Rather than creating a new "program" for sharing team learning, find the networks that already exist, enable them, and link them to other communities in their neighborhood.

There are many different kinds of connections between people. Some are ongoing networks focused on topics of interest. Some are temporary connections between people with ideas to share on a particular problem. Some try to capture and store the knowledge of their members; others bring people together to share ideas using little or no information technology. To decide what kind of connections to make between people, you need to understand what kind of knowledge they need to share; what kind of community they are inclined to be; and how tightly sharing knowledge needs to link with their everyday work.

Communities of practice are natural. Communities of practice arise spontaneously in most organizations. To enhance learning you do not need to design and build them from the ground up. You need to find and nurture them with the resources, structure and systems they need to flourish. Developing communities of practice is closer to husbandry than architecture.