Enterprise Social Network (ESN) groups: Can there be too many, and should they be public or private?

Originally posted Jul 21, 2017

Image for post
Image for post

Q: We have 17,000 Yammer groups and way, way too many are private. I personally believe the number of private groups should be less than 20 percent for a normal, large, global company.

Our current guidance on public vs. private is a bit weak: Private groups are suggested for projects and teams. Public groups are best for communities, as you want people from all backgrounds and businesses to be able to join.

A: 17,000 is too many groups in total. And having too many private groups is indeed a common problem.

Many group creators want their groups to be private. But private groups should only exist when there is an actual, specific, and valid need for confidentiality.

Even for projects and teams, public groups can be advantageous. Using the concept of Working out Loud provides transparency, allows for unsolicited help to be provided, and prevents problems from being covered up.

The following excerpts from 21 articles should be helpful:

1. Communities Manifesto: 10 Principles for Successful Communities: Communities should span boundaries; they should cross functions, organizations, and geographic locations. Minimize redundancy in communities; before creating a new one, check if an existing community already addresses the topic. Communities need a critical mass of members; take steps to build membership. Communities should start with as broad a scope as is reasonable; separate communities can be spun off if warranted.

2. To control or not to: only you can prevent redundant communities: One argument is that people are more willing to hold discussions in small groups with people they know and trust, and are afraid of posting in larger groups with members they don’t know. In my experience, most small groups struggle to become active, or to remain active.

Q: How many groups should an enterprise have?

A: Exactly one for each topic of importance to the organization and to its people.

An ESN should have a smaller number of groups, each with a larger number of members. A single, large group for each important topic, used for collaborating across all organizations and geographies, is more effective than having a lots of separate small groups for each possible subset of the topic.

The reasons for this include:

  1. Reaching critical mass (hundreds, preferably thousands, of members) for any group is the best way to keep a group active and continue to attract more members.
  2. Online communities work best when they cross geographic and organizational boundaries to facilitate virtual, asynchronous collaboration. Local communities work best when they meet in person, perform local actions, or participate in physical activities.
  3. Keeping things simple is best for both those leading the groups and those joining the groups. If there is just one group to join, that makes it easier for leaders to recommend it, and for potential members to figure out which group to join and post in.

3. Open the gates and tear down the walls; moving from “need to know” to “need to share”: My organization had a private ESN group. After it had been in existence for over a year, I asked if there would be any harm if outsiders joined the group. The answer was no, so we opened it up. As a result, others are now able to benefit from what is being shared. In the seven months since it was made open, it has grown from 400 members to 1,250 members. No attempt was made to grow or promote the group, but there is obviously a lot of interest in what we are doing and sharing. The open group benefits 850 more people, with no additional effort.

4. How to govern enterprise social network groups: If a group will include confidential or sensitive discussions, it should be private. Otherwise, it should be open.

5. Be agile, not fragile: Secrecy — Don’t give lip service to transparency while continuing to operate in a closed manner. Communicate frequently, truthfully, and openly.

6. Why won’t people ask questions in the open? Some people will just not ask in public. You can help these people by posting on their behalf.

7. Enterprise Social Network Tradeoffs: Some discussions and content need to occur in a private setting with a limited audience, but there should be a clearly stated preference for open groups.

8. Social Media Archetypes: Bashful — Those who post only in private groups

9. The Sound of Silence: Do it in private — Some people will type questions into a private chat, rather than ask them in public.

10. 8 reasons for working out loud and narrating your work: Multiple people may need to know what is going on, and you don’t know who all of them are; Provide transparency in thinking, decisions, and processes; Model the open way of working; Demonstrate trust.

11. What are you supposed to do in a community? People should post in public groups whenever possible, and only use private groups for truly private interactions.

