Synergy

"A world class 'varsity eight' (plus coxswain) can cover 2,000 meters over the water in about 5.5 minutes. However, a single sculler can at best row the same distance in about 7 minutes. The difference is synergy, and if rowing faster were a matter of survival, the cooperators would be the fittest."^[1]

^[1] "The Synergism Hypothesis: On the Concept of Synergy and Its Role in the Evolution of Complex Systems," by Peter A. Corning, Ph.D., Journal of Social and Evolutionary Systems, 21(2), 1998.

Partnerships are not about cost reduction, they are not about risk reduction, nor are they about adding capacity. The fundamental reason for partnerships is synergy, peopleand companiescan achieve better results through cooperation than they can individually.

Emergency!

Tuesday, December 2, 2003. A serious security breach was discovered in a Gentoo Linux server in an Italian University. The system administrator traced problem as best he could, then through a chain of contacts, got in touch with a developer in Australia who had once led the development of that area of code. The developer dropped everything and worked through the Italian night with the system administrator to pinpoint the exact location of the breach. Then he rounded up a friend, and they worked through the Australian night writing a patch. They sent the patch to a small group of Gentoo Linux user-developers. who had been alerted to stand by for testing. Less that 30 hours after the attack was discovered, an announcement of the breach and the tested patch were distributed to Linux users worldwide.

This story was told by Philip Evans and Bob Wolf in the Harvard Business Review article "Collaboration Rules."^[2] They summarized, "No one authorized or directed this effort. No oneamateur or professionalwas paid for participating or would have been sanctioned for not doing so. No one's job hinged on stopping the attack. No one clammed up for fear of legal liability. Indeed, the larger user community was kept informed of all developments. Yet despite the need for the highest security, a group of some 20 people, scarcely any of whom had ever met, employed by a dozen different companies, living in as may time zones and straying far from their job descriptions, accomplished in about 29 hours what might have taken colleagues in adjacent cubicles weeks or months."^[3]

^[2] This section is a summary of two stories told in "Collaboration Rules," Philip Evans and Bob Wolf, Harvard Business Review, JulyAugust, 2005.

^[3] Ibid., p. 99.

Saturday, February 1, 1997.^[4] An early morning fire leveled Aisin plant number one, the one that made all of the P-Valves that go into Toyota automobiles. A P-Valve is a cigarette-box-sized part that controls pressure to rear brake lines, and Toyota had maybe two or three days of inventory on hand. P-Valves are high-precision parts made by specialized tools, but theoretically they could be made with general purpose machine tools. Aisin immediately put out a call asking every company with machine tools for help. Sixty-two companies responded, and within hours, blueprints for the valve were picked up and tooling systems were improvised. The volunteers coordinated among themselves as they figured out how to produce the high-precision valves, and Denso stepped in to coordinate the messy logistics. Even as Toyota shut down all of its plants on Tuesday, a small supplier, Kyoritsu Sangyo, proudly delivered the first 1,000 production quality valves. By Thursday, 36 suppliers, aided by 150 subcontractors, were producing small batches of P-Valves, and Toyota began reopening its plants. One week after the fire, Toyota was back at full production of over 16,000 cars a day, each one containing two hand-machined P-Valves. It took Aisin six weeks to rebuild its line, and eventually it paid all of the interim suppliers for their time. Toyota also gave each first-tier supplier a bonus to show its appreciation, which they promptly passed down to second- and third-tier suppliers.

^[4] Ibid. See also "The Toyota Group and the Aisin Fire," by Toshihiro Nishiguchi and Alexandre Beaudet, Sloan Management Review, Fall, 1998.

"The parallels between these stories are striking,"^[5] according to Evans and Wolf. "In both of them, individuals found one another and stepped into roles without a plan or an established command-and-control structure. An extended human network organized itself in hours and 'swarmed' against a threat. People, teams, and companies worked together without legal contracts or negotiated payment. And despite the lack of any authoritarian stick or financial carrot, those people worked like hell to solve the problem."

^[5] Ibid., p. 100. Italics in original.

The people and companies that responded to these two emergencies were used to working together. They had already established an understanding of how to communicate with each other to get things done. They had learned to do this with no visible leader, each person or organization taking on whatever needed doing if they had the skills to contribute. Fueled by trust and paid with applause, each community was governed not by contracts or hierarchies, but by rules about how people and teams work together and how they communicate.

Open Source

We know that excellent software can be developed and maintained by volunteers working around the world with a few simple communication tools and some basic rules. In fact, many of the people developing Open Source software have day jobs as software developers. Some might even get paid by their employers to contribute to an Open Source effort. More often than not, Open Source contributions come from developers who modify an existing program to solve a problem of their own and then share the results. But none of this explains the underlying success of the Open Source model.

