Not so long ago in a place not so far away, my boss, the president of the Company Where I Worked, invited me into his office. “Sit.” He said.
So, I sat.
“Look at this wiki.” He turned his monitor toward me and arbitrarily clicked links on the screen. “I can’t find anything. I can search for stuff, if I know what words to look for, but I can’t browse to find anything.”
My boss then sent me on a Quest to reorganize the Company wiki. Before I started, I set out to arm myself with success stories from others who had gone on before. Fortunately for me, XML Press had just released a new book on the subject. A couple of emails later, and I had in my hot little laptop one of the first ePub releases XML Press ever published.
Wiki, wherefore art thou?
With the book Wiki: Grow Your Own for Fun and Profit, Alan Porter set himself an ambitious goal: To introduce the concept of wikis and the benefits a wiki provides without losing his reader in a maze of technology. For the most part he succeeds at this task. The most technical concept discussed is a basic overview of the process he and publisher Richard Hamilton used to author and publish the book. Through the rest of the book, Alan shares the history and practical uses of wiki software through the language of his wife, who has a passion for gardening.
The similarity between gardening and wikis is obvious; we often use the gardening metaphor when talking about wikis. By comparing the stages of setting up and maintaining a wiki to those of tending a garden, we can communicate abstract concepts at a level that most people can understand. Alan takes this a step further by using only high level gardening principles in order to maintain his non-technical focus. And, at times when the gardening metaphor doesn’t lend itself naturally to the topic, he continues to use language that is free from pedantic technical jargon.
Overall, the book serves its purpose. If you understand wikis, you could skip the first few chapters that explain the history of wiki software and examples of wikis used by individuals and teams. The middle chapters describe the collaboration and community aspect of growing the wiki at all levels of an enterprise. The final chapters contain case studies of specific companies who use wikis, an overview of the benefits of different wiki applications, and references to related books and websites on technology, collaboration, and building community.
The success of Wikipedia has led many to believe that wikis arose through the social networking push that ushered in Web 2.0. The truth is that Ward Cunningham’s original WikiWikiWeb software predates the popular definition of Web 2.0 by almost 10 years. You could argue that wikis grew naturally out of bulletin board systems, which existed before the Internet became a household necessity. If anything, social networking as we know it owes its not-so-humble beginning to the expectation of participation that wikis demand.
People, not processors
Early in the book we get the picture that a wiki succeeds more due to an engaged community than technology. When a wiki implementation works well, it is usually due to the collaborative efforts of people who regularly contribute knowledge into its pages, and time into its maintenance and organization. The wiki implementations that fail often were set up as a technical project, with the expectant hope that people might use it.
While reading this book, I saw that the wiki at the Company Where I Worked was doomed to failure, for three important reasons:
First, the cultural environment didn’t support the wiki. The technical aptitude of the staff was high, but the sense of content ownership was nonexistent. There was a running joke at the Company that the wiki was considered “write only”. The staff kept adding pages to the wiki without giving any thought to its purpose or relevance. They rarely edited each others’ work, so duplication ran rampant, and information often went out of date.
This haphazard usage of a wiki is why many believe that the accuracy of any wiki is questionable–after all, too many cooks can spoil the meal–and therefore cannot be trusted as an authoritative source. To that point, Alan asserts that “The modern belief in the sanctity and veracity of the written word is a relatively recent product of 19th and early 20th century thinking.” Throughout history, cultures have relied on professional storytellers to pass their ancestral heritage onto future generations. The accuracy of these stories was challenged and verified by several others in the tribe.
Alan cites another interesting example where the end result benefited from direct feedback. The noted Bard of Avon, William Shakespeare, often modified his plays between performances. This allowed him to improve his stories based on the audience response from the night before.
Second, even though the President mandated the use of the wiki in the Company, he never contributed or edited any information personally. Alan wrote that wiki engagement is driven largely by the executive example. When I forwarded draft wiki pages based on our president’s cryptic emails or post-it notes back for verification, he never touched them. It would have been a better example for him to start the stub posts and ask our teams to fill in the blanks.
This lack of visibility from those in charge sent the rest of the Company a mixed message: “The wiki is important so you should post into it; however, it is not important enough for me to post into it.” In this case, the executive considered the wiki a necessary evil, after all, every technology company had one.
Third, because the president himself did not feel the wiki was important, nobody felt a sense of ownership for any of its content. Chapter 8 delivers some strategies for wiki content ownership. Key subject matter experts should be engaged early on to verify the information. As the wiki grows, you should see a new dynamic emerge in the form of a collaborative environment. People keep using a wiki when “the content provides real value, and gives the participants a sense of belonging to a community that respects and uses their work.”
Alan hammers home several points about how a successful wiki in one enterprise usually leads to expectations that a wiki tool will be available when an employee moves on. This was certainly true in my case, as I have either managed or set up wikis wherever I have worked since becoming a technical communicator.
How wikis can help
I use wikis as virtual whiteboards, to store information that everyone in an organization used to keep in an email or a binder on their desk. When more people get used to the idea of communicating in the open, there is less risk of one team member missing information that was shared only through email.
When wikis are used for customer documentation, they provide a place for immediate feedback from the customers who are closely attached to the products. Well organized customer documentation wikis can reduce customer support calls, and in some cases the comments can even influence the development of the product. If you could have access to the thoughts of real users, wouldn’t you want to take advantage of it?
The book contains some interesting tidbits. For instance, the word “wiki” has sometimes been referred to by the backronym “What I Know Is”. The truth is that wiki derives it’s name from the Hawaiian word for “quick”. Alan shows us that wikis were designed to capture information quickly, and free of form.
The book in wiki form
Unfortunately our culture is not ready to embrace information completely devoid of old school structures. Alan laments that digital delivery in its current state is just “a shiny new package for the same old ideas. We are still locked into a book-based, paged-locked paradigm that has changed little since the dawn of the printing press.”
It is probably Alan’s desire to see a different form emerge that gives this book its disjointed feel. Because this book was written in a wiki, I felt like I was reading a wiki. When I read the book straight through from cover to cover, I found a lot of the material repeated itself. This method of writing allows you to read the chapters in the order that best suits you. And in the tradition of wikis, over time, the structure and organization would have to grow and change to meet the demands of its content.
But that very different problem is left waiting to be solved at another time.
