This week I'll be starting another new stage in my career, as I take on the role of Director of User Experience at Traction Software, Inc, marking my return to the subjects you've read me blogging about in the past: design of information retrieval and content management systems, knowledge management, and social networking and social software for the enterprise.

It's with great pleasure that I return to work on the application I used as a client, and to the team that I contributed some interface design work to over a year ago as a consultant. You'll be reading me return to blogging about the topics I mentioned above, but this time from the design and product development end of the conversation. Previously I wrote mainly about grassroots needs for social software and km and how blog/wiki tools meet these needs. In addition, I expect to show details of the application and its use for various forms of personal and enterprise knowledge management. I've used this tool in the past on a range of needs, including serving as a tracking system for usability testing issues, documenting project information (wiki style), and simply for logging my own projects and todo lists (personal km style wiki).

There will be more to come. I look forward to sharing with you.

Someone asked me the following question:

I'm considering using a wiki as a documentation tool for a collaboratively written project. The main functionally I need is a table-of-contents navigation, probably similar to how a document tree or outline format nests links under a multiple categories.

In response, I wrote up the following review of some of the Wiki and CMS options I've used and am familiar with. This isn't an exhaustive survey of the solutions out there, but my report of solutions I have experience using feel confident recommending. Other suggestions are welcome.

TOC of Single Page

When I left Bell Labs, we were using Twiki and were using the built in TOC variable for pages. Like Word Processing table of contents, this works by editing your page naturally using headings, and then inserting a %TOC% variable at the top of the page. The variable automatically generates a table of contents based on the headings you've used in the page. MediaWiki features a similar TOC variable.

Twiki TOC

MediaWiki TOC

TOC of Multiple Chapters and Pages

If you're looking to create a document that consists of a series of chapters and pages, like a traditional book, then you might be more interested in Drupal's Collaborative Book module. This module allows you to create books with chapters, and assign pages to chapters in the book. You work organically by creating pages and assigning the pages in a hierarchical book outline. The Drupal documentation itself is built as a series of books.

The administrative display for organizing a book is really quite good.

I was working with a client that wanted to basically take a printed publication and later move their editing process to a web-based application that allowed them to provde a companion ebook. The idea of a living document suited itself to using Drupal's book module. With the module, they can create a site organized in chapters as the printed book is, and also export or print the book as a single page PDF.

I had been looking for literature comparing the behavior of Intranet vs. Internet users as follow-on research from a blog entry I wrote about Ze Frank's Web 0.2 presentation and in reponse to a colleague's comment on the subject. The harder questions came up when I began exploring the topic of Internet/Intranet culture. As the increasing community of prosumers push the use of technology, as Internet users flock to social software and collaboration sites, how does this affect users of technology in the enterprise. Are business users taking risks with information technology? If they're not, why not? How does this all impact the evolution of collaborative technologies and how does that information feed back into products.

What I ended up reading didn't really answer all of these questions, but did get me to start thinking more about the evolution of blogs as social software. But, first, I want to talk about what I did find in the literature. The observations I found about intranet users were totally obvious. Culture and politics are key influencers when it comes to collaborating on the intranet. I'd already been saying that in my blog presentations. It's obvious. No major surprises there. Nothing in the research or academic literature seemed to be illuminating beyond that.

In the middle of attempting to read through papers, Boris Mann pointed me to a comment referring to karma as a motivator for collaboration in Drupal. Boris suggested that we might get to a point using Drupal where karma could be the basis for incenting collaboration.

I began wondering how these ideas apply in the corporate enterprise if at all. "This is excellent", I thought to myself after reading through this. Drupal developers thinking about more complex problems related to collaboration and how they can be solved with technology. But, to return to my problem, is this type of enabling technology pointless given a culture where people are not inclined to share? I once called this type of space a clenched-fist knowledge culture.

