Tag Archives: structure

Community Managers and Reporting Structures

There are many differences of opinion about where the community manager or the community team should fit into the reporting structure of any organization. In general, I think that it depends on the type of community. The community management function should report to the team most closely connected to the audience you are trying to serve.

Too many companies automatically put the community function under marketing, which works well for certain types of communities, but can be disastrous for other types of communities. For example, developer communities or customer support communities should rarely, if ever, report to marketing. However, I do think that marketing should manage the communities for certain types of customer communities or communities that support a specific marketing campaign. Communities focused on a product line could be driven out of a product marketing group.

Developer communities and open source communities should be driven out of a technology or engineering group, since developer and open source communities tend to work best when they are created by developers for developers. Developers in general have very little tolerance for marketing and anyone who lacks technical credibility.

Support communities should be driven as part of the broader support organization to ensure that the customers in the community are getting an appropriate level of support. The support staff deals with support questions all day and are the most appropriate group to be answering the questions in the support forums and making sure that support customers have what they need from the company.

In some cases, the community should report to the senior management of the organization. Some communities cover multiple functions including developers, support, customers, and product information. In those cases, the community team should be placed high enough in the organization to be able to effectively interface with all of the other teams in the organization. If the community is a critical part of the the products or services offered by the company, it might need to be it’s own function within the organization.

It is worth spending some extra time deciding where the community function should be placed within the organization. You need to take a careful look at the audience for your community and place the community in the appropriate organization.

Related Fast Wonder Blog posts:

A Structure for Your Corporate Community

Lately, I have been thinking quite a bit about corporate communities as I work with clients who are in the process of creating new online communities or improving their existing communities. Earlier this week, I blogged about planning and getting started with an online corporate community and maintaining a successful corporate community. I thought that it would be a good idea to also spend a little time on the things that you should be thinking about when coming up with a structure for your community.

It is important to keep in mind that every community software package is likely to have unique strengths and limitations when it comes to configuring your community. From a design and architecture perspective, I strongly recommend looking at this strengths and limitations of the platform and taking them into account before starting any design or architecture work. Make sure that any customizations that you do will be compatible with the community platform and will be easy to upgrade to future versions of the software. I have seen way too many companies try to shoe horn a design that just is not compatible with the platform they selected. In most cases, they are able to make it work for the initial launch, but then spend way too much time and effort during every upgrade or even worse, they get themselves into a situation where upgrading the platform or applying bug fixes becomes nearly impossible.

You should also take a careful look at how much structure to put in place when determining the category or discussion forum structure for your community. The specific categories will depend on the type of community and your specific situation, but I generally look at these three basic approaches: emergent, highly-structured, and adaptive.


In an emergent structure, very few (if any) categories are defined before launch, and the structure is allowed to emerge based on the discussions that people are interested in having within your community. As the discussions unfold, you should start to see some common themes. New categories are created and discussions are placed into these categories based on the themes that are emerging in the community.

Advantages to the emergent approach.

  • It is certainly the easiest to implement when creating a new community, since very little is defined before launch.
  • User buy-in may also be higher, since the community members see themselves helping to create the structure by discussing topics relevant to their situation.
  • You might also end up with something completely unanticipated that works very well, but is something that you never would have thought of creating as a category.

Disadvantages to the emergent approach.

  • Community members may get writer’s block when faced with an unstructured community. If confusion sets in and users can’t figure out how to participate, they may never return to the community.
  • A few early members may take the community so far off-topic that it becomes useless for the purpose that it was created to serve. While this is much less important for a social community, it can be devastating to a corporate community.
  • It can be more difficult to maintain in the early days of the community, since you will need to rearrange posts into newly created categories.

I do not generally recommend an emergent structure for corporate communities; however, I could see it being useful in certain situations. In an environment where the industry or product was undefined or unclear and you wanted to avoid constraining people’s ideas into categories, allowing the structure to emerge might generate more innovative or unusual discussions. This structure is also more commonly and more effectively used in social (non-corporate) communities.

Highly Structured

In a highly structured community, all possible categories are defined before the community launch in great detail.

