Extending The Discussion

I love blogging. Your sweat and you write and you post -- and every so often you get the chance to have a detailed conversation with someone you'd never ordinarily engage with.

Such is the case today -- I came to work and found myself scrolling through a multi-page thoughtful comment from John Tropea. 

Rather than responding with another multi-page comment, I decided to put the discussion in a post, and respond (hopefully) conversationally.

John writes:

Hi Chuck, I have posted about top-down CoP creation, which seems to be in contrast to your bottom-up creation???...

Yes, that's true, we've strived to create an incubation environment where people (with a bit of effort and support) can create their own communities.  We took this approach for a couple of reasons, (1) we've got a sprawlingly diverse organization, so any top-down initiative would struggle, (2) we believe that the ability for motivated individuals to form communities is a key social media proficiency skill, and (3) we like any approach that doesn't require an inordinate amount of work on our part :-)

I'm gathering at EMC|ONE that people can create their own communities (I'm refering to page 21 of your paper) But I'm not so sure, as I recall an earlier blog post of yours referring to a community request form (actually we based our form on this)...is this still the case? (as this would make it top-down creation)

Yep, it's still the case.  The "request form" was nothing more than a speed bump to encourage people to think a bit about what they were doing, and how they were going to do it.  If you're sufficiently motivated, you'll fill out the form and peruse some of the guidelines and best practices.  If you're not sufficiently motivated, you won't make the effort.  And that's how it worked out.

With our latest Clearspace platform upgrade, we now have "groups" which are entirely self-serve and are more informal than communities.  Lots of action there, I tell you.

On one hand I like the idea of bottom-up creation because if people see the "create" button they will do it. Instead if they have to request a community they may never get round to it (time and formality is an obstacle) Also if they do it themselves they may be more inclined to create small groups, rather than feeling communities are a formal and large thing.

Agreed.  We wanted people to put a bit of thought into communities and design for more scale -- so an entirely self-serve model wouldn't have done that.  But -- not to be exclusionary -- the newer group function is entirely self serve.

For me, it's all about setting expectations: communities are a bit more formal, structured and purpose-oriented.  Groups are more informal, unstructured, freewheeling and social.

There are so many work emails I come across about pilots, fixing a process initiative, etc...and these people are using email rather than a CoP. I feel they may use a CoP if they did not have to wait and go through a formal process, and rather just create them themselves. In saying this our CoPs are not very task oriented like Basecamp, even though they have the same tools (blogs, forums), Basecamp is designed for tasks. Does Clearspace handle tasks well?

We are slowly starting to wean ourselves off of email, but it will be a long journey.  For us, groups fill the need of quick-and-dirty social spaces that don't have to be persistent.  Although Clearspace supports the notion of tasks, we have elected not to use it.  Mostly, we see our efforts focused around connecting people and starting discussions, and not putting them on a task management treadmill!

Don't forget, we also have self-serve SharePoint and eRoom and file shares at EMC.  Bazillions of them.  The trick is to expose the conversation to others who may be outside the tight circle, hence the "no private communities" mandate at the outset.

You mention overlapping CoPs and that those CoPs can work it out on their own and merge. As Dave Snowden says it's better to have a few CoPs on the same topic if it means people feel confident to share, compared to a bigger CoP where they don't trust each other, even though it's the same topic...people like to have their own comfortable house and crew to hang out with.

One caveat is, if it's a Business unit(team) using a CoP, then there should only be one CoP for this. We feel if people create their own we will be littered with inactive CoPs due to people not knowing how to use them.

We have a mix of both -- some communities are clearly business unit driven, others are more overlapping.  In larger organizations, you'll probably have both.  Just so you know, we had a few business units that insisted on the top down approach and didn't execute, leaving several informal communities carrying the load, so to speak.

We could mitigate these with putting them in an inactive directory (to separate them from the rest). Then our job would be to monitor new CoPs, and say "we noticed you created a CoP, let's set up a meeting so we can set you on the right path on how to use the tools, best structure your community, and how to facilitate and sustain a community (people need time and passion to run a community)." At the moment we are having this discussion (along with the request form) before the CoP is created. Then we create it and give them tips to run a pilot, so it gives them time to learn the tools, and populate it before they open up.

Yes, but we have found this incredibly resource intensive -- just one community can consume many hours of patient discussion and feedback over many weeks.  For example, we've got close to 200 communities, and if you do the math, you're talking 5-7 people that do nothing but this, which is an unlikely investment scenario.