This is the space I was most concerned about when this inquiry started, because I perceive large companies that don't have a rich participatory information ecology to be positioning themselves for failure when it comes to knowledge management. But, while I'm generally interested in the topic of how to help transform clenched-fist knowledge cultures into open ones, that's not where I want to spend my valuable cycles these days. Instead, I'm interested in what to do to enable participants when the cultural space is open. How do you help them express themselves in that space?

I was reminded of some KM vendor presentations I had been to a few years ago where monetary incentive was mentioned as one key to sustainability. I don't remember the names of the products, but I found the suggestion interesting, but philosophically wrong. Years later, the explosion of blogs as the 99 cent KM solution emerged. The idea of incentive was interesting, but using money as the motivator was wrong-headed. With blogs we see that individuals may be more driven by selfish and unquantifiable incentives, e.g. self-promotion, prestige, authority, participation in a communal system because it gives back what individuals put in. These are not external motivators. They arise organically from within individuals -- from the grassroots.

In spaces where open knowledge sharing exists and where people seem to be getting as much from collaboration as they give, social software seems to fluorish. On the Internet, people take to Wikis, Weblogs, social networking communities and social bookmarking communities like mosquitoes to still water. Viewing the enterprise as a cultural petri dish, all you can do is set up the right environment and watch to see what grows.

For the most part, you can't simply drop social software into any cultural situation and expect it to "take". (I'm thinking about eggs attaching themselves to uterine walls as I write this. Sorry. Enough with the bad metaphors.) Install an enterprise wiki into a cold corporate space and no one will hear it die it's slow death. Perhaps a few users will exploit the technology, but if if the technology doesn't fit in with the culture, you're probably wasting valuable time. At a local level, this might not be the case, but in a large enterprise this might not cut it. Think of behemoth enterprises that drop SharePoint into the mix just because they can. Creating the pre-conditions for the right culture may seem to require withcraft or alchemy rather than business savvy. I can't tell you how to get that kind of change, although I'd like to see literature that talks to that issue.

If and when the cultural pre-conditions are right, then the enabling collaborative technology can be introduced. But we need to be certain that it focuses on objectives that provide value to users, that design for ease of use, efficiency, and relationship formation. When the object of the technology is relevant and the tool is implemented correctly, expression within an open culture may happen naturally and a rich, diverse ecology may emerge.

My recent post on Ze Frank on Web 0.2 continues my exploration of the topic of information use with regard to web users and the conversational nature of technologies that support peer to peer discussion, collaboration, and multimedia publishing. As you may know, the ideas about society, culture and the impact of these supporting collaborative technologies are cemented for me in the cluetrain and validated when the blogosphere and social software universe are viewed as information ecologies But what is missing is the literature examining the culture and behavior of enterprise users in these new technology-supported, social network environments.

In response to my post about Web 0.2, a colleague asked,

Does anyone address the question of the distinction between the public user/consumer and the organizational user/consumer? Speifically I mean that users of the "Internet" have desires and they have nothing to lose by freely expressing those desires whiteand pushing for tools to fulfill them. Whereas in the corporate environment there are politics, secrecy/info hording issues, and other factors that may cause "Intranet" users to silence, suppress or censor their desires, leaving us unsure what is really wanted. Or am I making up this distinction?

No. To my knowledge, no one makes that distinction in the literature or blogs that I've read. When we talk about Internet users, we're talking about the public and for the majority of the time we're talking about young , middle to upper class consumers who are active users of ecommerce and social software sites. They are the ones playing with social networking, creating, editing and publishing multimedia -- having conversations using the traditional language of the designer. Consumers are becoming prosumers because they have the means and time. They take risks in breaking rules because they don't know them. They publicize their lives on Flickr, MySpace and YouTube, eschewing privacy because they're being raised in an era of blogs and reality TV. But the main point is they are conversing openly and without fear.