Most Open Source projects have a leader, at least in the beginning. All Open Source projects have "committers," a trusted inner circle of people who have the authority to commit new code to the code base. Originally, the project originator is the committer, but as the project grows, more developers earn the right to join the inner circle of committers. The committers enforce any standards that may have been established and act as a first-line reviewer. It is an honor for new members to have their code committed, although contributing code that hasn't been thoroughly tested is embarrassing. The active community for any project provides merciless reviews of code once they see it, enforcing standards through aggressive peer pressure. This is definitely a challenging team sport with great psychological rewards for making an outstanding contribution.

Many people have obsessions that thoroughly absorb their attention outside of work. With Open Source that obsession just happens to be writing code. There is something about software that can be terribly engaging. We might ask ourselves what we can do to make software development similarly engaging in our organization.

Going back to Deming's 14 points, point 12 is probably the most important: Eliminate barriers that rob people of their right to pride in workmanship. Artificial deadlines, managers with no idea about what good code really is, sloppy code bases and coding practices, no way to see if new code works, no idea what the users really want, individual rewards for team contributionsall of these rob every member of the development team of pride in workmanship. Pride builds commitment, and without mutual commitment a group really isn't a team.

What if a software development leader had a job description similar to a project leader in Open Source? To get volunteers to work on Open Source, a new project leader needs an attractive idea and a good approach. To keep volunteers committed, the leaderand later the committer communitymust recognize, appreciate, and applaud good work. Good work means solving the problem (the developers are also the customers in most cases so they really understand the problem) with concise, readable code, committed into the system in very small pieces. Open Source developers will not waste their time working on software that is messy or brokenor if they do, they start by fixing it. And nobody, really, tells Open Source developers what to do. They are perfectly capable of figuring that out for themselves.

For a disciplined, competent development team, there is no currency that can beat respect, trust, and applause.

Global Networks

The Boeing 787 Dreamliner is being designed and developed by a global network because Boeing believes that the synergy of many cultures with varying areas of expertise will result in a superior aircraft. Procter & Gamble decided that it needed new ideas faster than it could generate them, so now it searches for innovative ideas throughout a global network and brings them inside to develop into products.^[6] Tapping into worldwide innovation talent is not the only reason for global networks. Both companies realize that they must sell their products worldwide, so global networks are necessary to help them understand and meet the needs of global markets.

^[6] "Connect and Develop: Inside Procter & Gamble's New Model for Innovation," by Larry Huston and Nabil Sakkab, Harvard Business Review, March 2006, pp. 5866.

In software development we have our own well-respected global network: Open Source communities. From Open Source we learn that people don't need to be in the same time zone to work closely together on software. The question is, what do people need to collaborate closely on software development, especially if they are not in the same location?

Let's reexamine the two stories at the beginning of this section. The first thing Aisin did was put out a call for help, and 62 companies responded. Everyone was engaged in getting Toyota's production back on track; it was a matter of both pride and mutual economic necessity. With commitment established, the focus switched to communication. During the crisis after the fire, Aisin could give blueprints to everyone, but it couldn't help the suppliers figure out how to machine the P-Valve. Aisin made automated equipment; it had little experience in using machine tools. Suppliers figured out how to machine the part by organizing daily meetings among themselves so machinists could talk to other machinists about what they were learning.

Fixing the security breach in Linux started with the commitment of a former project leader in Australia to fix a flaw in code he had worked on. Many people had come to depend on it, so as matter of pride, he jumped in to help. He spent hours in one-on-one communication with the system administrator in Italy before they pinpointed the exact spot in the code that was at fault. Then he paired with a friend who lived nearby to develop the patch, because tough problem solving is better done by bouncing ideas off of someone elseespecially when it takes all night.

We are often asked how to improve the communication channels of global teams, but all too often we find that the root of the problem is not communication, it is the absence of a committed team. Global networks and distributed work groups do not become teams just because someone calls them teams. Providing channels for rich communication is very important when team members are located in different time zones, but it is hardly sufficient to change a work group into a team.

The challenge of creating synergy among people who are geographically disbursed is very similar to the challenge of creating synergy among people who are co-located: Above all, team members must be mutually committed to achieving a common purpose. With global teams the challenge of mutual commitment simply has an added dimension: Effective communication among team members is more difficult.

From Global Work Groups to Global Teams

Here are some techniques that we have found helpful in creating commitment and facilitating communication among work groups that are widely separated by geography:

1. Frequent Integration: Very often, a work group is made up of several small teams, each in a separate location. If team responsibilities reflect the system's functional architecture, then the teams can usually work on separable modules relatively independently. This can be a very effective structure, but the teams must use nested synchronization, integrating their efforts frequently. Regular, frequent integration has many benefits, from establishing mutual commitment to creating a common repository of knowledge. The faster knowledge is communicated through the code base, the easier the code is to understand, the better the programmer tests communicate what each local team intends, the better their combined results will be.

