We detail an ongoing, consultancy partnership, where ethnographic field methods are being used to elucidate the work practices of software engineers in a large organization. We focus on intellectual and logistical challenges that we face as a team – non-collocation; widely varying experience of ethnographic methods, local language and culture; and conflicting responsibilities and lines of accountability. We consider the social spheres in which our team members operate and the sociality of our team as a whole. As ethnographic teams are increasingly considered de rigueur within corporations for cultural translation in the face of globalization, the issues we face are likely to become more commonplace.
INTRODUCTION
Ethnographers are increasingly being called on by corporations to do cultural translation in the hope that competitive edge can be maintained in an increasingly global marketplace. In this paper we present our own experience in this regard by describing an ongoing study, where ethnographic methods have been engaged to highlight issues in software engineering practice in a large organization. In this instance the cultural translation is two-fold – to observe the culture of software engineering within the organization and illuminate the gaps between management ideals and actual practices, but also to consider innovations in software engineering practice world-wide and to consider what innovations may be suitably introduced given the existing organizational culture.
In this paper we focus not on the domain itself, but on our experiences as partner/consultants. We discuss issues in the maintenance of productive sociality in our multi-cultural, multidisciplinary, distributed ethnographic fieldwork team, addressing the question posed in the call: “How are we as researchers embedded in social collectives and how does that relate to our research questions, presentation of findings and the ways in which we conduct ourselves in our research?” We discuss some expected and unexpected challenges in establishing and maintaining productive working relationships within the team but also between the team and those under study.
Product or Process?
We would first like to draw two distinctions we have found useful in situating our work within the broader arena of ethnographically inspired fieldwork within industries and corporations.
First, we distinguish between ethnographic methods directed at informing innovations in products and services for consumer markets (e.g., Cagan and Vogel, 2002; Squires and Byrne, 2002) and ethnographic studies focused on organizational change, or innovation in work processes. Of course this product versus process perspective does not necessarily mean a sharp split between time spent, observational or analysis method, or even number of settings. Both forms rely on the ethnographer’s careful empathic eye, and arguably a deeper social connection between the “observer” and the “observed” than is required for many other forms of investigation (e.g., surveys). What most distinguishes the two in our view is the output, and in the way in which the “results” are considered to be “actionable”. The former is focused on influencing the design of a tangible artifact or collection of artifacts. This product will likely lead to changes in the consumer’s relationship with others. The latter tends to produce recommendations for changes in people’s relationships to others and to processes; artifacts may be more or less designed as part of the process but are secondary. The distinction is ontologically tricky but important: One form leverages sociality that exists to create new product niches and considers changes in sociality as another opportunity for a market while the other sells the recommendations for a transformation of sociality. Our current study is an example of the second form of ethnographic engagement.
It follows that the work of the ethnographic process itself in these differing ‘modes’ may lead to differences in approaching the sociality of (and with) those under study, but also in the sociality of the fieldwork team itself. Studying processes and being committed to process change from the “bottom up”, honoring existing practices while at the same time discussing the possibility of new practices requires an inductive and collaborative strategy wherein the social relationships between team members and those we are studying is central. Accounts of the work process are jointly constructed in a collaborative sense-making process, where meanings are negotiated and clarified with fieldwork team members and those “studied” participating. Such an engagement requires time, and strong trusting relationships to form between ethnographers and those under study and between the ethnographers themselves.
The second distinction we draw is between the work of process ethnography to lead to process change “and change management”: “the process of developing a planned approach to change in an organization” where “the objective is to maximize the collective efforts of all people involved in the change and minimize the risk of failure of implementing the change” (wikipedia definition). Unlike many change management studies that use interview and survey analyses, we are more focused on the detailed, everyday work practices and the day-to-day sociality of employees. In this view, the existing organizational structures, procedures and processes are studied as they are actually accomplished by members of work communities, with the aim of collaborating with those communities to stimulate change. By contrast, in many change management studies these details are seen as epiphenomenal to structural understandings and strategic interests.
PRACTICE INNOVATIONS IN SOFTWARE ENGINEERING
As noted, our domain of study is software engineering practice. Software engineering is a set of diverse activities. It has been defined as “the computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting” (webopedia definition). This definition underscores that software engineering is a broad term for many kinds of activity with many stakeholders and participants.
Our project addresses system and product development in a large organization. In general, within the software engineering industry there has been a shift away from proprietary software systems and ‘closed’ mainframe platforms to open architectures. Increasingly intense business competition has accompanied this change; centralized software development operations of the 1970s and 80s have given way to a more distributed work organization and more variation in the development process. However, many long-standing software development organizations in our subject country are tied to the tradition of centralization, making process innovation much more difficult to achieve. In addition, software development in our subject country relies on long-standing relationships with subsidiaries and especially subcontractors to carry out development work. Efforts to develop systems and products that are more closely tied to customer needs have met with limited success for a number of reasons: a contributing factor is the aforementioned dependence on subcontractor relationships and performance, but, more critically, little has been achieved in the way of innovation in the ‘upstream’ (requirements, design) phase. The move toward extreme programming and lean or agile methods which foreground social interaction and rich, tightly coupled collaboration between development team members and between the development team and the customer, has had little effect on development efforts – complex system integration projects continue to follow a structured linear, sequential design method.
Thus, in our work we are focused on the engineers who design and manage the development of products and services for their customers. Our focus is on the ways in which the engineers construct their customer’s desires and needs (in engineering terms ‘requirements’) within the confines of their own organizational and professional culture. Our deliverable is a methodology for the effective creation of designed products and services for their customer; in particular, different ways for engineers to work and organize their projects in that creation process. In addition to our own fieldwork, we are also engaged in a long-term project to train an ethnographic eye into the practice of software engineering and project organization as practiced in the particular organization we are studying. This approach has methodological overlap with user centered design methodologies like Contextual Design (Beyer and Holtzblat, 1998; see also Wixon and Ramsey’s edited collection on field methods for software design, 1996). Our task is therefore not one of addressing the system building processes directly, but rather in tackling the relationships with customer, issues in project coordination and leadership, and the sharing of practical knowledge across their entire software business about how to achieve success in these matters.
COLLABORATING AT DISTANCE
Figure 1 gives an outline of our team structure and reporting chains, and thus the social spheres in which people on the team operate; for the purposes of this paper we will call our partner company in this project Acme.
Figure 1 Stakeholders and group membership for the PARC/ACME fieldwork project
On the left are Acme and Acme’s customer. Communications occur between Acme management and Acme workers through multiple means, including management meetings and emails. Acme sales and software engineering staff are the main point of contact between Acme management and Acme’s customers, although alliances at management level between companies is also common. On the right, is our research group, and beyond that the research communities to which the researchers belong. The main point of interest for this paper is the Fieldwork Project, shown in the centre of Figure 1. The fieldwork team is made up of researchers from our organization with varied backgrounds (but all of whom have experience in field work studies), and seconded Acme employees who are trained software engineers. The intention is that these seconded Acme workers will be trained in ethnographic methods and will then disseminate the methods throughout the organization.
In terms of numbers, the fieldwork research team on the ground in our subject country is made up of three research staff from our organization, and seven software engineers from Acme. None of the software engineers have previously had training in ethnographic methods. Two of the research staff from PARC are natives of the subject country; the third is not, but can converse conversationally in the native language. Three research staff travel back and forth between the US and the subject country, none of these are natives of that country, and none speak or read their language. Finally, one translator is based in the US, and three different translators are available on-site in the subject country. There is also one bilingual engineer who assists with translation on some occasions. Some of the other engineers speak and read English with different levels of competency, but none of these are able to function as translators in lengthy or detailed conversations. Three levels of management from the partner company oversee the project, with four managers present regularly in the team operations room, at meetings and in discussions.
Establishing the “Joint” for “Joint Construction”
Given this rather complex geographically and culturally distributed social group, which is unusually, perhaps uniquely, large for an ethnography-based project, it is interesting to draw some lessons and highlight some points that relate to the sociality and effectiveness of the team itself. Challenges we are experiencing are broadly broken into: Access to places; Access to people; Access to data – conducting collaborative analysis; Data integrity; and Report integrity.
All the issues we discuss affect members understanding of the fieldsite and therefore their communications with those under study, but also feelings of team membership. These in turn affect overall project effectiveness. While access to places and the integrity of data and reports are perennial problems for all fieldwork projects, and have been since the beginnings of ethnographic study, getting access to others and to data we thought would be less of a problem given the proliferation of communication technologies from media spaces to video conferencing to email and cell phones. Interestingly, however, in some senses our expectations led to a greater sense of disappointment and distancing than if we had entered into the project believing all communication would be limited to summary notes and infrequent face-to-face meetings. We will speak more to this in the sections below.
Access to Places – While we are working closely with certain members of the organization, it has not always been easy to gain access to other parts of the organization, or to customers and contractors. Given the organization relies so heavily on contractors, studying the project management process alone without gaining deeper insights into the contractor and customer settings is a problem. Further, as many of the software engineers in the organization work in customer sites, not understanding their work settings and the ways in which they relate to their parent organization while in these settings reduces our ability to fully comprehend the social dynamics of their work. In the end, as Auge puts it, “it is a matter of being able to assess what the people we see and speak to tell us about the people we do not see and speak to” (Auge 1995).
There are two other forms of access to place, however. First access to any site at all; those remotely located in California seldom have access to the sites of the work practice under study. And when access is possible, it is not sustained over a period of time; people cannot become accustomed to our presence, trust cannot build, and we have no insight into what are day-to-day, versus unusual, occurrences. The second form of (lack of) access is language and (national, rather than local) culture. Even when access to field sites and work artifacts is possible, activities cannot be understood without careful and in-depth language and cultural translation. Such problems have traditionally been overcome through long-term immersion – often on the order of decades (e.g., Moeran, 2005). The requirements of our project contract preclude such long term, detailed engagement. We do, however, have two native speakers from our company and several trainee ethnographers from the partner company on the fieldwork team. Which brings us to the question of how the remote project members gain access to them and what they know – bearing in mind this kind of (translation and) sharing is an additional task for them.
Access to People – With remote work and time differences, access to people is limited. Researching and designing to circumvent or alleviate problems caused by such time and distance issues has long been a topic of study within the field of CSCW (Computer Supported Cooperative Work). In our current project, the three Californian team members have been flying back and forth to the main team site, email exchanges are conducted and video and audio conferences are held regularly. Although some familiarity and rapport exists, for those of us who are traveling in this way, there is a constant game of “catch-up”. With no access to asides and water cooler conversations, being “in the thick of it” intellectually and emotionally is not easy. Audio and video-conference technologies do not replace co-presence. Time differences mean we are out of circadian phase when talking; in California we are readying ourselves for the evening following a day’s work when conferences occur (usually 5pm PST), while meetings are taking place at the beginning of the working day at the remote site. For those who travel back and forth, there is also a physical and emotional cost – there is a temptation to try to maintain working and personal relationships in both locations, and to keep on top of ongoing projects in both time zones, leading to exhaustion. These tendencies are obvious, but ones we have had to explicitly acknowledge, address and account.
Access to Data – Ethnographic analysis is discursive and artifact centered. Artifacts are a central part of getting to know the field site, and how those we are studying manage their relationship to their work, but also their relationship to each other. As Moeran (2005) states “‘Things give people ideas of one sort or another. They lead to shared beliefs. Always and inevitably they bring some people together and exclude others. The social exchanges that take place through things are often strategic.” Given the distributed nature of our team, and the differing language abilities and cultural background of the team as a whole, the sharing of artifacts for analysis with those not on-site has been a serious challenge. Network firewalls have meant file-sharing tools are not easily used and data size and bandwidth limitations at the field site have prevented sharing through email and through standard file sharing techniques.
Translation has been good with support from native language speakers on-site and professional translators, but again, an added burden is placed on colleagues located in the field site for translation, and even the most excellent professional translators may not think to translate the nuances and subtleties that are needed to fully appreciate people’s relationships to each other and to their work. We have found many professional translators can elide what they consider to be ‘unnecessary’ or socially inappropriate words and phrases on the part of the speaker/actor (the force of an uncomfortable exchange may be filtered for example). Tone of delivery is not always easy to decode even when one is present given the cultural unfamiliarity. In translated transcripts, all paralinguistic cues are missing. But, as we know, impoliteness, “unseemly” behaviors and affect cues (e.g., gestures, facial expression, glances, beat gestures) are our clues to the ‘real’ social dynamics of a setting; politeness and public fronts may be considered “professionally appropriate” but they are not our allies in fieldwork.
Finally, when artifacts are available through shared folders, emails or even through video, deictic gestures so crucial for orienting and developing shared understanding through body and language orientation to an artifact are a challenge (Churchill and Erickson, 2003). Considerable overhead comes in simply orienting everyone to the same place in/on the artifact (comments like “No, page 3, not page 2” are commonly heard as someone waves a sheaf of papers at the video camera). In addition, the frame or conversational setting is missing. Without shared data, joint analysis suffers, but also opportunities for building good working relationships are not available. And, as noted above, language translation cannot convey cultural aspects of the significance of, for example, documents that are collected even when they are shared.
In order to better exploit developments in digital data storage, tagging, translation and sharing further design needs to be carried out. While no technology will ever replace being there, such sharing technologies need to be social technologies not simply data storage and transport technologies. Certainly we need to allow access to artifacts such as transcripts, movies and images. But for collaborative data analysis to take place, technologies of sharing rather than simply storing are needed. That said, when concerns for data security mean shared networks are not possible, the quality of the application becomes irrelevant.
Data Integrity – If data breadth is one concern when problems exist in access to field sites, and concerns about data depth arise from lack of access to recorded field data and to deep sustained discussion, then data integrity is an issue that can arise from over reliance on inexperienced fieldworkers and from sanctions around information.
Our apprentice fieldworkers from the partner company who are highly familiar with the domain (indeed domain experts trained by and working for the partner company) are simply not always able to maintain an ethnographic stance of the other, the stranger, the stance from which much powerful analysis starts. On occasion, they take for granted and thus fail to highlight or even report items that for us, as experienced ethnographers with an inexperienced eye on the domain know to be crucial linchpins for developing understanding. Such expertise will develop over time. But even if such expertise develops, that does not solve the potential problem of reporting uncomfortable findings to their managers. This is the subject of our final observation in this paper.
Report Integrity – With so many stakeholders with different understandings and different emotional investments, many different forms of reporting are required, often when results are preliminary. The pressure to draw premature conclusions is often a problem in participatory design settings, but we are keenly aware of the push to elide uncomfortable findings and to legitimate existing narratives about process and to thus preserve the status quo. Typically, this pressure comes not from the senior management level that engaged us in the partnership relationship, but from those who consider they have most to lose – those who are closer to the work and those who are tasked with carrying out work practice change. Maintaining professional integrity in the face of this push to be simply a certification process for existing stories and practices (providing the “Ethnographically Approved!” stamp) is a serious challenge. And resistance to this pressure without risking trust (and therefore access to the work itself) is tricky and requires energy, time and negotiation skills. This situation is compounded because, as noted, some of the project team members (those from the partner site) are answerable to us as intellectual leads and trainers as well as to their company managers who are not themselves being trained. There is on occasion discomfort at reporting things that will make their managers (or their managers allies) “look bad” for fear of reprisal. Our apprentices live in a potentially uncomfortable social interstitial, between us their fieldwork mentors who are relying on them to deliver observations and insights and their corporate management for whom those insights may be deeply uncomfortable. To be effective as a team we must honor the constraints on all the team members for what they can deliver in the frames in which they are working, as well as the frames in which we are working.
SUMMARY COMMENTS
In this paper we have introduced our work in an ongoing field project investigating software engineering practices in a large organization. Given the distributed nature of the team and the multiple social worlds in which team members operate, we have been forced to reflect on our team sociality, mediated and face-to-face, to a greater extent than in previous projects. Practical, informational and cultural barriers to establishing a shared world-view from which to generate joint understandings exceed those we have previously encountered.
Issues have arisen due to geographical distance and language and cultural difference. Although networked technologies for reducing distance exist, these have helped minimally due to time zone differences (a problem for synchronous communication tools) and concerns on the partner side for data security (a problem for asynchronous tools such as shared folders). In addition the project was designed to be a tightly coupled collaboration with team members from both organizations. Participation in the social collective of the fieldwork team is challenging when the team is distributed, culturally diverse, have different skills, different levels of aptitude and commitment to the methods, and different levels and lines of accountability. Our own lines of accountability are complex as we are answerable to our own managers, but also to different levels of management at the partner company, each with their own sensitivities and concerns about what will and will not be revealed. Constant, gentle, polite resistance is needed to maintain the integrity of the fieldwork and reportage of findings. This kind of ongoing defense of findings and reestablishment of ground rules for ethnographic engagement in projects is, we believe, an essential part of the work of conducting effective fieldwork – work that is too often invisible when accounting practices are more focused on “tangible” deliverables results, and thus, work that is underestimated in planning and budgeting. As multi-sited, multidisciplinary ethnographic fieldwork teams are increasingly engaged as cultural translators within, between and for corporations, the kinds of issues we are experiencing will, we hope, come further to the fore.
Acknowledgments – The authors would like to thank Les Nelson for his thoughtful comments on earlier versions of this paper.
Elizabeth Churchill is a research scientist in the Computing Science Laboratory at Palo Alto Research Center. Her research centers on the design of effective sociotechnical communication settings – from online spaces to augmented physical environments. She is an active contributor within the Human Computer Interaction (HCI), Computer Supported Cooperative Work (CSCW) and Social Computing communities.
Jack Whalen is a Principal Scientist in the Computing Science Laboratory at Palo Alto Research Center. His research spans three areas: systems to support knowledge-sharing in work communities; artificial intelligence applications for workplaces; incarnate practices in service work. He is currently leading a project studying different approaches to system engineering work.
Ethnographic Praxis in Industry Conference Proceedings 2005,pp. 179–187. © American Anthropological Association, some rights reserved.
REFERENCES
Auge, Marc
1995 non-places. Introduction to an anthropology of supermodernity London and New York: Verso Books.
Beyer, Hugh and Holtzblat, Karen
1998 Contextual Design. Designing Customer Centered Systems. San Francisco, CA: Morgan Kaufman.
Cagan, Jonathan and Vogel, Craig M.
2002 Creating Breakthrough Products. Prentice Hall.
Churchill, Elizabeth F. and Erickson, Tom
2003 Talking About Things in Mediated Conversations: An Introduction. In Human Computer Interaction, Volume 18, Nos. 1&2. London: Lawrence Erlbaum Associates.
Moeran, Brian.
2005 The Buisness of Ethnography. Strategic Exchanges, People and Organizations. Oxford: Berg Publishers.
Squires, Susan and Byrne, Brian, editors
2002 Creating Breakthrough Ideas. The Collaboration of Anthropologists and Designers in the Product Development NAPA Bulletin 23. London: Bergin and Garvey.
Wixon, Dennis and Ramsey, Judith, editors
1996 Field Methods Casebook for Software Design. New York: John Wiley and Sons.
Web resources
http://en.wikipedia.org/wiki/Change_management, accessed 2 July, 2005
http://www.webopedia.com/TERM/S/software_engineering.html, accessed 12 September, 2005