12. 10 Sets of Knowledge Nuggets: Do good fences make good neighbors? Community tradeoffs — Should communities be open or closed, global or local, limited to senior people or not, open to both sales and technical people in the same community?; Nugget: What’s the harm of an outsider joining? There should be a clearly stated preference for open, global, and inclusive communities. The value of communities is largely due to the ability of everyone in the organization to benefit from participating in open and easily discoverable discussions.

13. Why share your knowledge? If I share, then others will apply the knowledge to their business, and we will lose our competitive edge. Actually, sharing encourages people to request that you apply the information you shared; knowledge is information in action, and this is what people actually want, not just written documents.

14. 16 Reasons Why People Don’t Share Their Knowledge — and what to do about it: They are afraid that if they share knowledge, people they don’t trust will misuse it or use it without attribution. They are afraid of asking or answering a question in public because it may expose their ignorance, make them appear incompetent, or subject them to criticism, blame, or embarrassment for sharing something improper or incorrect. Facilitate ways for people to establish trusting relationships through enterprise social networks and face-to-face meetings. Recognize those who ask, answer, and share in public, and provide ways to ask questions on behalf of others.

15. Does Size Matter in Communities? Group size is almost always the key determining factor of activity. Even a small, energetic team with high trust will not necessarily post to a group. They can benefit from having a closed team site to share information, but they will likely either talk to each other or email each other when they wish to interact.

16. Addition by subtraction: When to delete in Yammer: If a group will include confidential or sensitive discussions, it should be private. If you create a public group for this purpose, it may be changed to private. Look for those groups with inappropriate privacy (should be public, not private, or vice versa).

  • Make a private group public — do this with the consent of the group admin if they group’s subject is of general interest and the discussions don’t actually need to be private
  • Make a public group private — do this if a public group is discussing things that should be private, e.g., client-specific, confidential, sensitive, etc.

17. 5 questions to answer before starting a new community: Are people likely to want to join in sufficient numbers to achieve critical mass (100 or more)? They should:

  • Identify with it: view themselves as specializing in it
  • Be deeply interested in it, view it as relevant to their work, and want to deepen their understanding of it
  • Be willing to spend time learning and collaborating about it

18. Group Goals and Measurements: Publish a Group Health Report every month, and either nurture the inactive groups back to good health, or retire them.

19. Yammer Metrics: tyGraph for Yammer and SWOOP Analytics for Yammer

20. Types of Enterprise Social Network Groups: Here are eight categories which can be used to describe and organize ESN groups: COLLECTS — Community of Practice, Organization, Location, Language, Event, Community of Interest, Team, Support

  1. Community of Practice: work-related communities, open to anyone who specializes in or who wants to learn more about the subject; tend to be larger and public; tend to be based on a topic, role, or industry (e.g., Social Media)
  2. Organization: mostly top-down communications targeted at everyone in a formal organization; enable few-to-many communication; mostly public, but may serve as a cordoned-off area for people who work together (without outsiders) to make people comfortable; tend to be larger; (e.g., Human Resources)
  3. Location: used for people in a specific location or to provide information specific to a location; tend to be public, which allows visitors to a location to access information; (e.g., Chicago Office, Canada, EMEA)
  4. Language: used for discussions in a specific language; may be public or private, and large or small; (e.g., Portuguese Speakers in Brazil and Portugal, French Speakers in Canada, Spanish Speakers in the US)
  5. Event: used for sharing information related to a specific event; may be public or private, and large or small; examples include new hires who start on a specific date, tributes to late colleagues, photos from a community service day, and posts before/during/after a meeting (e.g., August 1, 2015 New Hires, Tribute to John Doe, Impact Day, Annual Worldwide Meeting)
  6. Community of Interest: non-work-related communities, open to anyone who is interested; tend to be larger and public; (e.g., Running, Photography, Music, Cooking)
  7. Team: collaboration within a project team, work unit, task force, or committee; limited to those people who are assigned to the team; usually small and private, for trusted colleagues only; (e.g., Project Cleanup, Finance Team, Merger Task Force, Holiday Party Committee)
  8. Support: get help or make requests to a specific set of people; enable many-to-few communications; tend to be public; provide archives, deliver transparency, and replace or augment other channels such as email, phone, instant messaging, or text; examples include call centers, help desks, specialized support, and transaction entry (e.g., Knowledge Brokers, IT Help Desk, Business Research Center, Book Orders)

