Wikipedia is perhaps the most monumental achievement brought about by social collaboration tools. Its tale has been told many times, and it was actually used as one of the examples of the new paradigm in Andrew McAfee’s groundbreaking book Enterprise 2.0: New Collaborative Tools for Your Organization’s Toughest Challenges that was published in 2009. Comprehensive accounts of Wikipedia’s history are also available online on Wikipedia itself and in the form of Wikipedia co-founder Larry Sanger’s memoir on its early history on Slashdot.[ii]

A brief recapitulation of the story is necessary for our purposes, but the main goal is to inspect the story through a Lean lens in order to visualize what Lean might have to offer for social collaboration.

Nupedia, the origin

In 1999, Jimmy Wales wanted to start a free, collaborative encyclopedia. Larry Sanger expressed his interest in the idea and was hired by Jimmy to lead the project the following year. Thus, Nupedia was born early in the year 2000.

Nupedia’s process placed great emphasis on expert review. Any new articles had to be assigned to a competent writer by the Advisory Board and go through a rigid seven step process (assignment, lead reviewer selection, lead review, open review, lead copyediting, open copyediting, and final approval) before being published.

Because new content for Nupedia was being created very slowly, Sanger and Wales decided to attempt to complement Nupedia with a more open wiki in which articles could be prepared for eventual inclusion into Nupedia. However, the majority of the Nupedia Advisory Board did not understand, nor wanted to work with, the wiki collaboration model. Thus, Wikipedia was launched as an independent site on January 15, 2001.

By the end of the year 2001, Nupedia contained only around 25 published articles, with around 150 drafts. By comparison, the significantly younger Wikipedia had around 20,000 articles.

Nupedia failed both from a social collaboration point of view and from a Lean point of view. What is interesting is that its failures were mostly the same from both points of view, and as Lean was already well-established by that time, whereas social collaboration was not, many of these failures were avoidable already with the knowledge available back then.

Nupedia’s failures from a Lean perspective:

• Inefficient process: As articles had a significant lead time and the amount of work in process (WIP) was significant compared to the number of published articles, Nupedia clearly suffered from an inefficient process. Sanger actually recognized this in 2001 and strived to simplify the process, but the proposed changes never became reality.
• Significant barriers to entry: Articles had to be assigned to writers, who preferably had to have PhDs or otherwise demonstrated expertise in the subject. This prevented many people from participating, contrary to the basic premise of Lean that the ideas of all people are needed.
• Attempt to build full articles in one go: Lean is about constant creation of customer value in the smallest possible increment. Whereas an article has been viewed as an atomic entity, Wikipedia has clearly demonstrated that this is not so. The attempt to build a complete article in one go made the items too large. Another common theme in Lean is continuous improvement, and Nupedia’s process attempted to make the articles too complete too soon.

It is an interesting thought to consider whether Nupedia could have succeeded had it incorporated Lean ideals. Its successor Wikipedia includes all of the above corrections in some form. However, Wikipedia also includes other features that may not fit the Lean ideal. It is those features that I want to highlight next.

Wikipedia, the success story?

Wikipedia started out with very few rules. Neutrality had been a guideline in Nupedia and it was adopted into Wikipedia as well, but in many ways the early Wikipedia was a free-for-all. This approach achieved several desirable effects, as it completely eliminated any barriers to entry, made even the slightest corrections and additions possible, and streamlined the article creation process to a level of utmost simplicity.

Larry Sanger describes this initial setup in his memoir:

So Wikipedia began as a good-natured anarchy, a sort of Rousseauian state of digital nature. I always took Wikipedia’s anarchy to be provisional and purely for purposes of determining what the best rules, and the nature of its authority, should be. What I, and other Wikipedians, failed to realize is that our initial anarchy would be taken by the next wave of contributors as the very essence of the project–how Wikipedia was “meant” to be–even though Wikipedia could have become anything we the contributors chose to make it.

This good-natured anarchy could very well have collapsed. Sanger details many issues in his memoir, and the path from anarchy to the present somewhat working collection of norms and policies has been long and winding.

Thus, Andrew McAfee, even though he is generally very excited about the emergent nature of policies in a collaborative environment, reaches the following conclusion:

The example of Wikipedia illustrates that some of the mechanisms of emergence are organizational and managerial, rather than purely technical. In other words, leaders can’t simply assume that healthy communities will self-organize and act in a coherent and productive manner after Web 2.0 tools are deployed. Wikipedia’s history reveals that much effort has gone into defining the social ground rules of the community so that its members interact with one another in largely positive ways.

