About dem WIKIs…

WIKIs are another example of a process framework for solving a class of organizational problems where you have a huge pool of hands and eyes and
you want to leverage that resource to make something good. I sometimes call those “talent scraping.” We have stumbled upon a few things over the last few years about such systems. Some people treat these “discoveries” with near religious reverence – which is fine because we don’t have too many of them so far.

Examples of what know:

• Create a large binding surface, i.e. lots of options, call it modularity, pages, plug-in whatever; but ship these options in preference to shipping finished products.
• Let the many hands self select what options to exercise; this lower’s coordination costs, and moves you closer to the customer/audience.
• Undo is good, it let’s people experiment at much lower risk.
• Stream changes past many eyes to capture free QA
• Very very lightly sort your community and give more power to people closer to the core
• Strive to lower barriers to entry on all community boundries
• Strive for open: a little ownership of turf is good, a little more isn’t, a lot is toxic.
• Bias for action where ever possible
• Ship early – real users embedded in real situations trump designers almost everytime.
• Ship early – highly open systems with lots of options have power-law tendencies.
• Labor to reduce the distinction between audience and creators
• Look for the network effects, nurture them.
• Tone is important – it will drive what you define as “good”
• Know that working and coordinating with infinite tiny options and infinite tiny resources is very different than working on systems with scarce expensive resources.
• …etc. etc.

You can see these in play in numerious systems, Wiki included. People who haven’t see the incredible value these systems can aggregate find them all a little topsy turvy – and indeed they are. They are upside down since they thrive on an abundance of labor all of which is only very marginally coordinated or committed. This upside down quality tends to make it tempting to label their processes as lame. Most traditional process is around managing scarcity and
That doesn’t mean that right way to get them on-board is to label their processes as lame. That’s a bad move. There is plenty of process design here.

(This is the second half of an old posting; but now I want it to stand alone so I’m chopping the old one in half.)