We elected to create a "heat map" of high-impact communities to spend our time on; and leave others on their own, so to speak.

What I like about our creation approach (top-down)is that before the community is created a lot of things have been thought out on structure and scaling, the last thing we want to do is merge and split CoPs later, as migration is a headache. It's also gives them a good chance for adoption the first time, as sometimes you don't get a second time.

You and I share the same concerns, but we might differ philisophically.  We wanted to learn from the journey -- making mistakes, celebrating successes.  We explicitly resisted the temptation to over-organize and over-control how communities were formed, grown and rationalized.  Not everyone is up for that sort of controlled chaos, though.

The only reason I would encourage bottom-up creation is that we would see more informal CoPs, as the user can instantly create one with a click. Our task would be then to have a meeting immediately so we can set them on the right path. Perhaps this is a good hybrid...bottom-up creation (empowering the user), but then catch them as soon as they come out the gate. Not sure how viable this is if too many CoPs get created to keep up with.

Well, in our environment, there was so much activity that we couldn't keep up.  The groups concept seems to be working well for us so far, in effect elevating communities to more formal constructs that require a bit more rationalization, focus, and so on.

With top-down creation we may be a bottle neck (slower creation, or no creation-as people decide to request another day, but never do), but at least the CoP is thought through, comprehended and started off on the right foot. Right now our CoP platform is not as easy to create as a Facebook group, it's a bit more robust, so the design has also led us down the top-down creation.

All I would suggest is that your team not get too wedded to their way.  We made a bunch of initial assumptions -- some of them were right, some of them were wrong.  What I think held us back was the natural human tendency to enforce rigidty and discipline at the expense of being responsive to people's needs.  Every assumption, guideline and procedure should be up for debate as you progress.

I'd love to hear your thoughts on this. Here's my blog post: http://libraryclips.blogsome.com/2008/12/18/the-top-down-and-bottom-up-creation-of-enterprise-communities-and-wikis/

-------------------------

I hope this was the sort of response you were looking for!

Comments

[John Tropea]

Thanks for your great response.

Just to be clear - do you have 2 things
1.communities (more formal and purpose based)
2.groups (more informal)

As you say "groups" are bottom-up creation.

What about "communities", are they bottom-up creations as well?

And how are they different?

OR, with the new release of Clearspace is the community module more informal and changed its name to "groups"?

I recall the new release was more akin to Facebook, where you have a social network, and can also create groups?

Sorry for all the questions

[P. Quinn]

Mr. Hollis--

My apologies for butting into an ongoing conversation. I'm the project manager for the Kansas Transportation Online Community (www.ktoc.net), which is, so far as we can tell, one of the very first OCs operated by government for the purpose of public outreach.

It's a strikingly different platform than EMC/ONE, but "A Journey In Social Media" has been critical in bringing it to life. I cannot count how many lessons I've learned from this blog, which ought to be required reading for anyone thinking of applying social media to large applications.

As we lurch ever-deeper into the uncharted waters of Government 2.0, I'll be keeping a close eye on your experiences. Bravo Zulu, as we used to say in the Navy. It means "Well done."

Thanks again.

[Chuck Hollis]

Mr. Quinn

Words of appreciation like that make it all worthwhile. Thanks for taking the time to leave a kind thought .. it makes a big difference!

Best of luck with your personal journey!

-- Chuck

[Ted Hopton]

Hi, Chuck,

Loved the way you chose to write this post. I've actually encountered John Tropea in the Clearstep community recently, so hello to you, too, John.

There truly must be a balance between top-down and bottom-up, but that doesn't mean they have to be "equal." In our experience so far (we're 5 months into our Clearspace implementation), we have seen rapid growth and adoption. The model we've adopted is heavily weighted toward bottom-up, but we've overlaid it with a loose governance structure.

Our company consists of a dozen separately run business units, so we charged each unit with creating a steering committee and selecting at least one local community manager. What we have seen so far is that the single biggest key to successful adoption and development in these units is the local community manager. The strongest, most active and skilled community managers are associated with the most active and mature communities. It sounds obvious when I say it like this, but we had no idea there would be such a strong correlation when we started out.

The local steering committees have not had as strong an impact as I would have predicted (at least so far), but again there is a correlation between steering committees that take a true leadership role in their units and community effectiveness.

Overall, however, we are allowing and encouraging user empowerment and the results are inspiring. We have a long way to go and much to learn, but I am very encouraged by the developments so far.

Thanks, Chuck, for your invaluable and inspiring blog. I recommend it to everyone who asks how to learn about developing social media communities.