LINEBURG


<< . .

 25
( 36)



. . >>

City (“what is a bagel”). The company refused.
A few other tactics:
— Hire a bi-cultural person. Your hiring practices for offshore work should place a

priority on hiring bi-cultural people.
— Learn the language. Of course, this is a longer-term investment. Even rudimentary

knowledge of the language is helpful. At one medium-sized Russian software ¬rm
we visited, there were two full-time English teachers on the premises who gave
continuous language instruction to individuals and to small groups.
— Conduct site visits. This is an opportunity to meet one™s partners and get to know

and understand their context and surroundings.


Case study Why the project was late: cultural miscommunication in an
Indian“American collaboration
Lu Ellen Schafer*

Christina Salazar knew that Karnatec, an outsourcing company based in Bangalore,
India, considered it a coup to land a contract with the leading Fortune 100 company
based in California where Christina worked. As a senior engineering manager, she
had selected Karnatec (an alias) over the well-known outsourcing heavyweights
because she needed a nimble partner that would bring to bear all their top talent.
Indeed, she knew these guys would bend over backward to make sure Christina™s proj-
ects were a success. With fewer resources after a recent downsizing, this attitude was
exactly what she needed since her team was working on a very aggressive schedule.
Christina understood there might be cultural differences with the offshore teams,
but she was not overly concerned. She was good with people in general, and had a
* Schafer is at Global Savvy, USA
188 Managerial competency



track record of reading them fairly accurately. The project managers in India
assured her that the India teams were quite westernized. After all, they were part
of the “Internet generation,” and most of them had worked on global projects for
several years.
In the Statement of Work, Christina de¬ned two speci¬c ¬xed cost projects, each
with speci¬c deliverables along an 8-month timeline. Vivek would manage the ¬rst
project; Ashok would manage the second. Each project would require a team made
up of 18 Karnatec engineers, plus two leads, working over 8 months. Christina and
her two main project managers from California spent 4 days in Bangalore working
out the details. Both teams committed to weekly calls and regular e-mail contact.
Karnatec was clearly very excited about being involved in the project; Christina
and her managers left Bangalore feeling relieved that they were all on the
same page.
Both projects got off to a good start. The teams in Bangalore and California
worked through the issues of time zone differences by being ¬‚exible. Sometimes the
California team called India from their homes in the early hours of the day; some-
times the India team stayed late to accommodate California™s time zone. The con-
ference call adjustments typi¬ed the ¬‚exibility that Christina valued. In fact, Vivek
further demonstrated his willingness to accommodate when he agreed to Christina™s
request to do all the migration testing. This freed up the California team to work on
new features recently introduced by their competitor.
One month after they started the project, as agreed, Vivek™s team had ¬nished the
testing. The quality met Christina™s expectations, but, to her dismay, she discovered
that Vivek™s team had slipped the schedule of the initial project they had been work-
ing on. Christina, who was worried that she would now be in serious trouble, sent a
pointed e-mail asking why Vivek had not informed her that he would be late on the
initial project. Why wasn™t this brought up in their weekly calls?
In the midst of trying to sort things out with Vivek, Christina and her team
met with Ashok, the second project manager, who had come to California with his
key lead.
Christina was aware that Ashok had a lot on his plate with Christina™s rather
complicated and dynamic project. Ashok™s e-mails frequently stressed all the
effort and long hours his team was putting in. Christina knew the required hours
along with tight scheduling could make them feel overworked. Her own team in
California was feeling stretched as well.
During their ¬rst meeting in California, Ashok laid out all that his team had
been working on. Christina and her engineers could instantly see that the India
team was signi¬cantly under-resourced given what they had to accomplish. One
of Christina™s engineers asked Ashok why he hadn™t told Christina he needed
more resources.
189 Dealing with cross-cultural issues



The Indian manager seemed exasperated. He said he had been telling them.
Christina™s team looked at each other in bewilderment. What was going on?
Christina began to wonder how they could have failed to communicate to this
extent after all the clarity in the Statement of Work, their weekly conference calls,
and the obvious intelligence of both her California team and the India team. In her
mind, she ran back through the topics of the conference calls and e-mails but could
not ¬nd clues that she had overlooked.

