Community Manager Appreciation Day, for me, is an opportunity to reflect on where we’ve been as a practice and as a formative industry, and where we are going.
There are vibrant & global conversations happening today and that makes me very happy. As someone who has invested most of their career building online (and offline) communities, it is encouraging to see the “tribe” come together for the day.
On the other hand, it occurs to me that the practice of building and managing online communities is in a critical place. With all the progress, we still have miles to go.
Consider other professions of practice: Imagine if Doctors didn’t agree on foundational concepts and definitions? Imagine if Architects didn’t agree on measurements and scales? Imagine if Musicians allowed themselves to be constrained by the theory they learned at university. I could go on – you get the idea.
Further, online communities as we know them are in a state of evolution: the needs and desires of the typical online “member” are changing; hosted platforms, social networks, mobile apps and in person gatherings are pushing the experience and identity of a community to the point of being ethereal and organizations that host communities are scrambling to make sense.
In short: What got us here won’t (fully) get us where we need to go.
Next year, what advances should we strive for in the industry and the practice of building online communities? I would love to hear your thoughts.
Bill Johnston 
6 responses to “A New Kind of Community Management #CMAD 2015”
I think one simple but effective change would be if the #cmgr community moved away from the word “manager” and more towards “steward” or something similar. If I had to guess where the term came from, it came from senior leadership in that particular organization who wanted to avoid angry customers. If we’re empowering rather than managing our communities, we’ll get significantly different results.
Bill, I think I read somewhere that you’ve facilitated unconferences, and it’s that sort of empower-the-participants mindset that I’d like to see brought over into the mainstream of the #cmgr community.
I think I first read the phrase “community steward” in Digital Habitats by Nancy White & others: http://www.amazon.com/Digital-Habitats-Stewarding-Technology-Communities/dp/0982503601
I think one of the largest constraints on Community Managers are having the right tools.
Currently there are several community platforms to chose from. While each has their strong and weak points, there are no clear front runners. There is a need to further consolidate the choices through mergers and acquisitions in order to speed up the process of combining the best parts of each into a more complete product. Some of the key areas that need to be improved are analytics / reputation management, maintaining customizations during the upgrade process, back end administration / project tracking and social / mobile device compatibility.
Of course the other constant constraint is in the form of funding not only for platform improvements but also for quality staffing. That is a whole different can of worms though.
Cy, I’m wondering what the result would be of a dozen community managers sitting down and mapping out their optimal toolset (what to include and what to not include). Has anything like this been tried?
Lucas, I think having a group of CMs together to map out the optimal tool set would be interesting. An uber CM would be needed to facilitate the moving pieces and keep the group focused. While there may be many disagreements on some of the finer points, a core set of agreed to minimum standards wouldn’t be unreasonable. I do not know if it was attempted in the past but Bill may have some insight there.
Hey Cy and Lucas – I don’t know of a comprehensive exercise to bring a large group of CMs together for product requirements / design sessions. My first hand experience with most of the major platforms is the largest customer and/or the ones willing to write checks for custom dev get their features in.
In many cases this leads to bloated platforms & hodgepodge feature sets.
I have to agree with Bill on the bloated platform and hodgepodge feature set in terms of customized code for particular companies. Sometimes the features get baked into next release of the product after some smoothing of the edges that make it more palatable.
While I am not sure if they still practice this, Motorola had a decent system for mapping upgrades to its Computer Aided Dispatch software for 911 centers. Each year they would collect a wish list from all of their customers and assign point values dependent on how much dev time would be needed to add the item to the next release. The customers would then receive back the lists and apply their votes to the items they felt were most important. This led to regional user group meetings where agencies would pool their votes to help assure that their highest needs had a better chance of adoption. The meetings also allowed the agencies to compare best practices and work arounds they had created.
While this wouldn’t be the same as a single commission to draft best practices it could be useful to any company that creates something similar if implemented correctly.