Motivations for collaboration: Innies, outies and petri dishes

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.

Comments

01 moshe
08/23/06 @ 13:50

nice piece, michael.

IMO, the key to gaining traction is enabling progressive popuarity (i just made that up). it is so simple to deploy wiki and blogs, that most organizations have some in their midst. no IT is needed for these tools. and as you say, a few people start using them. the vital piece then is how to gain the next wave of users. the wasy to gain them is to deliver value to them without much effort. a tool which only becomes valuable if most people use it is doomed to frequent failure. tools need to work well for 2 people, and then scale from there.

hmm, not sure i contributed all that much.

02 jibbajabba
08/23/06 @ 14:14

Thanks, Moshe. Progressive popularity sounds about right. In terms of blogs and wikis, sure Traction can come from people feeding off other people's individual willingness to share. In small, localized environments, that can absolutely work. If those hotspots of activity emerge, then it might affect the enterprise. The ability to scale up to meet demand is exactly what would work in that situation.

Advertisement
03 Paula Thornton
08/24/06 @ 12:37

The 'answer' is in the question: Where is the source of the energy? [speaking of karma]. When people do their work there are certain things they 'have' to do. For example, often people have to book their time to specific tasks and/or submit status reports. The key is to start from the "have to's" and branch everything else from there.

If we introduce something 'separate' -- it will remain true to it's design. No amount of cooersion will ever successfully break that design. The separation itself is inherently part of the design.

04 jibbajabba
08/24/06 @ 12:55

Yes, exactly. Start with the have to's.

In an enterprise environment, say we start with project management activities, e.g. reporting tasks, completion status, etc. We have a real need to communicate this information so doing it using technology seems obvious.

On the surface, it seems there's not much "opinion" or value judgement placed on PM activities. For the most part, while things like status seem to start out as binary values -- done or not done -- explanations might need to be appended to qualify not done. Or when the status is done, they might need annotation, e.g. "done, but with these provisions". So maybe it's not a matter of just reporting an activity and it's associated date, status, description. There are other bits that might need reporting as well. This is the stuff that I'm wondering about in my inquiry above.

Some type of CMS might seem adequate to do the reporting of PM activies. But does the richer annotation I discuss above get included in the system as well? It would valuable if it did, I think. But perhaps in the real world, that communication happens face to face after the alert has pinged those who care that they are affected. And thus the more complex communication HAS to happen face to face before it can be annotated again in the system.

Project management as a type of process is a good example to deconstruct because its information types, stages in process, contingencies, actors, etc. are well known. But the gray areas of communication that happens in the process is what's open for inclusion in a system. If you take that opportunity to include the communication/collaboration that often happens offline (i.e. in an unarchived or only locally distributed fashion) the design needs to be well integrated in the process of managing the "have to's" to have a chance at getting used. At least that's what I'm hearing you saying in making the distinction of branching from the core needs. Am I right there?

05 Matt Barkau
08/24/06 @ 13:55

The studies, benchmarking, and best practices literature you're looking for has been collected and shared by APQC. They've done some great work.

06 jibbajabba
08/24/06 @ 14:07

Thanks, Matt. Excellent resource! I just read through these 2 reports in the benchmarks section, which seemed relevant. Will start to look more deeply in the other areas as well.

This report "Failures in knowledge sharing seems to validate some of my assumptions."

With all of the money spent in knowledge sharing, much of it will go to waste unless organizations focus on learning from past mistakes and try to develop a different approach. In recent years, APQC has identified major barriers to knowledge sharing. In their book, If Only We Knew What We Know: The Transfer of Internal Knowledge and Best Practice, APQC Chairman C. Jackson Grayson and President Carla O'Dell point out four common reasons why knowledge is not
shared.

1. Ignorance. Grayson and O'Dell believe those who have knowledge don't realize others may find it useful. At the same time, someone who could benefit from the knowledge may not know that another person in the company already has it.

2. No absorptive capacity. Many times, an employee lacks the money, time, and management resources to seek out information they need.

3. Lack of preexisting relationship. People often absorb knowledge from other people they know, respect, and like. If two managers don't know each other, they're less likely to incorporate each other's experiences into their own work.

4. Lack of motivation. People do not see a clear business reason for pursuing the transfer of knowledge.

That's the kind of thing I'm looking for. Explains why people fail to share knowledge, and it doesn't have anything to do with technology.

Also of interest is the report "Cultural Barriers in Knowledge Sharing", which lists problems organizations have faced with knowledge sharing and how they were addressed. To focus on my inquiry:

Cultural barrierSuccess factor
Functional SilosSolicit senior leadership vision and active support.
Headquarters vs. the FieldInvolve users during design and implementation.
Language and Culture DifferencesAccommodate learning and sharing styles as well as provide translation tools.
“Fuzzy Concept” or “Bells and Whistles” Computer SystemDevelop operational KM definitions tied to business needs.
Perception of KM as a “Bells and Whistles” Computer SystemConcentrate on knowledge sharing needs and behaviors; IT is an enabler.
Lack of ParticipationFind and capitalize on passion, provide appropriate training, and use multiple channels for communication and promotion.

07 Tim 'avatar' Bartel
09/04/06 @ 13:07

Perhaps you are interested in my research in this area. I am running an online survey about Wikis in Enterprises also regarding Knowledge-Management.

You can take find it here: http://wikipedistik.de/survey/

It will be closed down in three weeks - shortly after you will find some results at this page. Thanks for your help.

08 hcp
02/21/08 @ 15:49

Tim 'avatar' Bartel : i see your project is outdated.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <strong> <dd> <dl> <dt> <i> <li> <ol> <u> <ul> <code> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.

More information about formatting options