The Right Kind of Feedback: Working through Standardized Tools

This article discusses the implications of working through globally integrated computer systems in transnational firms and addresses in particular employees’ possibility to give feedback on how these systems are working. The aim is to contribute to the literature on the standardization of IT with a focus on co-production by questioning the apparent neutrality of feedback processes. The literature focusing on co-production has shed light on the fact that standardized IT systems are not fixed, but rather flexible in the sense that they are continuously developed based on user feedback. However, based on my empirical case, I argue that employees identified the existence of a frame for acceptable criticism. Two different cases of business critical IT systems are presented; these cases share a common consensus among managers and employees that the systems required improvements. However, employees had experiences of providing business critical feedback on functionality that had not been acted upon. Consequently, when evaluating their possibility to provide feedback, this was not just interpreted in the sense of functionality of the system, but also the perceived prestige of the stakeholders of the systems, which in turn had implications for both the relationship between the central organization and employees and the functionality of the systems.


Introduction
When designing standardized IT systems intended to be implemented in transnational companies, it is important that this standardized frame functions across different cultural, temporal, and geographical contexts.In order to do so, a number of context-specific details not universally applicable have to be sacrificed.This means that standardization goes far in removing the particularities of a specific context, since standards have to "manage the tension among transforming work practices while simultaneously being grounded in those practices" (Timmermans and Berg 1997: 297-98).Consequently, the designers have to seek a balance in the system between being abstract enough to be transferrable, yet still include sufficiently detailed content to be workable.
From an anthropological standpoint, this tension between abstraction and specification points to an inherent paradox within standardization.Standardization represents a type of knowledge that in its abstract nature "strips away" context while the interaction that standardized products are meant to facilitate simultaneously demands context.The paradox is illustrated by Almklov (2006), who shows how creating objects like standardized prospects was important to make the work of the engineers he studies "talkable" by enabling communication by making different aspects of their task comparable.Yet he argues that it was through experience and practical work that one would gain the knowledge necessary to create and interpret such objects.A major challenge is to communicate this type of knowledge based on practical day-to-day experience back into the models.Different strategies are developed to facilitate the understanding of the relationship between the codified and the codifications, especially what information was emphasized as well as sacrificed to be able to codify and make models (Almklov & Hepsø 2011).Ambivalence arises from the realization that such standardized knowledge is required, yet it will always have a conflicted relationship with the type of situated, contextual knowledge that is just as important.
To achieve the best possible balance between generalizablity that allows transferability across contexts and a level of detail that enables local employees to use the system within their specific context, the company is dependent on feedback from the users.However, change is complicated by the fast-paced economic climate that also makes it difficult to keep the systems up to date.Moreover, as Busch (2011) comments, interoperability further complicates the picture as alterations in one setting can have unintended ramifications for others, resulting in path dependence in terms of the standards used.
This article addresses the dilemmas emerging here through an empirical case from Supply Inc., a Norwegian transnational maritime company providing the merchant fleet with products and services. 1The article specifically focuses on two cases describing employees' experience of working with globally integrating IT systems and their perceptions of the employees' abi lity to provide feedback.It is argued that the employees thought there was a frame of acceptable criticism, which had implications for both the relationship between the central organization and employees and the functionality of the systems.Most importantly, it led them to stop reporting bugs, which caused a vicious circle of continuing problems.
As we will see, the literature recognizing the standardization of IT as a process has a tendency to emphasize the co-construction at the expense of focusing on the embedded power relations.Although the point about co-construction is essential, my empirical case shows that the systems' potential for improvement was heavily affected by how the employees perceived their room for feedback.I argue that one has to look at this issue of co-construction in light of a wider debate of standardization and power relations.Scott (1998) illustrates how standardization of practice is also about power, considering that it is a matter of who has the authority to define such standards.A key point in terms of standardized IT systems is that both designers and users of IT software are dependent on each others' actions.Users are dependent on designers to recognize and agree with their assessment of the situation as changes to the formal procedure are ultimately made only if the standardizers see them as necessary.The shoe can also be on the other foot in the sense that the functionality of the system depends on the actions of the user (Latour 1991).If the systems are not used as intended and the users do not enter the information, the systems might end up as empty shells.
In light of the interdependent relationship among the designers, users, and systems, it is important to take a closer empirical look at what type of struggles and negotiations take place when workers try to adapt to the standards central management presents them with.To substantiate the proposed argument, the article starts by situating the topic of discussion within the wider topic of standardization of technology and the importance of a focus on IT in the study of organizations.First, a brief introduction to the company that serves as the empirical case for this article will be beneficial in understanding why this is of interest.

Supply Inc.
Supply Inc. is a significant player in the maritime business and operates in more than 120 countries around the world, either through an established office or through a hired agent operating on their behalf.Supply Inc. is involved in several business areas in the maritime business.Common to their involvement in all of them is that their marketing toward the customer emphasizes the advantages of their globally distributed network.Supply Inc. argues that it offers globally integrated solutions that competing companies operating only locally cannot match.
Supply Inc. delivers services and products to vessels traveling around the world and has a market-driven organizational structure (Dicken 2007).Their customers are moving targets, as it is hard to predict where and when they will need the services of the company.As such, it is crucial to be represented in many ports to cover their customers' needs.In the end, the company's organizational structure is a result of what locations are important to their customers.The coordination of delivery also requires a great deal of day-to-day cooperation among Supply Inc. employees worldwide.Workers' interactions to coordinate the deliveries are chiefly done through the computer.
This article focuses in particular on the employees' perception of the possibility to provide feedback on how these systems are working.The empirical data are based on 10 months of fieldwork in 2008 and 2009, divided between three of the company's branch offices: Norway, the US (Texas), and Argentina. 2