2. Exchange People: All too often we find that a team in one country has all of the necessary technical capabilities to develop a system, but their "requirements" come in large batches of written documents developed many time zones away. Predictably, when the application is finished several weeks or months after the arrival of the requirements, it isn't what the customers really wanted. Large separations between customers or analysts and the implementation teamwith over-the-wall communicationseldom works very well. The best way to deal with this situation is to locate a couple of people from one team on the other team for extended periods of time, preferably on a rotating basis. Either a couple of team members that understand customers should be located with the development team, or alternatively, a couple of people who are part of the development team should be located with those who understand the customers. Rotating people through these positions is even more effective.

3. Exchange Tests: We are familiar with one case in which moving requirements between teams was handled by sending executable tests, rather than requirements, to the remote team. The people who understood the customers developed detailed tests that the code had to pass. They sent the remote team tests. If the code passed the tests then it was considered to be working. Nevertheless, they found that unless the iterations were closed out and tested at the customer site once a week, the distance was too great and the remote team would drift away from delivering what the customer really wanted.

4. Proxy: We have seen very successful dispersed teams that communicate through a single person. Someone from a remote site becomes a member of a core team and serves as a proxy for the remainder of the remote team. Every day this person assumes responsibility for a large amount of well-defined work and sends it to the remote team, calling them each day to describe what needs to be done, answer questions, and retrieve completed work. Thus, the remote team maintains rich communication with one person on the core team, and the core team considers the remote team an extension of this proxy, who can take on work for several people.

5. Traveling Team Leader: In one case we know of, each co-located subteam had an Oobeya, or "war room," with the big visible charts showing project status and issues. The status charts were maintained identically in each of four rooms around the world. The program leader traveled from one room to another, holding regular status meetings at each location. The other locations called in to the meetings, which renewed the mutual commitment of all teams to their common objective.

6. No Second-Class Citizens: When part of a team must work using a second language while other team members use their first language, or when one group is a subcontractor while the other is part of the contracting company, or when one group clearly has higher pay or status than the other, people can easily get the perception that one group is "better" than the other. Such perceptions will quickly destroy the respect, trust, and commitment that are essential for true teamwork.

The Light Fiber Team

Nishijima-san decided that our plastic light conductor would make a great product for Sumitomo-3M. We toured the United States together for three weeks to look at possible applications, and Nishijima-san returned to Japan to form a team. At any given time over the next two-and-a-half years, he sent at least two engineers from his team to join my team in the United States. The engineers rotated so that everyone spent several months on the US team, contributing to our work and learning about the optics and the technology. Every night the Japanese engineers called in to a team meeting in Japan to keep everyone informed. Then at our meetings they brought us up to date on the progress in Japan.

We tried video conference calls, but they didn't work very well. Fortunately, they didn't need to, because whoever was in the United States from Japan was a full team member, and every night they drew their colleagues into our team. When we traveled to Japan we knew everyone on the team and felt like we were a part of their team. We jointly chose the brand name to work well in any language. If I were to do it again, I'd do it the same way, except that I would send two engineers to Japan in exchange for the engineers Nishijimasan sent us.

Probably the biggest concern was joint intellectual property, even though 3M and Sumitomo-3M were very closely associated and had intellectual property agreements. However, with the Sumitomo-3M engineers on our team full-time, we couldn't do much to sort out who came up with what ideas. So the vice president sponsoring the program told us to ignore the issue, and he asked the lawyers sort it out. I am convinced that this decision was critical in helping our teams feel like equals. Over time, we had several joint inventions. In fact, I was named on one of the joint patents.

Mary Poppendieck

Outsourcing

Global teams may exist entirely within a single company, or they may cross company boundaries. Actually, the same is true of local teams: Members may come from within a single company or from different companies. Outsourcing involves having some of your company's work done by another companythat may be a company down the street or half a world away. Outsourcing adds a different dimension than distance. It raises the question of allegiance. When workers make trade-off decisions, how do they weigh the interests of their own company, the other company, and the joint venture? And how do they balance that with the continued existence of their own jobs?

The best outsourcing arrangements make the answer to these questions very clear: The best interests of the individual companies and their respective employees will be best served by furthering the best interests of the joint venture. Without such clarity, we subject workers to veiled conflicts of interest. How can such conflicts of interest be avoided? The answer depends on what kind of work is being outsourced. Let's take a look at three possibilities: infrastructure, transactions, and development.

Infrastructure