But the corporate environment is obviously different, especially with regard to large enterprises. We don't appear to have as consistent a picture of the corporate intranet user and their behaviors as we do of the prosumer. But my colleague's impression of Intranet users, while insular with regard to its picture of a large enterprise user, is most likely valid. The constraints of a cultural and political environment might affect this type of users' ability or desire to converse in these new media languages and engage in a culture of collaboration, open conversation and risk. I think the degree to which a corporate Intranet user will risk engaging in these behaviors is also dependent on the corporate cultural (e.g. an open culture like that implied at Google vs. that at an older, large enterprise) and on the influence of an employees participation in the more open, collaborative culture of the public Internet. A flickr and MySpace user who happens to work at a huge corporation might be more inclined to act against a cultural norm that's characterized by witholding knowledge rather than sharing it.

I haven't come across any references to published literature researching environmental influences of corporate users yet. But then, I don't spend any time searching deeply on that topic either, e.g. in journal databases. It's a good question. One that I hope to begin exploring. In the meantime, I'm going to ping a few colleagues to see if they can point to any research in this area which might be found, I think, in ethnographic study and incidental findings based on user surveys.

Update: Articles on this topic provided by colleagues

I received some great feedback from colleagues, which I've listed below. Also, see the references added in the comments at the bottom of the page. I will be skimming this literature in the coming days and report back on how they relate to my questions, most importantly this one:

When describing the difference in behavior between the risk taking and openness of the public Internet Prosumer vs. the corporate intranet user are methods discussed that make the evolution of the behavior of the business user more like the prosumer?

1) Lilia Effimova blogged the following.

Work of Dirk Stenmark on intranets (I referred to his paper earlier in knowledge vs. information discussion):

• Stenmark, D. (2005). "How intranets differ from the web: organisational culture's effect on technology (PDF)". Proceedings of ECIS2005, Regensburg, Germany, 26-28 May 2005.

I could also imagine relevant things in the work of Jonathan Grudin - one of his interests is in corporate adoption of "internet technologies". This one should be on the topic:

• Messaging and Formality: Will IM Follow in the Footsteps of Email? (MS Word) T. Lovejoy and J. Grudin, 2003. Proc. INTERACT 2003, 817-820. (PDF)

2) Nick Kings provided an article about the Ben Schneiderman's model for trying to describe differences in behaviour. Schneiderman's book, "Leonardo's Laptop" is available on Amazon. Nick touches upon it in a paper he submitted to a workshop on semantic tagging.

3) Abe Crystal offered references from ASIS&T Digital Library.

• Informational environments: Organizational contexts of online information use. Roberta Lamb, John Leslie King, Rob Kling.
• Maintaining knowledge management systems: A strategic imperative. Kevin C. Desouza, Yukika Awazu.
• INTRANET USERS? INFORMATION-SEEKING BEHAVIOUR: AN ANALYSIS OF LONGITUDINAL SEARCH LOG DATA. Dick Stenmark and Taline Jadaan. ASIS&T Annual Meeting - 2006 (ASIS&T 2006). Austin, Texas, November 3-9, 2006
• A Perfect Storm for Intranet Search: How One Company Navigates. Moderator: J. Gregory Moxness, IT Fellow, CTO Missile Systems, Raytheon

4) Boris Mann offered a related link on the topic of incenting collaboration. The topic references game theory, karma and corporate communities.

• Komment Karma -- "Private and Small World is game proof as there is no benefit in gaming it. (Except inside corporate communities. Workaround there is to ration the Karma so that it gets spent wisely)."

5) Stacy Surla offered this paper:

• Onomi: Social Bookmarking on a Corporate Intranet. (PDF)

6) James Robertson reminded me of their paper:

• When intranet discussion forums work

7) A colleague suggested that I look at the Sociology literature and work by Lee Sproul. He also told me to go back and re-read Shirky and Englebart on related topics.

• Social software as a term. Clay Shirky. Many 2 Many
• Social Software and the Politics of Groups. Clay Shirky.
• Re-Place-ing Space: The Roles of Place and Space in Collaborative Systems. Steve Harrison and Paul Dourish.
• Process, Work Practices & Social Software. Mike Gotta.

I like the meeting format described in this Business Week article on Marissa Mayer, VP of Search Products & User Experience at Google.