Why Focus on Technology in the Analysis of Transnational Interactions?
Opinions about the role technology plays in an organization are highly variable, ranging from those who see it as an unproblematic transfer of ready-made packages to those who have empirically demonstrated the contextual situatednesss of technology use (Ellingsen et al. 2007;Hepsø 2009;Orlikowski 2010).Moreover, its role is often not explicitly addressed and consequently black boxed, as Orlikowski and Scott (2008) found when they reviewed four leading journals on management research, in which 95% of the articles published in the last decade had no such reflection.Considering the emphasis put on technology as a facilitator for the international division of labor and the investments companies make in such tools, this finding is puzzling (Orlikowski & Scott 2008).Harvey (1989) emphasizes how improvement in communication technology has enabled companies to spread activities across borders of time and space while simultaneously retaining some integration.The internet has provided a new global space for action and production (Boas & Kämpf 2007).
A focus on IT systems is moreover important because they play a role in forming employees' perceptions of the wider organization.In transnational companies, interactions among employees take place largely through information technology; many of the involved actors do most of their work situated in front of a computer.They are thus doing "screen work."The screen provides a platform for activities, which according to Knorr Cetina andBrugger (2001, 2002) makes it not only representative but also constitutive of reality.The authors comment that in many cases the screen is acknowledged to increase the reach, scope, and speed of communication, but adds that in their case the screen was not just an entrance port, but also served as an additional platform in the organization for the interface among participants that integrated and reconstructed the organization.
For transnational companies, globally integrated IT systems are essential because they provide a communication platform that enables employees in one location to enter data that their coworkers elsewhere can act upon.As a result, companies invest a significant amount of time and money in developing and implement-ing such systems.However, the information has to be recognizable to all involved parties for communication to take place.This is ensured by defining a narrow frame of what is allowed to be entered into the system, where actions are controlled through the code embedded in the systems (Aneesh 2009).IT systems consequently control work processes by providing a certain set up for processing information that involves standardization -a phenomenon academic debates identify as an important enabler or forerunner of globalization processes (cf.Eriksen 2008).Bowker andStar (1999/2000), emphasize how creating standards concerns the facilitation of production of objects by defining rules, or a recipe, which further enables standards to transgress a certain context (ibid.: 13-14).As Larsen (2010) has emphasized, standardization concerns the production of equivalents.It is important to stress that, in the current article, the discussion of standards relates to transnational companies and IT.To talk of standards in general is problematic because Busch (2011), among others, has demonstrated that the term is used to describe so many different phenomena.Furthermore, it seems that the definition of standard depends on the subject up for discussion.Establishing standards is vital for companies as it allows them to measure performance, transfer activity from one context to the other, and ensure that work tasks will be done in a similar way regardless of who is performing them.Moreover, I agree with Monteiro and Rolland (2012) that the aim for companies is not to transfer exactly the same uniform solution to their distributed organization, but rather solutions that facilitate integration by being similar enough to allow interaction.

Global Solutions and Local Adjustments
The focus in this article is on employees' ability to change the standardized IT systems by providing feedback on how they work.Consequently, it is also a discussion about to what extent standards in IT can be seen as fixed end products.I have emphasized the difficult balance between generalizablity and details in the process of developing standards.Timmermans and Berg (1997) use the term "local universalities" to capture this tension, saying that universality "…always rests on real-time work, and emerges from localized processes of negotiation and preexisting institutional, infrastructural and material relations […] no longer implying a rupture with the 'local', but transforming and emerging in and through it" (ibid.: 275).
Thus, universality is never universal in terms of the same solution everywhere.For Timmermans and Berg, standardization is a process in which they do not see local adjustments necessarily as a failure of the systems, because some local adjustments are a prerequisite in order for the systems to work.The most important insight here is that one cannot perceive standardized technology as a finished product.It will be altered after it has been launched as it is subjected to the practice of users (ibid.;Rolland & Monteiro 2002;Pollock 2005;Ellingsen et al. 2007;Pollock et al. 2007;Monteiro & Rolland 2012).Though, there is large difference between the various users influence in the feedback process, which also affects whether or not their feedback will be acted upon.A study of the design of two computer systems meant to work for multiple organizations clearly indicated that the designers were much more open to the feedback from early users of the systems than that of latecomers, when the usage had become more complex (Pollock et al. 2007).Rolland and Monteiro (2002) argue that one has to look at the cost and benefits for the involved parties to achieve a workable balance between universality and the necessary local sensitivity.In their own empirical case, they demonstrate that for employees such costs take the form of having to find creative ways to work around the system to be able to do their job.However, overly extensive workarounds are perceived as threats to management because they undermine central coordination and control.As these authors see it, steps will be taken to adjust the technology to the situation when the cost is seen as too great (in respect to loss of control).This is how the authors see a co-production taking place.Yet Monteiro and Rolland (2012) also show that changes are always tricky because changes in one place may trigger unintended effects in other locations.They describe how modifications in the system are triggered by a need to adjust to local demands from one context, but that this adjustment often produces side effects for another that demands further alternations.In their case study, it led the company to adopt a conservative attitude to upgrades, which had to be coordinated and synchronized from central IT and consequently hurt the local sites' ability to adjust to the demands from their setting.
These articles are primarily concerned with contributing to an understanding of how software packages actually do work across borders, and more specifically the co-production of standardized technology.Workarounds are then understood as an indispensable part of making standards work.Yet, the studies also shed light on the difficult balance by saying that systems will change as these workarounds become too extensive, thereby threatening the employees' ability to do their job or managements' control over work processes.The insight on co-production is essential, but in my opinion one would learn much about how this co-production unfolds by addressing the embedded power relations more seriously, and to pose the question of how neutral such feedback processes are.The co-construction depends on users' ability to provide feedback and convince system developers of its value.Although workarounds are an important part of the functioning of standardized systems, one can easily imagine that not all obstacles that occur are as easy to work around.In such cases, the users need the designers to recognize and agree with their assessment of the situation.As argued in the introduction, changes depend on whether the standardizers see the point in doing alterations.It requires that both parties have the same perception of reality in these matters; such negotiations about the prevailing definition of the situation put issues of hierarchy, status, and other organizational contextual factors on the agenda (Goffman 1959).
Therefore, it is important to take a closer empirical look at what types of struggles and negotiations take place when workers try to adapt to the standards that central management present to them.

