Socialtext

Moving a portion of day-to-day work into a wiki can be a powerful boost. The wiki serves as the memory that helps you participate in many more conversations, with more detail and shared understanding, over time. You literally can get more done. But don't mistake the wiki at work for Wikipedia. At work, you have many more levers at your disposal to get things done.

Project work is a slow motion conversation

In fact, project work is many conversations, among many people. Any given project usually includes a core group and a wider group. Over time, all of these people are having conversations -- sometimes in email, sometimes in meetings, sometimes in IRC or on a wiki. Even the documents, prototypes and presentations we all produce are snippets of the ongoing conversation. They're artifacts of listening, synthesizing and re-engaging the team or the customer in one long, grand conversation that comprises the project.

Have you ever noticed how some people are better than others at carrying on a conversation -- an actual two-way (or multi-way) dialog? Some people listen then build upon what was just offered. When this happens, it's a genuine dialog. If done really well it can be dialectic, where two opposing views can join, at least in part, to create something new and perhaps better.

Other people however, instead of listening, are preparing in their mind what they want to say -- irrespective of what the first person is saying. When the opportunity arises, they jump in and take the conversation in their own direction. When this happens, the conversation grinds to a halt. It shuts down the dialog by snuffing out the reciprocity, signaling "I have interest only in what I say, your input, at least right now, is not worth my time." If one person indeed does have all the answers, and they have a perfect understanding of all others' utterances, and they can execute as an army of one, then this may be a reasonable approach. Typically it's a recipe for repelling teammates, sapping productivity and suffocating innovation.

Like any tool, a wiki can be used well or poorly in the service of a goal. The vast majority of customers I work with want to better engage the many smart people around them to solve the current problems at hand. Their goal is better collaboration.

One customer this week mentioned most of the people he works with are loving the wiki, but a few are enamored perhaps a little too much -- with themselves and what they write. When these individuals write on a wiki page, they delete what they don't like and "correct" the remainder. The result, it's no surprise in this group of adult professionals in a private work wiki, is annoying other members, and in some cases dampening participation.

A simple conclusion is that these individuals are carrying over their bad offline conversation habits into this new social space. Could be. Perhaps these folks are tone deaf to the contribution value of others. On the other hand, it's also possible that these individuals are accustomed to editing public Wikipedia articles -- where the goal is a single shared-voice encyclopedia entry -- and they are making a good faith effort to model what they've learned. They may be intending to improve the quality of discourse, but in mistaking the change of context, are actually diminishing the conditions for conversation.

In enterprise wikis, unlike Wikipedia, company culture reigns

Unlike the very public Wikipedia, private wikis at work are composed of named authors, who very often know each other, all of whom are making many types of contributions -- some may be draft documents, project plans or customer service responses, and yet others may be meeting notes, market updates, open questions or daily blog posts.

In Wikipedia, the convention is no one contributor "owns" a page. It is acceptable, in fact encouraged, to edit and sometimes delete others' work. In service of the encyclopedia entry goal, this is perfectly reasonable.

In companies on the other hand, convention, roles, group forming and decision rights vary wildly. Moreover, the team goal is typically not a public encyclopedia entry. One common project set up has sponsor who "owns" a decision and team members who are responsible for completing steps in the process and making recommendations and/or the final deliverable. Each person often owns a step -- which wiki pages, or a section of a page, are created for.

At work, task responsibility is named, and as a result, page authorship takes on a little more prominence than in a public wiki. Individuals may not "own" pages, but consistent with their role in the company, they may steward them. Regardless of who's edited, every wiki page clearly states who started it. The content, thankfully, is still open for discussion and re-factoring. Nevertheless, the person with the task is still responsible for developing it. Roles, expectations and accountability are very much a part of all work conversations, including on the wiki. As a result, pride of authorship for a page increases over that of writing anonymously on a public wiki. Even more so, people care about their contributions and how they are viewed by others. Your company culture reigns.

Which brings us back to writing on pages with colleagues. If my theoretical investment banking teammate Ed is creating the acquisition target list for the big client meeting pitchbook, I don't need to delete part of his list and scrawl over it in order to make a contribution. I can add a comment, Ed can choose to re-factor it in or not.

If the task is more elaborate, say deciding whether to have a proprietary or open-source business model, create a separate "Talk: page" (just like the discussions in Wikipedia). When a milestone is reached, or decision time comes, re-factor the discussion into the "official" page.

If a pair has joined to co-develop a workstream, work together in real-time face to face, or on a Webex or screenshare, or IM, where you can alternate taking notes. When the session is complete, post the output in the wiki.

If the discussion is urgent, call a meeting and have at it. Then post the result in the wiki. I realize it may sound obvious, but there's no reason not to make use of what your team set-up has to offer (you're not going to get away from the team set-up anyway). You're not an anonymous contributor to Wikipedia, you're getting your job done.

Sometimes I see customers getting stuck either in what they call a "wiki mode" or an "old work mode", as if they have to make a choice to use one or another. The relationship isn't either/or. Your wiki (and your meetings, IM sessions, and so on) are all part of the conversations that compose work. The wiki is simply the memory for those conversations.

Outsource the role of memory

The value of a wiki is not to replace all interactions, it's to remember them. More specifically, it's to remember them in a way that is easy to organize (link, tag, search) and recombine (copy/paste, include) for the relevant people (invite).

Work conversations are healthy doses of both context and content. While a team's conclusion often hinges on the fine distinctions, compromises and agreements that the conversations surface, the details of both the context and content can erode quickly. After a day of eight meetings, the highlights may remain in my mind, but re-constructing the richness more often than not needs some priming. If the output of any given conversation or meeting goes in the wiki, I can rely on that for priming two weeks or three months hence when the same idea becomes active again. Even better, so can the whole team, on their schedule, at the moment it's relevant.

Use the work wiki to help remember. Use it to steward your projects, gain refinment and agreement. Most of all, use it as part of your overall drive to get things done. And even though you've graduated from it, you can still hit Wikipedia on the weekends.

5 Simple Tips
* Assign responsibility for workstreams, and as a result, pages
* Use comments to add your thoughts without crowding out the person stewarding the task
* Rely on abundance, use talk pages for lengthy discussion, then re-factor the discussion into a joint page
* Pair live on IM or a screen-share, alternate note-taking
* Have a meeting, take notes, post the output