21. 16 Knowledge Management Myths Debunked

Don’t Control

In the community realm, we often get into a debate about whether we should try to control the creation of communities. There’s not agreement on this. I have one position. There are other people who have opposing views. My own view is that there’s actually value in trying to limit the number of communities that any organization has. There are a lot of reasons to do this, but the counter-argument is that we should let a thousand flowers bloom and use survival of the fittest. Let there be 100 different communities all focused on social media. One of them will emerge and that’s the way it should be.

My own experience is, if you have 100 communities for social media, they’ll all die. None of them will thrive. There won’t be the survival of the fittest. There will be the death of all of them. Why is that? It’s because when someone tries to figure that out, and they say, “I want to go and learn about social media,” they look to see the available communities and they’re shown this bewildering list of, say, 10 communities to choose from, they’ll just give up. They’re not going to go pick one. They’re going to give up, or if they do pick one, they’ll miss lots of other people who would have benefited from sharing information or who could have answered questions.

The thought that we should allow there to be an infinite number of these things, in my experience doesn’t work well. In this instance, limited control has value. Get groups to combine. Make your communities so that it’s easy for the user to figure out which one to join, and to have critical mass where all people interested in the same topic can be together. You should try to prevent redundant communities, but it’s not because you’re trying to make some kind of top-down authoritarian control. Rather, it’s to respect your users — to give them an easy-to-understand environment where they know which community to join, and all the people can reliably be expected to be in that community.

We Need Our Own

Often, the reason for doing something is the belief that we need our own. I’ll be asked, “Can I have a community for SAP?” I’ll reply, “We already have one. Why don’t you just use that community?” They reply, “I need my own.” They don’t articulate it well as to why, but it’s generally some variation of we need our own. It could be for what they think is a valid reason. It could be “We need one just for this country that we’re in. I need a knowledge management community just for Portugal.” I’ll say, “Is knowledge management that different in Portugal from how it is in some other country?”

If they wanted to have conversations in Portuguese, that might be a valid reason, but if they simply want an English-language community that’s just for people in Portugal, then there are two problems with that: A, there aren’t going to be that many people in it; and B, they’re going to miss out on all the other knowledge management people in the other knowledge management community. Tell them, “You don’t really need your own” and try to refocus their energy to start their own new community into helping lead the existing one. In that case, the best advice is to say, “I’m glad that you’re excited to lead this new community. Let’s have you be a co-leader of the existing one. We can really use your energy bringing in your colleagues from the organization you’re in.” The alternative is to try to get a new one off the ground, which isn’t likely to go well.

Then there’s the narrow niche. This is where they need an enterprise social network group for a specific module of SAP. They’ll localize it even further. It’s going to be for Europe and the FI module of SAP. We say, “I don’t think that’s going to achieve critical mass. You aren’t going to find that many people. I know you’re excited about it, but you may be the only one in your community.”

We have seen people form their group and then write an initial post where they say, “Hey, everyone. We’re going to talk about the FI Module!” And they’re the only member of the group. No one is actually seeing their excited post. We need to help them understand and educate them and guide them, but we also need to help them to see that when you don’t get critical mass in a community, you generally don’t have an active community.

My colleague, Lee Romero, studied what number of people you need to have for a community to be active. That number turned out to be 200. If you have 200 or more, there is more likelihood of an active community. If you have fewer than 200, it’s less active. It doesn’t mean that there aren’t counter-examples. It just means that on average, if you don’t get to that magic number, it’s not as likely.

Written by

Knowledge Management Author and Speaker, Founder of SIKM Leaders Community, Community Evangelist, Knowledge Manager https://sites.google.com/site/stangarfield/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store