Over the past decade I have been one of the loudest voices in talking about the holistic nature of collaboration and how it is about “people, process and technology.” Now, I am not recanting those ideas, but having attended the NewWow Symposium that had a focus on “Cultural differences in distributed collaborative teams” and hearing Peter Block speak about his new book “Community: The Structure of Belonging (2008)” I am not so sure that trust is the critical attribute I once thought it was for successful collaboration. Trust was originally defined in a social context by James S. Coleman (no relation) in his Foundations of Social Theory (1990) as “an action that involves a voluntary transfer of resources (physical, financial, intellectual, or temporal) from the truster to the trustee with no real commitment from the trustee.” My colleague and Collaboration 2.0 co-author Stewart Levine says “Trust is the knowledge that you will not deliberately or accidentally, consciously or unconsciously, take unfair advantage of me. I can put my situation at the moment, my status and self-esteem in this group, our relationship, my job, my career, even my life in your hands with complete confidence.”

[More:]

Understanding Local Context

At the NewWoW symposium which happened a few weeks ago, they usually have an academic or a practitioner present a paper that is based on either a review of the literature or some research they have done. In this case Dr. Pamela Hinds from the Center for Work, Technology, & Organization in the Dept. of Management Science & Engineering at Stanford University, presented the keynote presentation on “Intercultural Collaboration in Global Teams.”
It was a good presentation and discussion and what I took away from all of this is how critical understanding “local context” is to distributed team interactions. Now I know this may sound like common sense to those reading this, or anyone who has worked on a distributed team using a collaborative tool, but it is one of the most common mistakes that cause team failure in any case.

What is Culture?

One definition Dr. Hinds used for culture is “A fuzzy set of attitudes, beliefs, behavioral norms, and basic assumptions and values that are shared by a group of people, and that influence each member’s behavior and his/her interpretations of the “meaning” of other people’s behavior” (Spencer-Oatey 2000). We then looked at 2 models for culture: Geert Hofstede’s model for dimensions of culture, (1994), where he goes on to define specific attributes for different national cultures. His work was based on an original study he did with IBM in the 70’s. The dimensions include things like: power/distance, masculinity/femininity, individualism/collectivist, and uncertainty avoidance. It was no surprise to see that the U.S. was very high in individualism, whereas a country like Japan was highest in uncertainty avoidance.

Another model that Professor Hinds found to be more up to date and useful for the current research was “from Leslie Perlow and her colleagues (2004) that emphasizes the role of institutional context and social structures, not cultural values as the primary antecedent of workplace dynamics.” This model is a series of circles each nested within the next circle starting with individual actions which are nested within a “Local Context” which in turn is nested within “Institutional Context” and finally all of them are nested within “Cultural Values.”

What I got from this model is that our individual behaviors and what we do on a team is greatly affected by our local context which can be a product of all of the other circles in the model, and that understanding each team member’s local context is critical to effective team interactions. One of the most telling examples is when team members from a “high context culture” interact with team members from a “low context culture.” The U.S. is a low context culture, i.e. what you say is what you mean… period. In a high context culture like Japan, that is not the case and what you say is only part of the meaning, how you say it, tone of voice, what words you use and their order, your body language, where you stand in the room or in relation to the person you are talking to, all help to determine the context of what you are saying. Because I was from a low context culture I took people I interacted with at their word (what they said) in Japan, and often they said “yes” when in reality they were avoiding conflict, and really ment "no." If I had been able to read the context of how they said it, I would have realized that they were really saying “no.” Obviously, you are at a great disadvantage in working on a distributed team working with people from high context cultures because you get less of the context cues when you work virtually.

If this is the case you need to go much greater lengths to understand your team members local context, this may mean reading their profile, talking to them in virtual social situations like online cafes , or engaging them in more personal conversations so that you can begin to understand their local context. Mistakes around local context come in two forms: either lack of information or not understanding information passed from one team member to another because of a very different local context, or offending a team member by your communication which does not support the way they communicate in their local context. Either way, it makes for difficult team interactions and can threaten a successful outcome to a project.

I believe that understanding local context is more important than trust. Yes, trust can be built through the process of your understanding another team member’s local context, but it does not always happen and is not always necessary. I have worked on teams where several members don’t trust each other, but they are committed to the relationship and the goal of the interactions and often that is enough for success.

Relationships are Key

If I am on a project team to deal with the re-building of a local power plant, and on that team are people from PG&E (the local power company) who own the plant, I may not trust them because I know their agenda (to keep the current dirty power plant running) is different than mine (to get a new cleaner power plant) but our overall goal and what the relationship is based on, is to continue to provide electrical power to the community. I can trust in the relationship, and can try to understand the local context of all the people on the team (in this case they all may be geographically closely located) which will help my communications and interactions with each of the team members, and help to prevent any misinterpretations of information based on different institutional contexts.

In a recent talk I heard from Peter Block, who has a new book out on Community, he challenged my idea that trust was critical for a successful distributed team and instead noted that in his many years of work, that often it was management’s desire to try to apply “control” to a team is what made it fail. I do agree with Peter that “control” is an illusion that many of us cling to, especially in a hierarchical social structure where those on the top try to “control” those lower down.

However, I have found that if everyone on the team is committed to the goal or outcome of the project, then the chance of success for the project is very high. So for a virtual team’s project success it is really more around “commitment” then around trust. Even if they don’t have the right electronic collaboration tools to support them or even enough resources, a committed team is very hard to stop. They will find a way around almost any obstacle or limitations set in their path. An extreme example of this would be a terrorist cell, with an outcome like that of 9/11 in New York City.

Critical Factors for Distributed Teams

In my thinking today, trust is great to have, and may come from some of these other factors, but understanding the “local context” of each member of your distributed team, and the commitment of team members to the relationship with the other team members and to the goal or outcome for the team are the two most critical success factors for distributed teams. Often this means that management has to get out of the way of teams, and stop trying to impose control over team relationships. People are complex and the interactions between them are even more complex, and from complex systems arise emergent characteristics which can’t be planned for, and often can’t be managed or controlled. For example, I don’t believe you can control an on-line community, you can nudge it in a specific direction with rewards and penalties, but you can’t really control it. Community managers, really don’t manage the community, but they more facilitate the conversations going on in the community. The same is true for distributed teams, they can’t be controlled, and often that is a good thing, in that the team surprises you with an outcome that is beyond your wildest dreams.

Tools for Teams

The tools that these distributed teams use also should not be controlling, i.e. they may support some structured interactions, but should not get in the way of any ad-hoc interactions, which are critical to team success and where a lot of the emergent benefits from the interactions (collaboration) are found. Tools that are easy to use (yes, I know every vendors says their tool is easy to use), require little training or overhead, and support team members in learning local context and committing to the relationship will be the tools that begin to see the most success and get the greatest adoption. I believe that there is a great need for tools that enable these types of interactions, and that this may be the next step in the evolution of collaborative technologies.