New features are digitally projected onto the right side of a conference room wall, big as a movie screen. Everything Mayer and others say is transcribed and projected on the left. Underneath both looms a giant mega-timer. Everyone gets an average deadline of 10 minutes. Mayer and her team add and subtract to the feature as time runs down. It is iteration at lightning speed.

While the formal quick pitch format is unnecessary in small groups, what makes sense is that this format allows for new features to be proposed with frequency high up the chain of command in a large organization with some amount of structure in terms of time restraints. I assume engineers working on the project can pitch directly to Mayer. The critique format also allows a good deal of iteration while exploring ideas so they can be worked on some more and revisited. This excerpt describes the process:

What's most fascinating to me is the projection of the demo on the screen and the immediate capture of the discussion, which I assume goes directly into that internal project management system they talk about. That's excellent. Capturing these trasactions of verbal communications, although using brute force methods of manual transcription, is what knowledge management is about. The post-processing and information retrieval in their system is what glues it all together. That they're openly capturing everything in these meetings is what makes it effective KM work. It's not so hard to imagine all the pieces fit together into a product or at least a process that could be sold as an idea for realistic KM at work:

• WebEx type presentation software
• Transcription (manual now, voice recognition later in the retrieval system?)
• Search mechanism with some simple hooks for metadata (parsing for based on minimal formatting conventions, e.g. "[field name]:")

If enterprise meetings all went this way, mining of the types of tacit information usually floating around in conversations might begin to mean a bit more. Taken too far it could make a lot of information also mean less I suppose, but who cares as long as we have bigger hammers to tackle the signal to noise problem in retrieval. So I'm wondering if that type of process could be adopted as a model and be rolled into a solution. I want to see more under the hood at Google.

Baseline has a feature story exposing bits about How Google works and what we can learn from them. Most of the story focusses on the unique infrastructure Google has been building to support its expanding needs. But most interesting to me is the small bit that takes a lok Inside Google's Enterprise. The article refers to Page and Brin's pronouncement in their IPO that the company is not conventional and doesn't intend to become so. And this appears to be true judging by the way they run the company internally. They won't follow the pattern of what's been done to run businesses in the past if they can find a better way themselves.

This is exactly the attitude that has slowly been building up a revolution inside the ranks at enterprises large and small. Knowledge workers, fed up with the way things are have turned away from conventional software to manage they way the work in favor of better, simpler applications that get out of their way and let them get on with with it.

The article talks about how Google uses a simple system that manages project information using relatively unstructured email as the interface. The system mails employees every week asking what they worked on the week prior and what they plan to work on during the current week. The response is parsed, fed and indexed into a searchable system that is open to the enterprise so that anyone else can track other employees projects that they are interested in. They call it "living out loud".

What they're doing is creating an open system that matches an open knowledge sharing ecology. That openness allows for the "cross pollenation" of ideas. Even better, it provides opportunity for the one thing that is driving nearly every aspect of the innovative web today -- open conversation. They're creating a system that better ensures sustainability because it works with an existing, accepted process -- communicating through email. This removes barriers to use because email is easy. The unstructured nature of the format also means that it can evolve with the needs of the system on the back end. The computer works harder so that the knowledge worker can just dash off a note and get on with their work.

Wow, right? That's revolutionary thinking, and it's so simple on the user-facing end that you hardly have any excuse for not participating. And opportunists that exploit the system by mining and tracking with it will benefit from it immensely. This is the evolving face of knowledge management. The idea of telling the technology to get out of the way so we can do work is what's driving the enterprise blog and wiki revolution. We all need to publish, share and collaborate, but we want to do it as simply and effortlessly as possible. Google embodies that idea completely inside and out.

Gerry McGovern makes excellent observations on CMS feature simplicity and sustainability of use in his article, "Complexity delivers short-term gain but long-term pain". He bases his argument on the "feature fatigue" phenomenon, cited by researchers at the Smith School of Business, which claims that most people focus on features when buying a product not on usability. The study notes:

