Problems With Open Collaboration

A recent article in Strategy+Business (a magazine published by booz&co) notes the pitfalls of open collaboration: tapping into the power of emergent, bottom-up social networks to generate innovation.  The companies that have been successful with it are well known:  IBM with its innovation jams, and P&G with its open innovation strategy.  But other companies often struggle to realize the benefits.  The article’s basic premise is that open collaboration is similar to the “quality” movements of the 1980s (remember TQM?)  The article notes:

Today, practitioners of open collaboration are picking up, in some ways, where the quality movement left off. They are working to tap the knowledge and creativity of a broad range of constituents, including employees and suppliers. In the process they are also rethinking their organizational structures and systems. Most important, at the core of both the quality and open collaboration movements (and sometimes it’s unclear where one leaves off and the other begins) are the values of trial-and-error learning, open communication, and systems thinking. Both movements recognized that employees — given the right tools, training, and management environment — are in the best position to do the analysis needed for meaningful improvement and innovation.

So what held back the quality movement?  Hierarchical thinking; truly listening to the ideas of the rank and file; making the long-term commitment to professional development and cultural change.  Of the seven suggestions the article lists for better success, I found three compelling: (1) Build a culture of trust and open communication; (2) Build a flexible innovation infrastructure; (3) Align evaluations and rewards.

Harnessing the Wisdom of Crowds

We’ve heard a lot about collective intelligence, Web 2.0.  Internet-based examples abound: Wikipedia, Google, Threadless.  Thomas Malone and colleagues have written a new article proposing an analytic framework to help us think about these networks, what they call the “building blocks” or “genes” of collective intelligence.  Of course, I wanted to see how their framework compares to my own “collaborative web” model from Group Genius.  Based on a study of 250 examples of web communities, here’s what they propose.

The four building blocks are answers to these questions: Who is doing the task? Why? What is being done? How?  How these questions are answered determines which “gene” it is.

The Who question has two genes: (1) Hierarchical organization determines who.  (2) Crowd gene: Anyone can participate.

The Why question has three genes: (1) Money (2) Intrinsic motivation of the task (3) fame or reputation.

The What question has two genes: (1) Create something new; (2) Select among alternatives.

The How question has two genes for each of the what genes, depending on whether it is independent or collective.  For “Create” the two genes are Collect independent contributions and Collaborate together.  For “Select” the two genes are Group decisions (Aggregate individual group decisions by voting or consensus etc.) and Individual decisions, through markets or social networks.

Then continuing the biological analogy, they analyze specific examples of web-based collaboration and call them “genomes.”

This is a useful way of breaking down different web-based communities, although I found it not very surprising or new.  The key thing that’s missing from this model is what I think is the biggest challenge facing such communities: What is the right degree of central control and structure?  Communities with no central structure are usually a huge mess.  Linux succeeds only because of a strong central guiding body, led by Linus Torvalds.  The model presented in this article seems most appropriate for tasks where no central control is necessary, where small items are created that don’t need to coordinate with each other in complex systems (in Wikipedia each entry stands alone; with Threadless, each t-shirt design is independent).  But with Linux, everything has to work together.  That’s a key variable missing from this model, but I have no doubt Malone and colleagues are aware of this and are thinking about it. (The 7/19/2009 NYTimes article by Steve Lohr, where Prof. Malone was interviewed, explicitly addresses this topic.)  Perhaps another paper will emerge from the same research study.

*Thomas W. Malone, Robert Laubacher, and Chrysanthos Dellarocas. February 2009.  Harnessing Crowds: Mapping the Genome of Collective Intelligence.

What Kind of Leader?

There’s a radical new form of participatory democracy: the Internet.  At least, that’s what some advocates would have you believe.  Take Wikipedia: anyone can create a new encyclopedia entry, add an interesting fact to an existing entry, or edit an entry to correct a mistake.  Take the Linux operating system, based on what’s called the “open source” model–which means, just like Wikipedia, anyone can edit the program that makes it work.  If you don’t like the way it does something–let’s say, the way it displays your files when you ask to see what’s in a folder–you can just dive right in and make it do what you like.  (Of course, assuming you’re a talented programmer!)

Groups of people that work on Wikipedia or Linux are known as “open source communities” and the business press would have you believe that they are the polar opposite of the hierarchical, cubicle, stuffed-shirt office.  For example, they’re often said to be pure meritocracies, where the best programmers always win: titles, hierarchy, and politics are no longer a factor.

However, any serious student of people in groups would be instantly skeptical of these claims.  No new technology, no matter how awesome, changes the fundamentals of human social dynamics.  The telegraph was, if anything, even more transformative for its day than the Internet (it’s been called “The Victorian Internet” in a brilliant book with that title by Tom Standage), and it didn’t change human social dynamics, either.

I’ve just read a new study by Siobhan O’Mahony and Fabrizio Ferraro* that analyzes how leadership structures emerged, over 13 years, in the community of developers working on the Debian distribution of Linux.  This is the second most popular Linux distribution, surpassed only by Red Hat.  There are over 1,000 Debian developers in over 40 countries; over 150 vendors distribute this software.  The Debian community was formed in 1993; the researchers discovered that over a 13 year period, the community went through a fascinating evolution during which the nature of leadership changed.  Here’s their analysis:

1993-1997:  The founder had the final say, and when he left he informally passed on leadership to one of his trusted lieutenants.  This person was thought to be overly autocratic and was asked to step down; at that point, the community had to think more explicitly about how they would be governed.

1997-1999: A third leader was selected who vowed to lead a collective effort to draft a constitution that would retain the democratic and participatory nature of the community.  The constitution was eventually ratified by 357 developers, and the leader was given the title of “Debian project leader” or DPL.  Much of the decision-making power was placed with a technical committee rather than the DPL.

1999-2003: DPLs were elected for one-year terms.  The researchers characterize this period as “experimentation with the leader role” because they identified three different styles of leaders among those elected, from “hands off” types to “visionary leader” types.

2003-2006: By 2003, the three earlier styles of leaders were supplanted by a new type, the “organization leader”: individuals who were not necessarily technical wizards but instead emphasized communication, culture, and relational skills.  When the candidates’ written platforms were analyzed, in 2006 76 percent of the text focused on organizational issues, whereas in 1999 only 37 percent was (back then candidates emphasized technical issues).

The conclusion is that although autocratic leadership failed early on, as the organization grew larger and more successful, they needed leaders who were more organizationally gifted; technical skills were not enough.  “Debian may be a meritocracy, but merit is not measured solely by technical contribution” (p. 1100).  The surprising finding, the authors say, that “a community so wary of the effects of positional authority that its members actively limited it would, over time, prefer leaders who expanded their reach of authority….even the most savvy online communities are not immune to well-known general principles of organizing” (p. 1100).

Another interesting finding from this important paper: developers who met more other developers face to face were more likely to get elected.  Even in geographically dispersed virtual communities like Debian, face-to-face interaction predicts community leadership.

Of course, these leaders are nothing like the autocratic bosses of the starched-shirt 1950s.  They’re more like the leaders you find in super-innovative organizations like W. L. Gore or Google: they embrace the role of leader, and leadership is necessary to make the organization work, but it’s not a top-down planned form of leadership.  It’s a kind of leadership that focuses on enabling the best innovations to emerge from the bottom up.  You need this kind of leader in every organization, not only in open source communities.

*O’Mahony and Ferraro, 2007. The emergence of governance in an open source community. Academy of Management Journal, Vol. 50, No. 5, pp. 1079-1106.