This past summer an issue of Harvard Business Review contained an article entitled Collaboration Rules by Philip Evans and Bob Wolf (Senior Vice President and Manager, respectively, of the Boston office of the Boston Consulting Group). The article explores how businesses seeking innovation and growth should take note of how the Linux open-source software development community operates. I’d like to summarize some of the article here because it illuminates the convergence of a number of the topics covered here including collaboration trends and software development methodologies.
The authors describe how Toyota’s direct supplier network exhibits the same self-organizing, collaborative traits as Linux’s open-source software development community. They give two historical vignettes about the responsiveness of these communities – the Linux community’s ability to work informally and quickly to patch a hacker’s system breach, and Toyota’s network’s ability to respond to a supplier’s factory outage by leveraging other suppliers. In both cases the community’s ability to respond can be traced to identifiable traits and principles:
- Common work discipline focusing on details – Linux’s short development cycles with testing early and often; Toyota’s short cycles of trial and error.
- Widespread communication with information shared widely, frequently, and in small increments – Linux’s postings of code to the wide community; Toyota's philosophy of continuous improvement comprised of a myriad of smaller collaborations.
- Leaders as connectors who instruct community members, articulate goals, and connect people by virtue of their own connectedness – the authority of leaders derives from their proficiency as practitioners.
These principles allow both communities to form a continuously adapting system that results in collective achievement and radical innovation. But these principles rely on two infrastructure components that must exist in the community:
- Common intellectual property – the Linux community mandates accessibility and precludes private ownership of code, thus ensuring viral dissemination and creating a transparent network that blurs the distinction between producer and user; Toyota's network of suppliers share process knowledge even among competitors.
- Simple, pervasive technology – the Linux community uses simple communication tools like email and listservs to ensure compatibility among all members; Toyota announces quality control issues in plants via pagers and TV monitors.
The organizational benefit of this type of vibrant networked community is a rich shared knowledge pool, modular teams that collectively advance the organization, intrinsic community motivation that excels despite the absence of financial incentives at each step, and higher levels of trust due to the reciprocal free flow of information and the emphasis on reputation that ensues. In particular this community trust can be viable substitute for traditional market contracts and hierarchical authority. And the authors then point out that these collaborative environments then change the economics of work by driving down transaction costs, which in turn allows organizations to employ a greater number of transactions resulting in greater productivity and innovation. They summarize this value chain as follows:
Bring together all these elements and you have a virtuous circle. A dense, self-organizing network creates the conditions for large-scale trust. Large-scale trust drives down transaction costs. Low transaction costs, in turn, enable lots of small transactions, which create a cumulatively deepening, self-organized network.
This is an exciting area to explore, and Philip Evans and Bob Wolf aren’t alone in exploring it. Rob Lucas had recently recommended to me The Success of Open Source by Steven Weber. Weber posits that the open-source movement potentially represents a new social engineering model for organizing labor (joining markets, hierarchies, and charisma). Evans and Wolf themselves cite the work of others including their BCG colleague Karim Lakhani at MIT.
This article is important for us at HBS on two levels – the community it describes is important to those of us developing educational technology both as an example of how we can better build technology and also what kinds of collaborative environments we can incorporate into our learning communities. Many of the principles touted as part of these collaborative networks are completely in sync with the Agile Software Development methodology that seeks to reduce risk and increase innovation in software design. And many of the emerging collaboration tools will become greater pieces of the environments we create.