Lessons
In both of these incidents, Christina and the India team had stumbled upon a pow-
erful but often unacknowledged cultural difference.
Edward Hall18 ¬rst coined the terms high and low context to describe different
communication orientations (a concept that was introduced earlier in this chapter).
The interactions between the Americans and the Indians in this story illustrate the
miscommunication that results from well-intentioned professionals from different
cultural orientations. The US team, being from a low-context culture, had a propen-
sity to be direct, to openly state their needs and expectations. The Indian-based
Karnatec team, on the other hand, was from a high-context culture. Vivek, Ashok,
and their teams, like many Indians and many outsource partners, had a tendency to
be implicit, to assume that Christina and the US team would read between the lines.
Their subtleties also evidenced deference shown to an important client. Besides,
they knew Christina to be an intelligent, experienced manager who would not require
that such things be spelled out.
In the ¬rst incident, Christina was surprised to ¬nd that Vivek™s team had slipped
the schedule on the initial project. From Vivek™s high-context point of view, he was
simply following Christina™s priorities. Christina knew exactly how many engineering
resources were devoted to her project, and exactly what they needed to accomplish
in a given period of time. The implicit message, one which Vivek did not feel was
necessary to reiterate as it was so obvious (to him and the Indian team), was that
Christina had decided that the testing was the priority or she would not have taken
him away from the other work to do it.
Christina, however, was operating from a very different premise. She assumed
that if Vivek had accepted this new assignment, he could somehow get it done while
completing the initial project as well. And if Vivek could not accomplish it all,
Christina reasoned, he would say so.
The second incident stems from the same differences in low versus high context.
Ashok felt he had been very clear with Christina about being under-resourced with
all of the changes in Christina™s projects. From his high-context perspective, all that
was needed to alert Christina to the fact that his team was too stretched was to delin-
eate what each engineer was working on. Since Christina knew how many engineers
190 Managerial competency



were working on the project in India, she should be able to clearly see Ashok™s
dilemma. From his perspective, Christina could do the math.
Christina, though, from a low-context position, expected Ashok to speci¬cally
state that he needed help if that was the case. When she received a list of accom-
plishments, she did not read between the lines to know that Ashok was actually
sending a message of help.
Ultimately, everyone paid for the miscommunication. Despite the heroic efforts
of both the California and Bangalore teams working to make up for some of the lost
time, the two projects were late. Christina and her team lost trust in their outsource
partner. Vivek and Ashok felt wrongly accused and under-appreciated for their efforts.
Additionally, all the managers involved had the additional job of bolstering up their
team™s morale.
All the managers in this case were experienced, intelligent, and performed with
the best of intentions. But with the clarity of hindsight, it is easy to see that much
more communication was needed, especially enough to circumvent the roadblocks
posed by a high-context team working with a low-context team across almost a
dozen time zones and 10,000 miles. Given the complexity of high- and low-context
communication, what can at ¬rst be seen as over-communication, is actually often
just barely enough.



Case study In a Russian sauna with the Dutch manager
Julia Kotlarsky*
In 1997, Lizatec, a small Dutch software house, faced a dilemma: Where to get
programmers? There were not enough good programmers in The Netherlands: Dutch
programmers had a reputation for producing low-quality software and asking for high
fees. The company started to look for opportunities to achieve better quality and reduce
development costs. Lizatec started to think about offshoring, but to which country?
Lisette Breukink, one of three managers and co-owners of Lizatec, visited several
companies in India to discuss the possibilities of outsourcing software work.
However, this did not work out, mainly because of cultural differences. Lisette came
back feeling that men in Indian companies could not accept the idea of working
under the supervision of a woman. They just could not handle the fact that a woman
would be their manager and give them instructions.
Lisette heard from some friends about Russian programmers and she convinced
her Lizatec partners to try Russia. In late 1998, Lisette visited St. Petersburg, inter-
viewed some Russian programmers, and a short time after that opened an offshore
* Kotlarsky is at the University of Warwick, UK
191 Dealing with cross-cultural issues



