Wikipatterns – Table of Contents
This is the point where most business books leave you with some boilerplate inspirational words about how whatever you’ve just read will radically reshape business, transform economies, and change the world.
I’m not going to do that, because the wiki isn’t going to change the world by itself. It needs you, and the people you work with, talk with, meet with, email, call, and IM to try it, be open to the changes it brings, and make it a hub for information and collaboration. A wiki thrives on active participation by as many people as possible, and in turn brings greater value to each individual user. It relies on transparency, trust, and willingness to share information more openly, work more collaboratively, and see information as more valuable when more people have access to it.
Transparency leads to better and more refined business practices, because people can work together to improve things in an iterative manner, instead of fixing things only when they’re broken. Access to each others’ information builds trust, strengthens people’s relationships and creates stronger connections between their work. Combined, these make an organization less likely to suffer bureaucracy and an inability to get things done.
Renegades are the ones who will bring in the wiki, firmly anchor it by making it central to their work, and get all their friends to use it too. Renegades see the potential in something like the wiki and are willing to disrupt their own status quo to try it. They aren’t afraid of failure and see stagnation and status quo as failure in itself.
A WikiChampion is a renegade because often bringing in the wiki is not part of his or her “day job”, and is a labor of love. He or she will set up the wiki, start using it for his or her own work, then use that initial work as an example to get other people excited about using it, and help them get started. The WikiChampion is absolutely essential to the success of a wiki, especially in its initial stages, because that person generates enough buzz and interest to build a community of passionate users that will continue spreading the word on a larger scale.
Technology Is Simply a Tool
For far too long, software has been rather stupid to the idea that people are the most important ingredient in building anything, and technology is simply a tool. Many knowledge management initiatives have failed because people don’t buy into them and make them an indispensable part of their daily work. The technology is just too complex, and requires an incredible amount of customization to do even a fraction of what people really want it to do. As a result, responsibility for anything involving these tools often ends up with the most tech-savvy person in a team.
People and context matter much more than the technology itself, and the wiki exemplifies this by minimizing complexity and structure so that everyone has the ability – and responsibility – to build, maintain, and use information. With a Wiki as the platform for group collaboration, that dependence on a tech-savvy person, and thus that almost unfair balance towards the more tech-savvy person experiencing the technology goes away, because the tool is simple enough that anybody can use it. Because the tool is so intuitive and approachable, people are able to focus on the content – what they are really experts in – instead of having to spend so much time up front learning the technology.
People Are Incredible Self-Organizers
In “Why Commercial Wikis Don’t Work”, (Great article. Bad title. My opinion.) Chris Taylor of Business 2.0 looked at why some highly publicized wiki experiments like the LA Times Wikitorial, A Million Penguins book project, and Amazon’s Amapedia product review wiki haven’t become the major successes their creators had hoped they would be. (Taylor, 2007) Taylor argues that the problem with these experiments is they rely on getting input from a community that’s too large, too random, and without a common binding element. He suggests that a better way to go would be an editorial, for instance, that’s edited by supporters of a particular political candidate, or a book about fishing written by fishing enthusiasts.
Despite the sensational title, the article makes a great point: Successful wiki communities need focus and a common goal to attract the right people. The idea is that a community with a common focus is more likely to produce a cohesive product that reflects that focus, because people are remarkably good at organizing themselves around a shared goal, and the flexibility of the wiki allows them to use it in a way that’s best suited to their needs.
A good example of this is Wikipatterns.com. It exists to help anyone who’s using a wiki find strategies to give their wiki the best shot at being successful. Because of that focus, it attracts people with a shared interest and gives them a place to get information – in the form of patterns to apply and anti-patterns to watch out for and fix – which they can apply to their own wiki communities. When they do so, they can come back to Wikipatterns.com to share what worked really well, what didn’t and how they fixed it, and each time they visit the site they get more ideas. This cycle keeps building the content of the site, and enriches it with a variety of ideas and depth of knowledge that no one person could ever develop alone.
“Find Your Place in the Community”
Especially when people are first getting used to the wiki, it’s important that they do it in a way that helps them see how it works, even if that means the first information they put on the wiki is something seemingly trivial like directions for shipping a package or information about themselves in their personal profile.
People should be encouraged to find the role that best suits them, since this is an important factor in how well they engage with the wiki. A WikiChampion will be most visible early on, but new faces should become prevalent as people assume roles like WikiGardener and PageMaintainer, and become regular contributors of content. Fixing typos, finding citations for quotes, fixing broken links, and adding links where appropriate are just as important as adding new pages and contributing content.
People who volunteer to be involved with the wiki should be especially supported since they likely have the curiosity and open minded approach that will make them influential in building a successful collaborative community. Leaders on the wiki don’t necessarily have to be the people with official titles offline, either.
For example, if one member of a team shows the most initiative and enthusiasm about the wiki, the manager of that group might designate that person the point person or PageMaintainer for wiki for that team. The point person might then be responsible for recurring activities like posting the first version of the staff meeting agenda, reminding others to add their notes to meeting minutes, and training other team members on the wiki.
Think Process, Not Features
One of the most important differences between the traditional notion of enterprise software, and the wiki: with the wiki, it’s better to think in terms of processes, not features. The traditional thinking goes something like this: when you need software to do something specific, you look for a feature that does that specific “thing”, and if it’s not there, you try to get the software maker to add a feature that does what you want. This takes time – often a lot of time since the software maker has to decide if it’s worthwhile, add it to the software development roadmap, and actually develop it. It also costs more money for the software developer since its one more thing that can add to the time required to develop a new software release, and that cost can be passed on to you in the form of higher priced software.
This is where the wiki is different. When features are added to software, they can limit how it’s used because people think of the software in terms of those features. Software that’s not defined by its features is more powerful because people in countless different situations can think in their specific terms about how to use it.
When people ask me about building specific features into their wikis, I explain that instead of a feature, a clever process can achieve the same goal. For example, if people need to sign off on a document that’s been drafted on the wiki, they could simply add a bulleted list of the necessary reviewers right to the wiki page containing the draft document. Then each reviewer can mark their approval by putting a check next to their name or typing their initials. Presto, they’ve approved the content!
Since they’re not signing their signatures as they would have done in the past with a paper-based system, how can their approval be verified as having come from them? It’s all in the revision history! If the wiki uses standard network accounts, as would be the case in most organizations, each person’s edit to mark their approval will be attributed to their username in the page’s revision history.
Sometimes people need a solution and know what they need to get done, but don’t know exactly how to do it in a new tool so they think in terms of how they did it in the old tool. That’s why software often starts simple and becomes increasingly complex as features are added that can constrain its use. Because the wiki is simple and flexible, it’s easier to emphasize processes over features, which keeps the wiki simple, avoids that “feature creep”, and ultimately makes it more useful for everyone.
Make Change the Only Constant
Introducing a wiki and shifting core activities to it offers an opportunity to examine existing processes, workflows, and ways of organizing information. Forcing people to rigidly apply existing processes to the wiki is likely to make it unsuccessful, as these ways of working may run counter to people’s discovery of more efficient methods.
Encourage people to look for better ways to do things when they use the wiki, and improvements that are organically borne out of wiki use should be recognized, embraced, and rewarded. If people feel that they can have a direct impact on the way they work, and are rewarded for doing so, they’ll be highly motivated to keep examining and improving their own work. Change should be the norm instead of sticking to the status quo, and anything that promotes constant smooth change will keep each team, and ultimately the whole organization, from becoming stagnant and inefficient.
Flatten Your Organization…in a Good Way!
When you make the cultural shift to basing information and interaction on the wiki, you can’t just get work out of people and still maintain central control. When you start using a wiki, leadership has to shift to the community itself, and the structure of organizations has to evolve to become flatter so that it’s easier for people all across the organization to directly work with each other. In the academic world, technology is changing the role of the teacher from a so-called “sage on the stage” to an informed guide who can help students navigate the ever-growing information in any given field. This is a reflection of the fact that one person can’t possibly hold all the information, and control the direction of a community. Instead the person who knows how to navigate the available resources should serve as an enabler for the things the community decides are most important. The same is true for all facets of the business world.
This doesn’t mean your organization should become leaderless – it means adjusting the leadership structure to serve the community, enable it to get access to the resources it needs, and make motivated people’s work easier by enabling them to get things done.
One of the best examples of an organization that’s built this way is Mozilla. Its structure is open, adjustable, and highly community based. For an organization that builds open-source software and relies on a distributed community of volunteer software developers around the world to build its products, its job is to provide the core services for each product community, like coordinating the development roadmap for each project, maintaining the source code repositories, and planning releases, branding, and marketing. Not surprisingly, a wiki is one of Mozilla’s organizing tools: [http://wiki.mozilla.org].
Stay Hungry. Stay Foolish.
In his 2005 Commencement address at Stanford University, Steve Jobs’ parting words to the graduates were “Stay Hungry. Stay Foolish.” They came from the final issue of _The Whole Earth Catalog_, itself a product of the collective efforts of a community, and they perfectly describe the attitude necessary to bring about change. Introducing a wiki to your organization and changing your culture for the better is an exhilarating experience. It takes time and dedication, and if you’re the WikiChampion, a few odd looks the first few times you tell people about the “wiki”. But it’s worth it, because it creates an environment where everyone is empowered to _directly_ make things happen, which gives people a deeper sense of purpose and accomplishment. It’s also essential if you want to build a successful new venture, or ensure the relevance and success of an existing organization in this rapidly changing world.
- Jobs, Steve. “Text of Steve Jobs Commencement Address (2005)”. Stanford Report (14 June 2005), http://news-service.stanford.edu/news/2005/june15/jobs-061505.html (accessed 31 August 2007).
- Taylor, Chris. “Why commercial Wikis don’t work”. Business 2.0 (23 February 2007), http://money.cnn.com/2007/02/21/magazines/business2/walledgardens.biz2/index.htm (accessed 29 August 2007).