INTRODUCTION

Only recently has corporate or business ethnography — the labor-intensive method for investigating organizational life — gained in popularity; the establishment of EPIC has certainly contributed to recognition of our field by the business world. A number of organizations have added professional ethnographers to their research staff and many more hire ethnographers as consultants for internal projects or market research. But even with these achievements, the recent commitment by the management of Fujitsu’s software and services organization to ethnography stands as remarkable. Fujitsu contracted with PARC to engage six researchers from our Computing Science Laboratory’s ‘Workscapes and Organizations’ area in developing a significant ethnographic capability inside its software business. Initially, the target audience for the ethnography training was the twenty Fujitsu members of the project working with us directly. Two thirds of them were system engineers (hereafter SEs) and the rest were researchers from Fujitsu Laboratories. Later, when the value of ethnographic research for and with Fujitsu customers became clear, we were asked to start training more SEs in the business units so that Fujitsu could make ethnography part of a new way of working with its customers. Training such a large group of young professionals in ethnography was not without its challenges, of course. In this paper we will describe our experiences, the results and the lessons learned. The outline of the paper is as follows. We begin with an overview of the project to set the context. Then we describe the initial training we gave and the challenges we came across. We used this experience when we later had to design the course aimed at educating a much larger group of SEs, and so we describe these courses in some detail. Finally, we describe how the organization has adapted fieldwork to fit in its own culture and ways of working with customers.

INITIAL TRAINING

Our project began in 2004 with two related goals: PARC was asked to use its ethnographic expertise to investigate Fujitsu’s organization and we were to do so in close cooperation with a Fujitsu team (the Fujitsu members had been pre-selected before we started the project) (see Churchill and Whalen 2005). We were to also teach this team how to do such investigations on their own. This paper will focus on the latter of these.

The first challenge for us was how to train the Fujitsu members in ethnographic fieldwork methods. Reflecting on our own experience of learning how to do ethnography we realized that we had acquired our skill in (diverse) academic institutions through a mostly unstructured and, to be honest, self-directed process. We had taken a few courses in which ethnography was explained as method, read a variety of writings on the topic (mostly actual ethnographies), had the disconcerting experience of being sent out to a field site on our own, and had written field notes that, if we were lucky, an instructor might later comment on. We learned mostly through informal discussions with fellow graduate students and advisors. We tried to mimic at least some of these experiences in a week-long training for the Fujitsu members that consisted of a set of lectures and exercises and also provided the students with relevant papers on and by ethnographers they could read.

Although these lectures were received politely, we learned over the course of those first months that many of the members of the organization were only marginally convinced of ethnography’s value as a method for their business. As it turned out, the problems that team members had with ethnography were actually quite profound; our method and way of conducting our research stood in marked contrast to what they considered sound working practices.

To understand the members’ problems it is important to consider their different backgrounds. As we explained above, the project team was comprised of two groups, members of the solutions and services organization (i.e., SEs) and members of Fujitsu Laboratories (i.e., researchers). These SEs had diverse academic training; some had a background in the physical sciences, some had been trained in engineering, computer science, and still others had non-technical background: linguistics, communication studies, sociology, and the like (Japanese software companies often hire young people for their overall intellectual skills not necessarily putting the highest priority on their educational background). Some of the SEs in our project team used to be in charge of managing projects, including such things as budgeting, scheduling, coordinating with subsidiaries and subcontractors, and managing the customer relationship. Others had led project teams. Software projects have clear development targets and phases, with their schedule ‘planned backwards’ from delivery (or cut-over) date using standard software engineering methods.

We explained to these SEs that one of the important principles of ethnographic research is that it is open-ended and that one cannot determine beforehand what the outcome of the research is going to be, and that therefore, there was little point in trying to create a terribly detailed project plan with a predictable trajectory. However, to SEs who had a highly structured approach to managing projects and developing software, this way of working – without well-defined and largely pre-determined deliverables at set time intervals – was not just unusual; it was a sign of poor project management. The reasons we gave for this approach were taken to be excuses or at least evidence of our unwillingness to embrace proper accountability standards (indeed, some thought our approach was irresponsible).

Many of the laboratory members felt similarly, but there was an additional aspect to their skepticism about ethnography. In their research, which had been overwhelmingly technical in nature, they always started out with a well-defined hypothesis and took a positivistic approach. Moreover, quantification was always preferred over qualitative description; without quantification there could never be any real ‘proof’. We repeatedly and carefully explained how this way of working, however valuable for other kinds of research, was at the end of the day incompatible with doing good ethnography. Although our arguments in this regard ultimately held sway and the project proceeded more or less in line with our strategy, it nevertheless became obvious that a number of members remained unconvinced. For instance, when we were preparing for field interviews they would persistently ask: “What exactly do we want to find out in this interview?” While this question in and of itself was not a problem for us, they expected the answer to it to then drive the interview process by creating a set of structured, quite specific questions. They had great difficulty with the way we wanted to carry out these interviews – relying on a set of open-ended queries with the goal being to let interviewees express themselves, to listen more than interrogate, and to normally raise specific questions only in response to what we heard (to clarify, for example) or when certain information was missing.

Another challenge for us was to convince the project team members of the need to go into the field as much as possible and to look at people’s work holistically, considering everything they see in its local context and without judgment. SEs commonly think in terms of the functionality of a system. They are used to working within a well-established paradigm in which they basically translate what they hear from meetings with the customer into their ‘system framework’. So SEs typically would seek just enough information to define the functionality of the system. The relevance of taking a first-hand look at an actual workplace, the physical environment, the way work is conducted and oriented to by people in the field, was not always apparent to them, let alone looking at other dimensions of the job or features of the site that were related to the work in question. Sometimes we were able to convince them of the relevance of looking more holistically at work, but even if they could see the value of this they wondered about the efficiency of such an approach especially since we would insist that just what one would discover in this regard could not be specified in advance.

Another challenge was the way the team members made their observations. Whereas seeing and listening closely were skills with which they came equipped, the steps of becoming aware of what they are seeing even when those things are very ordinary and then to be able to articulate the observations does not come naturally to all. When the SEs would go to field the observations they would come back with would often contain judgments about the efficiency or efficacy of what they had observed. So when looking at a workplace they routinely assess which part of the work they observe is not efficiently done. Whereas passing such judgment is not problematic per se, we found that all too often project team members’ judgment would prevent them from uncovering a deeper understanding of the workplace. ¹ This situation was only exacerbated when the SEs went out to observe other SEs, i.e., when they saw people do ‘their’ work they were even less able to look for the underlying logic of their work practices but were always judging whether the SEs were doing their work well. In our analysis sessions with project team members we repeatedly told them that they should suspend their judgment while doing observation, and instead probe deeper into the actual work practices but, ultimately, we found that it was difficult to overcome.

Finally, one of the challenges we faced was the project team members’ motivation. Whereas some were very motivated to learn and saw it as a new career opportunity, others were concerned about their career as SEs not knowing exactly what they could do with the fieldwork skills.