The Law of Large Numbers – or, why Enterprise Wikis are Fundamentally Challenged

Some will be taken a bit by surprise to read the title of this post; we have implemented a wiki in our group at work, and I have the evangelist role in promoting the tool. Still, a recent “event” brought home the fact that wikis are not the silver bullets that some breathless articles may make them out to be. To be fair, Hickins’ article does call out the “law of large numbers”, although the idea is buried in the body and not well explained. It’s a bit of a downer, you see – it’s why wikis and other collaboration environments often struggle and fail.

I kinda like to think I came up with this Law myself, over 10 years ago, when working on Knowledge Management (KM) projects at Searle / Monsanto. There was a general, budget-defying euphoria about how “knowledge bases” and “expertise systems” would generate “knowledge capital” that could and should be accounted for. The example given was always some riff on the internet, or BBS systems, even the old CompuServe forums. But even back then, the pattern was fairly clear … go: Visual Basic, and ask a question – any old question – then sit back and wait for your answer. Better yet, browse / search the forum for previously asked questions; chances are, you will be rewarded with a terrific answer that hits the spot. (You know, by the way, your Help Desk and the entire TechArch group is googling all day for their “brilliance”, right? </hhh>).

Now, the KM True Believers say this represents a democracy of knowledge – sounds like a good term, because it’s nice to think that knowledge is freely available. Unfortunately, this model only works because of the Law of Large Numbers.

Let’s imagine a universe of potential Visual Basic programmers at 1M souls – reasonable, I think, even 10 years ago. If only 1% of those folks even bothered to go to a web site / forum / knowledge base, that’s still 100K visitors. And if only 1% of those folks were energized enough to capture and share their views – why, that’s 1000 active authors, building a knowledge base that would definitely be something worth reading.

We’ll use the same ratios for the typical mid-size company – say, 2500 people who might have cause to partake in some knowledge base. Even if we increase participation by a factor of 10 – assume a captive audience, who is incented to participate – that still leaves us with 2.5 people actively participating in the knowledge base. Like as not, the typing will stop when they realize they can have a more spirited discourse at the local watering hole – and so ends the great promise of Technology Augmented Learning.

<aside>This Law of Large Numbers is not my original idea, I found a number of interesting links – including this one, which sounds like another explanation for the million monkeys banging away to produce Shakespeare (an interesting mental picture for the blogosphere, yes?). I also like the sinister 11 section – that extra push over the cliff …</aside>

Admittedly, this is not a new concept – caught some posts over the past few weeks that make some excellent points / observations …

This last point I discovered for myself with a major section of our new wiki. We’re introducing a significant new way of thinking about how we forecast and prioritize work in our IT group, and we’re using a Wiki to address multiple issues:

  • Training material / process documentation / standards / glossary terms and colloquialisms needs to be easy to find, searchable, and widely available
  • Training material etc. needs to be constantly updated as we learn new and better ways to do things – and online documentation solves the distribution problem

Those two are classics, but a significant “organizational development” issue we are indirectly addressing is the democratization of knowledge (ooo, that term again).

No, not the hackneyed Knowledge is Free (as in Beer), but democratic as in made for and by the people. Organizations need to be participative, and people need to know they have a say in how things get done. People also should be able to freely contribute, without asking permission or jumping through too many procedural hoops.

This, by the way, is the most powerful impact of the wiki – it actively enables participation!

… which can be good and bad challenging. Good, because the cynics have one less reason to complain about How Things Are (“Like, if it’s not well defined, then go define it, dude!“).

But challenging, because documents that have been authored by a large number of people look like, well, like documents that have been authored by too many people (spoilt broth and all that). Which (finally!) gets me back to my story, where a few days before the big unveiling of the Next Big Section of our wiki, the feedback was very negative, because the reader got lost in the unstructured, inconsistent, difficult-to-read text. It took a  couple of hours of strong editing to pull together all the great ideas into a coherent narrative, and this work has to be part of your planning for a successful wiki. Call it an Editor in Chief, a Detail Fiend, whatever – but a successful wiki implementation needs a core group of editors, to give the content a single, consistent voice.

This Post Has One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles