Lessons on the hard job of designing communities in the organization

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…)

[Read more...]

Can participation be mandated into communities. Yes…most of all when it’s not communities

Summary : organizations have to face a real issue about  managing their communities : making the system work without mandating. unfortunately there’s no alternative : communities rely on voluntary service. But there are two possible options. The first is, since it’s impossible to mandate participation, to tackle what prevent people from participating. The second is to wonder if the group in question is a community…and adapt rules accordingly.

Many organizations that try to harness the power of internal communities wonder if participation can be made mandatory. But they already know the answer : participation into communities rely on voluntary service and the best they can do is to create the conditions that will make employees feel like participating and understand how important it is.

There’s also  another lever. That’s not because participation can”t be mandated that it’s impossible to fight against what prevents people from participating. It’s obvious that many factors exist in the workplace that incite people not to participate. Job description,  goals, evaluations…are, among many others, strong signals saying “focus on your job, don’t put you at risk by joining this stuff”. Then, even before inciting people to play the game, rather start with what tells them not to. I remember people from financial group Hypoport speaking at the last Enterprise 2.0 Summit quoting their CEO : “wiki time is work time…”.

Then, remember that many of the communities organizations want to make emerge (I’m not talking about user generated communities) are not communities. So they don’t have to respect the art of managing communities. When your community has the same scope has an operational entity (team, department) and is supposed to be used to perform daily tasks through better collaboration coordination etc… so it’s a workspace, rather a socialized workspace. Since then, its rules are the team’s. What would you say to the sales representative who would refuse to use the CRM, the accountant that refuses to use the accounting software ?

The success of such group does not rely on content generation or of a community manager that would interfer with the real manager. It needs a model that fits employees needs, tools that fit in this model and some consistency into management. I remember of a director who said “the era of emails send to the whole department is over…everyhting has to be be shared in our new space. Same for the ideas I’m submitted, competitive watching, best practices etc…. This is also the only place where I’ll talk to you and answer questions that my interest everybody. It will also makes it easier for me to assess how collaborative and supportive each of you will be toward his colleagues in a transparent and factual way”. Let me tell you that “adoption” happened very fast. Of course, in the tool’s terminology, this group was a community but he knew that it was nothing but the way to fluidify his team’s daily operations.

A community will always rely on voluntary service. But are you sure what you’re setting up is a community ? Do you think it’s a part of people daily work to perform tasks that are part of their job description ? If so, that’s not a community, what does not mean that tools and operating models can’t be changed. Do you think it’s a voluntary contribution in addition to people’s “official” work ? This is a community and can be managed as such.

Setting up a pilot is not only a matter of sizing

Andrew McAfee recently raised the question Michael Idinopulos discussed some months ago :  is the concept of “pilot” relevant to enterprise 2.0 and should we drop it. Some (excellents) thoughts can also be found on Emanuele Quintarelli‘s blog.

In fact the cause of the discussions comes from some assumptions that are not always true :

1°) Pilot applies to over-the-flow activities

2°) The only thing that makes a pilot different from a mainstream project is the number of participants

In this case where reaching a critical mass is…critical, limitating the number of participants is an heresy that is equivalent to shooting oneself in the feet at the beginning of the projet. If something as to be limitated, rather limit the duration than the size (what was brilliantly done at CSC for instance).

That said, thninking that the underlying question with pilots is only about sizing may be a bit hasty.

1°) The question of a preliminary phase

Before going further, what matters is to know if a preliminary phase is needed before scaling up the project. Obviously the answer is yes : businesses need to be sure they can manage things and get some kind of benefits on a smaller scale before applying a new concept to the whole organization.

So the issue is not there but in what this phase is made of. Starting with its goal.

2°) What goal ?

I won’t elaborate too much since I already tackled this issue a few weeks ago. It’s important to know whether this phase aims at taming new approaches that will be implemented on a larger scale anyway or at assessing if the new approaches have to be implemented or not. The stake is not trivial : it’s hard to involve employees in something that can be shut down anywhen, with no certainty about its durability.

3°) What name ?

As strange as it may seem, the way this phase is called is not neutral. On the user side first (pilot = be sure we won’t give up…but may seem a little bit top down / experimentation : you are guinea-pigs, we don’t promise anything) but also on the business side, some namings making it easier to get the “strategic project” label and the exectuive sponsorship that comes with.

