Session at Community Leadership Summit on Saturday July 18, 2015 at 4:30 in Session 3
Different communities may need to pull together into an "umbrella" community. There are separate communities to start with because they represent different people (such as designers versus marketing) and have a number of separate interests.
In one company, communities offer both technical support and business development. Can let one community know of something interesting in another community by creating a reference to it. Use tags to allow a community manager to mark something as relevant to another community. When the product incorporates some functionality, can work with documentation created earlier by a user for that functionality--don't worry about it before then. There's also a general site called the "bucket" for questions that don't fit anywhere in particular.
When a problem crosses multiple technologies, which community do you go to for an answer?
Think about your business model when deciding which communities you'd like to form.
To build an internal forum (rather than have everybody put questions on StackOverflow), make sure your engineers participate on the forum.
People tend to identify with the "tribe" in the small community more than the umbrella community. May be unproductive to try to get them to focus on the larger community.
Can also have one forum specialize in a different topic every week or so.
As a topic matures and subtopics emerge, can break out separate subtopics and have a conference about each. At a conference, look at topis people express interest in and come together around. Even if someone can't come to a conference, they might want to hear that it took place and what went on at it.