facility in St. Petersburg. By early 1999, 12 software engineers were working at
Lizatec™s Russian facility (and by 2004 there were 25).
Not everything went smoothly. There were many cultural adjustments that both
sides had to make. Lisette related the three cultural vignettes described in this case.

Vignette 1
Dutch and Russian people have different perceptions of time. For example, the Dutch
make appointments well in advance and work between 9 am and 5 pm, while the
Russians are spontaneous and more ¬‚exible in working hours. However, you need
to give them special treatment like inviting them to your house and cooking dinner
for them while they are working, as Lisette did.
If a deadline is approaching and there is still plenty of work to do, what do Dutch
software developers tend to do? At 5 pm they stop working and leave. What would
Russian programmers do in this situation? When Russian developers from Lizatec
were preparing the launch of a new product and a deadline was approaching, they
told Lisette “Why don™t we go to your place, you cook dinner, and we work and eat:
it is more cozy to work at home.” And this is what they did: Lisette went shopping for
food and cooked dinner while the Russian programmers worked. Without knowing it,
the Russian programmers took a small risk when they asked Lisette to cook for them,
because Dutch women are usually not good cooks, in particular compared to Russian
women. The Russian programmers were lucky because Lisette is not a typical Dutch
woman and can cook nice meals.

Vignette 2
To motivate the Russian employees and keep them productive in the long run, you
need to create a family-like environment at work. This is not typical for Dutch culture:
Dutch people place strict boundaries between personal and organizational life, between
home and work. The Dutch have formal relationships at work, while Russians need
a home-like, friendly atmosphere in order to be motivated.
Lisette explained: “In the beginning the engineers made lunch by themselves, just
dry sandwiches. They would come in early in the morning and by the end of the day
they looked a little greyish and tired.”
Then, Lisette hired a cook. She later explained: “I decided to hire a cook just to make
a fresh salad and do some shopping, but she took her task very seriously and she started
to cook three-course dinners in a corner of the of¬ce. So we ended up having a real
dining room with a kitchen. And now every day we have a huge dinner at 2 o™clock.”
This is another cultural difference: in Holland people have dinner in the evening, while
in Russia dinner is in the afternoon (2“3 pm), with a small supper in the evening.
Lisette emphasized that now programmers can eat all their meals at work: “If you
are single, you don™t need to do any shopping. Because you can come in and have
192 Managerial competency



breakfast (we have sandwiches for people who come in very early in the morning),
then have dinner at 2 o™clock, and then leftovers are served for supper in the evening
for people who want to work late. So there is always soup and salad. Now they can
eat all day, and it is OK.”
She continued: “The cook is now like a mother for everybody. If you are on a diet,
she will cook for your diet. It is just her life “ cooking for these people, like a fam-
ily. [¦] And after this cooking, everybody started to look more healthy, because
they ate real fresh vegetables, and fresh meat. This is my investment in everybody
working well: everybody started to be more happy.”

Vignette 3
In Dutch and Russian cultures the human body is perceived and treated in different
ways, in particular the naked body. One might wonder: What does this have to do with
offshore software development? It is indeed related: when the Russian developers
(most of whom are men) go together with their Dutch manager (a woman) to a
sauna (˜banya™ in Russian).
Russian programmers do not place boundaries between work and home. So, it
was natural for Lizette™s engineers to organize various cultural and social events so
that their Dutch manager would learn about Russian culture. During the ¬rst year,
Lisette would come to Russia once a month for about a week. “We went to the the-
ater, paint-ball shooting, bowling, and to a music hall. Every visit somebody else
organized such an evening together,” she recalled.
One of the social events was to a summer house (“dacha”) on the outskirts of
St. Petersburg, to enjoy nature, have barbeques, and drinks for dinner, and, of course,
use the “banya.” This is where cultural differences became apparent. The Dutch are
very practical, and treat their body as something functional: for them the sauna is
associated with health and pleasure, and one cannot enjoy the sauna if he/she has some-
thing on. Thus, to enjoy the sauna fully, Dutch people take their clothes off and walk
in naked. The mixed sauna (men and women together) is very common in Holland
(as in Germany and in Scandinavia). For tourists and foreigners who live in Holland,
there are signs by the entrance to a sauna saying that entry in swimming suits is
forbidden.
However, this is not the case in Russia: Russians perceive the human body as
essentially sexual. When Lisette asked her Russian employees how the Russian
sauna worked “ if they undress and just walk in “ the Russian programmers were
shocked. They told Lisette that in Russian culture the naked body is a sexual object:
“if we see a naked body, we think about sex.” Therefore, in Russia, in a mixed
sauna, people put a towel around themselves or wear a swimming suit. Lisette was
surprised: for her Dutch sensibility it sounded strange that one could be in a sauna
and not be naked. “Strange, I don™t think about sex when I am in the sauna, it is too
hot,” she said to the Russian developers. However, there was no choice but to
193 Dealing with cross-cultural issues



