In one disintegrating collaboration studied in detail by Anca Metiu of INSEAD, software developers in a US company became very critical of their counterparts as an Indian partner. A dramatic increase in time-to-market pressures had led the US team to neglect the (previously productive) relationship. The Indian developers started grumbling about the lack of guidance, severely delayed feedback on their work and sudden changes in direction. Their junior status in the relationship made them especially sensitive to any perceived lack of respect or consideration. Predictably, the quality of their contributions and practicality of their suggestions suffered.

Oblivious to their own role in the problem, the US developers sensed that their Indian counterparts were not fully engaged. The US developers became increasingly critical of the work coming out of India and started manoeuvring to take control of all the modules of the project. As the ownership of the project shifted to the US, the need to communicate with India decreased, intensifying negative interpretations of the US partner’s intentions and encouraging some Indian developers to leave the project. This re-enforced the feeling among US developers that the project needed to be brought completely in-house.
When suspicions mount, collaboration partners often start sticking labels on one another, like unreliable, unreasonable, profiteering or paranoid.
In this case, the Indian partner came to be seen as uncommitted, while the US partner was regarded as unhelpful, but also devious in its attempts to re-appropriate the project.

Unfortunately, viewing each other through such lenses has a tendency to distort whatever new information is received – even if it happens to be contradictory.
Labels orient people’s attention and the way they make sense of data or events. In particular, the US developers focused on any work from India that seemed below par – and systematically brought these lapses to attention. If one Indian developer put a foot wrong, the whole US team knew about it. Moreover, US explanations for inferior work invariably focused on individual factors such as eff ort or ability, while neglecting external factors entirely. These biases were accentuated by steady turnover on both sides of the project.

More surprising still, reports that the Indian developers were working long hours further re-enforced their poor image. It merely fuelled US suspicions that the Indian developers must be working on parallel projects. In reality, deprived of US input, they were spending inordinate amounts of time trying to figure out the documents, instead of building on the work they had received. Such information processing biases and stereotypical thinking intensify under conditions of stress – and clearly the US developers were under severe pressure to bring the product to market.
[. . .]

The US company appointed a manager specifically to liaise with the Indian partner. Other measures included increasing personnel exchanges. Thus, a few US engineers visited India to help put faces to names and to get a better feel for the context.
Similarly, several Indian engineers were seconded to the US for overlapping periods of several weeks.
The partners also introduced weekly conference calls (at rotating hours) and daily updates.

The relationship between the US business and its Indian partner was restored, but at no small cost. First, several experienced Indian developers had been lost to the project. Then, the US managers had to devote significant time and eff ort to getting the remaining Indian team members to re-engage with the process. They also had to work hard to make sure that scheduled conference calls were properly attended on the US side. Finally, they were obliged to grant matching holidays to the US developers for each day spent at the partner site. Ultimately, the product was successfully launched. But a painful and costly process of reconciliation could have been avoided.

Questions
1. Further on in the same article, the authors propose two ways of addressing the problems they describe: intervention and prevention. The intervention method they suggest is similar to a medical one in that it is concerned with:

● Examining the symptoms: what are the difficulties exactly in terms of (non-) actions and expectations?

● Making a diagnosis: how have both parties contributed to creating the situation (e.g. divergent work practices, altered contexts or interests)

● Deciding on the treatment needed: resolve the issues on principles that both sides consider reasonable. Taking a step back to discuss these principles may well facilitate joint decisions that both understand, accept and implement, including decisions on how to handle future issues as and when they arise.

Apply this intervention strategy to the account given in the text: determine as best you can what the symptoms were of the conflict, make a diagnosis and show what treatment was decided on.

2. The other way that the authors put forward for addressing the problem is prevention. Part of this approach involves being aware of the mechanisms already described in question 1. However, according to the authors, there is also one overriding principle that must be followed in order to avoid such situations and that is to invest time and effort into the collaboration from the start.
In order to avoid conflicts, what concrete steps do you consider are essential from the start of such a cross-cultural collaboration, from the negotiating stage through to its implementation?