Working with Globally Integrated Systems
As previously mentioned, this article focuses mainly on two central computer systems where employees and managers alike agreed that the systems were not working optimally.The two cases will be presented separately, as the key to understanding their significance lies in the wider contextual setting of use.

Feedback Trade-offs
The global character of computer systems used in transnational companies means that not all relevant feedback will necessarily be acted upon.Developing and changing computer systems is expensive, and there will always be a trade-off concerning where one should invest resources to make alterations; the changes have to be relevant for a large part of the organization as well as crucial to their operation.If not, it is probably more economically sound from the company's perspective to let local employees work around the hiccups.
To avoid reducing the discussion to such trade-offs, I have chosen to focus on two specific IT systems where consensus emerged within the company among employees and managers alike that these systems were not working optimally.Furthermore, the systems' functionality at the global level was the focus of concern.Both systems were the main supporting platform for their area of business, which meant that the systems had high priority within the company as errors could have serious implications for the company's business.This central role was fairly new for both systems, although in different ways. 3In short, considering that central management in both cases openly acknowledged problems with the functionality of the systems, one would assume that user feedback was very welcome.It was also formally requested for most computer programs had feedback channels in them.Before engaging in the discussion of the malfunctioning IT, I have to stress that Supply Inc. employees in general positively emphasized other globally integrated IT systems as one of the company's true strengths.I stress this because it means that employees were not negative toward such systems in general; in addition, it further underscores that the aim here is not to paint a picture of a company with poor communication IT structure.Supply Inc. was rather an example of the opposite.
The consensus on the need to improve the systems makes them especially interesting as a case for understanding the dynamics of the perceived room for feedback.As Appadurai (1996) reminds us, a message will always be contextualized as the receiver will interpret the message presented from his or her position and in light of his or her own contextual space.A shared understanding of problems is therefore an important premise from which to discuss the perceived space for feedback.