respect Russian traditions and those of her employees. Lisette said to them: “Tell
me what to do and I will do the same.” This was the ¬rst time that Lisette sat in the
sauna wrapped in a towel.




Case study Offshoring usability to India
Johan Versendaal,* Ramanathan Subramanian,** and Kaladhar Bapu†
Baan had been offshoring software development to India for many years but had
never offshored usability. Usability is a bit different. Although the Indian engineers
are respected and well-trained software developers, there is no such heritage in the
domain of usability design (also called user interface design).
In 1997, the Dutch software ¬rm Baan was a 1-billion dollar company19 and one of
the major global ERP companies competing with SAP and Oracle. Baan was one of
the pioneer offshoring software ¬rms, with operations in India since the late 1980s.
By 1997, Baan had established large development and service centers in Mumbai and
Hyderabad. Baan had established a mature offshore structure that ensured low-cost,
highly standardized procedural software development. One of the characteristics
of this maturity was that not only were Indian centers in charge of a great deal of prod-
uct development; but that even some product management had been transferred to India.
Usability is a peculiar part of the software development life cycle in software
product companies. In order to create high-quality interfaces the usability consultants
visit customers, work closely with product management, and collaborate with prod-
uct consultants and developers. The usability consultants in¬‚uence the development
process throughout the life cycle. Usability has no veto in the development process
and must work through cooperation and in¬‚uence.

Motivation for offshoring part of usability
Baan had been growing its product usability functions for some time, but these were
all centered out of The Netherlands development unit. Baan was concerned that some
principal product modules “owned” by the Indian centers would not include usability
improvements. From a distance it was dif¬cult for the Dutch usability consultants to
interact with the Indian product consultants and developers. Furthermore, the Indian
developers and product consultants did not have the expertise to include usability
more explicitly in software development. Also, Baan-India thought it was important
that there be close cooperation between local usability consultants and the local devel-
opment group. Thus, the decision was made to start an Indian usability team.

* Versendaal is at Utrecht University, The Netherlands
** Subramanian is at Vanenburg IT Park, Hyderabad, India and Cordys R&D, India

Bapu is at Cordys R&D, India and af¬liated with the Indian Institute of Technology, Bombay
194 Managerial competency



Establishing a multi-site team
In order to successfully launch the new team in India, a string of activities were planned
over a year™s time, starting with advertising and interviewing Indian candidates.
Because Baan envisioned the Indian usability team working in close collaboration
with the headquarters-based usability team, one of the Dutch usability consultants
took part in all the interviews. However, the recruiting team could not ¬nd quali¬ed
engineers with backgrounds similar to the European usability consultants, who had
a background in computer science, psychology, and task analysis. Nevertheless, ¬ve
individuals were selected, fresh out of the university, who had studied visual com-
munications, product design, and graphic design.
Knowledge transfer was carefully planned. Two Dutch usability consultants moved
to India for 1 full year. Their main task was to help transfer domain knowledge and
transfer process knowledge to ensure consistency in working methods and deliver-
ables. They educated their Indian colleagues in the principles of usability design:
task analysis, user study, cognitive science, and psychology.
During this period Baan needed to formalize its corporate-wide usability style
guide. This effort became a joint project of the Indian usability team and their Dutch
visitors during the transition year. This effort helped the Indian consultants to better
understand the user interface design process. Simultaneously, the Dutch learned from
their Indian colleagues to better understand graphic design principles and color theory.
During the transition year the Indian usability group was led by one of the Dutch
usability consultants onsite. This was understood to be a temporary situation. Towards
the end of the transition year, an Indian team-lead was found. By Spring 1999, the
knowledge transfer and training was complete, the Dutch consultants returned
home, and the Indian team started to report directly to the Indian-based product group.

