Many of the Indian developers and managers we interviewed had previously worked with North American firms, and they often used this experience as a frame of reference to develop understanding in their Japanese relationship. In general, the Indians saw that the Japanese clients provided a greater potential for doing creative and higher value-added work earlier in the relationship than most North American firms. The Americans typically spent about 5 “6 years on lower-value bug-fixing and maintenance projects before delegating work in core technologies. The Japanese were willing to assign projects involving new, sophisticated technologies on products that were at the critical stage of marketing testing early in the relationship. An Indian manager described the different approaches and motivations for outsourcing of the North Americans and Japanese as follows :
I think the Japanese ...need and motivation for outsourcing is slightly different from the motivation of the North American countries that enter the market for reasons of cost effectiveness whereas the Japanese, to my understanding, is more a technology outsourcing. So, obviously, the relationship is at a much higher level as compared to the North American one where they already know everything about the product and you kind of pick up their knowledge. This puts them on a higher [plane].
The reference to ˜power is interesting as it indicates who has the potential to drive the communication process, and with it to enforce the rules and resources for communication. For example, in the GlobTel case (chapter 3), the Indians were on weaker ground because of their initial poor understanding of telecommunications. They had to depend on GlobTel for the knowledge and also the structure in which software development could take place. In new technology areas, however, there is more of a ˜level playing field in which activities can take place. For a number of Indian firms, the focus in Japan was on the high-technology niche sector of telecommunications where interesting and rapid developments were taking place in mobile and wireless applications. Innovative companies like Sasken (Bangalore) took a brave and futuristic decision to taper down some of their existing lines of work (mostly in the EDA sector) and focus primarily on telecommunications, with an emphasis on the Japanese market. Since Japan represents a key centre and testing ground for new telecommunication technologies and products, an increased demand for software services is expected to come from Japan in the future.
Our interviews, however, indicated that achieving this rich potential in Japan is extremely difficult. A key challenge both sides face is communication. We discuss three communicative challenges:
The structuring of the business model
The structuring of project management practices
The development of social relationships.
For both the Indians and Japanese, dealing with communication challenges was a key aspect in shaping the business model of the GSA relationship. Of course the primary concern was economic, but the business model was concerned with the need to deal with gaps in communication and to understand each other s practices. For the Indians who faced difficulties in understanding the Japanese user requirements, and for the Japanese in expressing them, an ongoing concern was how actively to develop mechanisms to minimize the ˜communication and service gap . Several alternative business models, some quite different from the Indian GSA relationships with Western firms, are being explored in the Japanese context. While it may still be too early to comment on the effectiveness of these models in practice, it is interesting to analyse some of their strengths and weaknesses in dealing with communication issues.
In our empirical work, we saw three main kinds of business models being adopted. The first was a semi-customized product model based on having semi-customized ˜off-the-shelf kind of product templates that the Indian firm can then customize with marginal effort to specific Japanese customer needs and products. The Indians examined these templates particularly in relation to the need for communication “ minimizing the number of people who need to be sent for Japanese-language training, for example. Such a model can potentially help to reduce time to market and to increase value through enhancing the number of business transactions in the marketplace using the same product. In the telecom domain, protocol software such as Bluetooth needs to be adapted to new devices and platforms. It can be approached in a ˜semi-customized product model which does not require to go through the traditional cycle of under- standing requirements and specifications and places a heavy burden on the need for intensive communication. The disadvantage of such a model is that the services market becomes downgraded “ the market that has traditionally represented rather a lucrative domain for the Indians in GSAs with Western firms. Such a model typically involves a core group of Indian developers based in Japan with a working knowledge of Japanese; the on-site component of such a model would thus be small but relatively continuous with the primary responsibility being market development and providing customer support.
With the domain-focused service model , the Indian firm develops software for the Japanese company through the traditional process of understanding requirements, coding and development and finally testing and integration. The domain-focused service model runs into difficulties in business domains such as banking where client interface is important and constantly changing requirements place a heavy burden on communication. In this model, the Indian firm needs to develop human resources for the long run.
The Indian firm needs developers who are capable of speaking the Japanese language and have a reasonably sound understanding of the Japanese way of doing things. The CEO of an Indian firm in Japan that is relatively successful in using the service model described their level of investment in people:
We realized early on that in order to expand we have to familiarize ourselves with the Japanese way of doing business. We hired two professors from Japan and they ran a nine-month course for us in our development center. The engineers assigned for the course were housed there full-time along with the Japanese professors. Not only did they learn the Japanese language but they also learnt culture, dress codes, stories and music. It was a deep training. The software engineers are trained in both Japanese and technology. We have been quite successful. In addition, we have done a number of other things like hiring Japanese translators, hiring Japanese nationals at the front end, setting up an office in Tokyo, etc. We now have about 150 people who have gone through the training program.
In order to address the communication complexities that come with the service model, some Japanese firms attempted to develop a strategy of outsourcing to India only ˜closer to the machine (like compilers and operating systems) where development is largely guided by standard protocols and conventions, and interactions with users can be minimal. We quote from the interview notes made by one of the authors in Japan:
Three Japanese engineers attended the interview. Some extremely interesting points were highlighted relating to communication, approaches to software development, and the differences in approaches required for hardware development as contrasted to pure software development. Hardware-related development requires greater face-to-face contact as compared to pure software. First, hardware- related development is subject to much greater changes based on continuous feedback from endcustomers. So, it was not possible to freeze the technical specifications before initiating the development phase of the project. Secondly, there is a much greater need to explain concepts using measuring instruments that cannot be done easily over the phone or email. So the next phase of work, that is going to be more hardware-based, the Japanese plan to do with a stronger component of on-site work rather than off-site. In off-site work, it was strongly felt that it would be only those projects that involved the use of standard specifications (for example, building C compilers or debuggers ) where the contact points required for communications were minimal.
The above model will typically be operated with a small group of Indian developers, some of whom can speak Japanese, who will be onsite during the requirement analysis and also in the final testing and integration stage. Most of the development work is carried out offshore in India with the Japanese-speaking Indians trying to address the need for clarifications and questions by interacting electronically with the Japanese.
The broker model is one in which the Japanese company establishes a third party as a ˜communication bridge between themselves and the Indian companies. During the course of our research we saw brokers in different forms and sizes, ranging from the individual consultant to dotcom firms and even to larger conglomerates and subsidiaries. The individual consultants were typically retired Japanese officials who had lived in India and understood the working of the Indian system and made some key contacts in the upper ranks of some Indian firms. The dotcom brokers typically offered matching services of potential Japanese users and Indian providers registered on their database. Building business through this model was described by a dotcom operator as being quite difficult because of the importance of human contacts in Japan. An interesting new approach was the establishment of a joint venture called Japansoft (a pseudonym for a joint venture between a Japanese firm and three Indian software houses ) to serve as a communication link between Japanese clients and three Indian software firms. An Indian engineer felt that Japansoft had placed a strong emphasis on communication, and although this is required, it downgrades to some extent the technical aspects of the project, leading to later problems in design and requirements analysis.
Another popularly used ˜bridge by Japanese firms is the subsidiary. Given the recession in Japan, firms have been obliged to support their subsidiaries to the maximum extent possible. A large Japanese conglomerate in which we took interviews were using their subsidiary in Singapore as the ˜communication hub through which to outsource software development to India. Managing this hub were Singaporeans of Chinese origin who were fluent in English. They could interface with the Indians and at the same time show some degree of understanding of Japanese communication. However, this model introduced a ˜Chinese layer between an already difficult to understand ˜Japanese “Indian interface. Many Japanese managers showed preference for establishing subsidiaries as it allowed them to communicate with people with a ˜similar mindset . We quote from interview notes made in a large Japanese firm that showed a preference to outsource to their subsidiaries:
The role of subsidiaries was emphasized in the context of outsourcing software development. The software engineers from the head office were described as sharing a certain common mindset with their subsidiary engineers because of their prior experience of working together. Used to this mindset, they found it quite difficult to work with the Indian engineers. For example, they were used to working on a discussion basis that they felt made it difficult for them to interact with the Indian engineers who seemed to prefer a more document-based kind of interaction.
The three models described above have different demands and needs for knowledge. Both Indians and Japanese need to adopt varying organizational support structures . While the service model can be seen as an attempt to deal with communication challenges by creating ˜hybrids who know the Indians and Japanese, the broker model attempts to keep the two groups independent and link them through a ˜gateway or a ˜hub arrangement. The semi-customized product model, in contrast, attempts to minimize communication interactions by focusing on products rather than services. In table 9.1, we summarize the associated communication strategies for the three models and their implications for managing the GSA.
Semi-customized product model
Minimize need for ongoing communication as implied in formal systems development methodologies
Reduce time to market by minimizing communicative transactions
Downgrading on the lucrative service sector
Support traditional software development methodologies with extensive training and education on Japanese language and culture
Japanese prefer ˜closer to the machine projects
Extensive investment in learning language and culture
Use of a ˜person or organizational entity as a communication ˜bridge or ˜hub supposed to understand the language and working systems on both sides
A ˜bridge introduces its own complexities
Technical aspects seen to be downgraded in quest for making communication strong
The various business models adopted reflect the efforts of the Indians to access the Japanese organizational knowledge (Lam 1997) and of the Japanese to try and preserve it. The Japanese show a preference for the use of subsidiaries, as it helps them to deal with the internal labour market and people with whom they have worked before and who speak the same language. The Indians, in trying to access the complex Japanese organizational knowledge, try to revise their professional knowledge in two ways. (1) They redefine their professional knowledge relating to systems development methodologies by adopting a ˜semi-customized focus that does not require the traditional development cycle. (2) They supplement their professional knowledge by making heavy investments in language and cultural education, much more than they would when working with North American firms. These models make varying demands on the Indians to understand the Japanese culture and way of doing things, and also on the Japanese to develop expertise in formal systems development methodologies. While the service model places maximum demands on the Indians to learn Japanese, there is equal pressure on the Japanese to understand structured systems development approaches.
Communication issues vary with different aspects of the project and include the processes of initiation, requirements analysis and reporting control systems. The manner in which these issues are handled has significant implications for the functioning of the project and also the GSA. We discuss these issues related to three different facets of project management:
One of the firms we studied described the extremely detailed and long-drawn out process before the Japanese decided to start a GSA. Hampden-Turner and Trompenaars (1993) described this approach to relation-building as ˜polycularity representing a ˜gradual and seemingly circuitous route in which the Japanese build their relationships (1993: 114).
A senior manager felt that negotiations for a contract with the Japanese executives are more difficult and time-consuming than with North Americans. Contracts from North Americans are like a ˜ low-hanging fruit . The large teams of Japanese company executives who come to visit and negotiate are prepared with detailed background information about the Indian firm that is often unknown even to the Indian executives from the same firm. Japanese executives are seen to bargain hard and negotiate to the smallest detail in project costs and schedules. An Indian executive described in amazement that ˜they even specify Tokyo or Bangalore time . The same executive described the negotiation process to be very demanding, with the Japanese even employing specific ˜ wearing -down tactics like extending a meeting for 14 hours. All aspects of the project need to be negotiated down to a fine level of detail, but once finalized, subsequent changes are strongly resisted by the Japanese. In contrast, the Indian developers with working experience in North America described the American clients as relatively more relaxed , less formal and open to variations in estimates and project deviations as long as they were informed in advance. An Indian female manager described that, while the Japanese were meticulous in deciding to enter into a GSA relationship, the situation changed quite radically once the initial trust and confidence had been established:
The trust was built maybe in 3 years, that s a lot of time. First they say we are not having many projects, and we will keep you open. But once that happens, they just say, ˜I want this project and can you do it? It doesn t go through the formal processes with the marketing department making presentations. They will just directly pop an email to one of us and say, ˜Can you do it, and how much is it going to cost me?
Central to the task of requirements analysis is the process of communication and how effectively firms manage them. The Indians described the interactions during the requirements stage as being extremely time-consuming and taking place mostly in colocated settings. This face-to-face interaction was considered necessary to establish the basis for further communications in the project, which occur mostly over email, rarely by telephone and almost never by videoconference. The specific approach for communication adopted for the requirements analysis varied with a number of issues, including the kind of project, prior experience of working together and the platforms on which development needed to take place. One project leader who had worked with different clients said that it was more crucial to do analysis when they were working with firms that did not have standard development platforms. As many of the Japanese did not, available documentation was normally minimal (and in Japanese), thus emphasizing the need for analysis, and placing extensive demands on translation and communication. However, in other cases where there were more standard platforms in place and there was also prior understanding of working together, an Indian engineer said: ˜We don t really have to submit our specs to them. They just give it to you and we have to implement it. That is all they have given us. That is [how it is]. However, in general, many of the Indians echoed the feeling that they tried to keep the communication to a minimum:
So they always prefer the minimum requirement we come out with. So they prefer less interaction. That is one thing that leads to a lot of confusion because we perceive something and then we deliver it. Then they see it and say this is not what we wanted. We have come out better when we have face-to-face meetings. We try to always do that, however time-consuming it is.
In general, the Indians described the interactions with the Japanese to be extremely time-consuming because of the problem of language and the extremely detailed manner in which the Japanese checked requirements. An Indian engineer described his understanding of the language problem in the following way:
The key issue out here I see are the cultural differences and different ways of doing things. There are language barriers. Japanese are perfectly okay with the written language; we give them the documents or mail. They will read and send it, be able to respond, but in face-to-face meetings it is not so.
This quotation reflects a rather superficial understanding of the Indian engineer, as he is not able to tie up the language issue with a deeper cultural understanding and a broader analysis of the Japanese way of doing things. For example, another Japanese manager describing his reasons for preferring the Chinese to the Indians for GSAs said: ˜The Indians may understand some part of the spoken language, but the Chinese also understand the written and unwritten language. The emphasis on the unwritten aspect reflects the importance of the cultural context and its intertwining with expressed and unexpressed language.
After the requirements stage, which normally takes place at the Japanese site, the Indian engineers typically take the development offshore to India and work from there, while trying to maintain minimum electronic interaction with the Japanese clients. Sometimes the Indian engineers need to go to Japan to deliver something or obtain clarification . A senior Indian executive of a large Indian firm who had had experience with a range of offshore clients said that their company had an onsite component of around 5 per cent in Japanese projects which contrasted quite sharply with the 20 “25 per cent figure with North American firms. While the number of interactions was few, when they took place they were extremely detailed and time-consuming. In frustration, an Indian engineer said:
They go through in detail. They take much time. I won t be surprised if they go through the code even. They go line by line through the program they write. We were so surprised when we sent our engineer; they had four days specifically for code reading. And they went through it line by line .
Despite the emphasis on detail and the time that interactions took, the Indians did not see the reporting and control systems of the Japanese to be as obsessive as those of their North American clients. A senior manager who had worked previously with the GlobTel account said: ˜We have project reports and reviews, but they are not as tight or religious as in the case of GlobTel. The method is more like, We have given you the jobs and what we expect on the day of the delivery . In general, the Japanese system of communication over the course of the project was described as oriented more to outputs rather than to the process milestones which are typically specified by the software development methodologies. The focus on output, while giving the developers a sense of freedom in contrast to the complaints of ˜micro-management against the North Americans, also led to problems in some cases. The Indians felt that in the final stages of project delivery the Japanese would tell them that this was not what they had asked for. While the late detection of such problems could potentially have been minimized with closer control of the process, developers often associate closer control with the fear of a loss of freedom. Also, some of the rather young (and often more brash) Indian engineers attributed the Japanese lack of emphasis on process to be a sign of their failure to understand software development.
In general, the Indians approached the project using their professional knowledge of formal system development methodologies, and various quality certification standards (ISO and CMM) to which their firms conformed. This professional knowledge had over the years been reinforced and developed in working with the Americans who had emphasized a similar structured approach to software development. This adherence to professional knowledge could be seen as the reason why the Indian engineers in their interactions with the Japanese would emphasize written documentation, including project plans, specification documents and project deliverables with well-specified start and finish dates. In contrast, the Japanese would typically start without a formal plan or a specification document; many of them expressed in interviews a preference for business based on discussion rather than formal written communication.
This preference could be understood in relation to the historical experience of the ˜employment for life system where employees shared the same mindset about how things were done, and requirements need not be written out, since a person could always walk across to a colleague and seek clarification. The Indians constant emphasis on a document-based communication put unwanted pressure on the Japanese engineers who were largely unused to working in a culture of reading and writing long documents. Historically, the Japanese have shown a seeming indifference to formal contracts, relying more on the ˜spirit of the law rather than the ˜letter of the law (Hampden-Turner and Trompenaars 1993). The Indians, on the other hand, were more guided by the ˜letter of the law expressed through formal methods . The Indians were often working with Japanese hardware engineers who seemed to have a greater indifference to structured ˜waterfall -type methodologies than the software engineers.
In interviews in both India and Japan we were told that the Japanese showed a preference for pictures as compared to text. Hampden-Turner and Trompenaars (1993) write that the ˜very existence of the comic books for the educated shows Japan s greater reliance on whole pictures and images rather than printed words alone (1993: 123). We observed this preference in interviews where the Japanese respondents would often reply to a question by drawing a picture and we also saw young and old people alike engrossed in reading picture-based comics in subways. This preference for graphics and texts was at odds with the Indian style of writing long text-based memos and reports. An Indian engineer remarked:
One of the greatest learning [curves] we have is how to express themselves as much as possible graphically rather than in words. Describe something if we can try [it] out and explain it to them, that way you get the message across. The biggest [problem] we have out here is we are dealing with a customer or with a partner who, because of the very nature of the work, is not able to give very clear specification.
Indian software managers felt that although the Japanese in general conform to procedures and work processes defined in detail, they appear to face problems in following software work processes. The Indian programmers seem to be more proficient at this, probably as a result of their stronger base of ˜professional knowledge . Consider the following two quotes from an Indian software manager:
The Japanese are very proficient in the hardware business but not so in software. The Indians are more systematic, they have procedures in place. The Japanese do not follow [steps of software processes] strictly . They know what the functional design, etc. is but they do not follow it. In software, they do not have so many procedures.
Highly structured and relatively slow-to-change processes are well executed by the Japanese. Software processes, however, need to be fleshed around a skeleton of rigid process. This needs flexibility and initiative that is difficult in the traditional Japanese approach.
In general, the Indians felt that highly structured and stable processes were well executed by the Japanese. Large Japanese computer companies such as Hitachi, Toshiba, NEC, Fujitsu, etc., attempted to organize software work along lines similar to manufacturing activities. The resulting so-called ˜Japanese software factories that were initially successful (Cusumano 1991) did not survive rapidly developing technology. As some Indian managers commented: ˜The Japanese are very strong in legacy systems but they are very badly positioned in terms of recent skills. They are in crisis. A possible interpretation of this crisis could be the relatively slow and limited uptake of the ICTs in the course of GSA work. A common assumption made in GSAs is that ICTs normalize problems of communication across cultures. Walsham (2001) has challenged such claims, arguing that homogenization is difficult, if not impossible , given the extreme diversity across the globe. From the Indian perspective, we found their use of ICTs to be guided by two interconnected considerations: (1) understanding the Japanese way of doing things; (2) dealing with the issue of understanding and speaking the Japanese language. The ˜Japanese way of doing things , which can be interpreted on the basis of the ˜organization knowledge model, is extremely difficult to understand, especially for the young, technically qualified Indian engineers who strongly believe in the supremacy of their professional knowledge of software development, a view reinforced by their relative success with North American clients. One Indian engineer complained about the Japanese ˜group approach to software development “ when there is a bug in the software, the entire team is responsible for finding and fixing it, rather than just the person responsible for the particular module, as would have been the case in a North American project. This ˜group responsibility of the Japanese working style also means that multiple rather than specialized skill development is encouraged (Hampden-Turner and Trompenaars 1993). The young Indian engineers, used to the emphasis on specialization and clearly demarcated modularized work, found understanding the Japanese people to be much more complex than understanding the North Americans:
One thing about the Japanese is that it is very difficult to read. And the Japanese people, I just don t know what there is in their mind. Is very easy to read an American. A Japanese will be so polite to us but we don t know what there is in his mind. It is difficult to know who controls in Japan and who makes the policy decision . . . in North America you know who really calls the shots. Here it is not that open. It tends to be more collective, and it does not look like there is one person. You would not know with whom to campaign, as you don t know very clearly where the buttons are.
In trying to deal with the complexity and apparent ambiguity of culture and decision making, young Indian engineers tried to communicate minimally and very directly, and related only to technical issues, by specifying keywords and leaving management issues to someone more experienced . A young engineer with 2 years experience with Japan described communication processes during the course of a project:
I communicate only on technical issues. I am not involved in the management level. We try to simplify the language as much as we can, and with every mail we write that ˜If it is not clear, you can come back to us . Videoconferencing, too, we use only for technical reasons.
Another engineer emphasized how long it took to communicate even relatively simple issues. They had to repeat each question two or three times before it could be understood. As a result, he said: ˜I do not use the phone much, and given the option I would ...use...onlyemail. The manner in which the email text is structured from both sides is quite different from the experience of communicating with North Americans. The Indians try to write very brief, simple, short sentences where each line only makes one point. And while the Japanese reply often takes longer, it is meticulous in dealing with all the points raised. An Indian manager remarked:
If you ask them a question, it is not that they won t answer as very often is the case in the USA under a similar situation. You ask five questions in a mail, one would fall in the crack. When you ask five questions in Japan all five question will be answered meticulously, even if it takes 2 “3 weeks to do it. Because the mail would probably be sent to somebody who can translate English to Japanese and then the Japanese engineer will ask him to translate from Japanese to English. The translator can always overload it.
Along with the long time taken in communicating, there are also misunderstandings, ranging from the harmless and the funny to the more serious. One Indian manager jocularly described how a Japanese manager told him, ˜You are welcome to Japan and we will hospitalize you . An Indian lady manager gave examples of more serious misunderstandings:
A bottleneck was communication, and generally we have misunderstandings. The requirements text was given to us about an order in which we were to design a chip, and they always said, ˜that we had to down the data, down the data . And we perceived it as though the data were right. And this was happening for almost 7 “8 months. But actually what they meant was ˜read the data . And we were sending it thinking that it was all the correct answers and we did not know why. Then we visited them and realized the misunderstanding. Another example was they would say, ˜it has to support all the layers . While for us ˜all the layers meant what is there now, for them it meant also all the layers that it can have in future...
The Indians seemed to rely primarily on intensive initial face-to-face communication and subsequently on email, which they tried to keep to a minimum. Often the requirements were sent to them by hard copy or by fax rather than email. Phone calls were used but not extensively. Even though Indians may have learned some spoken Japanese, what is spoken over the phone is very different. In fact, we were told that private institutions run special language-learning classes for ˜telephone Japanese . So, the Japanese, who are used to speaking on phone primarily to Japanese people, told us that they had great trouble in shifting to the mode of talking to Indians who have learned Japanese in classes primarily intended for face-to-face interaction. Videoconferences were rarely used because the voice was deemed to be not as clear as on telephone, perhaps because of bandwidth constraints.
The choice of using a particular ICT is tied to other issues, including how the Indians perceive the Japanese way of doing things and vice versa. These perceptions significantly shape the choice in the use of technology ( ˜never use videoconferencing ) and also the mode of expression ( ˜write short sentences with one idea ). These choices have broader implications for the project “ for example, on the percentage of offshore and on-site work “ which is in turn related to the question of attrition, as described by an Indian manager:
In GlobTel we were working with the North Americans, and thus you get a chance to go to the USA and work there. That one thing is more attractive and lucrative for the engineers than Japan. But here we do not get much chance to go abroad once the development goes on in India. There are certain cases when people have gone to Japan but only for short periods like a month or two, while with North American clients we can go for a year or two, make some money and come back. That is a critical fact that makes one decide whether or not to work for a North American client.
The choice of technology is not simply of whether it is used or not. The choice is intricately tied up with a range of socio-cultural issues , some of which have already been discussed. In table 9.2, we summarize the key communication challenges at various stages of the project, and how individuals tried to deal with them.
Response to the challenges
Role of ICTs
The process leading to the decision to start a GSA is very detailed, long-drawn-out, time-consuming and exhausting
Large groups of Japanese visit India
Long and detailed meetings
Indians try to revise their expectations based on the North American experience of picking ˜low-hanging fruit
Minimal as the primary reliance on building a relationship is based on human networks
Problem of expressing requirements in English
Indians insistence on detailed, frequent written documents resented by the Japanese
Japanese show preference for graphics to text
Indians specify start and finish while for the Japanese these distinctions are more ambiguous and blurred
Non-standard development problems with minimum documentation (or in Japanese)
Initial meetings in co-located settings
Indians set up a core team, few of whom may speak Japanese
Indians try to develop as detailed requirements as possible to avoid electronic contact later
Some Japanese seek ˜closer to the machine applications to try and minimize communication
Minimal in the initial stages as face-to-face meetings preferred
Once trust is established, projects can be started without detailed requirements specifications
Email used minimally to clarify requirements
Sometimes documents, especially in Japanese, sent by fax
Japanese focus on outputs rather than processes often causes problems at the time of project delivery
Indians need for documentation resisted by the Japanese
Excessive time taken to answer queries because of translation issues
Frequent misunderstanding in meaning
Frequent project reviews but not as ˜religious as North Americans
Indians changing strategy about their use of ICTs, both medium used and content and structure of message
Indians revise expectations of how much and how email should be used
Email is preferred medium, phones less and videoconference even more limited
Drastic redefining of structure and content of messages “ brief, simple, short, less frequent
Communication and social relationships cannot be separated from each other, and the analysis of communication is fundamental to understanding social structure (Couch 1989, 1996). The manner in which we communicate “ written or unwritten “ and interpret and respond to communication is fundamental to shaping our feelings of cohesion and reciprocity with others. In GSAs, the situation is complex, as a significant aspect of the relationship and interaction needs to be managed in conditions of a ˜virtual presence , where members, especially when work is being done on-site, need to share consciousness of each other through some combination of textual, auditory and visual contact. The degree of reciprocity in communication, what Couch (1989) describes as ˜social responsiveness , reflects an understanding of the mutuality of interests, beliefs and emotions, without which ˜there is a minimal merger of self and the other . The extent of this merger has implications for identity which is created and experienced through the ˜negotiation and co-construction over ˜meanings and manner among members interacting in a specific context (Wynn and Katz 1997). Identity, when congruent or shared, reflects the sense of ˜oneness among the actors in a collective, irrespective of their personal biographies or geographical locations (Couch 1989). A shared identity permits organizational actors to perceive themselves as part of a larger and more autonomous whole. Formation and maintenance of such a shared identity is a prerequisite for future oriented cooperative action, especially where there is a high level of task interdependence among the teams (Knoll and Jarvenpaa 1998).
Social relationships thus include a number of aspects, including a sense of cohesion, a feeling of co- constructed identity and mutuality of interests and emotions. While our empirical basis is too thin to substantively comment on these complex issues, we make some tentative observations about the issue of communication and social relationships. In the Indian “Japan GSAs, written and verbal communications are seen to be extremely complex and time-consuming, especially compared to interactions with the North Americans. There are challenges in speaking the language, understanding meanings and the amount of time and effort required for even ˜simple transactions.
Other difficulties in building social relationships arose from broader differences in working styles and, also interestingly, eating habits. The Japanese tended to work extremely long hours and nearly every day, in contrast to the Indians, who worked fewer hours and had frequent holidays. This was often interpreted by the Japanese as meaning that the Indians were too casual and not careful about adhering to deadlines. The frequent turnover of the Indians meant that the Japanese had to interact with a new individual that made it difficult to develop enduring social relationships. Indian engineers, frequently vegetarians, were often reluctant to travel to Japan for extended periods because of the difficulties in finding vegetarian food and also the exorbitant cost of dining out. Often, the Indian engineers would prefer to sit at a different dining table to their hosts because of the radically different food preferences. In Japan, where social relationships are often best developed over food and drink, when sitting together after work, the Japanese managers often felt that they had limited opportunities for the team members to bond together. Another issue was age; typically the Indian engineer would be younger, fresh out of college, as compared to the Japanese manager. The Japanese culture emphasizes respect for elders, and the wishes of elders are accepted unquestioningly. The younger Indians felt that such structures limited the expression of their creative energy. They felt that these structures made acceptance and openness to learning from past mistakes difficult. The Japanese interpreted such attitudes as the Indians being ˜too Westernized .
Despite the challenges of language and limited physical and electronic contact, it was very interesting to note that the Indians expressed very positive feelings about the social relationships and understanding they had with the Japanese. A key reason for this seemed to be the underlying sense of a personal touch in the enduring communication that extended temporally and socially beyond the official boundaries of projects. This made the relationship much deeper as compared to the Indians North American relationships. The ˜personal touch is created because the Japanese do not separate the official and formal from the unofficial and informal; this gave the Indians a feeling of personal involvement and an engagement that transcended the work relationship, which to them was very significant. A sense of trust was built because the boundaries of the relationship were not seen to be restricted by official time or limited to just the one project. This sense of solidarity was not developed by extensive communication or use of emails; instead, meaning was found in limited but relevant interactions, where expressions of commitment (like spending time) and care (as in sending gifts) transcended the complexities of the physical limitations of language. What magnifies the positive aspect of the Japanese ties is the contrast with prior experience of working with the North Americans, where relationships are seen to be rather superficial and set within business-defined boundaries. Quotations from Indian managers and developers expressed strong social ties with the Japanese, despite the long time it took to transcend initial boundaries:
I think in Japan those relationships matter that are considered sustaining . In the relationship it is primarily a very high degree of trust that the other person is not taking you for a ride. If he says something and I don t understand, I have faith in him enough and I go to him and ask him ...to explain. Maybe he has a good reason for doing what he is doing. So that s the relationship when it is established. That is what sees us through all hot spots.
It is very easy to interact with the Americans rather than Japanese. You should be very careful, very polite with the Japanese. But once trust is built up there is nothing to [fall back on]. You just work on trust. In America, building up the relation has no value. In Japan, everything about the project is my own, like my own child. I have in so many instances made mistakes, but because of the rapport, it was okay.
The Japanese are very formal, very cooperative, and the person there tried to help and he asked us and came shopping. The first day at the airport, it was a big problem and they took us to their canteen. We could hardly get any food, and they stayed with us, and they went around showing us various foods . They took real pains to see that we had some food we liked .
The Japanese are very sceptical to begin with. They will scrutinize you, but once the relationship is built up, then they always rely on you. After a project, they will say: ˜I prefer if you do the next project.
And they just send the email and say that your group should take it up. This is because of the kind of trust and the rapport that is built up.
I found them very polite and very, very, sympathetic and helpful. Even in personal relationship development. Forget about the business. All my clients send me personal gifts. And it is not only to me, but also to my other group members. When I had my baby I received gifts from almost all my Japanese clients. Someone sent me CDs and songs, etc. So this is beyond your work, and it makes you feel it is more than work when you share a personal note. So I enjoy and relish most of my projects that I do there.
They are trying to be very friendly with us, and not being very official. So, I have a very soft spot for the Japanese. I can also give one more instance when I went to Japan last year to install something there. One weekend was free, I was so touched: the manager and the developer said: ˜I have arranged [for] a man who knows English, to take you around Nagano, to show you the places around Nagano. They took me for two days all around Japan. This is unlike what any other clients would have done. With North Americans, their relationship stops at 5 o clock. Of course they help you, like when you have the problem of ticket bookings. Probably we Indians think too much about such personal things.
The Japanese are much more demanding, they have longer hours, much tighter schedules, and on the face of it they are stingy with praise. The USA is very different; when they come here they take the engineers out for a party and give them T-shirts and caps. They will say, ˜You have done a fantastic job, etc. . A Japanese equivalent would be ˜Thank you for completing the job .
The strong social ties with the Japanese are especially interesting because they have developed in conditions where everyday communication is problematic because of language, limited use of ICTs, different working styles and quite contrasting social structures. In all the Indian organizations we studied, we found some senior people who shared a passionate feeling towards Japan and were acting as champions to build up business there. These strong social ties seem to provide the strength to deal with the everyday communication challenges and to develop the relationship in the future.