This section explores how the use of metric-based processes, such as databases, to organise work can flatten and eliminate complex issues. This representative practice raises issues of power effects, resistance and a
questioning of the infallibility of processes. The following anecdote highlights how these issues unfolded when the service team discussed how to implement standardising processes to accelerate their decision-making. Jason, a service engineer, explained how colleagues in his department developed an Excel-based process to help prioritise the risk-levels of problems with the operating wind turbines:
So there is such a huge list of things that need dealt with, problems with the turbines. These are called non-conformity reports (NCRs) and are registered as part of a quality assurance process. However, you end up just dealing with the top ten of fifty a week, and so to prioritise the tasks, you end up giving them a number – it’s called a QRI number – and it goes up to 1000. So if you have a 900 it will get done, if you have a 100 it probably won’t get done … The higher the number, the higher the priority is, so on our Monday morning meetings we look at all our high QRIs.
While I was work-shadowing Jason one day, he showed me how the QRI was configured. A QRI code symbolised a combined score of risk in the equation: QxRxI = Repetitiveness x Cost x Impact. However, if the NCR was connected in any way to a health and safety issue, then it was automatically given high priority. I asked how they established the figures to enter in to a QRI equation. Jason commented that they were very subjective figures so they tried to discuss them as a team before they were added into the database to be as objective as possible. They mentioned that they often found this task very difficult, and that the QRI system was insufficient for representing the complexities of their work. It seemed that the QRI calculation was making the material traces of the decisions that constitute the notion of ‘risk’ invisible as it translated them into a hierarchical, metric-based system.
For example, Andy, another service engineer, was frustrated with the QRI calculation because, as a rating system, it did not account for the subtleties of the customer relationship and maintaining TurboUK’s credibility. For example, the QRI formula used to calculate the risk of the problems caused by a ‘noisy’ fan at a particular wind farm site, Cathwell, did not equate to a high QRI number, as Andy pointed out:
With Cathwell’s NCR [fan sound], I couldn’t have classified that anything other than low, because it is low – financially, health and safety wise, and repetition – it’s all low. The only risk is it could harm the reputation of the technology in the UK sort of thing, we don’t want the Exalt going into the press as being shut down. So that [QRI] system works in some respects but then it only really covers faults, it doesn’t allow you to prioritise other aspects of our work, which aren’t on the system.
As I will discuss in the following chapter, Andy had to react very quickly to this noisy fan, negotiating a solution with the council and client, and thus ensuring the Exalt’s positive reputation. So, if Andy had relied on the QRI calculation to prioritise his tasks, the Cathwell NCR would have not been attended to and resolved. He had learnt that whilst the QRI system seemed to exert ordering power, and could appear immutable, he resisted being enrolled in it, and used his professional discretion to override this process: he realised that the QRI was not an infallible process.
Finally, another difficulty arises when processes do not function appropriately for the task in question. For example, Fay explains how she wrestled with the design of the database they used to order turbines:
I had a hell of a problem on a project before because with this particular turbine and tower height combination, it looked like on the database that you couldn’t have a lift. I was like, ‘But you must be able to have a lift because all our turbines come with lifts,’ and my boss was panicking because he was like, ‘What if there hasn’t been a design for the lift, what are we to do because this has to be on site?’ and I’m like, ‘It must just be a mistake. Someone must not have put the documentation on the database,’ or whatever, and it turned out that was the case … You then get stuff that comes to site and it clashes, there’s people having to hacksaw holes in platforms because the cables can’t go where they need to go and it’s like, ‘Nobody checked that this switchgear was compatible with the holes to put the cables?’ Apparently not!
On the database interface, there was the option to select certain combinations of turbines and their components using drop-down menus. Once selected, the user was presented with a range of ‘extras’ that certain turbine combinations were programmed to offer. However, when the database was used in practice, it caused problems for the engineers because the technology had “back-talked”, in
Styhre, Wikmalm, Ollila, and Roth (2012, p. 152) terms. That is, “it was not functioning as anticipated in the regime of prescribed technological standards and was instead in need of further investigation” (p. 162). As another actor had not engaged with the database accordingly, it was not allowing them to add certain components (e.g., the lift) or check whether materials were compatible with each other (e.g., the switchgear cables and the platform). The software was back-talking to Fay, exerting power through its black-boxed inscriptions. When Fay realised the system was not working, she had to stop and question its design. Similar to Andy, she realised it was not infallible, and therefore knew she had to over-ride the system to get the combination she needed.
These examples of delegating decision-making to technical processes shows how information and data can end up being homogenised and filtered to fit the system. If this information is forced to fit into a drop-down menu on a database that only offers a select number of options, or is transposed as a number, then this translation can restrict, or hide, complexities and subtleties. This issue is particularly pertinent to emerging industries where rapid innovation and changing policies generate precarious information that resists being represented by pre- defined checklists. Furthermore, this representation has consequences for power, as Edwards and Fenwick (2015, p. 1399) write:
When centres then translate these resources into representations such as numbers, they can flatten and display them in one space, eliminating their material complexities and cutting their relations of power. Thus decontextualized and reconfigured as non-material, these entities can be calculated in ways that produce hierarchies of advantage.
The elimination and flattening caused by the representation of complex issues with the use of numbers invited engineers to treat processes and databases as matters of concern, in Latour’s (2004) terms, rather than matters of fact. The engineers needed to keep re-opening the design of these processes, making them visible to allow for local contingencies and flexibilities. For example, Fay started to question who had designed the database, and tried to assess where the database, as an actor-network, had failed to enrol the necessary actors (the lift documentation). The engineers’ realisation that processes, protocols and
databases were not some pre-existing, invincible system afforded a critical knowing-in-practice for organising work.
Yet, on the other end of the spectrum, TurboUK engineers were faced with instances in their everyday work where the processes were still so undeveloped, so messy, that they had too many material traces to follow. Newcomers felt pulled by multiple potential modes of ordering and they were unsure how to move forward. The next section explores this issue of learning to patch together multiple modes of ordering in more detail.