Larry Sanger also provides a very insightful account of lessons learned that could be applied to future projects that sufficiently resemble Wikipedia. These lessons learned are very interesting when evaluated from a Lean perspective:

If you intend to create a very large, complex project, establish early on that there will be some non-negotiable policy. Wikis and collaborative projects necessarily build communities, and once a community becomes large enough, it absolutely must have rules to keep order and to keep people at work on the mission of the project.

There is some policy that, with forethought, can be easily predicted will be necessary. Articulate this policy as soon as possible. Indeed, consider making a project charter to make it clear from the beginning what the basic principles governing the project will be. This will help the community to run more smoothly and allow participants to self-select correctly.

Establish any necessary authority early and clearly. Managers should not be afraid to enforce the project charter by removing people from the project; as soon as it becomes necessary, it should be done. Standards that are not enforced in any way do not exist in any robust sense.

As any disagreements among project managers are apt to be publicly visible in a collaborative project, and as this is apt to undermine the (very important) moral authority of at least one manager, make sure management is on the same page from the beginning–preferably before launch.

In knowledge-creation projects, and perhaps many other kinds of projects, make special roles for experts from the very beginning; do not attempt to add those roles later, as an afterthought. Specialists are one of your most important resources, and it is irrational not to use them as much as you can.

Radical and untried new ideas require constant refinement and adaptation in order to succeed; the first proposal is very rarely the best, and project designers must learn from their mistakes and constantly redesign better projects … there is no substitute for constant creativity and problem-solving–nor for honesty about what problems need solving.

Most of these suggestions are perfectly in line with Lean. Lean is process-based, because of the belief that lasting improvements are achieved only through standardization and then continuous improvement of the standards by all participants. So, policies, enforced standards, constant refinement and problem-solving, sounds like a match!

However, there are also a couple of suggestions here that are not compatible with Lean. As Lean strives to continuously innovate and improve the process, disagreements among project managers are to be expected, and resolved through analysis and discussion. In a fully Lean culture, undermining the project manager’s moral authority through disagreement is an incomprehensible notion, as the direct focus of improvement is always on the process, not the people, even though it is through participation in improvement efforts that people are also improved. I understand that this suggestion comes from long experience in dealing with “trolls”, which should not be such a big issue in a corporate environment, at least internally.

Special roles for experts is another notion that is strange to Lean to an extent. Lean is based on the contribution of all people, and everyone is important. It is true that people can have different roles to play in an organization, because it is effective to specialize and distribute work, even though Lean promotes building multi-skilled individuals where applicable. However, the idea of a super black belt ninja problem-solver is definitely anti-Lean.

Wikipedia has incorporated some of Sanger’s advice to its operating model: some policies have been defined as non-negotiable (neutrality in particular), some level of authority has been established, and the operating model is being constantly improved.

There are nonetheless areas where Wikipedia is not operated on Lean principles: most policies are optional (which can result in wasteful edit wars) and there are no processes to ensure that anything gets done, e.g. an article on a new subject or a requested peer review of an existing article. It is an interesting question whether such critical mass exists that there is no need to ensure that things get done by implementing processes and instead it is a viable alternative to trust that individuals in sufficiently large numbers take care of everything automatically.

Furthermore, it took Wikipedia years to evolve from a good-natured anarchy to its current somewhat less anarchistic state. When considered from the point of view of business design, this evolution process is highly undesirable, not as evolution itself, because that is indeed always necessary, but because of the length of the process and the level where evolution started from.

Conclusions on Wikipedia and Lean

Based on the above, one contribution that Lean could bring to social business design is a standardized, process-based approach that creates structure in the chaos. I guess beauty really is in the eye of the beholder, as Andrew McAfee used Wikipedia as an example to argue for exactly the contrary – that high-quality results can come from undefined, non-standardized, and uncontrolled processes. It is important to note, though, that for McAfee, controlled processes represented a form of Taylorism, in which the right to make decisions was taken away from the employee and into the hands of experts – a notion vehemently opposed by Lean.

If we view the issue from a different perspective, starting from Lean and building social elements on top of it, the Wikipedia example shows us that there are significant opportunities in openness, transparency, and radical collaboration (anyone can edit any part of anyone else’s work, putting up unfinished drafts is encouraged). Lean has already solved the apparent conflict between standardization and shop-floor decision-making in a non-networked world, and the question becomes how to transfer this solution to a fully networked world where the participating groups are much larger.

Photo: Wikipedia – T-shirt by mikeedesign @ Flickr (CC)