Asys
Asys was the supporting platform for the agency side of the business, which was a service offered whereby customers could hire a representative from Supply Inc. to take care of their business in local ports.As vessels travel to many foreign ports, they hire an agent with local expertise about the demands of that port to arrange all the necessary activities, both big and small, for the vessel.The agent works as a sort of a personal coordinator for the vessel.In one way, this type of business is locally oriented: the customers buy local expertise and their evaluation of the service Supply Inc provides depends very much on the actions of the company representative.
Although Asys in itself was not new, its role had expanded with changed ambitions for the business area it was meant to support.The change is an important backdrop for the coming discussion.In the past, there had not been much cooperation between the geographically dispersed parts of Supply Inc. when it came to agency services.At the time, Supply Inc. was in the process of redefining the business area, emphasizing the potential implied in thinking of themselves as a global network for both themselves and the customer.In a survey conducted by Supply Inc., the customers had according to central management asked for more uniformity in, among other things, reporting.The customers had expressed frustration because they found themselves wasting time looking for information since reporting depended on location.Thus, they wanted more consistency.They also wanted Supply Inc. to make better use of their systems to provide, for example, evaluations about the customers' own operations in which they were involved, including efficiency measurements.
In central management's effort to refocus this business area to be globally oriented, Asys' role shifted to become the "glue" which was meant to help organize this business globally by coordinating the activities worldwide.Thus, naturally the ambitions were high in terms of the role the program should play.Asys was no longer just a reporting mechanism from local ports to headquarters, but was also to be used as a platform for the geographically dispersed parts of the company to exchange information.Some of the information found there was also available for the customers.Thus, Asys was intended to be an important tool both internally and externally, which meant that it was vital for the information it contained to be up-to-date and correct.The program was up and running, but had several shortcomings, which both employees and managers realized.In fact, during my time at the headquarters as well as in Texas, this program and how it was working were recurrent topics of discussion among both employees and managers.
At the headquarters the concern was primarily Asys functionality as a management tool and as a tool for the customers.Management for example wanted to compare targeted activity vs. actual port calls.Such evaluation became tricky because not all employees entered the necessary information, and then the numbers management was meant to compare were not updated.In a department meeting at the headquarters the central agency team discussed the relationship between operations, sales, and systems.They were concerned that despite guidelines for how to use the implemented systems operations did not make full use of them.They mentioned the various ways agents provided disbursement accounts to customers as an example.The Agents were meant to use Asys, but according to the central team the customer, depending on location, sometimes got the information through Asys, sometimes on an Excel sheet and sometimes just copied into an e-mail.Two consequences were that the customers complained they were not receiving the global solutions they had been promised, which again made the sales force reluctant to advertise the agency offer as globally coordinated.
The central management team at the headquarters in Norway was very concerned with how to get the employees to use the program as they intended, and Asys was often on the agenda in their department meetings.In addition, steps were taken to improve the use of the program, such as arranging training sessions.The discussions concerning Asys at the headquarters indicated that the central team was of the opinion that the users throughout the network did not have enough training on using the system and were therefore not making use of the possibilities the system provided.
As part of the centrally initiated campaign, representatives of the team made a series of visits to the organizational network to promote their work.Their mission was also to discuss the challenges the business area was facing with the organizational network.One of these visits to the network took place in Texas, where the central team invited the agents to join in on the discussion of the state of the business area.Gathering many of the agents at once said something about the importance of the meeting as these agents were normally out servicing vessels -a more or less 24/7 type of job.Indeed, the agents communicated that they were always working under time pressure.The group of about 7 agents at this office in Texas could in total receive up to 500 e-mails a day, which came at all hours and came in addition to phone calls and actual ship visits.During the meeting, the participants talked mostly about the potential opportunities for the business area, where they were going, as well as the overall challenges concerning a recent change to the company's name.
During the meeting, the discussion concerning the computer program that worked as their base was meagre, although the central manager did comment that it played an important role.The agents mentioned in passing that they had some difficulties with Asys and that they had sent this information to central services, but nothing had been done.However, the role of the computer program and its problems were not discussed in any detail at the meeting.When they did start a discussion of the problems in Asys, it quickly derailed into how the company needed to train employees to use the system.I was somewhat surprised that the discussions of Asys were so meagre because, by that point, I had spent some time in different arenas in the company and the problems with Asys were a topic that kept resurfacing among employees worldwide. 4 I was later able to spend some time with some of the agents in Texas to learn more about their activities.Their work varied greatly depending of what vessel they were servicing, and most of their work took place communicating by telephone or e-mail.The agents worked in teams, in which one vessel manager handled everything that had to do with Asys.When a vessel was coming to port he registered the vessel and the estimated cost for the services it wanted done in Asys.This generated an e-mail that he forwarded to the vessel with pre-arrival information, including information about the port the vessel was arriving at.In the agents' work, it was clear that they continually experienced various problems with Asys.Many of the problems had to do with formatting.Like when the agent was to send the information he had entered into Asys to the customer something happened with the format of the text.As the information was exported from Asys to an e-mail, the text, that looked neatly organized in Asys, appeared as a chaotic mess.The agent then had to spend time organizing the text in the e-mail so it was readable for the customer.It was not all that time-consuming, but in their hectic workday, it was a source of irritation that -together with other such small issues they had to work around -became a time-consuming activity.One of the agents, Ben, said Asys had its pro's and con's.He found Asys to be fine from a financial point of view, but operationally it worked poorly.He also admitted that the work with Asys became to some extent "noise" since they had to attend to so many emails and telephone calls.
It should be mentioned that such practical issues were not only addressed in Texas.For example, at a training session on Asys at the headquarters, the agents attending this course also raised a number of similar practical issues.It concerned among other things how various customer wanted different type of information included in their reports.Also, customers using Supply Inc for multiple port calls wanted one joint disbursement account for all port calls, which was difficult to handle in Asys at the moment.They also mentioned things like small buttons, and problems with "time outs" in Asys that interrupted their work.Another obstacle was that there was no link in Asys to Outlook, so when they had multiple recipients they had to work around the system or send the e-mail from Asys to their own Outlook account and then forward it.It was said that a system that originally had started out as a tool for operations, had developed into something primarily to meet the needs of the customer; and one of the agents commented that it was problematic because "Asys is meant to work for us, it is not we that are meant to work for Asys".
In Texas, sitting alongside the agents working with Asys, I eventually commented on the ongoing problems to one of them, and his response demonstrated that he was really frustrated with the system as well as the possibilities to get assistance on these problems.He mentioned that several of the agents had sent feedback to central services about different issues, but nothing had been done.I asked why he had not made a bigger issue out of these problems at the meeting a couple of months earlier and if that would not have been the perfect opportunity to get those with influence to put pressure on central services to fix the issue.He responded, "Yes, but they don't want to hear that, so I tell them what they want to hear." His answer was telling as to how he perceived the meetings and the place for feedback.The purpose of the meeting was for the agents to provide their input, but the agents seemed to think there was a frame for acceptable criticism.Considering the strong focus on redefining the business area, as well as the computer systems' role in this area, it was somewhat puzzling that feedback from the users seemed to fall on deaf -or at least selective -ears when the problems addressed concerned the overall functionality of the system.As the discussion of problems in the meeting illustrates, the response seemed to be that the users were not using the system correctly and needed training.This was most certainly true in some cases, and an important dimension of the issues the company faced concerning the program.However, moving toward a general discussion of the need for training took focus away from addressing the concrete issues concerning functionality.As the example with the e-mail illustrates, agents were using valuable time correcting things that seemingly could be easily fixed.Considering the widespread discussion among company employees worldwide about the malfunctions of the program, it is evident that the problems were not only minor touch-ups, but also concerned larger issues.

