Despite the investment of time and money Microsoft has made in the name of community, there are those within the company that look upon community as a resource drain that competes with the development of our products and services. I would argue that the activities that live under the umbrella of community are in Microsoft's vital interest.
Whenever community is discussed in a meeting at Microsoft, I sometimes wonder how each person in attendance perceives the value of community. Then I wonder about the people who chose not to attend because it was “just” a community meeting. I know to some, “community” means answering a newsgroup post or responding to an issue through the MSDN Product Feedback Center.
Instead of worrying what others think of community, I’ve tried to focus on what I think it is. The purpose of this post is to work through some of my ideas, and the ideas of others who have influenced me and clarified my thoughts, such as Etienne Wenger, et al.
Community in general is a very broad concept, but all technical communities share three common characteristics:
- Community Members. Technical communities cannot exist without community members. People and the relationships they form create the social fabric that holds the community together. Without the discourse among community members, a community simply doesn’t exist.
- A Domain. Technical communities focus on a particular domain, which is the common interest shared by all community members and represents the realm of possibilities. The domain also gives the community a common identity and sense of purpose. Because the scope of a domain can vary, communities can exist within communities as the level of specificity increases.
- A Body of Knowledge. Technical communities enjoy an ever-expanding body of knowledge. The core purpose of a technical community is to develop knowledge about the domain and share it with community members. To me, content is simply the persistence of community knowledge.
Take for an example the growing community around Visual Studio Team System. Its community members come from a variety of roles and backgrounds. The domain is a product, which is common for Microsoft communities. In this example, Team System is the domain. The body of knowledge has already been growing for years, but it isn’t equally shared across the community. A lot of the base knowledge is still locked in the heads of the product team members. Through blogs, forum posts, articles, presentations and books, we’re working to change that.
I think of the three characteristics listed above as forming a triangle (as you are inclined to do when you have three things to consider, right?) that represents the community. For now, let’s discuss the Team System community triangle.
By definition, the domain is Team System. The product we ship defines the realm of possibilities for this release. Our partners also contribute to the domain with additional products that help actualize some of what’s possible.
Team System community members join on their own volition by either choosing to build, use, or extend this product. They are attracted by the domain, but are not obligated to stay. A product-based technical community, especially a commercial one, can easily lose community members. Not every community member is an active participant. Studies have shown that participants are typically outnumbered by non-particpants, the “lurkers” if you will.
Now, the Team System body of knowledge is where I concern myself the most. As I noted above, the core purpose of a technical community is to develop knowledge about the domain and share it with community members. The greatest service a product team can do for its community is to impart as much of their knowledge of the product as possible. This happens in a variety of ways: documentation, seminars, Webcasts, blogs, conferences, books, magazines, technical articles, white papers, forum & newsgroup participation, chats, and the list goes on.
Fear, uncertainty and doubt, or FUD as it’s commonly called, exists in the absence of knowledge. Let's look at a few examples where a healthy community helps erradicate FUD:
- Let’s consider Team System pricing and licensing. When first announced in March 2005, there was a lot of FUD surrounding the topic. It was through knowledge sharing in the Team System community that the FUD clouds began to dissipate. We learned more about the community and in turn, the community learned more about the product and our plans. Because of that learning process, the community had an impact on those plans. For more information, see Rick LaPlante's post [listening to customers].
- FUD also arises when you can’t figure out how to make the product do something you expect it to do, or how to make it stop doing something you didn’t expect it to do. Without a community to support you, either interactively in a forum, or by accessing the community's body of knowledge – its content, you’re lost. Recently, a security update altered the way in which downloaded CHM files behave. This confused and bewildered many, including myself. I followed a hunch that it was security-related and I was able to determine what was happening. I blogged about it and helped clear the FUD clouds that were forming for some [Viewing Downloaded CHM Files].
- Knowledge sharing within a community helps expand the collective knowledge of the community. In my blog I frequently aggregate blog posts from around the world that I consider to be of interest to those in my community. Lately, I've been grouping them as "suggested reading". In many cases, the content is concerned with the larger techincal community related to software development. I never realized how beneficial this could be until I saw a post [The Power and Impact of Blogging] by Sam Gentile.
- I primarily use my blog to share & disseminate knowledge about Team System. To do so, I dig through forum posts, RSS feeds, search bots, internal mailing lists and more. This also helps me monitor the health of the Team System community - sort of a FUD forecasting tool. Korby Parnell calls this kind of blogging, human aggregation. For an example, see my New Team System Stuff posts.
- As noted in the first example, feedback from community members can also help clear out the FUD clouds for Microsoft. More than once, S. Somasegar (Developer Division VP), has noted the impact of customer feedback. Just take a look at his most recent post [Nulls not missing anymore]. In this case, customer feedback helped remove doubt surrounding a tough decision.
A community clouded in FUD is an unhealthy community. If the FUD doesn’t dissipate, the community will. Shipping the knowledge is just as important as shipping the product. Unlike the product, shipping knowledge is an ongoing effort. This is why Microsoft needs to care about its communities. This is why I care about the Team System community.