"Consumers give more weight to a product's capability benefits and less weight to a product's usability before they use the product than after they use the product-despite the fact that a product's usability strongly influences their satisfaction with the product."

McGovern argues that the same can be said of CMS and that buyers of CMS should beware this tendency to be wowed by features over usability.

Feature fatigue and CMS

The Smith study focusses only on pre-purchase behaviors and perceived satisfaction during use. They say that it's only in the actual use of a technology that you can determine satisfaction. I don't know if the study mentions any data about sustainability, but the article on the Smith study implies that when users of consumer electronics are confronted with complex, unfriendly technologies they may eventually abandon them, as they say "chucking it in frustration".

I'm a believer that satisfaction is a good determining factor when it comes to sustainability and that another statement would also be true. If users are confronted with an easy-to-use technology, they will be more likely to continue to use it. You'd have to prove that, of course and I don't know if it follows logic to simply say that since unusable technology has one effect, that usable technology should have the opposite effect. But it seems obvious. I would go further to say that an even worse outcome is that if a given technology is necessary for running your business and that technology perceived as a user-hostile experience, that it will interrupt the normal flow of one's work and slow the company down.

Putting the feature fatigue concept in the context of enterprise CMS seems a logical analogy. However, there are variables in corporate environments that may make it difficult to make a clean-cut transition out of existing systems unless there is understanding from the top of what pains users lower down the chain. The concept of user satisficing—the tendency to select the first option given that can work for the situation rather than the "optimal" solution—is one phenomenon that contributes to the complex issue of use and sustainability. People make do with what they have.

That leads me to wonder what the path to change is when people have become accustomed to using complex software that is difficult to use? What factors exist in this situation? Are people on the low-end able to communicate upwards what they experience in terms of dissatisfaction? Is that information received? Can it be used to evaluate current technologies as successes or failures in supporting sustainable information management processes?

It may seem difficult to change in the direction of usability and satisfaction when you've invested heavily in technologies that are the cause of your pain. Moving away from a family of products may feel disruptive if bulk licenses are already paid for and staffed to support those specific technologies. But the bottom line for decision makers is that the payoff comes in business intelligence, the ability to make sound decisions based on experience. That past and ongoing experience is retrievable because your employees capture it in an easy to use CMS. Let's look at a few dimensions affected by ease of use to illustrate why it's an important element in affecting a company's bottom line.

1. Ease of use leads to satisfaction with CMS and sustained use
2. Sustainability leads to a richer information repository (CMS)
3. Rich information repositories lead to more meaningful information mining
4. Rich information mining leads to more informed decision making
5. Better decision making leads to fewer dollars lost and more business opportunities

In the end, it's about money. If you believe that ease of use leads to making more money, you start to take it seriously. We need to see some studies demonstrate that. But what we're talking about here in terms of actions is simply ensuring the satisfaction of your key asset, your knowledge workers. To put it simply, if employees are happy to keep adding reusable knowledge to the business, the business benefits in explicit terms that may be traced back to the information capture. If you want to prove it, it would seem that if you can capture longitudinal data to compare the flow of knowledge into the CMS with ease of use and satisfaction dimensions, then you can provide some insight into return on investment.