Hsys
The other system in question was the supporting platform for HR, which I have called Hsys.Similarly to Asys, the role intended for this program was significant, as illustrated in the relevant HR governance policy, which stated that "Hsys is the only HRM system that should be used for employee information."Another factor that played into its importance was how the program fed information into other company computer systems.This meant that the reliability of these other IT systems depended on whether or not the data coming from Hsys were accurate.Among the computer programs that got data from this one were two self-service programs for managers and employees.Illustrative of the interdependence between the systems, in the managers' self-service program, a manager had access to employee information on the basis of who Hsys said belonged to his or her unit.If this information was incorrect, the manager would not have access to employees' information as they would not be listed as subordinates.
Similar to the case with Asys, the central HR department also recognized that the Hsys system was not working optimally at the time.One example was the registered number of employees in the system as approximately 1,500 employees were missing compared to the financial system.The central HR group had a meeting, during which they discussed this discrepancy between the systems and different scenarios that could explain it.Among the explanations (partly it was a question of who should be counted) they found that not all divisions had been entered, so they realized they had to talk to each and every business area so they could look at the numbers in more detail.During these discussions, it became clear that HR's concern with the inaccuracy related to their ability to retrieve the information they needed from the system.Other types of problems with the system also surfaced, such as how one should relate to reporting, registration, counting, etc., and who should enter what into the system.
In light of the central discussions, one could assume that feedback from the users was necessary and welcome in order to improve the system's functionality.The headquarters were concerned with feedback from users, as it was a topic of discussion in their strategy seminars.However, the participants were also discussing what type of feedback they wanted.It was explicitly stated that, yes, they did want feedback, but feedback that related to the set scope of what the system was meant to do (indicating that not all the feedback received was of that nature).The question then was whether there was an active request for feedback.First, the system, like most other systems, had the possibility to provide feedback as a function.Second, feedback was also mentioned in the training material on Hsys targeting new users.However, this was in the format of a PowerPoint presentation consisting of 37 slides, and the topic of user feedback was mentioned once, as one out of four bullet points on page 23.In other words, it was not really highlighted.
One of the most interesting episodes involving employee feedback took place during a training session on Hsys in Texas.The two-day training session had only two participants: Julia and Anna.Julia was a regional HR manager who was training Anna; Anna was an employee about to take on HR-related tasks in her office.The training took place in a live training environment using a test version of Hsys that allowed them to practice performing HR-related tasks without changing anything in the real system.Considering that the test version was a mirror of the live version, it should include the same functions as the live version.
Part of Julia's job during the training was to "sell" the system to Anna.She described the system and all the possibilities it provided to its users.Julia stressed the importance of keeping the system up to date by demonstrating some of the ways Hsys fed information to other computer systems and explaining some of the ways headquarters used the system (to do headcounts, audits, etc.).
During the two days of training, the women performed routine HR tasks by using the functions of the systems, mainly maintenance and recruitment. 5Early on, small issues with the functionality of the system started appearing.Some of them had to do with the setup of the system which complicated processes.One example was that if the position was created in the system before a person was registered in the system, this person could not be employed in that position.HR staff had to find ways to work around such problems, and this particular problem was solved by entering a false, much earlier date of employment in the system, so the person preceded the position in Hsys.Also, when a position in the company became available, it had to be recreated in Hsys, because that particular position was "used" if someone was employed in it, and then one could not use it again.
As the problems of varying degree started appearing Anna got frustrated and said that in her opinion it seemed like the program had a lot of errors, was messy, and was not very logical.They were able to ignore or work around most of these issues, but on day two when they moved on to the recruitment part of the system, the women encountered issues that concerned Hsys's overall functionality on a global scale that prevented them from executing their tasks.One example of the problems emerging was interactive buttons that were not working, so they could not enter certain parts of the system.Another issue concerned practicality, as in the recruitment part of the system there was something wrong with the setup so the image did not fit the screen; as a result, they could not read what was written on the far right on the screen.HR staff therefore had to ask applicants for a paper copy as well, which counteracted the intention of turning recruitment into a "paperless" process.Moreover, while applications from internal candidates ideally came directly through the company's Employment Self Service program to Hsys, external applicant did not.So, the HR staff had to have two parallel processes running.
The problems culminated when it turned out that there was a glitch in the programming as there was a link between the real and the test version.At this point Julia started to panic because it meant that the people they had been moving around for two days could potentially have been moved in the real version of Hsys (after all, a manager in Singapore could be a little surprised to find that he was now a driver in some small port in an African country).
Julia -who up until then had kept her game face and had tried to downplay any bugs.-became visibly upset and commented that she was frustrated with the system as a whole and that it did not work properly.She further admitted that there were parts of the system they just did not use in their HR processes because there were so many issues.She said she had given feedback to central services and nothing had been done.When Julia realized there was a link, she corrected what she could of the changes they had done and sent an e-mail to central services to inform them of what had happened.In this e-mail, she also listed some of the problems that had appeared during the two days.What was interesting was that, in typing this e-mail, she was very concerned with the wording and the type of issues she included in the e-mail.She commented that they had to be careful about what type of issue they addressed and how they addressed them.Based on how she discussed the program, she seemed to be under the impression that the headquarters had stakes in this system and recognized an element of prestige attached to it.She seemed to think that the central organization in Supply Inc. had played a role in designing the system or tailoring it to the specific needs of their company.Her previous experience with giving feedback as well as her opinion of the headquarters' stakes in the program seemed to lead her to the conclusion that critical feedback was not necessarily welcome.
It is interesting that, in the case of both of these systems, there seemed to be a general consensus throughout Supply Inc. that the programs were not working optimally.Even so, there seemed to be a tone of communication where the employees had an understanding of what type of feedback the headquarters really wanted.In both cases, the employees had previously sent e-mails with feedback, yet nothing had happened.In addition, in both cases the issues the employees identified in the programs were of such a nature that they related to important issues in the employees' day-to-day tasks, which one would think would make fixing these frustrating elements a priority.
A question emerging is how the central headquarters thought about the value of feedback.To my knowledge, all computer programs had functions where employees could give feedback directly.Although it would have been highly beneficial to have more knowledge on how incoming issues were handled at the headquarters, the most important element in this discussion is not what actually happened, but the consequences of the users' perceptions of the sequence of events. 6Despite the seemingly open channel for feedback, the employees' experiences told them otherwise.How can this be?In order to understand this, it is useful to look at another arena where employees were facing difficulties using the system provided.

