Detroit’s Big Three, once the epitome of beleaguered U.S. manufacturers, now appear to be at the forefront of a resurgence in American manufacturing. As Fortune described it: “Having adapted Japan’s techniques of lean production for themselves, U.S. carmakers are reaping the benefits of lower costs and improved technology…Chrylser has transformed itself into America’s low-cost producer by bringing new efficiency to product development…Ford is extending its global reach by integrating the U.S. and European functions of design and engineering…[and] GM managers are moving faster — and with greater coordination — than they have in decades” (‘The World’s Top Automakers Change Lanes,” Fortune, October 4, 1993).
In the 1980s, automakers focused on manufacturing enhancements and vastly improved the quality of their cars. Those efforts, however, eventually hit their limits — poor quality designs. The focus of the 1990s has therefore shifted from manufacturing to new product development.
A number of forces are driving this increased emphasis on new product development. In today’s global market, companies no longer have the luxury of extending product lives by pushing old products into new geographic markets. Instead, products must be introduced almost simultaneously across the globe. Rapid scientific advances also mean more companies can access new technologies faster. The result: competitive advantages based on currently superior technology are often short-lived.
These changes place great pressure on product development organizations to become more flexible. For those that meet the challenge, the rewards are great: lower development costs due to reduced rework, higher margins due to premium pricing, and improved quality due to better design integrity.
Superior performance in product development can also have profound implications at the corporate level, since the learning that occurs in the development process can enhance a firm’s understanding of its markets and internal processes. Exploring the intersection between product development and learning may therefore provide a focal point for organizational improvement efforts.
We have the technology, the people, the skills, all the pieces — why can’t we put it all together?
Putting It All Together
Despite all the new product development research that has been done, however, product development managers have a lot more questions than answers. As one manager put it, ‘We have the technology, the people, the skills, all the pieces — why can’t we put it all together?” Even when an organization has all the component technologies and expertise necessary, performance can be greatly diminished by the way it is man-aged in concert. Consequently, the greatest barriers to better product development performance may lie in the organizational structure and systems. New product development efforts of-ten suffer from a gap between the goals of the individual product teams and the needs of the entire process. Improving performance therefore requires building a shared understanding that allows people to connect their individual activities to the whole. The “Tragedy of the Commons” systems archetype may help provide some insight for managing product development so that the performance of the whole is not sacrificed for the optimization of the parts.
Tragedy of the Commons
The storyline for the ‘Tragedy of the Commons” archetype was first outlined by Garrett Hardin in 1968. Hardin described the ‘Tragedy of the Commons” using the analogy of a common pasture where many herdsmen graze their cattle (see “Tragedy of the Commons:’ All for One and None for All,” August 1991, and “Using ‘Tragedy of the Commons’ to Link Local Actions to Global Outcomes,” April 1993). Each herdsman is allowed to graze as many cattle as he wishes, and as long as nature, wars, and disease keep the number of humans and their animals below the carrying capacity of the land, the system works well. When one begins to approach the limits of a system, however, tragedy results: “Each is locked into a system that compels him to increase his herd without limit in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons. Freedom in a commons brings ruin to all…”
Tragedy of the Suppliers
Tragedy of the “Power Supply” Commons
How does the ‘Tragedy of the Commons” dynamic play out in the product development process? For one car manufacturer, “Cars, Inc.,” the ‘Tragedy of the Commons” archetype helped create a better understanding of the dynamics of its product development system. The original system, as the product development manager described it, was based on resource control and restraint. The engineering design validation process over-involved senior management, treated suppliers with indifference or hostility, and greatly reduced operating personnel’s ability to meet their quality, cost, and time objectives.
For example, at Cars, Inc., individual component teams in the product development program all drew power from a limited power supply. Although it made sense for each component team to draw as much power as they required to maximize the functionality of each part, the collective result was an over-loaded power supply and an impasse in the design process. No team could concede what it considered to be in the best interest of its own component.
Cars, Inc.’s product development team acknowledged that appealing to the “good of the whole car program” is useless in such a situation, because no component group leader is willing to sub-optimize his/her component (and face the backlash from his/her functional area or team) in order to optimize the whole.
When teams had encountered this problem in the past, they struggled among themselves until at some point the product timing was jeopardized and a decision had to be made. The program manager would then have to step in and dictate how much power each component could draw. This process was unsatisfactory for all involved: the teams felt a lack of empowerment because they were not able to make the decision themselves, and the product development manager was frustrated because he had to intervene when he had expected the team to make the decision. The reason would appear to be that the team was poorly-aligned or the manager was heavy-handed. Without a general framework to interpret the actions, the outcome was seen as situation-specific.
To understand how their patterned responses kept them trapped in old behaviors, the product development team used systems archetypes to build an ongoing learning process within their organization. Once the team mapped out their situation and saw it as a ‘Tragedy of the Commons,” the course of action and the reasons why the action was necessary were clear. The program manager was given all the component designs and asked to make the decision on how much power to allocate to each of the components. Those who had to give up some functionality did not like it, but given the systemic structure, they understood why.
The ‘Tragedy of the Commons” doesn’t minimize the importance of individual actions; instead it recasts them in a systemic context. It also reveals how the rewards and incentives can conspire to make solutions at the individual level ineffective. For Cars, the archetype provided a common framework that helped all parties rise above the shared view that individuals (or teams) are responsible for either succeeding or failing and realize there are larger structural forces that govern certain situations.
Tragedy of the Supplier Commons
Subsequently, other teams at Cars, Inc. looked at similar common resource issues and realized that they, too, fell into the ‘Tragedy of the Commons” structure. For example, relationships with component suppliers also revealed a ‘Tragedy of the Commons” situation in which the “commons” was the performance of a particular supplier (see ‘Tragedy of the Suppliers”). As a division builds up a good working relationship with Supplier X, that division is more likely to contract with Supplier X in the future (RI). If another division decides on the same supplier, Supplier X’s ability to satisfy both divisions’ requirements can erode (B3 and B4). Given its historical relationship and dependence on Cars, Inc., Supplier X feels it is not in a position to say “no” to any of the requests for fear of losing future work.
The unfortunate outcome is that Supplier X becomes overburdened and fails to deliver on some of its commitments. Cars, Inc.’s purchasing department concludes that Supplier X is no longer reliable and drops it from their list of suppliers. Both parties collude in destroying what was once a strong relationship, but they are blind to how each was responsible for making it happen. Without some form of commons management that oversees and coordinates the different relationships, all such programs are susceptible to the ‘Tragedy of the Commons” dynamic.
A “Commons Managements’ View of Product Development
The prevalence of the ‘Tragedy of the Commons” archetype in the product development setting provides a systemic understanding for why a heavyweight product manager with wide authority over an entire product program makes sense. Clark and Fujimoto’s Product Development Performance lists several characteristics that a heavyweight product manager must have to be effective. Among them are the following:
- Coordination responsibility in wide areas
- Responsibility for concept creation and championing as well as cross-functional coordination
- Frequent and direct communication with designers and engineers
- Circulate among project people and strongly advocate the product concept rather than do paperwork and conduct formal meetings
A heavyweight program manager is especially important in situations where there is a “commons” that individual component groups can destroy, or when a firm has limited resources and each department vies for more of a common resource (e.g., drafting) in order to produce the best product. Clark and Fujimoto showed that product managers who have broad authority in setting agenda — and who clearly convey that information to the engineers — have significantly greater success than those who have less authority and influence.
Managing the Product Development Commons
How does viewing the product development process from the “Tragedy of the Commons’ perspective change the way it is managed? The following is a tentative list of implications:
At the sub-system or component team level
- At the start of each product program, all the potential ‘Tragedy of the Commons” issues should be identified
- All individual players who are port of a “Tragedy of the Commons” should know what commons they are a part of, and with whom they are sharing it
- Each commons member should know who the governing authority is for his or her commons
- Those who share a commons should have systems in place to maximize coordination and sharing of information
At a program manager level
- Identify all of the common ‘pools’ of company resources that the program depends on for success
- Identify all of the critical suppliers who are susceptible to being overburdened by demands from all programs
- Meet regularly with other program managers to update and communicate for the purpose of managing the commons
At the product development organization level
- Design an information system that provides real-time feedback to all sub-systems and component teams concerning how their commons is being affected by everyone’s collective actions
- Design a dual-recognition system that gives teams credit for producing the best individual part and also credits them forgive-ups” which sacrifice part functionality for product integrity
The items listed above may sound like resource allocation issues, and at a basic level, they are. What is most important are the underlying assumptions which govern those allocations. A “zero-sum game’ or an “us versus them” mentality will produce a very different outcome than a systemic approach. Viewing the product development process as a commons management issue leads one to focus on how the system as a whole is interacting to produce undesirable results, therefore directing efforts to work on the system rather than on the individuals.
The idea of a heavyweight program manager seems to fly in the face of empowerment and the precepts of a learning organization, such as the belief that individuals should have autonomy in their work. In reality, the reverse is true. Many organizations have joined the “empowerment bandwagon” recently. What few have done, however, is make the necessary changes in their organizational and reward structures to support such a shift in power. Empowerment in settings where the incentives are individual-based and where the goals require collective compromise ends up being an exercise in frustration. And when such efforts inevitably fail, they only serve to reinforce the view that “strong” management is required.
Managing from a commons perspective requires relinquishing autonomy in certain areas so that the collective good is served. Once it is recognized that a “Tragedy of the Commons” structure is operating, the players involved usually recognize the need for management to take charge of strategic decisions such as allocating power consumption requirements or weight limits. At Cars, Inc., for example, the team members voluntarily relinquished strategic autonomy, while still retaining the operational autonomy necessary to engineer the best parts and sub-systems possible within the given constraints and objectives.
Empowerment therefore does not mean relinquishing total control in every setting, but having a clearly understood boundary and context within which individuals have true freedom of choice.
Portions of this article were drawn from Daniel H. Kim, “A Framework and Methodology for Linking Individual and Organizational Learning: Applications in TQM and Product Development,” Unpublished Ph.D. dissertation, MIT Sloan School of Management (Cambridge, MA).
Further Reading: Kim B. Clark and Takahiro Fujimoto, Product Development Performance: Strategy, Organization and Change in the World Auto Industry. (Boston: Harvard Business School Press, 1991). Garrett Hardin, “The Tragedy of the Commons,” in G. Hardin and J. Baden (Eds.), Managing the Commons (New York: W. H. Freeman & Co., 1977).