It made sense. A large high-technology company had established an innovation center in one of their U.S. offices where employees were entrepreneurial, engaged, excited to come to work, and as a result were quickly developing new ideas for customer-facing products. So the firm wanted to replicate that success in other places, namely India and China. Leaders from the U.S. held week-long workshops designed to expose workers at the China and India sites to the U.S.-developed practices of rapid development cycles, user-centered design, and collaboration in an open office layout. Leaders also provided the sites with detailed instructions on how to implement these new practices. They even sent one of the U.S. employees to work on site in India for a year.
But the effort didn’t have the results they expected—and elements of those important concepts were lost in translation.
Leaders, like those at this company, often assume that if a practice worked in one place, it will in another—and they want to reap the benefits of sharing common practices across locations. But they aren’t always successful. Many of us know this intuitively: best practices are optimized for a particular place and time and don’t necessarily transfer well between cultures. They’re like a shoe that doesn’t always fit. You can put the shoe on, and it may even look nice, but it will likely create blisters if the fit isn’t exactly right. That’s how it is with practices that don’t quite fit another cultural context. It isn’t that workers in other countries, such as China and India in the example above, are doing anything wrong—they’re not the cause of the blisters. My research reveals some interesting findings about how and why practices do and do not transfer well from one culture to another.
I’ve contributed to three different studies that show why certain practices fall apart and what leaders can do to avoid wasting money, squandering time, and frustrating employees.
The first study was at the high-tech company I mentioned above. Sara Vaerlander, Bobbi Thomason, Brandi Pearce, Heather Altman, and I observed what happened after the innovation practices were shared with the company’s Indian and Chinese counterparts. What we saw, and what I’ve seen happen elsewhere, is that despite the fact that these employees were all part of the same company and even doing the same type of work, the practices weren’t interpreted or implemented the same ways across cultural contexts.
In the U.S., for example, shorter development cycles were understood to be analogous to a start-up culture in which workers have more autonomy and room to experiment. U.S. employees therefore welcomed the opportunity to take more chances and saw failure as promoting learning and innovation. In China, however, workers equated speed with efficiency. They told us that the compressed schedule increased their focus and led them to be more discerning about the functionality they included in the product. In India, workers had yet another interpretation: they saw the shorter cycles as a way to align their processes and skills with developers around the globe, who they believed were also moving to more rapid cycles, and they applauded the move as a way of forcing more engagement with customers earlier in the process.
None of these interpretations is wrong, of course, but they resulted in inconsistent implementations. For example, the efficiency lens in China led to an adoption of the practice that was out of line with the goals of the innovation center to be more agile and iterative. They accepted the 90-day deadline, planned tighter schedules, reduced functionality, and exhorted themselves to work more efficiently. So although implemented as specified, the shorter development cycles had no discernible impact on innovation.
Something similar happened with user-centered design. In the U.S., the practice was seen as a natural extension of a customer-oriented culture, one in which customers were more involved in the development process. In China, however, talking with customers was seen as in imposition on both the developers and the customers, who were considered uninterested and unreliable in articulating product requirements. Given the China site’s historical emphasis on high quality software development, incorporating regular input from customers was seen as contrary to good engineering practice so developers didn’t adopt the approach. In contrast, developers in India welcomed user-centered design as an extension of their existing practices of engaging their community and personal networks to get input throughout the development process.
The third element of the innovation center concept was open office space. In the U.S., managers believed that open, flexible workspaces fostered collaboration and innovation and the center was established some distance from the main campus, which U.S. employees found liberating. Open office layouts were rather unusual in China and developers there were confounded by the expectation of being more collaborative. Instead, they continued to follow their conventions of working quietly at their desks with little interaction except during meetings and over lunch. And they saw the separation from the main campus as isolating. As a result, many of the workers spent the bulk of their time back at the main campus where they felt more a part of things. Eventually, this innovation center closed so that the employees could return to the main campus.
Workers at the Indian site also weren’t fans of the geographic separation; they worried they were losing their connection to other parts of the organization. We also noticed that the Indian workers were uncomfortable in the wide-open spaces and reverted to using meeting rooms as project spaces, in which they collaborated intensely. So while this wasn’t what the company had intended, the Indian workers were able to apply the spirit of the open space mandate. Still, the inconsistency was interpreted as a failure by the U.S. leadership.
At first glance, it might seem like the developers in China were resistant. To the contrary, they were in fact enthusiastic and highly motivated, but as they worked to integrate the practices into their local activities, they encountered barriers and didn’t have the guidance to overcome them. Unlike the site in India, the developers in China didn’t have a liaison who helped them with the adaptation process, so the practices were lost in translation.
Although some practices transfer intact, many require adaptation. Without adaptation, practices tend to be either rejected or adapted only ceremonially, thus not achieving the desired benefits. In this study, when workers understood the intent of the practice and had the freedom and support to reinterpret and adapt the practice within their own cultural context, they were much more likely to achieve the spirit of the practice.
In a similar study, Catherine Cramton and I interviewed and observed members of nine software development teams with two locations represented on each either US-India, US-Germany, or Germany-India. With these groups, we noticed that management practices that worked well in Germany and the U.S. didn’t fare as well in India. For example, processes for evaluation and rewards that motivated American and German developers created dissatisfaction in India and even drove workers to look for other jobs. For example, in Germany and the U.S., workers were given minimal supervision from management and they appreciated the autonomy. In India, however, developers were younger and hungry for more contact with and frequent feedback from managers. In some cases, they left for companies where managers were more hands-on.
The flat hierarchy common in Germany and the U.S. was also met with disappointment in India where a steeper hierarchy afforded more opportunities for quick advancement. In India, workers yearned for regular promotions as tangible indicators of their career growth. The India office adapted by rotating Indian developers through project lead or coordinator roles that provided the responsibility and indicators of growth that Indian developers were seeking. These practices helped to ease the dissatisfaction.
In a third study, which is ongoing, Steve Barley, Zachariah Rodgers, and I are examining the use of collaborative technologies in a company with offices in Japan, Mexico, and the U.S. As we expected, despite these employees working for the same company, doing the same type of work and having access to the same systems, we noticed differences in how they employed these collaboration technologies. In Mexico, for example, we found that workers’ commutes were less predictable so working from home is more common. As a result, technologies that supported telecommuting were more enthusiastically adopted than in Japan where tradition dictated that work happen in the office. We’ve also noticed differences in the choices of collaborative technologies. For example, Jabber was more heavily used in Mexico and the U.S., than in Japan and, when it was used in Japan, it was used more formally, e.g. with formal greetings. Workers in Japan relied more on high-end telepresence systems whereas workers in Mexico and the U.S. were more inclined to use desktop audio or video solutions for meetings with distant collaborators and customers.
I’ve observed elsewhere differences in how collaboration technologies, such as knowledge management systems, are adopted. These systems are meant to encourage employees to share their knowledge and expertise with others, and oftentimes, in Western cultures, there are incentive systems that reward contributors with “points” and awards. Implicit in these systems is the assumption that individual workers own their knowledge. In more collectivist and hierarchical cultures, however, individuals may not see themselves as having the authority to share knowledge. Instead, such rights reside with the team or manager. As a result, we tend to see a significant drop in the use of knowledge management systems as they move from West to East.
So if transferring best practices across cultural lines is difficult to do and sometimes just doesn’t work, what can be done? Here are a few things I’ve seen work in the organizations we’ve studied.
- Focus on the intent of the practice, not specific behaviors. When leaders focus on the goals and intended outcomes of the practice, it creates space for workers to adapt the practice to the cultural context while still realizing the underlying intention. This is what happened when the India innovation center used project rooms in the open office. Workers were collaborating, even if it wasn’t in the way the U.S. leaders had intended. When leaders actively encourage adaptation, it allows workers to achieve the goal in a way that is optimal for that location. This, of course, requires leaders to be extremely clear about the intent of the new practices and ask questions about what might work in a given location rather than providing detailed implementation instructions. Of course, it can be difficult to differentiate cases in which practices are rejected because they are out of alignment with the cultural context from cases in which workers are resisting change. Liaisons can help with this.
- Have a cultural liaison help translate the practice. This is someone who deeply understands the practice and can do the work of making sure it’s adapted in a way that maintains the spirit of the original. Ideally, this person also has experience in the receiving cultural context so that they know what aspects of the practice might be incompatible. We’ve observed that the adaptation process, with the help of the liaison, tends to be iterative, where the receiving site might try out the new practice and identify ways in which it doesn’t fit, and then try out practices that better resonate within the cultural context, while also preserving the intent of the practice.
- Strive for compatibility, not replication. When teams are globally distributed but collaborating closely, allowing each site to adapt the practice to their own cultural context can create confusion and strain coordination. For example, in the case described above in which the company rotated the project lead and coordinator roles in India to give Indian developers more of a sense of career advancement, inconsistencies were introduced in the roles across locations. Employees in other sites complained about not knowing who to go to or what level of expertise someone with a specific title had. When collaborating globally, some discrepancies across sites are inevitable. The challenge is finding practices that are compatible across multiple culture contexts. Experimentation—and flexibility—can be helpful in identifying practices that work across sites.
- Support experimentation. It often takes multiple iterations to find an adaptation that fits the cultural context and achieves the original intent of the practice. For example, in the case of the Indian employees’ concerns about career advancement, the company iterated several times to come up with a practices that worked both for the Indian employees and the company as a whole. Receptivity and willingness to adapt at both sites is essential to the success of this process. Leaders play a vital role in inventing workarounds and, what Catherine Cramton and I call, “standing in the gap” i.e. personally absorbing or filtering tensions through this process.
Common practices make collaborating globally far easier. And they can be a source of competitive advantage. But our research shows that wise leaders focus on the intent of the practice, not the specifics, and encourage adaptation and experimentation to ensure that the practice achieves the desired benefits. Companies that get this right are likely to find that their people are more effective and happier at work. And ultimately, giving employees the space to experiment in this way allows them to come up with new innovations that can be shared elsewhere.