Transparent Office

4 Solution Areas

One of the questions I get a lot is "What do you use a wiki for?" It's a fundamental question, but I've been frustrated for a while at how long-winded and imprecise the answers are that people give to it. So my Socialtext colleagues and I spent some serious time around the whiteboard talking about patterns we're seeing--not sociological or usability patterns, but patterns of business value being generated using wikis and other forms of social software. We distilled them into 4 core solution areas. I posted a page on them in Socialtext Customer Exchange, but I think it's worth re-posting here. If you'd like to read more, Ross Mayfield talks about the 4 solution areas in a recent interview with CIO Magazine.

---
Based on our experience with hundreds of customers, we have identified four core solution patterns that we see across customers. They're not the only ways to use a wiki, but they pop up in almost every enterprise deployment we do, regardless of industry. They are excellent examples of ways that wikis can help companies solve urgent, high-impact business needs. They provide a good starting point for any manager thinking about the business value of better collaboration. They're also a good way for internal champions of wikis and Enterprise 2.0 to engage colleagues in business benefits and potential opportunities.

Collaborative Intelligence

Collaboration across a distributed sales force is extremely important. Sales reps needs current versions of critical materials (e.g., marketing materials, the latest product specs) from Marketing and Product Development. Out in the field, reps are constantly gathering critical information about customers, competitors, and channel partners which needs to be bubble up to the center to inform product design and messaging. Moreover, sales reps are always reaching out to each other to ask questions, post observations, and pick up on the latest "buzz" from around the network.

Traditional collaboration across sales networks is rife with inefficiency and missed business opportunity. Most reps do not have a single place to go where they can reliably find the most recent product and marketing materials. Valuable competitive data gathered in the field is either not captured or bottled up in highly structured call reports. Conversations across reps are lost in the river of email.

A Collaborative Intelligence wiki can solve these problems. By creating a "one-stop shop" for the sales network, managers can greatly improve both the dissemination of critical information to the field, and the organized capture of critical information from the front lines. Collaborative Intelligence wikis typically include the latest marketing and product information updated frequently by Marketing and Product Groups, and robust discussion threads for reps to post questions and report observations from the field.

Participatory Knowledgebase

Timely access to the relevant up-to-date knowledge is critical in many areas, but especially to call centers, where success is literally measured in seconds. Call center agents need to quickly put their hands on the precise knowledge required to solve a customer's problem. This is especially challenging when the calls in question deal with exceptions, and agents can't simply rely on the standard "script". Precious minutes drain away as agents try to figure out who has experience with these exceptional questions or try to solve them for the first time.

Call center managers are finding their traditional knowledge management systems increasingly poorly equipped to handle exceptions. Rigid information taxonomies, complex templates, and elaborate approval processes delay by as long as 6 weeks the process of getting knowledge from an agent's head to the system. And in many cases, agents are so frustrated by their systems that they do not contribute at all.

A wiki-based Participatory Knowledgebase can solve this problem. By making it really quick and easy (and fun!) for agents to post questions, comments, tips, and tricks, the wiki dramatically accelerates the rate at which new knowledge is posted and disseminated. In such customers as Dell and Symantec, for example, we have seen knowledgebases grow to thousands of pages in relatively short periods of time. The result is not just a valuable knowledge asset, but a noticeable reduction in average call time.

Flexible Client Collaboration

In many industries, and especially professional services, seamless collaboration with clients is critical. Attorneys, consultants, accountants, bankers, and other advisers need to be in constant contact with their clients. They iterate frequently on documentation with multiple versions which need to be managed and vetted. They are constantly answering questions, discussing approach, giving and receiving feedback. All of this needs to be done on tight time-frames with busy professionals who spend a lot of time on the road and in airports.

Most client collaboration today happens through email. Documents are emailed back and forth with titles like "Draft of 2/1", "Draft_Jane_Edits". Comments are posted in reply to all emails which become harder to follow with each new reply. In the middle of it all is the busy partner, drowning in hundreds of emails a day from multiple projects.

Wiki-based client collaboration is different. By setting up private wiki workspaces, shared directly with their clients, professional services teams have a single, easy-to-manage place where they can put all the materials related to a project or client: letters of proposal, powerpoint documents, legal filings, product designs, to-do lists, meeting notes, etc. Because clients have access to the shared collaboration wiki, they can easily access the latest version of materials, and offer comments, questions, and feedback right in the wiki. The result is a satisfied client who can always find the latest materials and feels truly integrated with project team.

Business Social Networks

In today's dynamic business environment, few companies can "go it alone." Leading companies recognize the importance of surrounding themselves with an ecosystem of customers, suppliers, distributors, resellers, and other types of business partners. These relationships are invaluable, both for the direct value they provide and for the insights and feedback that a thoughtful partner can provide to a company.