Maybe some have found the “magical name” that reconcile both needs.

4°) What kind of social experience ?

Maybe that’s where things should start. Deploying enterprise 2.0 logics and tolls is not about doing something uniform. As I mentioned in the past, there is “social for communities” and “social for teams“. In other words, gathering an undefined population around some topics and optimizing the “organic” functioning (departments, teams…) of an organization are two complementary but different logics. I won’t elaborate on the management and leadership differences between both and the difference bewteen conversations and interactions, what matters is that in the one case a critical mass is needed and in the other a deeper work on alignment and integration in workaday practices and actions is  key. In short, that’s one more case where distinguishing between in the flow and over the flow matters, and that’s a part of the pre-rpject analysis that’s too often overlooked.

The truth is that both approaches have to articulate and live together in the organization, so it should be the same in a pilot. In the other hand, according to the goals (it’s possible to experiment many social experiences at the same time) businesses should now that some experiences have a defined and limited number of participants by definition and some others need a critical mass.

So the matter is neither sizing nor “pilot or not pilot” : it’s about knowing what is aimed at, what the organization is trying to validate, assess, learn…and the rest will naturally come.

Are in-the-flow activities a cure against cultural barriers ?

The importance of culture on the success of enterprise 2.0 projects is now acknoledged by everybody. The issue was widely discussed at the last Enterprise 2.0 Summit in Franfort where I took part in a panel about it. Even apart from this specific session, culture was the hot topic in many discussions during the breaks and the lunches what proves that beyond the agenda of the conference this subject was naturally coming to the surface.

Besides that, let me make a short aside about that. I appreciated a lot to see some our overseas counterpart showing interest about this point. Even if Dion Hinchliffe can often be seen in events taking place in Europe, the attendance of Gil Yehuda who wanted to “see by himself how things were going here and have a better understanding of our context” (if I remember well his words) was a really good news. I don’t even mention those who would have liked to be there but couldn’t due to the closeness to the San Francisco Enterprise 2.0 Conference. In short, on the heels of all the discussions on  blogs or on twitter, both sides of the Ocean are beginning to get  closer, listen to one another and the idea that there is not one adoption model that is supposed to work everywhere emerges. So any international project has to take all local issues into account. In my opinion, discussions and cooperations between Europe and the US will be a major trend in 2010…

This allowed Gil to write two insightful notes (here et here) about his discovery of the german market.

Coming back to the conference’s discussions, it was very easy for each of us to find many example of cases where cultural issues impacted a project. Sometimes it was local culture (country or even region), sometimes corporate culture, or even language issues that are often cleared with the back the hand (“How course, all our employees are fluent in english and many other languages…”) and often come back as a boomerang. I also learned with interest by people from CSC that beyond the strict adoption, depending on countries, people do not necessarily use the same functionalities or don’t use them the same way.

In the “Culture hurts” series, competing to find the most painful experience was not hard at all. But, as conclusion was coming up, I felt that something was missing. Culture is obviously a key issue in many projects but…many projects went well without any problems due to cultural issues. Sometimes it was because culture has been properly addressed, but some other times it was because culture forgot to bother us. And, in my opinion, it was not always a matter of luck.

So I tried to quickly gather the common denominator of all theses projects (of course its only reflects my own experience). And the conclusion was obvious : most of times, the projects that successfully neutralized the cultural issues were those that favored the “in the flow ” dimension rather than the “over the flow” one.

This is also the difference between community management and team management : the first needs feeling like participating, conviction, and cultures plays a big part to make people decide whether to get involved or not, the second only needs people to follow the “official way of doing things” and, even if the cultural dimension does not disappear, it’s less impacting because people’s free will does not have much room.

I also found a corroborating voice in Andrew McAfee’s book (Enterprise 2.0) that also concludes that over the flow activities may not lead to a massive and uniform participation, contrary to in-the-flow activities.

So I let you draw you own conclusions from your own experience (and comments are welcome) but it seems that it’s something that as to be taken into account when designing an enterprise 2.0 project in a multicultural context. Maybe we can also consider that the best way to reassure people and make them feel more comfortable with the “over the flow” is to start with “in the flow” that is more worklow oriented but less involving.

This is one more argument in favor of in-the-flow activities which, more than properly addressing the sense and alignent issues also allow to lower the cultural risk.