It's not Me, it's You…
One illustrative example was an episode with some portable computers the workers at the warehouse in Texas brought with them aboard vessels.These were meant to make their job easier and more efficient as they could access and enter data while they were working, instead of waiting until they got back to the office.However, a manager fairly high in the hierarchy in Texas told me that the employees using them reported that they experienced several problems.One of the issues was that the computers were incredibly slow at downloading the data -so slow employees could be stuck at a vessel for a long time waiting for the computer to get ready.Thus, from the employees' (and the local manager's) perspective, the computers did not make them more efficient; rather, it was the reverse situation.I asked the manager why they did not tell the headquarters about this.I was told there was no point.Basically, their experience was that feedback backfired and was determined to be a lack of training.He commented sarcastically: They always find a guy in Singapore or something that reports there is no problem, so then we are the ones with the problem.It always comes back as a lack of training in the network and not a problem with the system.This employee therefore seemed to think that coming forward with problems with the tools they were given served nothing but to weaken his own position as he was met with responses referring to a lack of training, which ultimately brought the issue back on him.This attitude seemed to be widespread among the employees.
In respect to how central management argued that some countries reported no problems, it might be valuable to take into consideration different cultural traditions and how this affects codes of communication.Eckhart (2004) comments that scholars doing business research in China have to be aware of how elements in Chinese society have implications for how the Chinese view hierarchy and, consequently, their reluctance to say something that will reflect negatively on their managers, even in situations where the answers are anonymous.She says Chinese answering questions will be preoccupied with how someone in their place in the hierarchy is expected to answer.Although one should not stereotype groups into one specific response, it is a useful reminder that different cultural codes of communication can translate into different ways of responding.In fact, the reluctance from Asian employees to say no was a topic up for discussion on several occasions in the marketing department at the headquarters.If the company is aware of such differences, it becomes even clearer how the response from headquarters is a way of not really taking into consideration the employees' comments.
After the end of my fieldwork, I went back to the headquarters for a visit, where I made a short presentation on some of the issues I had found interesting during my time in their organization.Here I discussed the topic addressed by the American manager and included examples of situations where it was evident that there were real issues with the system.I then continued to explain that the employees felt their concerns and feedback were turned back on them instead of the company hearing their arguments.At that point, one of the vice presidents raised his hand and asked me if I had the impression that employees who had been told that they lacked training had taken a step back to evaluate if they really had done the necessary training.His question further emphasized the attitude the employees had expressed as he immediately turned the question back onto the employees. 7 Even if in many cases it did come back to training, the examples in this article demonstrate that this was not always the case.His response therefore became illustrative of what the employees were expressing.

