In recent decades several metaphors have been used in order to “grasp” what the transnational or global organization is like; the “networked” organization (Castells 1996) the “matrix” organization (Gottlieb 2007), or the “virtual” organization (Cascio 2002), to mention some. I am not launching a metaphor here to replace these. Rather, I seek only to try to think of a metaphor that can emphasize the darker side of an organization where production split up, standardized and rationalized in order to make it possible to move work to wherever wages are lowest. What could be better than the metaphor of an ugly creature with a pointed tale, giving associations to the more demonic side of liberal capitalism?
As I demonstrate later in the piece managers and consultants are far too eager to find positive metaphors for what goes on in organizations; linking for example work with metaphors drawn from the fields of leisure, sports and play (including even, the jazz improvisation of work [Kamoche et. al. 2002]). Wrapping ugly things in shiny paper, or performing magic rhetorical tricks to one side while scrupulously doing whatever it takes to increase return on investment is one aspect of corporate management, but that does not mean that employees have nothing to bargain with. In this context, the aim of this paper is twofold; one is to show the poisonous sides of corporate life from a worker’s perspective – in particular, the rationalizing and standardizing and shuffling around and contracting out of jobs, and the intensifying of work for employees as a result of such processes. The other aim of this paper is to show how workers might resist getting stung by the scorpion. I argue that by taking the knowledge and practice of employees seriously, giving them autonomy and a space/place for engaging in practice together, employees can “own” their work in a much stronger sense and thus also protect it from getting divided and distributed.
A few words should be said on the choice of title. First of all a scorpion is a creature in the family of arthropods. Arthropods come in various shapes and sizes, but they share the characteristic of having segmented bodies connected by soft tissue. In fact, the term arthropod comes from Greek and literally means “jointed feet”. Furthermore arthropods have a nervous system shaped like a ladder; paired nerve cords run through their fractured bodies, ending up in their brain, and each segment holds tissue of nerve cells that is directly connected to the brain cells. And the sweetest feature of all; each segment has a piece of the heart in it.
I introduce, then the metaphor of the organization with a geographically distributed work flow as a scorpion - a segmented creature, flexible in is movements, but still linked together, its blood system, nerve cords and heart running through all segments. And in what follows, also introduce Van Gennep’s role in this plot. But, before that some information about the research case study.
Changes in software work
As part of my PhD research I have looked into the structuring of work of an elite group of software programmers working in a Norwegian subsidiary of an Internet company. Programming is complex work and it demands disciplined persons with strong analytical capacities, good communication skills, and a sense of perfection. My informants have described their work as “challenging”, “fun”, “creative”, but also as “routine”, and “like laying one brick on top of the other”. However differently they describe their work, they nonetheless agree that it is “teamwork”. Each team member is doing an incremental part of the total system. It follows from this that coordination is a crucial criterion for success in software development projects. And a lot of time is devoted to “talking” software alive (Bertelsen & Bødker 2002). Because of the “social” nature of their work, it was a lot more fun to study them than I had originally expected. I had worked with software developers earlier, at the end of the 1990s, and I saw that changes had taken place. Back then programming seemed a much lonelier endeavor. While my informants in the Internet company would meet up and “synchronize” their work at least once a day, the programmers I knew ten years ago would meet maybe once a month.
So I asked myself: What has happened? Why all this talking, all the meetings, the “synchronizing”? And what is it about fancy words like “sprinting”, “scrumming” and “stand-ups”? That was when I started learning about the consequences of a heightened speed of software development work, and about the increasing commoditization and standardization of software production.
Commoditization of this line of work represents a challenge; software systems are non-linear, complex, and always-work-in-progress. Thus, carving out objects ready for “shipment” demands strong discipline and control over production and some form of what often appears to be extraterrestrial or divine intervention. It was upon this point of realization that Van Gennep entered the scene, waving his notion of rites de passage. I had noticed the frequent use of metaphors and symbols in the programmers’ project methodology, together with some highly ritualistic features. For example, after the programmers of my study have made official a new version of their product, they arrange what they call a “post mortem”, a meeting where they summarize the work process of the product just sent out. Thus, they are creating a border between the old and the new, drawing the line between the object that has been produced, and the one that is still in production. Software development is loaded with symbols and metaphors and rituals like this, and I see it as a way of creating order out of chaos, and as practical ‘tools’ in their effort to transform the flow of work into capital objects.
Joan Greenbaum (1979; 2004) has looked into the standardization of office work. Even though clerical work was Taylorized during the 1960s, in an effort to enhance control over workers and create a less expensive work process, it was commonly thought impossible to standardize professional work since it demands thinking, which is not measurable (Greenbaum 2004:76). Programmers were included in this group, and they enjoyed their privileged status as skilled labour conducting work that was “little understood and in great demand” (Greenbaum 1979:3). However, just as the factory model rationalized more and more office work, the computer workers eventually became subject to the same type of standardization and simplification (Greenbaum 2004). During the 1970s and 1980s they were divided into functional groups of architects, designers, programmers, testers, and technical support, each of them supposed to do their separate part of the total production, and gradually their work was transformed from worker-related processes to management controlled tasks (ibid.).
Today this is still the situation. And in the organization where I have done my ethnographic study this division of labor is visible. On one floor we find the “hard core” programmers, while on the other floor we find those who test and “package” the system, and who help clients install and use the system. The in-house-hierarchy is visible. At the same time they are part of a hierarchical division of labour stretched out between the U.S, Norway and, finally India. The head office is located in the U.S, while the product they are making in Norway is sent to India to be tested there. There is constant pressure to produce well and according to plans and deadlines. Not so long ago one of the only two internet search engine communities (one located in the US and this one located in Norway) was declared superfluous. The one in the States was shut down, while the unit in Norway now has to integrate a larger part of the internet technology production with their original product.
Five years ago they changed their project methodology in order to control their work process better and keep up with “the deliveries” which the head office demanded. They implemented so called “All-at-Once-,models” of running software development projects (Sutherland 2001), where ‘Scrum’ has been one of the most popular methodologies so far. Compared to how they structured work earlier (in separate sequences of planning, designing, production, testing, where each phase had to be done before initiating the next) the new methodology creates more integration, both between people and between tasks, thus making it more difficult to split ‘the knower’ from the known (Brown and Duguid 2000). In what follows I describe some of the features of Scrum and then move on to highlight to the the ritualistic features of Scrum.
“Scrumming”, “Sprinting” and “Standup’s”
The term Scrum originates from the Rugby field; scrumming is a way of restarting the game after an interruption or when the ball has gone out. One of the most important features of such a team, writes Nonaka and Takeuchi (1986), who originally launched the concept of “Scrum”, is that it “tries to go the distance as a unit, passing the ball back and forth” (1986:138-139). As a result of this the team will get deeply integrated and collectively engaged in the tasks; self-organizing teams becomes the result.
At the heart of Scrum lies the idea that software production should be planned and conducted via short steps (Schwaber 2004). Software development is difficult to plan ahead. Consequently, to stay in control one should keep to very short time frames. And within each such timeframe, called a Sprint, functional software should be produced by a cross-functional team. One of the programmers explained it to me like so:
In Scrum, work is divided into three phases: one phase where a task list is made. Then follows a phase of production where management will not interrupt programmers with changes to the plan. Programmers are shielded from any “noise” from the overall company. “They are supposed to focus”, says one of the three team leaders. “So we [the management] will deal with the necessary office politics”, he continues. The only meeting activities programmers are involved in are the Stand ups; a morning briefing session wherethree questions are addressed: 1) What has each team been doing? 2) Further plans? 3) Are there troubles ahead?
The third and last phase is the one involving integration; what has been produced is integrated into the system. The teams present and demonstrate “new functionality” and they terminate the Sprint with an evaluation of the work process.
Production and rites de passage
Arnold Van Gennep recognized that the human being goes through “a series of passages from one age to another” through his life (van Gennep quoted in Rapport and Overing 2000:229). In various societies these passages were singled out and celebrated, often by “certain, ceremonial, public rites” (ibid.). And what is more, these rituals seemed to share a common form: a tripartite structure, which van Gennep called the preliminary stage, the liminaire stage and the postliminaire stage.
In the first stage the individual was parted from his/her old status. In the middle stage, the liminal stage, the individual was to undergo change. This was a “betwixt-and-between”- phase (Turner 1969), representing a “time out” where people related to each other (those who went through the rites de passage together) as complete human beings, without socio-cultural constraints in the form of position and statuses. Turner (1969) argues that the precondition for the very continuation of a group/society lies in such regular separations or “time outs” where individuals get the chance to observe society from askance. He uses the term “communitas” to describe the sense of intense togetherness that emerges during this second, liminal stage.
The third and last phase of the rites de passage is the postliminare, also termed “rite of incorporation” (Rapport and Overing 2000:230). It is the stage marking the return of the individual to society, but an individual “born anew”. With the structure and mode of “rites de passage” in mind we will now return to the methodology of Scrum.
As soon as I heard of Scrum and eventually saw it in practice in the organization of my study, I could not help thinking of Van Gennep. The point I am trying to discuss here is not whether or not their work process can be viewed as a rites de passage. While rites de passage is related to life-crisis situations and moments of social transition, in this Norwegian workplace the ritual-like work process should be viewed as a practical way of handling the capitalistic reality. Since knowledge is immaterial, in order to transform it into capital objects, it needs to be divided into “sellable” parts for which the customer would want to pay. An additional benefit lies in the fact that it enables my informants to create “time-ins” and “time outs” for management interruptions. Such interruptions are kept to the lowest possible level in the mid-phase of production, thus there is room for a ‘community of practice’ (Wenger 1998) to develop with something resembling or having a touch of what Turner (1969) describes when he deals with the ritual “communitas”. In Scrum, the strictly ordered and disciplined initial phase of planning and prioritizing, and the last phase of delivery and the moment of “truth” where everything has to “fit”, creates a room in-between where people are free to get engaged in a creative, productive phase of trial and error. Hatch (1999) writes of something similar when she describes “empty spaces” in organizations. These are spaces for creative activity free from constraints like rules and norms. Empty spaces are hard to point out spatially and structurally, rather they represent working and thinking spaces which open as a result of ambiguity and emotions. And according to Hatch this is where organizational creativity is made possible.
The goal of the ritualized project methodology can be seen as something more than an attempt to attain control over worker and production. Through the three stages in a production phase work is made meaningful for the programmers in a deeper sense than it used to do in the “old” model of software development. Everyday work is still everyday work and sometimes “fun”, creative”, other times “routine” and “like bricklaying”, but by shifting intensive work to short time frames and starting “fresh” in each Sprint, people are engaging with their work and their colleagues in a different, and, according to my informants, improved way.
In mainstream economics knowledge tends to be thought of as always having the qualities of material artefacts, that can be stored (albeit sometimes in people’s heads), but always ready to be spread, transferred, controlled, possessed, lost and measured (Amin and Cohendet 2004:30). This reified view of knowledge is implicit in management’s effort to split, standardize and ship off work to all corners of the world. When this fails, it may be because they have neglected the tacit dimensions of all knowledge (Polanyi 1967) and the fact that knowledge is relational and contextual and, thus should be seen in relation to when, where and by whom it is ‘put into action’. I am not going to debate this further though. My point for now is to state that the reason why the programmers of my study have succeeded so well in producing well functioning technology is because they have taken this relational nature of knowledge seriously. The management within the Norwegian unit takes the knowledge of their workforce seriously, they emphasize worker-autonomy and give their employees the privilege of being the most important asset, shielding them and giving them room and space for a collaborative work forms to develop - a collective know-how and knowledge to develop - that is impossible to split up, carve out from context, and send off to other places.