Copyright
Preface
one
Communities of Practice and Their Value to Organizations
two
Communities of Practice and Their Structural Elements
three
Seven Principles for Cultivating Communities of Practice
four
The Early Stages of Development
Planning and Launching Communities of Practice
five
The Mature Stages of Development
Growing and Sustaining Communities of Practice
six
The Challenge of Distributed Communities
seven
The Downside of Communities of Practice
eight
Measuring and Managing Value Creation
nine
,Community-Based Knowledge Initiatives
ten
Reweaving the World
Communities beyond Organizations
Notes
Bibliography
About the Authors
, CHAPTER one
Communities of Practice and Their Value to
Organizations
IN 1988, WHEN JAPANESE COMPETITION WAS THREATening to put the Chrysler
Corporation out of business, no one suspected that the resurgence of the company (now the
Chrysler unit of DaimlerChrysler) would depend in part on the creation of an innovative
knowledge system based on communities of practice. While some of its competitors took as little
as three years to get a new vehicle to market, a typical new-product development cycle at Chrysler
easily ran five years. This was no way to compete. The first order of the day was to achieve a
dramatic reduction in this product-development cycle.
The story is well known, though the role that communities of practice played is less widely
understood. At the time, Chrysler was a traditional organization typical of large manufacturing
operations, with functional units such as design, engineering, manufacturing, and sales. The
design department would send a new design to engineering, which would send it back for redesign
a few times. The design would then go to manufacturing and be returned for reengineering until
the vehicle was deemed “manufacturable.” The localized focus of the various functional units
limited interaction between departments and thus gave rise to these unavoidable iterations.
Repeated hand-offs, duplication, and therefore slowness, were built into the system.
The decision was made to radically reorganize the unit. Engineers would now belong to “car
platforms.” These platforms were product-oriented, cross-functional structures that focused on a
type of vehicle: large cars, small cars, minivans, trucks, and Jeeps. Each platform was responsible
for all phases of development associated with the whole vehicle. Engineers of all specialties
reported to supervisors within the platform on which they worked. As a result, their primary focus
was on the development of a specific vehicle. For instance, if you were a brakes engineer, your
main allegiance, your reporting relationships, and your performance evaluation were no longer
with the brakes department, but with a platform, such as small cars or minivans.
Eventually, the move to car platforms succeeded in reducing the productdevelopment cycle
from five to two and a half years, with a corresponding cut in research and development costs. But
the restructuring did not come without its own costs. A host of new problems started to appear:
multiple versions of the same part with slight variations, uncoordinated relationships with
suppliers, innovations that did not travel, and repeated mistakes. The company had gained the
advantage of product focus, but compromised its ability to learn from its own experiences.
Something had to be done to save the platform idea.
With a clear need for communication across platforms, former colleagues from functional
areas started to meet informally. Managers recognized the value of these informal meetings in
fostering learning processes that cut across all platforms. Still, they wanted to keep the primary