The value of these business networks is limited by the fact that most interactions with customers and partners happens 1-1: A manager talks with his channel partners, or exchanges emails with a customer. Far more valuable, however, is a forum where channel partners, customers, and other stakeholders can talk with each other. Wiki-based business social networks can create conversations where all a company's strategic stakeholders--internal and external--can talk directly to each other to share experiences, answer questions, offer feedback to the company, and ideate on product and service improvements. The result is a rich source of insights for the company, as well as a highly energized and committed group of stakeholders.

Socialtext People is in-the-Flow!

Socialtext announced two major product announcements today: Socialtext People and Socialtext Dashboard.  I'm excited about Dashboard, but People really rocks my world.

A lot of the coverage of People is calling it "Facebook for the enterprise". That's a fair description, but it misses what it is to me the coolest thing about People: Its in-the-flow-ness.

I love the way Facebook, LinkedIn, and other social networking sites organize content around people and relationships. What I don't love is how very above-the-flow they are. Facebook and LinkedIn are places where you go to "network". Unless you're under 25 (which, for better or worse, I'm not), they're detached from the rest of your daily activity. A person's activities or experiences show up on Facebook or LinkedIn only when somebody makes a special effort to put them there. As a result, most of a person's activities don't ever show up. (For instance: I've run dozens of user feedback surveys, but you wouldn't know it from my LinkedIn profile.)

A few years ago, Lee Kempler and I wrote in the McKinsey Quarterly that companies need better ways to connect employees to each other based on their interests and expertise. Our core insight was that what matters most is not what people say about themselves, but what people's experience says about them. In other words, it is what people do in-the-flow not what they do above-the-flow that makes them interesting to connect and network with. The missing ingredient of social networking is connecting to in-the-flow activity that makes a person's profile and relationships meaningful.

Enter Socialtext People. Socialtext People isn't just an inside-the-firewall social networking tool. It's a networking tool that integrates with Socialtext wikis where people are doing their in-the-flow work: posting messages, drafting meeting agendas, taking notes, documenting processes, spec'ing products, and so on. You can see what people are actually doing, not just what they say they're doing. You can also see who they're doing it with.

That makes for an incredibly rich, detailed, nuanced view of a person's interests, activities, and expertise. It makes Socialtext a platform for a whole bunch of new and powerful activities:

• Identify true experts across the organization on even the most minute topics
• Find and connect with colleagues across the organization working on similar topics
• Conduct due diligence on internal "hires" for internal transfer or short-term projects
• Monitor employee or colleague activity
• Identify key influencers in the organization for change communications and post-merger management

You won't find that on Facebook or LinkedIn.

If you're interested, here's some of the buzz:
http://www.techcrunch.com/2008/04/17/socialtext-putting-a-little-social-intoenterprise-wikis/
http://mashable.com/2008/04/17/socialtext-people-dashboard/
http://www.webware.com/8301-1_109-9920967-2.html
http://scottschnaars.com/2008/04/17/socialtext-is-made-of-people/
http://ross.typepad.com/blog/2008/04/putting-people.html
http://advice.cio.com/c_g_lynch/socialtext_to_add_features_to_its_enterprise_wiki

Culture is a destination not a starting point

I was just checking out the results of the recent AIIM Survey on Enterprise 2.0. (My company, Socialtext, was one of the underwriters.) There's a lot of great material there about how managers perceive Enterprise 2.0. I was particularly struck by how prominently culture appears as a theme in the responses. There is a view out there that an organization needs to have a "culture of collaboration" culture in order to successfully employ wikis and other Enterprise 2.0 tools.

That view is dead wrong. I've seen wikis thrive in un-collaborative cultures. I've seen wikis fail in collaborative cultures. I've seen wikis thrive in an organization alongside failing wikis in the same organization.

Even within "non-collaborative" cultures, people have to work with other people. We've seen lots of examples of wikis being introduced into those cultures in very safe ways--to streamline and simplify existing business interactions within existing organizational silos. What tends to happen then, often quite organically, is that the members of the wiki start interacting in new and different ways enabled by the wiki. Then the wiki is discovered by colleagues in other groups who work with participants of the wiki and want to be connected to the network. As they join in, the wiki starts generating new interaction patterns and norms that cut across organizational silos. Voila! You now have cultural change, as workers collaborate in new ways with their colleagues across organizational silos.

When managers complain that their organizations "just aren't collaborative enough" to embrace Enterprise 2.0, it's probably because they're trying to go straight to the sexy stuff--all-encompassing, above-the-flow "internal Wikipedias" where everyone shares everything they know with everyone else. There are a few places where that kind of thing can thrive immediately, but most companies need to work their way up to openness, beginning with incremental operational benefits derived from better collaboration within existing boundaries.

Culture is a destination on the collaboration journey, not a prerequisite for taking the first step.

Pyramids and Hierarchies

I was talking today with Michael Kieran, our newest Customer Success Manager at Socialtext, about structure in wikis. As I've blogged about before, it's very important for a wiki to have some structure. WIthout structure, people get confused, lost, and according to my friend Barry Schwartz the author of the Paradox of Choice, depressed. At the same time, there's nothing more annoying than an overstructured website, where you have to click through link after link after link to get to the content you care about. How do we reconcile those two observations?

The answer is that a good wiki is structured around a pyramid, rather than a hierarchy.

Content in a wiki should never be more than one click away. Beyond the first page of the wiki (and maybe not even then), there should never be pages that are just pages of links. At the same time, all of that content should follow the  Pyramid Principle on which these are articulated at a high level first, then articulated in more detail further down. In other words, every wiki page should have content, but that content should contain structure (via links) that take the user down into more detail, or sideways into related topics.

Wikipedia is a great example of this, and I think it's one of the reasons why Wikipedia is so popular. Every Wikipedia entry has content. You don't have to click through a bunch of links to get to the good stuff. At the same time, each entry is chock full of links that take you into greater detail.

However, there is one important way in which the pyramid metaphor breaks down on a wiki: a link on a wiki doesn't necessarily take you into greater detail; it may take you sideways into a different topic. 

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.

A Moment of Clarity

I do my best thinking when I'm talking. That may sound funny, but it's true. When I write, I tend to overthink the issues and get ahead of myself. But when I'm talking to another person, or better yet a group of people, I slow down and spit out what's really essential. (I'm a solid E on the Myers-Briggs test.)

So it's not surprising that I had a moment of clarity the other day while talking to a customer. The customer had asked me how you launch a collaborative, wiki-based community. We didn't have a lot of time--I was late to pick up my kids from school--and I had promised him a 60-second answer. What I said was, "Look, it's really very simple: Structure, populate, review, invite, and garden." As soon as the words had passed my lips I thought to myself, hey, that's pretty clear. Maybe I should write it down. And now I have.

It's a good, and simple, way to remember how to do it. So I propose "SPRIG" as the acronym for remembering how to launch a collaborative community:
Structure the wiki up-front with stubs and links
Populate it with real content
Review what you've done within your core group and refine the structure as needed
Invite a few people who have relevant knowledge and relationships and will be into the idea
Garden the wiki content as things get going.

In my next few blog posts, I'll elaborate on each of these activities. So stay tuned. And if my tone seems conversational, now you know why.

BTW, "SPRIG" may not be the world's catchiest acronym. Maybe we could do "SPRING" playing off the first two letters of "Invite". Any reactions or counter-suggestions?

Supply and demand 2.0

A primary reason why I've started an external blog is to share and elicit insights about how organizations are using social software to improve the way they work. I do that by telling stories with morals.

I was talking the other day with the head of a Research department in a Fortune 100 company. His group had created a wiki which had gotten a little usage early on, but quickly turned into a dumping ground for a lot of traditional, published reports which were already being written. Somewhat useful, but not user-friendly, not collaborative, and not generating new insights or connections between people.

The wiki became a dumping ground because it was driven by supply. When the wiki was set up, researchers were told "Here's a wiki, put your research into it." That's what they did, but it didn't have the desired outcome.

The Web 2.0 orthodoxy might lead you to believe that a nebulous entity, "the Community", magically organizes content once it shows up in a wiki. But that rarely happens. Emergent structure happens only when individuals spend time doing the organizing. Most enterprise wikis, especially new ones like the Research wiki I described, lack the critical mass of participation required for that emergent organizing to take place.

The way out of the dumping ground problem is to position wikis as being demand-led rather than supply-led. The way to do that is to structure or "stub" a wiki in advance--before you invite others to join the wiki. Here's a simple four-step process:

1. Get a small group of core community members to whiteboard a high-level information architecture in the form of a few categories (not more than 4-8) and subcategories (not more than 1-2 levels deep)

2. Create a series of blank pages or "stubs" hyperlinked  to reflect the category structure

3. Assign each category to an individual member of the group to flesh out

4. Reconvene in 1-2 weeks to review what everyone has done, share learnings, and revise the category structure

Once those steps have been followed, you'll have a structured wiki which people will want to read. You'll have a core group of champions personally committed to the wiki's success. And you'll have a structure that encourages organized, thoughtful participation in line with the wiki's strategic business objectives.