Contingent Interactional Spaces?
At first, it seems quite puzzling that feedback is not acted upon when employees and managers alike apparently agree that the programs are not working as intended and that it is necessary to make improvements to optimize the functionality.To understand why the employees found a frame of acceptable criticism, it is necessary to take a closer look at the power relations at play in this relationship.
To understand the power relationship, one cannot just discuss employees versus central management.The examples presented herein demonstrate how the technology is working as what Latour (1991) would call a non-human actant as the technology is in part producing the work context in which the employees are operating.The computer systems and the technological infrastructure in general are part of the "missing masses" in the organization (Latour 1992).As Aneesh (2009) pointed out, the algorithmic code in these systems structures work processes by limiting the choices of how to implement data, consequently limiting employees' options of how to perform their tasks.It does not just control work; part of the work is also delegated to these systems.The information stored there keeps track of stock, remembers previous encounters, and allows employees other than the one initially implementing the data to act on the information.Much of the organizational activity is dependent on the correctness of the various IT systems.This means that power is not just in the hands of management.As Latour (1991) says, the fate of technology is in the hands of the user.
It is useful to take a relational approach to the issue of power.Foucault is influential here as he shifted the focus perspective on power from focusing on who has it to how it works: "those practices, techniques and procedures that give it effect" (Townley 1993: 520). Foucault's (1975/1994) discussion of discipline is a reminder of the "hands off" strategy for control that lies in IT structures.In addition to the concrete ways of controlling how work tasks are performed, the potential for surveillance also functions as a self-disciplining element to workers' actions.
Most important to this discussion is the fact that these systems are a manifestation of the headquarters' strategic investment in a particular work tool.Bowker andStar (1999/2000) comment that "…in many ways software is frozen organizational and policy discourse" (ibid.: 135).Their quote is a useful reminder that implied in these systems are decisions on how work should be done, who should perform what and so forth.As was clear in the employees' discussion about the programs, the enormous investment in terms of time as well as money that comes with introducing IT systems was not lost on them.The non-working computer systems seemed to put issues of hierarchy and status on the agenda, emphasizing the differences between the strategic and the operational world of the company.I earlier stated that an important premise for the empirical cases presented in this article was that employees and managers shared an understanding that problems existed.The empirical examples modify this statement.While it is true that employees and managers agreed that there were problems, they did not have the same outlook on what these problems were.They discussed them at different "levels" and thus were looking to get different things out of the systems.In the case of Asys, the headquarters' focus was global, the most pressing issue was getting people to enter in the necessary data so they could act on it globally; for example to use it as a base for statistics.For the agents, however, although they too saw the advantage of the data Asys provided, their concern was how these data could be used in a time-efficient way in their communications with customers.While the agents recognized the value of the systems from a financial perspective, they found shortcomings in respect to operations that in some way turned the system into "noise" rather than a tool in their work.The same was true of Hsys, where the central HR group's main concern was that the employees kept the information in the system updated, so they could use it to extract data about the organization.However, locally HR had to make this system work in a way that made their HR work processes more efficient.Many of the workarounds the local HR staff had to do did not mean the system lacked information, but that their processes had more steps than necessary.It was clear that this difference between management and employees focus of what the system was for was apparent to the employees.
Employees were not indifferent to whether the various problems they encountered in their day-to-day tasks were fixed or not.Time and time again, employees in Texas and Argentina were eager to tell me about their issues, and on many occasions they stated explicitly that they hoped I would communicate this information back to headquarters.There are many ways to interpret this, all of which are probably part of the full explanation.One factor has to do with media like email or embedded feedback channels, which do not allow the employees to see how the receiver interprets the message, thereby robbing them of the possibility to adjust/correct the receiver's impression.It brings to mind Appadurai's (1996) notion of "mediascapes," where a central point is that such media messages will always be fractional and mixed.This implies that, as the information presented can never tell the whole story, people are therefore left to interpret the information being received.When telling me about their problems, employees could ensure that I had the contextual knowledge of the local situation that was needed to understand why the problem existed.I became what anthropologists in the 1970s termed a "go-between" working as a "messenger between the parties" (Larsen 2010: 255).Another element is that communicating feedback through e-mail or embedded feedback channel meant that the person making the comment was associated with the problem.As the American manager discussed herein illustrated, this was not necessarily good for anything else than hurting one's own position in the company.If employees were met with comments about the need for more training, there was an implicit message that the employee had not done enough himself to solve the problem.One could imagine that possibilities to provide anonymous feedback would have changed the situation slightly, although it would still not remove the obstacle concerning the lack of contextual knowledge.
To understand the feedback channels from the employees' perspective, it is interesting to turn the focus back to the discussion of standards and the power to define them.Scott (1998) argues that issues of discipline and power are closely linked to the issue of standards; thus, when looking at the dynamic interaction between a standardized system and actual practice, it is important to keep these factors in mind.Presenting alternatives requires an influential voice, and it seems like the employees were under the impression that they did not have such a position.As Bowker and Star's comment concerning software as frozen discourse point to, the systems represent corporate decision about how work processes should be done, and consequently what information was needed.Even if most employees discussed herein have some sort of managerial position in the regions (apart from the agents), they were still part of an organizational hierarchy.In all the situations mentioned above it is clear that the regional staff were aware of the discussions at the headquarters concerning the programs in question.The employees referred to the money invested in the system, linking it to prestige for the involved party.The employees' interpretation of this therefore seems to be that there is less room for actual critical feedback.
It is evident that feedback is not just feedback; there is a difference in the implications of what is communicated.For a global system, it is one thing to give feedback on dead links, yet comments suggesting that the programs are illogical, messy, or not serving their purpose are clearly much more potent statements that in effect criticize the strategic investment the central organization has made, as well and central management's definition of how work processes should be done.It is evident in the examples here that the employees were acutely aware of this difference.The central organization made a strategic decision to invest in this program and had defined the role it was going to have.As a result, from the employees' perspective, the feedback had to be formulated in such a way that it worked within what they saw as the frame for acceptable criticism.
I have already stated that the main object of this discussion is the employees' perceptions of the room for feedback and that the question why central management did not react as employees might have expected is less important.Nevertheless, I will in conclusion briefly reflect on the apparent paradox that, even if both parties agreed that changes were needed, the employees' experience was that nothing was done.This is worth spending a moment on because the employees did raise a number of issues that were of a more practical nature and related to their ability to complete their tasks efficiently.Why then does the central organization answer employee business critical feedback by turning the problems back on them by referring to training?It seems that employee feedback to some extent became noise rather than valuable input.First, it is important to remember the operational versus strategic outlook on the abilities of the system, which meant that central management and local employees wanted different things from the system.The understanding of the situation is therefore different depending on organizational position.As they are looking to get different things out of the system, it is possible that this affects the pressure centrally put on IT support (who, I imagine, gets swamped by different requests of varying technical competent nature) to prioritize to fix this at the expense of other issues.
In is likely that, in a hectic work environment, it is easier to turn the finger back on the employee than to do something about it.Fuller (2002) argues how knowledge managers' understanding of knowledge emerges from being situated in an "information explosion," characterized by an overwhelming landscape of information they need to navigate. 8This is part of the reason why Fuller argues that knowledge management has an instrumental approach to knowledge.One is not interested in all types of feedback, but only the kind that is crucial for business, from their perspective of the organization, that has to be addressed.Considering the tardy process of making changes in IT systems, this instrumentality can be a useful lens for interpreting this topic.Making changes is a slow, costly, and often complicated process that helps explain why feedback (even in regard to essential elements) can be seen as noise by the stakeholders, who are defending a costly investment in a computer program.When a program is implemented, one needs to stick with it.Yet the implementers were not expecting this to be problem free.There was a consensus concerning the troublesome processes of implementing the systems.Supply Inc. had already had one experience where a program that was now seen as a success story almost put them out of business when they were implementing it.In fact, this program was now seen as a major reason for the company's competitive edge.It is clear that no one set out to make sure that the systems would not work.It is probably for the most part a matter of an overwhelming load of information combined with time pressures.
Yet the fact remains that from the company's standpoint there seems to be an essential paradox here in that the company was absolutely dependent on feedback from the network in order to better their systems.The examples here demonstrate that the dynamics of interaction led to a vicious circle in that the employees were afraid to communicate their experiences, leaving headquarters with the same issues of how to get the system to work.