Dealing with cultural differences
From earlier offshoring experience, Baan knew that they would encounter cultural
differences. For example, Indian usability design professionals seek more freedom at
work than their Dutch counterparts: they were not comfortable with the strict, punc-
tual working style of a European company. As opposed to the more rigid working
hours in Holland, the usability consultants in India started late each day, but ended
up staying late and working even more hours.
The most dif¬cult cultural difference was assertiveness. Culturally, the Dutch have
an assertive, straightforward communication style. Usability consultants need to be
especially assertive since they must be able to “¬ght themselves into” software devel-
opment. The two visiting Dutch usability engineers recognized issues of assertiveness
early in their stay in India “ during the initial team-building sessions. In particular,
when playing team games outdoors, the Dutch consultants would take the lead
roles, while the Indians would accept secondary, supportive roles. In cultural terms,
195 Dealing with cross-cultural issues



the Indian consultants accepted the hierarchy of the more senior and experienced
Dutch “ and did not question this. The team-building exercises sparked discussions
about assertiveness. Consequently, during the transition year, the Dutch usability con-
sultants emphasized assertiveness: coaching their Indian colleagues in attitude, ¬rst
by jointly working on projects, later by evaluating work progress, and last by providing
advice. By the end of the transition year, the Indian usability consultants had been
thoroughly trained onsite to become more assertive.
Culture had another impact: on user interface design itself. When de¬ning a screen
icon, the palette of colors was chosen carefully to be sensitive to cultural, religious,
and nationalist beliefs. Icons with hand gestures were rejected to avoid all possible
cultural misinterpretations. The consultants™ work together reinforced this rule, as
they realized from their personal interactions that certain gestures, which were
acceptable in one culture, were considered offensive to the other.

Lessons learned
Baan considered the transition successful in several respects. Knowledge transfer to
the offshore team was complete; cultural adaptation was considered a success; the
corporate-wide usability style guide, jointly developed by Dutch and Indian usabil-
ity consultants, was fully applied by development; screen navigation developed in
India had signi¬cantly improved; and icon design, also jointly developed, became a
routine part of screen design.
All this was achieved at considerable cost: rotating two European consultants
to India for an entire year. Unlike most offshoring efforts, establishing a usability
team at Baan-India was not driven by cost reduction, but by product and process
effectiveness goals. One of the conclusions from transition was that the organiza-
tional structure in India mirror the one at Baan headquarters in which usability was
co-located with development. This would ensure clarity in communication and
reduce ambiguity in roles and responsibilities.
There was one area, however, where missteps were made: giving more autonomy
to the offshore team. Initially, the Indian consultants were allowed too little authority
and too little design freedom. Often, work came prede¬ned from The Netherlands,
leaving little scope for creativity in India. It would have been better if both teams
worked more in real collaboration that could lead to more mutual learning. Similarly
Baan learned to give more autonomy on personnel issues and day-to-day manage-
ment. Issues related to employee bene¬ts, laws, policies, and practices required
a deep local understanding and experience, and were best delegated to the Indian
team manager.
Part III

Other stakeholders
10 Building software industries in
developing nations

“¦ those countries in which science and technology is not applied as a guide to
business, will fall behind and will be ever dependent on the development of others,
for in today™s society, those who use their knowledge and cleverness best, will be
those who achieve advantage over others ¦”
Jos© Mariá Castro Madriz, First President of Costa Rica,
Speech to Congress, September 15, 1844

“It is time to widen the scope of our participation in the knowledge economy from
being mere isolated islands on the periphery of progress, to becoming an oasis of
technology that can offer the prospect of economies of scale for those who venture
to invest in our young available talent.”
King Abdullah II of Jordan,

<< . .

 25
( 36)



. . >>

Copyright Design by: Sunlight webdesign