Lessons on the hard job of designing communities in the organization

Sharing is caring!

Summary : If communities have a real value for organizations, there are still few certainties about their positioning and management. Out of the work flow by definition, communities only create an indirect value for organizations, hence the fact there’s been a lot of efforts to bring them as close to the flow as possible in order to make them a produce a concrete and tangible value. Whether it lead to turn work groups into communities or give communities so much structure that they lose their agility and become a burden for the organization, many tactics reached their limits as it happened recently at CISCO that dismantled a system that what considered exemplary until then. The key question is to ascertain the maximum organizational acceptable effort to make the community work and setting up mechanisms that make the reuse of the intangible capital almost automatic into dy to day business activities.

 

Most people now consider as an established fact that communities fill a gap in terms of knowledge exchange and capitalization and collaboration. On the other hand, things as still very unclear when it comes to determine their positioning.

If we rely on the most basic and shared definition of a community, it’s a group of people willing to share and discuss a topic outside of any hierarchical or structured process. A community may have, of course, a global and permanent objective (ex : capitalizing and sharing best practices on a given topic) but no specific deadline (ex : deliver such or such thing, solve such problem before a given date). Even if the community may be encouraged to behave this way, members won’t have to comply with what can’t be more than a suggestion that has nothing to do with their job definition and appointments.

A fundamentalist approach to communities inside the organization would be to say “let those who make sense and really exist live, remove what prevent them from being active” and, most of all, “don’t think you’ll generate on-demand communities even if the topic looks legitimate to you”. The topic of a community can only be suggested and, in the end, it belongs to employees. communities can be facilitated, lightly managed but never imposed.

Most organizations are not comfortable with this approach. If followed, it will concern at best 10% of employees who want to participate and contribute in addition to their assigned work. As a matter of fact, since participation can’t be imposed, organization can’t rely on the community as they use to do with formal teams that must deliver what’s requested on time. They will produce, at their own pace, ideas, knowledge the organization will be able to use once available. The community has the control of its agenda or, rather, the organization can’t impose any agenda. There’s nothing bad here if we rely on the “fundamentalist” definition : the community creates intangible assets that have to be reused in day to day activities to create value, at its own pace. (Remember  strategy maps…)

But it was not enough for some organizations that tried to rationalize communities, to make them become operational entities. The purpose was to make the ROI of the community effort if not more predictable at least less chancy. That’s why some project groups were turned into communities only by moving from one tool to another. Why not, since it helped to justify the social network investment and because, in the future, projet management will have some community management components. Unfortunately, social tools are seldom designed for project management and the groups in question often suffered from such a move that what rather a matter of alibi than of ROI.

There’s also been attempts to institutionalize communities. The most famous and successful examples comes from CISCO. For CISCO, communities were business plan design and decision making accelerators. Nothing to do with our “good old communities”. For that matter they were renamed “councils” : temporary gathering of experts to produce a business plan. And it worked, providing one of the best case studies on enterprise 2.0 ever…until CISCO decided to dismantle its system. The reason ?  The community structure had an organizational layer that added to organization one and was beginning to make the organization more and more heavy than agile. (Note : that does not mean at all that CISCO is stopping their enterprise 2.0 program, they only seem to be changing their approach to communities).

It’s certainly too early to draw definitive conclusion, most of all if some facts are not made public. But we can start thinking about what happened. The more we want to make a community directly operation and “business productive”, the more the community needs structure. As Rosabeth Moss-Kanter said in the above mentioned post, when it comes to execution or production, self organized groups without hierarchy are a myth. So, the less the community is turned into something formal, the more it loses its agility while needing the implementation of command and decision structures that compete with the traditional ones.

As a conclusion, organizations seem to have three options to integrate and position their communities :

• Deep integration and heavy structure : real business value but organizational cost too big. (cf CISCO)

• Light integration and structure : chancy business value but acceptable cost (“traditional” community management”).

• Autonomy and connection ; that’s an approach I explained in many posts. The idea behind is to let real community live their own lives and only spend a minimum energy on them but to optimize the reuse of the knowledge and relational capital they produce in day to day business. Unlike the two previous approaches, it need a deep integration work on tools so that those who are unlikely to visit communities to find information have contents and expert profiles pushed into their business applications when they need to solve a problem of make a decision, in the context of the very task they’re carrying out. The good news is that some vendors have this in their roadmap.

Anyway, something must be clear for anybody. A community produces for itself and its members, not for the enterprise (not directly at least). Instead of helping communities that don’t exist to survive on a drip of making them so “in the flow” that they become unproductive and lose their serendipity potential, organizations, rather facilitate those that really exist, remove the organizational constraint that keep them in check and organize the reuse of the capital they generate in the context of productive activities. In addition to that, it’s better to “20-ize” or socialize existing structures by changing their flow, exchange, autonomy and decision making logics instead of trying to turn them into communities for the sake of having communities…that are not communities and don’t follow the same rules.

 

To end, I’d like to emphasize what is obvious at Cisco but so far from the 2.0 culture that it’s seldom tackled or mention. The existence (or implementation) of a participating culture, if we want to organization to rely on it, needs a real work on rules and arbitrations in terms of resources and time allocation. Having more and more collaborative opportunity slots with the same number of people, knowing the impact of interruption and re-focus on attention, does not look sustainable and I have not the impression that organizations are willing to “hire more to collaborate and produce more”.

 

 

Sharing is caring!

Bertrand DUPERRINhttps://www.duperrin.com/english
Head of Employee and Client Experience @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler
172FansJ'aime
12,579SuiveursSuivre

Articles récents