Conclusion
This article has argued that, to understand standardization processes in respect to IT systems, one has to empirically situate the discussion in the everyday experiences of those using the systems.Although the literature on the co-production of standard sheds interesting light on how employees through feedback play a part in changing these standardized structures over time, it is only by seriously address-ing the organizational power relations that evolve in this co-production that one learns the degree of influence the users actually have.
In my case, it is clear that employees found there to be a frame of acceptable criticism.They did not evaluate whether or not to communicate a certain problem only in light of its impact of the systems' functionality, but also in light of how they thought this feedback would be received by central management who had invested in these systems.
Malfunctions in the system create costly processes as people work around glitches, do not trust them, and do not necessarily communicate local experiences.In particular, the latter poses serious challenges to co-production of standardized solutions.The tension between the level of generalizablity that allows the IT software to transgress borders and the level of specific content that is sufficient enough to fulfill the task it is meant to do partly explain the issue at hand, but also apparently create more problems.When people do not communicate their experiences, the systems are not able to improve this balance.
The problems with the IT systems also play a role in forming employees' opinions about their own positions in the company.In their evaluation of their ability to get through with their comments, it is clear that they interpreted their options in light of their status and hierarchical position within Supply Inc.
Marte Fanneløb Giskeødegård is a PhD Candidate at the Norwegian University of Science and Technology.The article is based on empirical data from her PhD study in social anthropology, funded by the NTNU globalization programme.The wider PhD project is concerned with interaction within transnational companies and the efforts towards creating a transnational community.E-mail: Marte.giskeodegard@svt.ntnu.no.

Notes 1
The company, as well as the computer systems described here, has been given fictitious names to hide the identity of the company. 2 This fieldwork took the form of participant observation, where five months were spent at the headquarters in Norway, three months in Texas, and the remaining time in Argentina.3 The HR system was a fairly new program, while the other system had a "new" role, seeing as the company put much more emphasis on the global organization, which meant the role of the system became more important and also expanded.This topic of feedback emerged after my fieldwork in Norway, which was an important reason for the lack of focus on central services there.
7 It has to be added here that the body language of some of the other participants at the meeting seemed to say that they realized that the question underlined what I was saying.As opposed to the economist that has an understanding anchored in the industrial revolution, where new knowledge led to progress.New knowledge then becomes a value in itself, while for the knowledge managers knowledge is only useful if it can be put into action to better their activities and competitive position.Knowledge for the sake of knowledge might be a potential threat in the knowledge managers' eyes (Fuller 2002). 6 8