Some more thoughts about community structure and bottom-up creation, see past posts The participation issue from community ownership and structure, The community paradox, and The top-down and bottom-up creation of enterprise communities, and wikis.
The easiest communities for us are the cross interest or special interest communities like the “bicycle users group” or “bulk materials handling” as the people who approach us are the one’s that are passionate about the topic.
Whereas, existing organisational teams wanting to form a community are a bit harder as the team already has a structure and dynamic, instead of it being born in the community.
They like having order and one community being the definitive hub for a topic, but the problem is that this community is too big, and people don’t always feel comfortable participating in such a big circle.
Smaller communities are better as people trust their peers and feel confident to participate, plus they have a similar shared context, so community activity is to your calibre…soon it becomes your favourite coffee shop to hang out and talk with your favourites friends about your favourite topic.
If I have to merge my community or open it up to a 100 people, then my coffee shop loses it’s intimate character, my favourite topic may become diluted, and all these people, even if I warm to some, cannot all be my favourite friends. Secondly they won’t all share my dynamic and context, humour, and all the idiosyncrasies that made the original community warm.
So the originals end up trying to find a booth in this loud coffee house, until they find a new coffee house.
If I was in a large room I would be more hesitant to share, but if I was in a small room with my direct circle of peers I would have no problem sharing, in fact I would go off on diatribes. This is why people like email because you are confident to have thriving discussions with people you trust (but it’s a silo and not designed well for this purpose)
Two approaches to structuring organisational communities
NOTE: I’m not referring to the original “communities of practice” concept of people with like interests clustering together in a group, instead I’m referring to existing teams that want to use a community space.
1. Usually the lead wants to build a community for their people (a one stop shop of conversations and documents for their business unit). So we build a community for hundreds of people, and structure it by region or topic or sub-teams etc..
Now this is OK for essential communications, but for blogging and discussing know-how it’s not as smooth, as people are shy and confident to participate in front of hundreds of people, even if it is their business unit.
The idea is to create forums for people in the community, and if we see clusters of people swarming around a forum, then this may warrant to be a community in its own right.
The only issue is the forum will be buried in a community, and the homepage of the community may only be 50% immediately relevant to a given cluster of people.
There is also the chance that some people participating in your forum may slow it down, or steer the topic the wrong way…this wouldn’t happen if it was your own community, as you would be in charge of membership.
So, we like the idea of a general test bed community, and see what percolates into potential new communities, but we want to make sure the nature of this test bed doesn’t hinder participation from the start.
Eg. if one of the same forums was in it’s own community, would there be more participation
2. Another idea, much to the chagrin of the lead, is to have many communities, as now there will be more places to visit to find information, but that’s OK because we can perhaps aggregate or be able to batch communities together and search multiple communities in one go.
The gist here is having a global community for essential communications and questions, but to let people in the team create their own communities, and see what coalesces.
I’d like to see an experiment where you could compare this self organisation (bottom-up) approach to a planned (top-down) approach.
Anyway…
Ethos or not, if your tool is not a simple design people may create, but not use, and as a result you will get a huge support load. It’s a good idea offering 2 or 3 one page quick reference guides, but other than that people just couldn’t be bothered reading. They are used to Facebook where the design is so intuitive you don’t need a help guide, or if you do, there are pointers on the page for information or even help.
If the software is really well designed you don’t need a manual, and therefore you can go with a bottom-up approach where people can create communities.
The top-down model does not allow for any emergence whatsoever, it also clashes with a knowledge sharing and conversation model (people are more likely to participate in a trust circle, and the more shared context, the more chance you have of properly transferring knowledge). If you get overlapping communities it doesn’t really matter, because if you were to merge them into one you will see participation drop.
The messiness can evolve naturally into something we could never pre-define.
|
It’s not about the topic of the community, it’s about the people.
|
.
|
I think if people with like interests can find each other, then similar communities can also find each other.
|
NOTE: This post has not mentioned adoption and participation points of facilitation. Even if you do everything right, participation may still be lower than you would like. This is when the community leader needs to use techniques such as getting some regular bloggers, and sitting down with them and helping them post, for a month or so, till they gain traction.
If people still use email, the lead must discipline them into using a blog or forum (people are just used to routines, or fear new tools).
And lots more…
![email.png](http://services.nexodyne.com/email/icon/GxbiQvgbwBgCnw%3D%3D/oIp%2BJMQ%3D/R01haWw%3D/0/image.png"){kind=icon}