When we started our business in 1999, we knew we needed a Web site and e-mail capability, but we had no interest in setting up a server. So we found a company (which happens to be in Canada) that would host our Web site and provide e-mail for a modest monthly sum. Over the years the company has improved its offerings and lowered its prices to the point where we sometimes wonder why any small business would host its own Web site and e-mail server. We don't worry about downtime, security, or even growth. The service is very easy to use, and in the few instances where we've needed technical support, the response was more than satisfactory.

We have outsourced infrastructurewhich is probably the easiest thing to outsource. The expected features of the infrastructure are well defined in the marketplace, provided by many vendors, and competitively priced. While we are technically competent to provide our own infrastructure, we get a lot better return on our time if we spend it elsewhere. It makes a lot of sense to outsource infrastructure when the market can provide it more competently and cost-effectively than you can. Most people are comfortable with outsourcing infrastructure.

Transactions

Another thing that can be outsourced is transactions. For example, a company that has to transcribe a lot of paper documents to an electronic format can scan the documents and then ship them anywhere in the world for transcription. Because transcription is labor intensive, sending the documents to a country with low labor rates can be very cost-effective.

But there is a caution here: What if the real competitive advantage in the industry will go to the company that figures how to capture the data electronically and dispense with the paper documents? Companies that outsource the transcription to lower their costs will lose the incentive to ask themselves why the documents need to be transcribed in the first place. Before outsourcing transactions, simplify the value stream first and try to eliminate the need for the transactions.

Most of the conflict of interest in outsourced transactions lies in a piece-work approach to compensation. When an outsourcer is paid on a per-transaction basis, their incentive is to reduce the amount of time per transaction. But if the real value lies in reducing the number of transactions, piece-work compensation systems create a conflict between allegiance to one's employer and allegiance to the company that generates the transactions.

For example, in Chapter 2 we told the story of how BMI, a UK airline, outsourced its call center to Fujitsu. Typically call center outsourcers are paid based on the number of calls (transactions) that they handle, but Fujitsu was able to show BMI that it could reduce the number of calls it handled and decrease BMI's operating expenses at the same time. Thus, Fujitsu was able to convince BMI to shift the incentive so that payment was on based on potential callers, so they could make money by helping BMI save moneya win-win partnership. This approach to compensation makes it crystal clear that looking out for the good of the joint venture is in everyone's best interest.

Development

Just as outsourcing infrastructure makes a lot of sense, outsourcing software development for common industry processespurchasing for examplecould also make a lot of sense. You can expect to get the industry average with this kind of outsourcing, however, because your outsourcing provider is usually working with other companies in your industry. If your practices are below par, then outsourcing is a quick way to bring them up to the industry average. Outsourcing this kind of development is basically the same as outsourcing infrastructureand it rarely raises issues of allegiance.

Some companies outsource a portion of developmentfor example, manual testing through a user interface is often outsourced because it is so labor intensive. The real advantage, however, goes to the company that realizes that testing does not need to be done manually through the user interface. This company will automate testing beneath the user interface and then integrate that testing as far back in the development process as possible. In fact, it will try to write the tests first and then write the code to pass the tests. This company will have a significant competitive advantage in its entire software development process over the company that outsources the manual testing.

Outsourcing the development of key components of your product or the software that supports key differentiators in your process requires careful consideration. Some companies keep this kind of development entirely internal, providing a key lever to create competitive advantage. Other companies have learned to outsource these critical areas of development effectively. For example, in the United States, more than 70 percent of the parts in a Toyota car are both developed and manufactured by suppliers.^[7] The global innovation networks of Boeing and Procter & Gamble mentioned earlier in this chapter give them access to the most technically advanced thinking in the world, no matter where it exists. Thus, advanced development that used to be done internally is now carried out in partnership with other companies.

^[7] See Jeffrey H. Dyer, Collaborative Advantage: Winning Through Extended Enterprise Supplier Networks, Oxford University Press, 2000, p. 33.

Companies that gain a significant advantage from outsourcing critical development areas operate from a few basic principles:

1. The reason for outsourcing critical capabilities is motivated by the need for access to a broader set of technical capabilities than the company possesses or to broaden its market understanding and reach, or both.

2. Outsourcing of critical capabilities is always set up to be a win-win partnership. The partnership is not just expected to create synergy it is managed to create synergy. The compensation system, interaction rules, and management expectations give clear signals to the workers that loyalty to the joint venture is equivalent to loyalty to their individual companies, and a successful joint venture will serve their best interests

3. Companies exhibit a deep respect for their partners, and this respect is embedded in the processes and procedures they use to frame the details of the partnership.

Supplier managementdone wellcan bring the same dramatic advantages to the development world that supply chain management brought to the manufacturing world. It all starts with a recognition that outsourcing is not about cost reduction, it is not about risk reduction, it's not even about adding capacity. It's about creating a synergy. It's about coming to the realization that by rowing together, the companies can get to the finish line faster than even the strongest of them could manage alone.