Transparent Office

Enterprise Adoption: Why wikis aren't like other IT

If you look at adoption patterns at the enteprise level, wikis are an unusual technology.
Most enterprise IT deployments are all about standardization and scale. A purchasing system reduces procurement costs by aggregating purchasing power across business units. A corporate finance system enables aggregation and standardization of accounting ledgers company-wide. An HR system enables standardization and cross-calibration of roles, titles, compensation bands, utilization rates, etc., across the company. The benefits of these systems are all about leveraging enterprise-wide scale benefits of aggregation, standardization, and cross-calibration.

As a result, these systems are almost always implemented top-down. Centralized functions (Purchasing, Finance, HR, etc.) partner with IT to mandate the implementation of these enterprise-wide systems. There's usually a struggle with individual business units, who insist that their needs are unique and Corporate doesn't understand the realities of life in the trenches. These traditional IT systems are implemented when the interests of the overall firm trump the interests of the individual business units.

Wiki as a technology tends to spread very differently across an enterprise. Wikis usually come into an enterprise through local, grassroots efforts. A group tries a wiki, likes it, and starts seeing business value. Other groups get wind of it and try it for themselves. The impetus is bottom-up from the business rather than top-down from the corporate center. It's a very different adoption pattern.

What accounts for the difference? I see three factors.

First, wikis are not a scale play. A single business unit, a single team, even a single person can derive business value from using a wiki. Of course the network effects are exponentially greater at larger scale, but there's a lot of benefit even without the scale.

Second, wikis are not a standardization play. Traditional IT systems are all about trying to limit variation and get everyone to do things the same way (often for good reason). Wikis area all about morphing, molding, and adapting to the way people and groups want to work. So the grassroots appeal is not surprising.

Finally it's difficult to force someone to use a wiki. It's relatively easy to force compliance around a Purchasing, HR, or Finance system: simply mandate usage and take away the alternatives. But the alternative to wikis is email, and who's going to take that away? People will use wikis only if they want to, so the adoption has to come from front-line workers freely choosing the wiki over other alternatives equally available to them.

Addendum 3/29: Since I posted this last night, I realized I overlooked the most obvious way in which wikis are different from traditional enterprise-wide IT deployments: economics. Thanks to SaaS delivery models like Socialtext and open source products, individual departments and business units can implement wikis quickly and cheaply. They don't need enterprise-level IT to get in the game. Over the long run, most companies will benefit from a more holistic approach to wikis, but the economics help explain why in many companies it's the individual business groups who are leading the charge.

Creating a Participatory Knowledgebase: 3 Best Practices

One of the most common, and thanks to Wikipedia most visible, uses of a wiki is creating a participatory knowledgebase--a shared knowledge resource that is created and maintained by a distributed community. I've built quite a few of these, first at McKinsey, and in my current role at Socialtext. Here are three top-of-mind high-level best practices based on pitfalls I've seen some companies start to fall into:

Structure by topic, not by organization. Every participatory knowledgebase I've ever worked on has started with participants assuming that the wiki's structure would mirror their own internal organizational structure. Bad idea. The whole point of the wiki is its ability to bring people together and connect dots across organizational silos. That won't happen if you structure the wiki around those very silos.

Lead with what you want, not what you have. Many groups, especially research groups, tend to use the wiki as a dumping ground for research they've already done. This research typically takes the form of reports which were written for a specific audience to answer a specific question at a specific moment in time. So the value of the reports themselves isn't so great. What is valuable, however, is the insights embedded in those reports. That's what contributors should be encouraged to post to the wiki. Put differently, a page called "Trends in Retail Channel Marketing" is a better wiki page than "2006 Analysis of our Company's Channel Marketing Spend". (Of course, the report might be useful as backup--so include it as a link from the main page on trends).

Link link link. New contributors don't cross-link. They're not usually averse to it; they just don't think to do it. Encourage them to "linkify" any term (yes, I mean any term) in their entries that is either proprietary vocabulary, potentially unclear to some readers, or describes a strategic concept where the company might have proprietary insights. These three criteria cover a pretty broad range of terms, and in even a short (e.g., 1-2 paragraph) entry, you can probably find at least a half-dozen terms that should be links...even if the underlying pages don't exist yet.

Work-in-Progress Culture

Much has been made in the last 5 years about the democratization of publishing and how the line between publishers and consumers of content is getting blurred. It's an attractive way to describe the trend. (Hey, who doesn't like more democracy?) But I think it misdescribes what's really happening.

The real paradigm shift in Web 2.0, I believe, is the blurring the line between publication and collaboration. In the old days, people collaborated in private. They talked to their friends and colleagues, wrote letters. Later they sent emails. All the real thinking happened in those private conversations. Eventually, once the key insights had been extracted, refined, and clarified, they published: books, articles, speeches, blast memos, etc.

To me, the really exciting thing that's happening in Web 2.0 and Enterprise 2.0 is that more and more of those private "pre-publication" interactions are happening in public (or at least semi-public). I think of this as the dawn of the "Work in Progress" culture. We no longer think that something has to be finished before we let strangers into the conversation.

There are great public examples of this. My personal favorite is the by-line on Chris Anderson's Long Tail Blog. Chris describes his blog as "a public diary on themes around a book". (If memory serves, it used to be called "a public diary on the way to becoming a book." I guess he had to change the by-line when the book came out.) What's cool about Chris's  blog  is that it's not exactly democratizing publishing. Chris is a veteran journalist, and he probably would have written the book with our without the blog. But the line between pre-publication and publication got blurred, and I'd wager that the book, and the public discourse around it, were far better as a result.

McKinsey on Informal Networks

Catching up on some back reading, I ran across Harnessing the Power of Informal Networks in the Q4 edition of McKinsey Quarterly. It's a really nice article, written by my friends and former colleagues Lowell Bryan, Leigh Weiss, and Eric Matson. Well worth a read. The main points, taken from McKinsey Quarterly's website are that:

• Most large corporations have dozens if not hundreds of informal networks, in which human nature, including self-interest, leads people to share ideas and collaborate.

• Informal networks are a powerful source of horizontal collaboration across thick silo walls, but as ad hoc structures their performance depends on serendipity and they can’t be managed.

• By creating formal networks, companies can harness the advantages of informal ones and give management much more control over networking across the organization.

• The steps needed to formalize a network include giving it a “leader,” focusing interactions in it on specific topics, and building an infrastructure that stimulates the ongoing exchange of ideas

What I particularly like about the article is the notion that managers can and should do things to foster the development and health of informal networks. Managers (or at least thinkers about management) have recognized the existence and importance of informal networks for a long time. But they haven't really tried to do anything to encourage them--except for heavy-handed attempts to formalize them with reporting structures and heavyweight IT systems. This article strikes the right balance between ignoring informal networks and squashing them.