"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]
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]
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.
"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."
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 SourceWe 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 NetworksThe 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.
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.
OutsourcingGlobal 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. InfrastructureWhen 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. TransactionsAnother 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. DevelopmentJust 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.
Companies that gain a significant advantage from outsourcing critical development areas operate from a few basic principles:
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. |