Community and social computing
The folks over at The Community Roundtable have released a new report on The State of Community Management which I thought was quite good.
A key takeaway from this report that I find quite revealing: it contradicts the common belief that all communities develop into a 90-9-1 rule (90% lurkers, 9% contributors, 1% authors). Per the report: “As the community management discipline matures, there is increasing understanding of where certain rules of thumb like this apply and where they do not.” I've once looked at the origins of this meme, and other than the Pareto principle, in online communities it dates back to specific posts in a Usenet newsgroup around the early 1990s. I need to find that link again. We now think of much more than just contributors and lurkers since there are many other ways to contribute as well which are not so obvious. That is a distinguishing mark that elevates the level of insight that this report brings above others.
What thrills me is that of the eight competency areas within, only on area focuses on tools. The majority of the focus lies in business principles: strategy, leadership, culture, policies, etc. The general media and blogosphere is always fascinated with new tools and toys but the real value is in understanding the almost unchanging business principles many of which are outlined in the list of competences. Each of the sections on these competencies specifically identifies lessons learned directly from the real life experience of members of The Community Roundtable.
I've talked before about the value that community managers bring to organizations, so I have to point out a specific section the role and issues of Community Management which can help current organizations understand the heavy demands of this role. Perhaps, with this insight, more organizations will take to heart that Community Management is not a part time, or a junior role in the organization. It takes a lot of people and relationship skills that develop with experience, and in doing so creates the same qualities we ask of our business leaders.
[I should say right ahead that I’m not picking on them (since I disagreed before), but when many good ideas come across from Hutch Carpenter and the Spigit folks, sometimes I just have to disagree.]
The article Maslow’s Hierarchy of Enterprise 2.0 ROI on the Spigit blog from last week proposed a framework for a pyramidal hierarchy of needs aimed specifically at ROI of Enterprise 2.0. They are correct in some ways describing a pyramid of levels starting at the base with tangible needs and moving up towards increasingly intangible ones.
I’ve linked to their image here, source Spigit Blog. [I may take this image off if they ask so but you can generally find it on their blog post]
However, I’m not so sure that it can be so easily applied here in terms of the levels. For one, Maslow’s theory indicates that humans cannot focus on the higher levels until the lower levels are satisfied. This would be nice to conclusively say this of Enterprise 2.0 ROI but I can give examples where it is very difficult to identify “cost-savings” at the bottom of the pyramid in a conclusive and replicable way, but easy to identify “employee satisfaction” somewhere around the middle.
Cost savings is a comparative; you need to determine that it is most efficient to do things with one or more e2.0 tools than existing or traditional non-e2.0 processes. The trouble is that this is not systematic across all e2.0 experiences. It’s not simply a matter of deploying a discussion forum, for example, to support customers before you start seeing results (even before you see cost-savings); in fact, there’s no guarantee it will ever become enough of a social environment where the vendor, partners, other users etc. are properly supporting the needs of a customer. In comparison, a support workflow, even if more expensive, has immediate results. Until the social environment actually does support customers, it is a cost-center.
However, even without knowing cost-savings per Maslow’s theory, you can use survey instruments to determine employee satisfaction. Qualitative measures such as “satisfaction” work best by gathering input directly from people; it’s simply something in their heads that you need to get to. This means surveys, interviews, and focus groups. However, it does get a metric—which ROI is—of the level of satisfaction, without ever having to find out if the social environment creates cost-savings. This is similarly so for “customer satisfaction,” and I’d argue for “cross-org collaboration” as well.
So, while the idea of relative dependencies and ranking of hard and soft metrics that indicate some beneficial return, I don’t think this approach works. The logic has some holes and I wouldn't be able to sell this idea to folks around here.