When colleagues learn that my graduate degree is in anthropology rather than business or computer science, they’re usually puzzled. They assume that I’ve changed careers, or that studying human cultures is an interesting but frivolous hobby-like, say, building model ships.
In fact, over the years my expertise in anthropology has turned out to be one of the most valuable tools in my management kit. It’s particularly helpful now, when more and more IT projects are becoming collaborative endeavours at locations around the world, involving people of vastly different backgrounds.
Consider my experience at Moody’s Investors Service. I joined the credit rating agency in 1993 when it was embarking upon a major expansion outside the United States, as well as undertaking an ambitious strategy to replace legacy mainframe processes and standalone desktop applications with a more efficient global data architecture. Today, Moody’s publishes ratings and research electronically in real-time on its Web site. Its analysts gather information about market conditions affecting companies, governments and debt instruments wherever people issue bonds to raise capital. Its internal systems integrate financial, HR, marketing and workflow operations in offices on every continent except Antarctica.
As an IT manager, one of my responsibilities was serving as the liaison between the central systems development group at the U.S. headquarters and the developers and end users in other countries. That meant leading project teams of staff members, consultants and vendors who were multinational, multiracial, multiethnic, multireligious and multilingual.
Changes in Latitudes, Changes in Attitudes
You might think that a multicultural IT project is much the same as any other. After all, developers who employ the same programming language can usually decipher each other’s code even if they don’t speak the same human language. English now unites the IT world as Latin once united the Roman Empire. Yet in my experience, multicultural projects almost always generate conflicts. And that’s because people from different cultural backgrounds have different notions of leadership. In sum, global workers have varying attitudes about the importance of deadlines, the flexibility of rules and even the need to write things down.
At Moody’s, these cultural differences hampered our ability to conduct software testing and engineering process audits. Effective quality assurance requires an independent perspective and an open acknowledgment of defects. Until the mid-1990s, in a largely homogenous American development environment, the dynamics of QA methodology depended on three very American values. The first was the egalitarian ideal of social intercourse-the way distinctions of rank are supposed to be minimized in our daily interactions. The second, emerging from the first, was the informal give-and-take Americans learn in school as they’re encouraged to express opinions, challenge other students (and sometimes even the teacher) and brainstorm solutions. The third was the “tell it like it is” approach to conflict resolution, in which criticism may be expressed, ideally without shame or fear of reprisal.
But many of the IT workers who have emigrated to the United States within the past 10 years do not share those values, and they follow radically different codes of conduct. For some, a caste system or other rigid hierarchy establishes the ground rules of social relations. For others, education means rote learning and strict obedience to authority. In many cultures, open disagreement and direct criticism entail a painful loss of face and thereby close off the possibility of ever resolving anything.
As these values and behaviors collided, gaps in communication began to appear. The relationship between developers and testers changed. Developers have always enjoyed a higher status than testers, yet the formal organizational and informal social disparity widened dramatically. Testers became less willing to criticize and possibly shame their betters, and developers became less willing to collaborate with their inferiors.
Discouraged from pursuing a challenging, intellectual give-and-take with developers, testers sought to demonstrate their productivity by running lots of easy, superficial tests and generating reams of documentation. And although on paper it looked as if we were allocating more and more resources to quality assurance activities, in reality our test coverage and our process audit function were in decline.
Many other companies experience the same dilemma. In response, some organizations seek to employ Capability Maturity Models or Six Sigma for reconfiguring their processes. Instead, we opted for a simpler solution. We found that culture shock problems could be resolved-or avoided-by making a minor but significant organizational change. A QA manager was appointed at the project manager level. Testers reported to both a project manager and the QA manager in a matrix relationship, raising their status in their own eyes and in the eyes of the developers. The QA manager became responsible for coordinating standards and procedures across the project teams.
The QA manager also served as an ombudsman, combining the functions of a diplomat and a parliamentarian. Not only testers, but also developers, business analysts and product managers were encouraged to regard the QA manager’s office as a place where they could express sensitive concerns. In an environment where individuals were sometimes embarrassed to call attention to the cultural differences, the QA manager was usually able to approach the issue as a matter of workflow or communication protocol, allowing everyone to save face. After six months of this arrangement, test methodology and coverage substantially improved. Issues of engineering process and risk analysis were being discussed openly again. Both developers and testers felt that communication had become easier.
Skirting the Iceberg
It’s an understandable mistake to misdiagnose cross-cultural conflicts as issues of personality or job performance. Like an iceberg, most of a person’s cultural identity is below the surface. Differences in accent, clothing, table manners-those are obvious and therefore relatively easy to maneuver around. What don’t show are core beliefs and the questions they engender such as: What is fair? What is proper? To whom or what does one owe allegiance? What are the boundaries of ambition and responsibility? Those submerged incompatibilities pose the greatest danger to successfully navigating IT projects.
At Moody’s, I was the QA manager who confronted these issues. But nowadays, you may not need a professional anthropologist. An increasing number of organizations provide training in multicultural management. This practice makes good business sense. Not only can it help avert problems, it can also show IT executives how to transform their workforce from mistrustful tribes eyeing each other across the cultural divide into a corps that profits from each other’s perspectives.