Evangelizing simplicity in the enterprise (the software user's story)

So the question for corporate decision makers feeling the pain of complex and unusable technology becomes, "how do we sell our company on the idea of usability as a strategic move?" If the revolution can't happen from below, the vision has to come from above. But the people above need to be convinced through the experience. Sometimes, the perfect pitch can go nowhere without concrete examples. The way you sell it is by demonstrating value through use.

First, point out success stories. If you read and agree with 37 Signals' popular ebook "Getting Real" then you don't need to be convinced that simplicity and usability can equal dollars. They focus on simplicity because it ensures satisfaction in 95% (or some high number like that) of their customers. That 95% uses 37 Signals' customers comes to 37 Signals because the specific solutions they provide are the antithesis of what they've used for processes like project management and collaboration. They want small, simple and efficient and they leave satisfied that they can get in, do what they need to do to collaborate or organize their stuff and get back to work. How's that for a productivity pitch?

Second, prove the concept. Set up real world demonstrations. Put it before people and show them how it works. Remove obstacles and make it easy. Provide an open testing period, do a super-short training screencast or cheat sheet and then let your staff have at it. You can set up pre-determined areas for activity and open up the system for personal information management. This way, users determine it's usefulness. But most importantly, they get to try it out and experience an environment that makes their information management process simpler and more satisfying.

I've been privy to demonstrations where vendors allow some testers to use their software beta in order to build up some excitement around their software's release. Vendors get potential customers to start experiencing their sofware ahead of releasing. And if they create an environment of open communication they also get to establish a relationship with their customers. Other benefits include word of mouth recommendations, feedback on improvements,and if their software is well received, better assurance of its use. All of this before they even release the software commercially. It should go without saying that a vendor would benefit greatly from beta tests.

As a CMS customer, a company could follow this lead and do the same thing, testing vendor software in an enterprise environment. Set up a private testing period for a select set of users and create an open environment of communication around it. Let the feedback stream in and use it to build momentum around the technology. If it's received as a simpler, more usable way of doing business, you're on the right track. Use the feedback to improve how it integrates with your processes. Use that feedback to get better usability improvements out of your vendor. When you're happy that your test users are satisfied with the experience, release it to the enterprise and keep the communication environment open.

Using simplicity as a design strategy (the vendor's story)

And how do you employ usability as a strategic factor if you are a software vendor? First, believe that ease of use should lead to satisfication with your product, and that usability in turn leads loyalty to the company in terms of renewals. I hate to sound like a Mac Fanboy, but the Macintosh Operating System is proof of that. Google search may be proof of that as well.

Consider that usabilty and simplicity is one of the key factors making weblogs attractive as replacements for complex CMS in the first place. It's the main reason that many corporates took the leap and tried this new thing, blogs as the 99 cent KM solution. Many were likely comparing the simplicty of blogs to failed KM solutions they bought. Use that knowledge to your advantage. Simplify your experience to show customers a better way.

When the software you have developed has evolved over time into a more and more complex environment, are you out of luck? Of course not. You step back, take a look at the customer's experience of using the software -- everything it evokes as they use it. Find ways to make it easier. Simplify where you can. Remove obstacles. Do whatever you can to take the pain away. Guage satisfaction constantly by listening to feedback and factor it back into improving the user experience with your software.

It may not happen over night, but making your software usable is a worthwhile goal. Overall, it's not impossible to change in the direction of simplicity. More concrete advice is to break the process down into smaller steps.

1. Cement your strategy with user experience and usability as a keystone.
2. Understand your users by creating personas that describe who your users are and what their goals are. Focus design on them (persona-based user-centered design).
3. Describe the use cases that apply to personas.
4. Describe specific scenarios for each use case above. What types of actions would they take with your software in order to achieve goals?
5. Prescribe improvements to the user experience that match with the expectations found in the use case scenarios. Suggesting flow and interaction improvements. Suggest usability improvements to elements of your user interface.
6. Validate the implementations and test against real people.
7. Use the feedback to validate information about the design process you just underwent. Iterate.

That's all there is to it! Well, no, there is a lot more to it, but this is a start.

Food for thought

The Smith study and McGovern's article should be enough food for thought. It's our job as users and makers of software to just understand that satisfaction can be improved when software, however complex or simple in features, is easier to use.

Applying the Smith study's consumer electronics research is just a start I think. It would be valuable if someone did longitudinal studies that track satisfaction and abandonment or sustained use in other areas, especially with regard to personal and enterprise productivity and content management software.

I'm starting to copy the simple bits of embedded Perl code I've used over the past few years. As you may know, my company has plans to merge with (or be acquired by) Alacatel. One popular form of knowledge management is to mine your people's processes, methodologies and assets before you fire them reduce headcount. I've already been pretty good at capturing the necessary bits about processes/methodologies on our Wiki over the past few years. I do this in case, as we usually say, one of us gets by a bus or something. Morbid. So, anyway, they won't have to mine my head. But there are little bits of actual code all over the place that I haven't captured for myself.

So I'm going to start doing some retrospective knowledge management for myself to capture some of the methods I've used on presentation-layer server-side scripting with Embperl. These are mostly the little subroutines that I think might be reusable. I'm not sure I'll ever work in Embperl outside of this place. I'm not even sure there are really that many people interested in Embperl out there, but if you are, you'll be able to find the scripts in Resources section over the next few weeks.

For the non-perl stuff (e.g. IA/ID-related processes and methodologies, html and css snippets), I've been keeping notes here on the blog as well as in my wiki. Not sure if I'll publish any of that though because a lot of it requires explanation. The nice thing about the little code snippets is that they're for doing very small things in Perl and are pretty self-explanatory.

Fredrik Wackå posted an entry related to the rise of blog consultancies that are appearing in the marketplace. In "Internal Blogging More In Focus - Blog Consultants Beware", Wackå makes the following statement about the dangers of pushing for the introduction of corporate weblogs.

It's one thing to for example build a personal brand with blogging for an individual. It's an entirely different thing to try to change corporate culture, working methods and so on with blogging as one of many tools. Where a good writer and decent businessman can build a blog consultancy to do the first, it takes strategic organizational and communicative competence to do the other.

I'm going to go out on a limb and agree with him here, although I'm sure everyone in the professional blogging consultancy market will disagree. Fredrik's point here, I think, is that weblogging is not just a technology that's introduced into the information ecology. There are aspects about weblog publishing that are directly related to how one views there place in the company and its culture. The point is well made in a comment left by Agile:

My experience is that corporate employees exhibit risk-averse behaviour in word and deed. In spite of the fact that the upper management will exhort iniative and outspokenness amongst staff. Because middle management will in turn punish such behaviour severely. Everybody knows that. So internal blogging will equally be a very sanitized version of what could and should be said.

Corporate blogs are effective and relevant when they're organically created out of a need to share from the grassroots, and not merely from a mandate chucked down from the C levels. It is, however, important to have the support of higher-ups for a weblogging culture to emerge. His point about lower-level employees avoiding the risk of stirring the waters or inviting criticism sounds acutely attuned to the type of behavior that tends to exist in large corporations. Because of lack of support or fear of reprisal for openness, people may tend to do as little as possible to keep their job and as much as possible to maintain the status quo. If the status quo has not included openly sharing/publishing information, then the shift to blogging will be pretty significant.

I'll reiterate again a point I made in past presentations about the importance of diversity and decentralization in the information ecology. For blogging to be useful, it has to grow out of one's own expressed needs to share. This keeps ownership close to the blogger and makes the probability of sustainability and success greater. I don't think you can effectively incentivize blogging from above. You can create policy to support an open environment for communication. You can create a technology platform to ease people into the tools to publish. But the real incentives to publish what one knows must come from the author. For the blog author to communicate genuinely and directly, they have to be willing and able to do so. This is the tipping point you are looking for. When the culture exists to allow people to feel comfortable to blog, probability exists that blogging may succeed in the company. If a consultant sells you on a technology platform, but fails to discuss users, the ecology of prospective corporate bloggers and their culture, they're selling you snake oil. The only up side to buying into a technology such as weblogging without having these discussions, however, is that you won't have to pay the huge pricetags that we saw with KM packages in the last 5 years.

I'm saying all of this above because I think the emergence of the business blogging industry is very much directed by the writing of those who are keenly attuned to the possibilities afforded to companies by this format. On the buying side, there are many high level management folks within companies that are buying the "blogs will help your company" sales pitches. But consultancies and prospective corporate customers should be aware that in your needs assessment and discovery process, the aspect of culture cannot be overlooked. Otherwise, all we are doing is packaging corporate messages, rather than allowing true conversations (in the spirit of the ClueTrain) to emerge.