In helping companies cultivate communities of practice I frequently hear the following lament: this community idea is important but we just don’t have the time to get involved in yet another meeting. I can see their point. If you view the development of a community of practice like a project this will always be a problem. The project view, which tends to be the default, dictates a need for clear objectives, a defined time-line agreed and adhered to, and a set of tasks undertaken based on best practice lessons. The reality is that communities just don’t evolve in the same way as projects are rolled out. The project view employs a mechanistic metaphor applied to an organic phenomena. In a previous post I suggested we might develop a set of simple rules to help evolve communities. This post explores some simple rules for getting a community started which in turn suggests some possible interventions.
Back in 1995 Dave Johnson, Paul Shelley and I helped the Australian Geological Survey Organisation organise their scientific datasets. We wrote the project up in this paper. Our biggest challenge was in motivating scientists to document their datasets. To them it was a boring, thankless task. Our first attempt was a disaster—we just asked the scientists to describe their datasets for the good of the organisation. Nothing happened. Our second attempt was more successful. We created a new publication type called a ‘published dataset’ which was linked to the merit promotion scheme and performance appraisals. Perhaps most importantly the published dataset could be included in the scientist’s bibliography. Once the system was in place there was an instant line up. The conditions were right for action.
As our paper illustrated, the approach was based on helping the target audience clear three hurdles in order to spark motivated action. These hurdles, listed below, all start with understanding people’s needs because after clearing all the hurdles the outcome must satisfy at least one need. Here are the three hurdles:
- the activity must be easy compared to the output created
- the output must be appreciated
- the appreciation should lead to an outcome that satisfies a need
These hurdles provide us three perspectives for developing simple rules for community formation.
Simple rule 1: Participating in a community must be easy. Hold meetings on a regular basis—say the first Tuesday of the month. Make the technology dead simple. Avoid technology until you need it.
Simple rule 2: Someone ‘who matters’ must care about what you are doing. In the early stages it might be quite unclear how your community’s activities delivers business value. Consequently, the ‘people that matter’ must initially believe in the concept of a community of practice. More importantly, the core team and then the other members must care about the topic—nothing new there. Knowing what a group cares about can sometimes be difficult to work out. It requires discussions among members to discover the activities people would commit their precious discretionary time to. If you don’t find this, you don’t have a community in which case people will always be too busy. The choice here is to disband or persist in looking for a better topic. This is the point where your community activities should operate like a skunkworks. Low cost and exploratory.
Simple rule 3: Community activities must link to member needs. Remember I said the end result must link to a need. Some people need to be connected, others need public recognition, while some want greater access to power. Your discussions at the outset need to get a sense of the many needs your community should cater for. Running anecdote circles would be a good way to get people to express these needs.
Developing tasks that adhere to these three rules should remove the problem of people not having enough time to participate. Rather, you will hear a new lament: we just don’t have enough resources to support our community.
Listed below are links to weblogs that reference Motivating community formation:
» 3 hurdles to community formation from Monkeymagic
Following on from last post about trying to work some of the benefits of internet CoPs into intranet CoPs, there's some interesting reading over at Shawn Callahan's Anecdote blog. Shawn did some work on this while at IBM (as far... [Read More]
Tracked on April 26, 2005 2:08 AM