There continues to be great dialog on wikis in the mix of knowledge work in organizations. Ross Mayfield, of socialtext, has an excellent summary post on Group Voice that makes a good point to pick up this thread.

Its not a choice between one or another. The temporal structure of weblogs and logical structure of wikis are a complement for lasting effects. One of the more powerful patterns in an organization is how an opportunity is published in blog, possibilities are swarmed upon in blog conversation and then driven to consensus and outcome in a wikified document. After the outcome, the knowledge and its social context remains.

Both tools together create powerful effects for publishing, communication and collaboration.

Denham Gray calls attention to the key differentiating aspects of wikis in a comment he posted. His key distinctions:

• The power to contribute BOTH to content and structure - other genres require you post within a predetermined structure (blogs, bulletin boards, guestbooks, IM....)

  True equality - blogs have an implicit posting hierarchy - some get main board status, the rest are relegated to buried comments (if allowed)

  Collaborative writing at the most fundamental (text) level - this is very different from annotation, editorial commentary or letters to the editor!

  Open edit - you can change anything at anytime - no attributation, notime/ date stamps in wiki- just pure flow

Stuart Henshall recommends a look at NexistWiki and also offers several interesting reports on the use of wikis in working sessions (see The One Hour Wiki). Doug Holton at Ed Tech Dev offers a pointer to Tiki (and other CMS tools) for Teaching. One curious thing I've noticed is that wikis appear to be very popular in the Smalltalk/Squeak community. Here's one directory, for example, of Smalltalk Wiki Webs.

Next steps for me will be to begin frequenting a few wikis, installing a wiki somewhere I can play with, and looking for appropriate group opportunities where I can apply wikis. As if I had spare time I was desparate to fill :).

(part 1 and part 2 of my original posts on wikis)

[McGee's Musings]

Part of me is missing the Weblogs and Business Strategy conference in Boston, despite the excellent liveblogging going on from so many of the participants (topic exchange channel and Denise Howell in particular). My aggregator is overflowing with great input from the conference. On the other hand, the distance and the need to focus on my work at hand also provides a valuable filter for processing that input.

While my last several large posts have focused on wikis (part 1 , part 2, part 3) and the social dimensions of knowledge work, I want to shift back to the personal level of blogs. There's a thread to the use of blogs inside organizations that I want to spend some time exploring.

As blogs and news aggregators move from fringe activity to leading edge phenomenon, it becomes possible to talk about the design of knowledge work. Tom Davenport, for example, has a column in the most recent issue of CIO Magazine [via Internet Time Blog] that says it's time to look at improving the effectiveness of knowledge workers. He talks about a new effort by the Information Worker Productivity Council to study knowledge work tasks with an eye toward how Accenture and HP and Xerox can help (possibliy with an eye toward selling us something). That's great and I'll be following their work with interest. They've certainly assembled an all star list of researchers. I wonder if they'll be blogging their efforts?

Meanwhile, I'm interested in following the radically decentralized action research program now underway in the efforts of all of us knowledge workers beginning to narrate their work and share in their collective experiments at making knowledge work more effective.

Some of us are lucky or talented enough to roll our own tools. Moreover, they've been willing to invite the rest of us in as co-designers . Now, many of the tools already in our toolkits theoretically allow us to participate in a design process. They've been built by programmers, after all, and programmers almost always prefer to solve general problems with tools rather than provide highly specific solutions to specific problems.

Unfortunately, most of those programmers work in organizations where the marketing staffs graduated from the "have solution, will travel" school of marketing and really aren't terribly interested in having active customers who actually are interested in co-designing their tools.

In the blogging community, however, the offer to participate as co-designers is serious. Blogging tools represent my favorite class of tools--ones that can be abused in interesting ways, even by ordinary users. They grew out of their developers needs to solve their own problems. What becomes interesting now is the alignment between the problems of developers and the rest of us doing knowledge work.

Taking advantage of that alignment does demand that we take an active role in the design process. Knowledge work is craft work brought into the 21st century. As many have observed, knowledge workers own their own means of production. If we are craft workers and we are judged by the quality of what we create, then we have an obligation to be mindful about how we use our tools and how we fit them to our own needs. To be most effective, we need to take design responsibility for our own knowledge work environment. I'll grant that we are still only at the Visicalc stage of blogging and aggregators. But that does not absolve us of the responsibility to understand and capitalize on what today's level of technology can do for us.

[McGee's Musings]

KMPro with Mark Clare. Mark Clare argues that KM needs to step back and define knowledge before plunging forward with the "next wave" of knowledge management approaches or applications. [Knowledge Jolt with Jack]

I disagree.

I think that most efforts to define knowledge get hopelessly bogged down. The reason this happens is that the discussion is locked in an assumption that there needs to be a centrally managed agreement (at a minimum) about the definition.

I take a different approach. Focus instead on knowledge workers and knowledge work. Work on eliminating friction and hassles in their ability to do whatever it is they think matters. Attack the problems that are preventing knowledge workers from being as effective as they would like to be.

There's an old story that I've heard described as a Russion proverb. It says that if each one of us takes care of sweeping the sidewalk in front of our own home, we won't need streetsweepers. It's worth thinking about how that might apply to the world of knowledge work, both on the level of being an individual knowledge worker yourself and on the level of helping make the other knowledge workers that surround you more effective.

[McGee's Musings]