Advantages to the highly structured approach.

  • The company creating the community has full control over the community structure with categories clearly defined in areas where people should focus their discussions.
  • The community members have clear expectations about the types of conversations that are appropriate for the community.

Disadvantages to the highly structured approach.

  • It is a restrictive and inflexible with fewer opportunities for the community to take the discussions into new areas.
  • The company may also face more community resistance, since the community members did not have any input into the structure.
  • The end result might also be a structure that does not work for the community with categories that do not resonate with the intended audience.
  • Too many categories can also make the community seem very fragmented and give the appearance of less participation. This is particularly true if too many narrow categories are selected.

This structure may work fine in certain situations where the categories can be easily predicted and the environment is well understood; however, it can be a bit heavy handed. When it is used, I recommend sticking with broader categories rather than narrow ones whenever possible. Broad categories with more participation will make the community look much more active than if the same amount of participation is split among twice as many categories.

I made the mistake of using this approach when I created the structure for the Jivespace community. I defined way too many narrow categories and put too much structure in place. There were a few categories that people used most of the time, and a few that were rarely used. I would have been better off if I had defined about half as many categories or if I had used the adaptive approach described below.


The adaptive approach is really a hybrid between the emergent and highly structured approaches. A few very broad categories are created to get the community started in the right direction, and additional categories are created as needed after people start participating.

Advantages of the adaptive approach.

  • Better user buy-in, since the community members have some influence over the structure.
  • The company maintains some control over the initial structure to help ensure that the discussions fulfill the purpose of the community.
  • The community may also evolve in unanticipated positive directions that would not have been anticipated in advance.

Disadvantages of the adaptive approach.

  • The company has a little less control over the structure.
  • Getting user traction early in the process is required to help set the direction.

In most situations the adaptive approach is the one that I recommend. It is the most flexible, and it is fairly easy to implement.

Allowing Off Topic Discussions

When you create the structure for your community, you should assume that people will have some off topic discussions in your community. The best way to facilitate this without disrupting the rest of the community is to create a place where people can have these discussions. While they may be slightly off topic, I have found them quite productive for the community on occasion. For example, I’ve seen people using the community to find out which other members were planning to attend an upcoming conference on a related topic. As a community manager, I have used them to talk about interesting things going on in the company or the industry that did not directly relate to community. I caution against calling it something like “off topic”, since people may take you up on the offer to discuss too many random topics. I’ve had pretty good luck calling it “the lounge” or something similar.

Ultimately, the structure you select for your community will depend on your individual situation. No one structure is right or wrong for every situation, so you may need to experiment a little to get it right for you. During the beta phase for your community, you can get quite a bit of feedback about the structure allowing for some adjustments prior to the public launch.

You should also plan to adjust the structure over time regardless of which approach you use. The industry and your products will change over time, and the community structure will need to evolve along with these changes.

What are your tips for organizing and structuring your community?

Related Fast Wonder Blog posts

Fast Wonder Community Podcast: Approaches to Online Community Structure

I released the third Fast Wonder Community Podcast today, Approaches to Online Community Structure. In this podcast, we talk about how to best structure a new community and how to evolve the structure over time as the community evolves. I started by discussing the pros and cons of three approaches: emergent, highly structured, and adaptive. Listen to the podcast to learn more.

If you have any suggestions for people you would like to see interviewed on a future podcast, please let me know!

You can also subscribe to the Fast Wonder Community Podcast via RSS or iTunes.

Related Fast Wonder Blog posts:

Episode 3: Approaches to Online Community Structure

This episode contains the third of four recordings made during a recent discussion I led at the December Portland Web Innovators meeting. In this podcast, we talk about how to best structure a new community and how to evolve the structure over time as the community evolves. I started by discussing the pros and cons of three approaches: emergent, highly structured, and adaptive.


After these initial four podcasts, I am planning to switch to an interview format (via skype most likely), so if you are doing something really cool with your online community, please let me know! I am open to suggestions for potential interviews.

You can also subscribe to the Fast Wonder Community Podcast via iTunes.

Related Fast Wonder Blog posts: