During my study, it seemed to me that the engineers were engaged in diverse, yet comparable, tasks over different temporal periods and geographical locations. I noticed that the engineers appeared to be drawing on different disciplines within the organisation, such as electrical, mechanical, and civil engineering traditions, as well as marketing and sales activities. After a considerable period of observation, I could begin to see how these distributed work activities were emerging, albeit patchily, as a coordinated effort. I then started to question how these multiple heterogeneous practices, often over-lapping and sometimes conflicting, were jostled together to accomplish this coherent effect, and what this meant for engineers’ knowing.
I was drawn to the organising effects of a project management tool, the ‘Stage Gate Process’ (SGP), which seemed to be a key actor in mobilising this patchy coordination effort. I noticed that the SGP was mentioned frequently in everyday work and seemed tied to key activities of planning, designing and marketing the turbines. Employees discussed it very seriously: they showed frustrations about it ‘blocking’ their work, or referred to it as a panacea to solve disputes. I took a
photo of the first page of the SGP and showed it to the participants in their third interview (Figure 19). It created substantial dialogue in the interviews, highlighted by a comment from James, a Business Development Manager (BDM):
I think the Gate Process would be the most important thing out of all the things I’ve spoken about which helps me make my work easier because without that you don’t get the buy-in of others and you need the buy-in of others to progress.
James was appreciating how powerful a coordination tool it had become in ordering his everyday work.
So how did the SGP work, in principle? I asked the engineers to explain it to me. The idea was to implement metaphorical ‘gates’ between each stage when bidding for a potential project, obtaining the signature on the contract, building the project, and servicing the turbines. A ‘gate’ was the term used by the engineers to denote a controlled passage point through which collective decisions had to pass. Again, this could be understood as an obligatory passage point (Callon, 1986a). The department heads created a project team for each potential project,20 and included engineers from the four different departments. The project team was invited to every Gate meeting. The stages were laid out in a typewritten document detailing what needed to be achieved at each stage, which required a signature by members from each relevant department before a project could progress through the Gate and on to the next stage.
The SGP was initiated to support a coordinated effort that had reach and scope “beyond a single event or one-site practice”, and it did not have to be “reinvented each time or assembled for each task, but invisibly supports those tasks” (Star & Ruhleder, 1996, p. 113). These are two of the dimensions that Star and Ruhleder (1996) would argue are characteristic of infrastructure. In this sense, it could be argued that the SGP, positioned as a protocol, was acting as part of TurboUK’s infrastructure as it related to its organising practices.
20 This ‘project team’ was comprised of a project manager (referred to as a ‘PM’, from Project
Management), a project engineer and an electrical engineer (from Technical Support and Service) and a business development manager (known as a ‘BDM’, from Sales). A project was considered ‘potential’ if the engineers considered their turbines a suitable fit, both with cost and technical
However, I want to interrupt traditional understandings of infrastructure that tend to position infrastructure as a stable, a priori entity, “something upon which something else ‘runs’ or operates” (Star & Ruhleder, 1996, p. 112). I find Star and Ruhleder’s (1996) notion of ‘relational infrastructure’ helpful to start disrupting these understandings, repositioning ‘infrastructure’ as constantly enacted relations of associations, some held in place more strongly than others. Although originating from an ecological tradition, this foray into the relational infrastructure literature is helpful to position the SGP as a gathering of moving, interdependent bits and pieces that are momentarily assembled to support work over space and time. I will now show how the concept of relational infrastructure is helpful for an ANT-inspired analysis.
Firstly, Star and Ruhleder (1996) recognise that infrastructure is more than just familiar, transparent tools, such as power grids. I felt that if I asked the TurboUK engineers to define ‘infrastructure’, they would refer to the concrete materials of the organisation – the things that ensure stability – for instance, telecommunications, wires, datasets, and financial arrangements. I imagine if I started talking to the TurboUK engineers about a different kind of infrastructure, one that comprised abstract entities such as spaces, organising processes, and relationships, they would say, “That’s not infrastructure!” However, in this chapter, what I am trying to show is that this is how their infrastructure was being enacted with them as one of the (human) actors. Showing participants the photograph of the SGP in their third interview (Figure 19), I wanted to follow Latour’s (2005, p. 23) advice that, “the task of defining and ordering the social should be left to the actor themselves, not taken up by the analyst”. I asked them how the SGP helped and hindered their everyday work, which helped make this more abstract infrastructure visible for them.
Secondly, a relational infrastructure highlights the taken-for-granted and often invisible dimension of working with processes (Star & Ruhleder, 1996). Star and Ruhleder (1996) argue that infrastructure “becomes visible upon breakdown”. For example, when “there is a power blackout” (p. 113). As previously discussed in Chapter 3, Latour (2005, p. 81) advises the researcher to attune to “breakdowns”: to look for “silent intermediaries”, which can make visible important
ambivalences, disconnections and contradictions in the engineers’ everyday work as they resolve these breakdowns. I will be drawing on the metaphor of visibility and invisibility throughout this chapter. This resonates with Law’s (2004) presence and absence metaphors discussed in Chapter 2.
Finally, a focus on the relational aspects of an infrastructure emphasises how the mundane relationships between processes, databases, and software packages are not stable entities, but enact certain ways of organising, or ordering, that are not neutral. Infrastructures evolve, change, and are changed by the practices of the people using it (Bowker & Star, 1999). I thus needed to be attuned to this entangled, recursive relationship as I followed the work of the SGP.
However, I still feel the word ‘infrastructure’ implies a ‘thingness’ that is counter- intuitive to ANT language. In this light, it may more useful to talk of infrastructuring, rather than infrastructure (Mathisen & Nerland, 2012). Working with ‘infrastructure’ as a verb, rather than a noun, is in line with Law’s purposeful semantic shift from ‘order’ to ‘ordering’ (Law, 1994, p. 101). This better depicts an on-going, incomplete and recursive process, which is more harmonious with the assemblage and network metaphors that I have been drawing on so far. To summarise, the SGP appeared to me as a key actor to follow during my time at TurboUK, and could be argued to form part of TurboUK’s infrastructuring in relation to its organising processes. I am advised by both relational infrastructure literature and ANT writings that it is helpful to look for moments of breakdowns to make visible the complexities and messiness of the SGP, and to remember that it is an inherently political, multiple and unstable endeavour. Keeping in mind these characteristics, I will now proceed to show what the SGP process becomes as it passes through the hands of multiple actors. Firstly, though, I consider how the SGP acted as the protocol intended: to make visible and mobilise practices of support to help patch together expertise.