Library clips

This post is kind of a continuation of my community paradox post (also see Community Lessons, and The top-down and bottom-up creation of enterprise communities, and wikis)

I have come across an adoption issue relate to a structural issue…I have an example of a business unit of 3 teams combined into the one community, which is causing a fuzzy feel of ownership and low confidence to participate.
NOTE: all things considered with adoption and facilitation techniques, I still think we have a structural issue.

At the moment we have a community for our business unit (so it’s an organisational community), and our unit is split up into 3 teams (Practice, Technical/Support, Development)
It’s considered a good idea to have all teams in the same community because our work effects each other, we need to be aware of what the other is doing, and we can help each other out discussing issues. Plus all the conversations and information is in one spot.

Problem is this means there are lots of people in the community, and some people fear to participate because so many people are listening, and they don’t want to make a mistake in front of them all or say something stupid, especially that it will be immortalised for everyone in the company to wander around and see…in fact non-members are able to subscribe to content.

Role-models

As mentioned earlier we are employing adoption techniques such as championing, boss role modeling…but to tell you the truth this could be a little better, so before proceeding with the below suggestion of splitting the community, I will try to engage the team leaders to set an example. If one team leader is not participating and encouraging use, then that’s all it takes for failure.

I guess the problem stemmed from one team leader setting up the community, and other teams joining, but the other team leaders have not been incremental in doing their part, they need to actually lead their team in the community space like they do in other tasks.

If we were split into 3 communities

1. people in their own team space would be more prone to participate, as they are hanging out with their immediate peers and have more confidence (again, it’s a good thing the team leader always leads by example)

2. the community would be named after the immediate team, so they feel they have their own house to hang out in (an increase in ownership)

3. each team could at least be “guests” of each others community, this way they can have some sort of minimal participation

4. this means all the business unit info is split in many communities (this is the compromise)

5. we’d hope that each team would at least subscribe to the other teams communities, as we want to make sure each team is aware of what’s going on in the other teams…plus we want them to be able to interact if they have some handy know-how to contribute.
- but would this bring up fear of participation again because lots of people are listening to your contributions (as you don’t have to be a member to subscribe), my hope is that this effect will be lessened if they feel more ownership of the community as it’s named after their immediate team

Where do we communicate and discuss content that is pertinent to all teams?

This is where we could have a home community. In fact our communities have a feature where you can create a community, and then nest sub-communities (which are just regular communities, but at least they are all bunched together).

So that’s the paradox

1. splitting into separate communities is a good idea, as you are hanging out with the people you mostly interact with, you have more of an intimate shared interest…participation will more likely increase due to an increase in confidence

2. it’s a bit scattered, if you are looking for information you may have to search around in 4 communities, but if they are all nested under the home community we can search all 4 at once.
Also if you want to participate you may sometimes get confused in which community to use…but I think this can be overcome.

3. what I like is that some other development team in another business unit may come across our development teams community and hang out…this wouldn’t happen if we were in one community, as our development team would be buried and not as findable. But even if they were found I don’t think the visiting development team would feel as comfortable to participate.

Closing

The ownership and structure of a community can effect the level of participation, and the shared identity of the community.

In this situation we have an organisational community where we want to make sure we have cooperation, coordination and awareness between teams, but at the same time we want this to happen within each team. And if sharing a community with other teams is the main reason (other reason noted was team leader role-modeling) for the lack of participation, then we must consider splitting into smaller communities where there exists more shared identity and ownership which will naturally increase confidence and participation.

The other key is to to still have an ambient awareness and interact with the other teams, and I think this can be more cemented by having a home community for issues pertinent to all teams.