Working alongside Robotic Process Automation and emergence of technostress

Kimmo Haapanen WORKING ALONGSIDE ROBOTIC PROCESS AUTOMATION AND EMERGENCE OF TECHNOSTRESS UNIVERSITY OF JYVÄSKYLÄ FACULTY OF INFORMATION TECHNOLOGY 2024 ABSTRACT Haapanen, Kimmo Working alongside Robotic Process Automation and emergence of technostress Jyväskylä: University of Jyväskylä, 2024, 71 pp. Information Systems Science, Master’s Thesis Supervisor: Salo, Markus Two phenomena are increasingly common: the increased use of technology in working life and the increase in sickness absences due to mental health problems and stress in the working age population. While the two could be linked only coincidentally, technostress is an existing burden for many people who are in contact with technology in an occupational context. The ways of working and the continuity of work roles are under constant pressure of change. One force for change is the increased use of automation at organizations. One such area of automation is the use of Robotic Process Automation (RPA). RPA is set to promise an increase in efficiency and reduction in repetitive tasks at work. With RPA the desired effect is on the positive side, but at the same time knowledge about the negative side is light or non-existent in the academic literature. Technostress has many effects on workers in organizations which may lead to symptoms like emotional outbursts, negative moods and conflicts. This study aims to increase understanding of the human interaction with RPA as a technology, experiences of technostress and occupational stress at the workplace and how they interact with each other. The technology of RPA and the interaction between technostress and occupational stress are both understudied as of now. The data was gathered through qualitative interviews of 22 experts working alongside RPA either as end users or as technical stakeholders responsible for upkeep of the technology from multiple organizations and roles. The results suggest that technostress exists in the field of RPA as well, but it also interacts with occupational stress through workflow disruptions and performance hindrances, which increases the overall stress load of an individual. The use of technology also makes teams more susceptible to experience of stress through rustification of skills needed to conduct the automated tasks in cases of RPA malfunction, and also by making working days more intense. The RPA also causes different kinds of stress experience in different stages of the RPA lifecycle. Lastly RPA causes different kinds of stress experience depending on your viewpoint as an end user or as a technical person. These results provide novel understanding on how RPA causes a mix of technostress and occupational stress and how the maturity of the RPA and the viewpoint of the individual modify the stress experience. Keywords: technostress, occupational stress, Robotic Process Automation, organizational mitigation TIIVISTELMÄ Haapanen, Kimmo Työskentely ohjelmistorobottien rinnalla ja teknostressin muodostuminen Jyväskylä: Jyväskylän yliopisto, 2024, 71 s. Tietojärjestelmätiede, pro gradu -tutkielma Ohjaaja: Salo, Markus Kaksi ilmiötä yleistyvät samanaikaisesti: teknologian esiintyvyys työelämässä sekä mielenterveyshäiriöperusteiset poissaolot työikäisillä ihmisillä. Vaikka näiden kahden välinen yhteys voi olla sattumanvarainen, on teknostressi olemassa oleva kuormitustekijä monelle ihmiselle, jotka joutuvat tekemisiin teknologian kanssa työelämässä. Samanaikaisesti työnteon tavat ja työroolien jatkuvuus ovat muutoksessa. Yksi automaation muoto on ohjelmistorobotiikka (RPA). RPA:n hyödyntämisen uskotaan johtavan muun muassa tehokkuuden kasvuun ja toistuvien työtehtävien vähenemiseen, mutta muiden teknologioiden tapaan teknostressin riski on siinäkin olemassa. RPA:n käyttöönottoon liitetään toiveita positiivisista vaikutuksista, mutta samanaikaisesti tieto negatiivisista puolista on vähäistä tai olematonta akateemisessa kirjallisuudessa. Teknostressi vaikuttaa organisaation työntekijöihin monilla tavoilla kokonaiskuormituksen kasvamisen myötä, ja voi johtaa erilaisiin oireisiin, kuten tunteenpurkauksiin, negatiivisiin tunnetiloihin ja konflikteihin. Tämä tutkimus pyrkii lisäämään ymmärrystä ihmisten vuorovaikutuksesta RPA-teknologian kanssa, sen tuottamasta teknostressistä ja työperäisestä stressistä työpaikalla ja mainittujen stressityyppien välisestä vuorovaikutuksesta. RPA, sen aiheuttama stressi ja niiden välinen vuorovaikutus on vain vähän tutkittua. Aineisto kerättiin 22 laadullisen asiantuntijahaastattelun kautta. Kohderyhmänä haastatteluissa olivat loppukäyttäjät ja RPA-ohjelmistokehittäjät 11 eri organisaatiosta. Tulokset osoittavat teknostressin vaikuttavan myös RPA:n parissa työskenteleviin työntekijöihin, mutta samanaikaisesti aiheuttavan myös työperäistä stressiä työntekoa häiritsemällä, jotka vaikuttavat työntekijän kokemaan kokonaiskuormittumiseen. Teknologian käyttö myös altistaa työntekijöitä tuleville stressikokemuksille taitojen ruostumisen kautta, kun ajan saatossa automatisoidun työtehtävän suorittamisen taito hiipuu, jotka kuitenkin tulee suorittaa RPA:n häiriötilanteissa. RPA aiheuttaa myös erilaista stressiä eri RPA:n elämänkaaren vaiheissa. RPA aiheuttaa myös erilaista stressiä roolin mukaan: loppukäyttäjä ja ohjelmistokehittäjä stressaantuvat eri tavoin. Nämä tulokset lisäävät ymmärrystä RPA:n aiheuttamasta teknostressin ja työperäisen stressin sekoituksesta, niiden välisestä vuorovaikutuksesta ja RPA:n kypsyysasteen sekä roolinäkökulman vaikutuksista stressikokemukseen. Asiasanat: teknostressi, työperäinen stressi, ohjelmistorobotiikka, organisaation mitigaatiokeinot FIGURES FIGURE 1 RPA and the conceptualized interaction between types of stress in organizational context………………………………………………………………..19 FIGURE 2 The layered viewpoint of stress in interaction with the RPA…………33 FIGURE 3 The dynamic between RPA, technostress and occupational stress….52 TABLES TABLE 1 Causes of technostress in different phases of the RPA lifecycle by the viewpoint and the RPA characteristics related to them…………………………..43 TABLE OF CONTENTS ABSTRACT TIIVISTELMÄ FIGURES TABLES 1 INTRODUCTION ................................................................................................. 6 2 THEORETICAL BACKGROUND .................................................................... 10 2.1 Stress and occupational stress .................................................................. 10 2.2 Technostress ............................................................................................... 15 2.3 Robotic Process Automation .................................................................... 19 3 RESEARCH METHODS ..................................................................................... 23 3.1 Data collection ............................................................................................ 23 3.2 Data analysis ............................................................................................... 25 3.3 Evaluating the quality and credibility of the study .............................. 27 4 RESULTS .............................................................................................................. 29 4.1 General information about the RPA used by the interviewees .......... 29 4.2 Different viewpoints on the same technology ....................................... 31 4.3 Emergence of technostress and interaction of RPA characteristics, technostress and occupational stress ...................................................... 32 4.3.1 Awareness of the RPA ..................................................................... 33 4.3.2 Technostress and occupational stress before the RPA is implemented ..................................................................................... 34 4.3.3 Technostress and occupational stress during and after the RPA is implemented ................................................................................. 37 4.4 RPA characteristics related to stress responses ..................................... 43 4.5 Organizational mitigation of stress caused by RPA ............................. 46 5 DISCUSSION ....................................................................................................... 51 5.1 Research contributions .............................................................................. 51 5.2 Practical implications ................................................................................ 55 5.3 Limitations and future topics ................................................................... 56 6 CONCLUSIONS .................................................................................................. 58 REFERENCES ................................................................................................................ 60 APPENDIX 1 EXAMPLE INTERVIEW QUESTIONS…………………...………..71 It is almost impossible to be a part of modern working life without interacting with computers. The rise of the Information Technology (IT) solutions in use at different organizations and in individual use has rapidly risen over the decades (Salo, Pirkkalainen, Chua & Koskelainen, 2022; Ragu-Nathan, Tarafdar, RaguNathan & Tu, 2008). The increase in use of IT has created a lot of benefits on the organizational level. These include increase in productivity, effectiveness and efficiency (Bharadwaj, 2000; Melville, Kraemer & Gurbaxani, 2004). Frey and Osborne (2017) predict that in the next two decades 47 percent of jobs will be replaced by automation and the World Economic Forum (2020) predicted that 85 million jobs may be displaced due to labor moving from humans to machines by 2025. The push to increase automation at work by utilization of robotics has spread to the use of IT as well. In 2010 a company named Blue Prism arguably pioneered what is now called Robotic Process Automation (RPA) (Syed et al., 2020). RPA refers to tools that increase productivity through automated scripts which mimic humans doing labor with IT (Barnett, 2015; Gartner, 2023). RPA allows alleviating the workload of humans through shifting the rule-based, well-structured and repetitive work to automation (Syed et al., 2020). Adoption of robotics can have many benefits for a business. Automation in the workplace can lead to new jobs, increased productivity and reduced personnel costs (Yam, Tang, Jackson, Su & Gray, 2023). Increase in use of automation can also increase annual labor productivity growth, total factor productivity and lower output prices (Graetz & Michaels, 2018). RPA is one of the ways to utilize automation in business settings. RPA is used to automate mundane tasks that would be otherwise done by employees (Syed et al., 2020). These benefits seem to be alluring for the organizations as spending on RPA is set to reach 2.9 billion dollars worldwide, which is a 19.5 % increase from 2021 (Gartner, 2022). Automation is set to change work and therefore organizational members must find new ways to collaborate with each other as the old hierarchal structures are predicted to be flattened (Servoz, 2019). However, automation at the workplace have downsides as well. 1 INTRODUCTION 7 Increased usage of robotic assistance at the workplace leads to increase in job insecurity and in turn increase in job insecurity can contribute to burnout and workplace incivility as well (Yam et al., 2023). Workplace incivility in turn can lead to decrease in wellbeing and threatens physical and psychological health (Kivimäki, Vartia-Väänänen, Elovainio, Vahtera & Virtanen, 2000; Kivimäki et al., 2003; Nieuwenhuijsen, Bruinvels & Frings-Dresen, 2010; Sinokki et al., 2009; Sinokki et al., 2010). At the same time absences from work due to mental health conditions are on the rise worldwide according to the World Health Organization (2022), some of which could be attributed to stress from various sources. One source is thought to be the increased use of information technology at individual’s life including workplace (Dragano & Lunau, 2020; Elo, Leppänen & Jahkola, 2003). Though it is hard to show that the increase of information technology in working life is responsible for the increase of stress-related problems, the two are still coexisting. There are some studies which have drawn the link between the use of IT and increase in work exhaustion and burnout (Berg-Beckhoff, Nielsen & Ladekjær Larsen, 2017; Kao, Chi, Thomas, Lee & Wang, 2020; Moore, 2000). However, the increase in IT around organizational members seems to be an ever-growing source of stress. Stress is a normal part of life and even necessary for human beings, and it has many meanings in everyday language. Even in science there have been many ways to conceptualize stress (Le Fevre, Matheny & Kolt, 2003). The physiological stress process aims at maintaining the homeostasis in the body through allostasis (McEwen, 2002). The psychological triggers for stress response are caused by an internal appraisal process (Lazarus, 1971; Pearlin, Menaghan, Lieberman & Mullan, 1981; Lazarus & Folkman, 1984). Human beings appraise the challenge that they are facing, check the internal resources available to them and make an evaluation if they are enough to overcome the challenge. There are several different theories on how the stress in occupational setting forms and how it affects members of an organization (Dollard & Bakker, 2010; Edwards, Caplan & Van Harrison, 1998; Elovainio, Kivimäki & Vahtera, 2002; Karasek & Theorell, 1990; Schaufeli & Bakker, 2004; Siegrist, 1996). These can be applied to studying technostress in an occupational setting in organizations that utilize technology, robots and intelligent systems. What studies in information systems have shown is that use of technology can cause stress in humans and it has been dubbed technostress, which refers to the subjective stress felt by human beings while interacting with technology (Ayyagari, Grover & Purvis, 2011; Bondanini, Giorgi, Ariza-Montes, Vega-Muñoz & Andreucci-Annunziata, 2020; Brod, 1982; Brod, 1984; Salanova, Llorens & Cifre, 2013; Salo, Pirkkalainen & Koskelainen, 2019; Tarafdar, Gupta & Turel, 2013). Technostress is the subdivision of stress which is related to the usage of information technology by human beings (Ayyagari et al., 2011; Brod, 1982; Brod, 1984; Ragu-Nathan et al., 2008). As the amount of information technology in our lives grows, so do the sources for technostress increase in number. Technostress negatively affects many aspects of working life like job satisfaction, organizational 8 commitment, perceived work overload, information fatigue, loss of motivation and employee outcomes (Bondanini et al., 2020; Ragu-Nathan et al., 2008). It is also possible for a person and organization to mitigate the effects of technostress through different organizational acts and individual coping strategies (Salo, Makkonen & Hekkala, 2020; Salo et al., 2022; Tarafdar, Cooper & Stich, 2019). Understanding this interaction with technology and wellbeing through the lenses of stress could give us opportunities in building a better and healthier working life. Connecting robotics with technostress Dragano and Lunau (2020) made findings about digitalization as the technology-driven transformation at work environment which creates a basis for experiences of technostress at the workplace. The research on technostress has multiplied in recent years (Bondanini et al., 2020). Research connecting technostress with RPA in work context has not been studied extensively, however. It is important for the providers of RPA to understand ways of making the experience of using automation less stressful in order to prevent users from changing providers (Salo et al., 2020). In this paper we will explore stress through psychological (Lazarus & Folkman, 1984), different occupational and technological (technostress) lenses. This study will focus on the negative impact that RPA has on the individuals working alongside RPA and aims at narrowing the research gap on how the technostress is formed in the context of automation use at organizations, namely RPA. We ask these three research questions: 1. How does technostress emerge in the use of RPA? 2. How do the characteristics of RPA influence the emergence and mitigation of technostress? 3. What and how organizational structures and strategies related to the use of RPA influence mitigation of technostress? The research questions were answered through the literature review and the qualitative methods. The source material and references for the literature part used were retrieved from multiple databases: Google Scholar, ACM Digital Library, IEEE Xplore Digital Library, ScienceDirect and Scopus. Additionally, the University of Jyväskylä’s own database, JYKDOK, was also utilized in search for the previous studies and literature. The database queries were done using a combination of keywords, some examples of keywords being “technostress”, “software robots” and “robotic process automation”. Journal quality was checked with The Publication Forum if applicable and the quality of the research article itself was assessed by the author. The relevance of the article to the topic at hand was considered by the author. After the literature review, we conducted a qualitative study. In total 22 interviews were done with individuals who use and/or interact with RPA in their work. The qualitative method was selected to ensure the ample data about the subjective feelings of using robots and the technostress it causes in the users. 9 There are five key findings in this study: first, the stress experiences happen in layers of proximity to the RPA. Second, the maturity of the RPA during the RPA lifecycle affects what kind of stress experiences organizational members will experience. Third, depending on your role as a stakeholder to the RPA your stress experience varies. Fourth, some RPA characteristics were recognized that cause technostress. Finally, the look into how technostress and occupational stress interact with each other is a rare viewpoint on technostress. Rest of the report is structured in the standard research article form. First, we go through the theoretical background of the study. Second, we present the methodological choices and justify them. Third, we report our findings. Fourth, we discuss our theoretical contributions and practical implications, and limitations of this study are considered. Future directions of research are also described. Finally, a conclusion to the study is presented. 16 refer to the feeling of coworkers understanding the technology better in comparison. Complexity can lead to feelings of inadequacy in employees. Techno-uncertainty refers to the pace of change of technology in an organization. It leads to employees being worried about their competency to conduct a job and stress related to constant learning related to new technologies. Fast pace of change can lead to situations where experience is hard to develop. Techno-invasion refers to the amount of space in life that the technology interferes with. Invasion refers to a situation where the technology invades personal space and leads to situations where the person is always reachable. This can lead to longer workdays as well because the stress recovery is delayed as the technology interferes with separating work from leisure (Ragu-Nathan et al., 2008; Tarafdar et al., 2007; Tarafdar, Tu & Ragu-Nathan, 2010). In addition to these often-repeated technostress creators, other creators have been identified as well. Shu, Tu & Wang (2011) studied the effects of technology dependence as stress creators. Technology dependence refers to the degree that a person is dependent on the technology to work. Higher dependence means higher relevance of computer-related technology in routine work. Higher dependence thus means higher likelihood of facing trouble in computer-related technology (Shu et al., 2011). Techno-unreliability has also been added to the list of possible creators, though it has been studied less than many of the other creators (Fischer, Pehböck & Riedl, 2019). Techno-unreliability refers to the degree in which the system works like it is intended to or is anticipated to work like (Fischer et al., 2019). Unreliable technology has been linked to an increase in physiological stress markers (Riedl, Kindermann, Auinger & Javor, 2012). Siitonen (2021) also studied communication challenges and unrealistic expectations. Communication challenges refer to misunderstanding between the technology and the humans in situations where information was to be exchanged. Unrealistic expectations refer to situations where the users in the organization might think about the technology in unrealistic manner and lead to feelings of annoyance and frustration when those expectations are not met (Siitonen, 2021). Stressors, however, do not just happen out of the blue, but rather they are caused by something from the surrounding world. Ayyagari et al. (2011) added a model for how technology characteristics cause stressors which in turn lead to strain. Characteristics like usability, intrusiveness and dynamism have been linked to work overload, role ambiguity, invasion of privacy, work-home conflict and job insecurity (Ayyagari et al., 2011). As a characteristic, usability is divided into usefulness, complexity and reliability. Usefulness is defined as the degree to which characteristics of technology enhance job performance. Complexity is the degree to which using the technology is effortless. Reliability refers to features and capabilities offered by the technology being dependable. Intrusiveness is divided into presenteeism and anonymity. Presenteeism refers to the degree to which individuals are reachable through the usage of the technology. Anonymity refers to the degree to which a user could be identified through the use of technology. Dynamic feature refers to the pace of change of technology, the degree to which the changes in the technology are thought to be rapid (Ayyagari et al., 2011). 17 There can be many different outcomes for being exposed to technostress. The negative end of the outcome spectrum are outcomes that are non-beneficial or adverse for the individual. These outcomes can be divided into four categories: outcomes related to job, outcomes related to IT use, well-being related outcomes and physiological outcomes (Tarafdar et al., 2019). In the domain of job-related outcomes are decreases in job satisfaction and commitment to the organization, increase in turnover intentions, role overload and role conflict (Ragu‐Nathan et al., 2008; Tarafdar et al., 2007). Technostressors also increase perceptions of workstressors which in turn lead to other outcomes (Maier et al., 2015). In the domain of IT use related outcomes frustration caused by technostress leads to changes in use of information technology. Technostress has a negative effect on the user experience, user satisfaction and the felt benefits of IT use (Maier et al., 2015; Tarafdar, Tu, Ragu-Nathan & Ragu-Nathan, 2011). In the domain of well-being related outcomes technostress has been shown to increase problems with mental health (Siitonen, 2021; Dragano & Lunau, 2020). Multitasking while using information technology has been linked to exhaustion which negatively affects work motivation, commitment and job satisfaction (Ayyagari et al., 2011; Tarafdar et al., 2007). Concentration problems, sleep problems, social relation problems, anxiety, depression and burnout are all possible well-being related outcomes of technostress (Dragano & Lunau, 2020; Salo et al., 2019; La Torre, Esposito, Sciarra & Chiappetta, 2018). In the domain of physiological outcomes technostress can lead to increase in cortisol level, skin conductance, heart rate, blood pressure and cortisol (Riedl et al., 2012). Galluch, Grover & Thatcher (2015) noticed an increase in salivary alpha-amylase scores, a hormone that is considered to be an objective indicator of strain, when IT-related interruptions became more frequent. However, some things can moderate what happens to the body and mind in the event of technostress. Not all individuals feel technostress in the same manner. Individual characteristics and backgrounds influence how a person reacts to technostress creators (Ragu-Nathan et al., 2008). Age, education, gender and computer confidence are all factors that can alter the appraisal of technostress. These variables affect personal beliefs which in turn change the user reactions to IT. Males might feel more technostress in general and increases in age, education and computer confidence decrease technostress (Ragu-Nathan et al., 2008). Personality has been also studied in the context of how individual differences affect the relationship between technostress and job outcomes (Srivastava, Chandra & Shirish, 2015). With certain Big Five personality mixes technostress creators might lead into positive job outcomes as well (Srivastava et al., 2015). In addition to passive characteristics, human beings and organizations can be active as well in lessening the effects of technostress. The effects of technostress that the use of technology can have on individuals can be lessened. Individuals and organizations have always had ways to mitigate and cope with technostress (Benlian, Klumpe & Hinz, 2020; D’Arcy, Herath & Shoss, 2014; Pirkkalainen, Salo, Tarafdar & Makkonen, 2019; Salo et al., 2020; Salo et al., 2022; Tams, Thatcher & Grover, 2020; Tarafdar et al., 2010). The effects 18 of stress can be altered with different coping strategies on individual level. Individual coping refers to the cognitive and affective behaviors which they take in situations of stress to lessen the effects of stress (Tarafdar, Pirkkalainen, Salo & Makkonen, 2020). Coping has been found to be proactive or reactive in addition to problemand emotion-focused coping (Folkman, 1984). Proactive coping refers to preparing for stressful situations in advance through meaning-making and mastery. People in stressful IT-situations can also cope with reactive strategies by emotional responses. Reactive coping strategies include expressing emotions and separating oneself from the situation. Proactive coping strategies also influence reactive strategies. In technostress situations both strategies can exist concurrently (Pirkkalainen et al., 2019). However individual coping is just one side of the whole, and organizational mitigation has the possibility to be more effective than individual coping. Technostress mitigation on the organizational level is very important as well if we consider the research on burnout being a symptom of dysfunctional organizational structures (Maslach & Leiter, 2016). Organizational mitigation refers to creating conditions for end users that prevent the negative effects of technostress (Tu, Tarafdar, Ragu-Nathan & Ragu-Nathan, 2008). Technostress mitigation on the organizational level is focused on preventing or decreasing the amount of stress that individuals in the organization might feel when around technology (Ragu-Nathan et al., 2008; Tarafdar, Pullins & Ragu-Nathan, 2015; Tarafdar et al., 2011). Ensuring structures that support the use of technology in the organization create effective coping mechanisms for the employees and is the main method of mitigating technostress on the organizational level. These include technical support, literacy facilitation, technology involvement facilitation and innovation support (Ragu-Nathan et al., 2008; Tarafdar et al., 2011), job control and rewards (Hung, Chang & Lin, 2011; Tu, Wang & Shu, 2005), increasing skill through training (Szalma & Hancock, 2007; Tu et al., 2005), task adaption (Szalma & Hancock, 2007) and communication-related measures (Pflügner, Reis, Maier & Weitzel, 2020). Technical support includes user training to use technology and help desk support which both are required with the adoption of new technologies (RaguNathan et al., 2008; Tarafdar et al., 2011). Literacy facilitation means distribution of information and knowledge related to the technology inside the organization. This would include best use cases for the technology as well. Technology involvement facilitation means involving the users in decisions related to the usage of the technology and development of it. Innovation support refers to empowering individuals in the organization to find ways to utilize the technology (Ragu-Nathan et al., 2008; Tarafdar et al., 2011). Job control refers to the autonomy for the workers to organize the work in a way that suits them (Hung et al., 2011). Rewards refers to honors, promotions and compensations given in organizations (Hung et al., 2011; Tu et al., 2005). Training refers to formal or informal ways in which skills in use of technology are increased to meet the demands of the changing work environment (training individuals to become citizen developers in the realm of RPA is one example of this) (Szalma & Hancock, 2007; Tu et al., 2005). Task adaption 19 means ignoring cues irrelevant to tasks, akin to focusing on a task and ignoring all else irrelevant to performing the task (Szalma & Hancock, 2007). One reason behind automation in general is that it lessens the amount of information that the human has to process in order to complete a task. With automation it becomes possible to ignore some aspects of a task while the automation performs it (Szalma & Hancock, 2007). Communication-related measures refer to executive sponsorship and distribution of best-practices in the organization (Pflügner et al., 2020). Both occupational stress and technostress are relevant concepts when looked through the lens of overall strain that an organizational member is under when acting in the sphere of influence of the RPA (figure 1). This interplay of stress must be considered if the academic literature strives to link the technostress to the broader outcomes of mental health (Dragano & Lunau, 2020). FIGURE 1 RPA and the conceptualized interaction between types of stress in organizational context 2.3 Robotic Process Automation One way that humans and machines interact in working life is the use of automation to conduct certain tasks. The continuous development of IT leads to an ever-changing landscape of used technologies at the workplaces. One aspect of changing landscape is the intelligent augmentation of work which requires the organization to reassemble work into new formats within the organization (Baptista, Stein, Klein, Watson-Manheim & Lee, 2020). There are a variety of robots in use at organizations like chatbots, embodied robots, virtual assistants and software robots (Siitonen, 2021). The amount of robots working collaboratively with humans is increasing as the automation becomes more sophisticated (Paluch, Tuzovic, Holz, Kies & Jörling, 2022). Definitions of RPA vary by source, and software robots/Robotic Process Automation are often used interchangeably. RPA 20 can be defined as “the use of a preconfigured software solutions that uses business rules and predefined activity choreography to complete the autonomous execution of a combination of processes, activities, transactions, and tasks in one or more unrelated software systems to deliver a result or service with human exception management” (IEEE Corporate Advisory Group, 2017). Makkonen, Salo & Pirkkalainen (2022) conducted a study on robots, including software robots, at a workplace context in which they concluded that software robots are usually synonymous with RPA and that these bot programs aim to automate computer tasks usually performed by employees. RPA is a software that is used to automate manual repetitive tasks in order to decrease human errors and emulate the workforce and leads into situations where a robot performs the tasks that humans would be doing otherwise in order to increase efficiency, productivity and data security, and improve accuracy (Syed et al., 2020). Benefits of RPA include increase in organizational operational efficiency measured by cut in cost of human resource-related spending, increase quality of service measured by decrease in errors, low costs of implementation and integration in comparison to large enterprise systems and finally reducing risk and increasing compliance (Fung, 2014; Syed et al., 2020). In some cases, anthropomorphic, or humanlike, features are added to technology to increase trust and acceptance between humans and the technology (Benlian et al., 2020; Mourey, Olson & Yoon, 2017; Touré-Tillery & McGill, 2015; Waytz, Heafner & Epley, 2014). Anthropomorphic features may include for example humanistic shapes or use of smileys in communication (Qiu & Benbasat, 2009). In the field of RPA this facilitates acceptance of RPA as true team members through naming conventions (e.g. giving real names to the RPA) or the way the RPA communicates with the team members (e.g. saying “Hello” at the beginning of giving a report to a human user) (Waizenegger & Techatassanasoontorn, 2022). Syed et al. (2020) present that the architecture of RPA in literature is positioning RPA within the presentation layer of the Open Systems Interconnection model which locates RPA as a means to interact with data on any existing application source without integrating it into the system, and many RPA solutions began as recording/screen-scraping the programs that humans have been using, but since then many vendors primarily support centralized server models with virtual desktop environments. RPA has a role in transitions between human work and extensive business process automation (Van der Aalst, Bichler & Heinzl, 2018). RPA accesses different IT-systems and performs tasks by imitating humans (Moffitt, Rozario & Vasarhelyi, 2018; Van der Aalst et al., 2018). A task or process is especially suitable for automation via RPA if the process follows a standardized and rule-based structure, is often done manually by human workers and requires multiple-system access (Asatiani & Penttinen, 2016; Moffitt et al., 2018). Processes ripe for automation are characterized through information technology as follows: high volume of transactions because they are generally routine and repetitive, high value of transactions because of a good business case, frequent access to multiple systems because of the high manual effort required, stable environment because instability leads to unpredictable disruptions, limited human 21 intervention because of straightforward decision-making, limited exception handling because of limited decision-making capabilities of automation, manual IT processes prone to errors or re-works to minimize human errors in data handling, ease of decomposition into clear IT processes to capture the work process to be automated with ease and finally clear understanding of current manual costs to build the business case for automation (Fung, 2014; Santos, Pereira & Vasconcelos, 2020). RPA is often tailored for the specific need, and some examples of places where RPA could be utilized are transfer of data between two different information systems (like patient record system and spreadsheet editor) or automated notification of a bill due after the payment deadline. As RPA is not just an object to be bought from the shelf, but rather a process to be implemented, RPA does not just appear overnight at the workplace. RPA is built in stages and can be seen as having a lifecycle (Enriquez, Jimenez-Ramirez, Dominquez-Mayo & Garcia-Garcia, 2020; Jimenez-Ramirez Reijers, Barba & Del Valle, 2019). There is not a single way of implementing RPA, but generally the process involves the following stages: analysis of the processes, or parts of it, that are candidates for being robotized, the design of the selected process with understanding of the actions, data flow etc. which must be developed, the development of each designed process, the implementation of the automation in their individual environments, a testing or control phase in which the performance of each automated process is analyzed and errors are detected and finally the operation and maintenance part (Enríquez et al., 2020; Jimenez-Ramirez et al., 2019). Notable is that RPA has fewer possibilities for a testing environment which leads into more riskier adoptions since often only the production environment is available. In these different phases different stakeholders are also involved (Enríquez et al., 2020; Jimenez-Ramirez et al., 2019). Developing RPA requires both domainspecific knowledge and software-specific knowledge to implement the solution which means that collaboration between domain experts and software developers is usually part of the process of implementing RPA (Mendling, Decker, Hull, Reijers & Weber, 2018). That is why taking both end user perspective and developer/designer perspective on the stress is important as well. In addition, there are different ways to implement RPA as well which should be considered. RPA applications can be divided into two categories: attended and unattended robots (Kedziora & Penttinen, 2021). Attended robots have human-in-theloop monitoring, pausing, interrupting and stopping it at any time while unattended robots work more autonomously without requiring input from human operators and are run on a scheduled basis from a tool called “orchestrator” (Syed et al., 2020; Wewerka & Reichert, 2023). Unattended robots refer to RPA that does not require use interaction from human operators while running and is usually suitable for simpler processes (Syed et al., 2020). Wewerka & Reichert (2023) made a distinction between unattended robots and attended robots through reclassifying unattended robots as RPA and attended robots as Robotic Desktop Automation (RDA). Under this classification RPA would be defined as virtual users working from a centralized server while RDA would be personal 22 attended assistants working on the user’s desktop (Weverka & Reichert, 2023). RPA in general creates a new dynamic for organizational members to live with. Responses that RPAs elicit in humans vary, ranging from positive to negative and cause affective, cognitive and behavioral responses. The negative affective triggers in the interaction between humans and RPAs are related to technical errors and restrictions, robot’s autonomy, robot user’s self-efficacy, emotional connection with the robot, fear of losing job and decrease in human-human interaction (Lampi, Venermo, Salo & Pirkkalainen, 2022). The effects of RPA on employees are thought to be both positive and negative. On the positive side RPA frees up time to pursue more creative and meaningful tasks, but RPA might also be seen as a threat to job security, creating pressure to learn new skills and cause role stress (Seiffer, Gnewuch & Maedche, 2021). Challenges that employees meet when setting up software robots are multitude. Four categories have been identified: employees need to learn to set up and/or use the software robot, they need to be able to do change and error management, they need to learn to interact with the robot and other challenges (Venermo, Lampi, Salo & Pirkkalainen, 2022). In summary, an existing research gap has been identified in research on individual-level consequences of working with software robots (Seiffer et al., 2021; Syed et al. 2020; Van der Aalst et al. 2018; Venermo et al., 2022). While the use of technology and the technostress that emerges through it has been studied, there is less study on how the specific technology of RPA and how technostress and occupational stress interact with each other in an organizational setting. Most of the studies focus on the direct interaction with the technology, but as is in the nature of automation, less interaction is intended. Studying the technology of RPA in the organizational setting while taking a look at both technostress and occupational stress could shed a light on how the technology affects organizational members further away than just in the direct interaction with the technology. We are aiming to increase understanding of the emergence of technostress, what characteristics of the RPA can cause technostress and how the organization can mitigate the said stress with our empirical study. 23 Qualitative research methods were used in gathering and analyzing the data for this study. Qualitative research methods enable the gathering of insights from people working with robots and generate new understanding in how this relationship generates technostress. Stress is a subjective experience and to truly understand how working with RPA form technostress, and how individuals think about the characteristics of robots that accentuate or mitigate technostress ample data was required. With this approach we were able to generate deep insights about real-life situations of working with RPA (Pentland, 1999; Schwarz, Chin, Hirschheim & Schwarz, 2014). Iterating between the narratives collected through personal interviews and making comparisons to the literature on stress and technostress, occupational stress and RPA allowed us to deepen the understanding of theories behind the phenomena. 3.1 Data collection Interviewing is a way of shining light, permitting us to see that which is not ordinarily on view (Myers, 2020). Narrative interview in a semi-structured form was chosen as the data gathering method, because it allowed us to gather information on actual events that happened to the interviewees instead of imagined hypothetical situations and the interviewees were able to communicate using a familiar language to them instead of being forced to use terminology brought by the researcher to the situation (Myers, 2020; van der Heijden, 2012; Gruen, Rauch, Redpath & Ruettinger, 2002). Individuals that have direct experience with RPA are best informants on the subject matter (Pentland 1999; Schwarz et al., 2014). The data collection was conducted in accordance with the research ethical guidelines of the University of Jyväskylä. We interviewed 22 users who had subjectively experienced technostress related to working with the RPA during a 10month period in 2023. Purposeful sampling was used to find users with experience of working with RPA (Patton, 1990). We utilized social networks (personal 3 RESEARCH METHODS 24 contacts) to find the first few potential subjects for interviews after which we asked the interviewees to recommend potential additional interviewees for us. This technique of gathering recommendations from interviewees is called snowballing technique (Patton, 1990). We started by finding a couple of persons from two different organizations, but through the use of snowballing ended up with a representation from 11 different organizations. Inclusion criteria for this study were: 1. to have experience working with RPA, 2. the interviewee possessed the ability to tell about the experiences of working with RPA and 3. had motivation to participate in a one hour recorded interview conducted via Zoom, or face-toface using cell phone to record the interview. The interviews were then transcribed. Attention was given to the inclusion of a variety of voices through that we included many kinds of workers in the interview pool: RPA developers, RPA designers and other workers that comprised the end users of RPA like accountants. Through this we attempted to reach the triangulation of subjects (Myers & Newman, 2007) and have the different voices heard through the interviews to reach a saturation (Myers, 2020). Prescreening using a questionnaire was sent to each interviewee before the interview to ensure experience of working with RPA. Although our initial contact with the person to be interviewed included confirmation that the person worked with RPA to some degree, we wanted to separate for example working experience in years from experience with RPA. We developed a semi-structured interview before starting the interviews but made some modifications after gaining experience on the subject matter, focusing on the most interesting themes in relation to RPA and technostress (Appendix 1). We aimed to gather information on what kind of RPA the interviewees have interacted with, which kind of stressful moments they have encountered, which characteristics of the robot made the stress experience worse or better and what might have helped with the stress from individual or organizational point of view. After noticing some repeating themes, we started to deepen our understanding on those themes in addition to following the more open-ended narratives as well. Developing the interview process and questions as experience accumulates to the interviewer has advantages when exploring areas with little prior research (Berg, 2004; Myers and Newman, 2007). We started the interviews by focusing on the experience of working with RPA and what kind of RPA the person has worked with. We also asked about the person’s ideas about how RPA will affect the future of work. After that we deepened the discussion with focus on the characteristics of the RPA that might cause stress and strain for the individual. We asked about the quality of strain that the interviewee might have experienced and how the stress and strain might have affected occupational stress. We also asked about characteristics that the person wished the RPA could have to make use interaction easier with the RPA. In the end we discussed what an organization or individual can do to mitigate stress felt through the co-existence with the RPA. Myers and Newman (2007) set seven guidelines for a qualitative interview in the field of Information Systems which we followed as closely as we could. We did a semi-structured interview to leave room and flexibility to be open for the 25 data gathered in the interview (Myers & Newman, 2007). We focused on open questions, rephrasing what we heard and asking for the interviewee to tell more by using their own words to gain depth and insight from subjects’ world as a way of mirroring (Myers & Newman, 2007). We built connection and alliance with the interviewee by behaving well and respectfully towards the interviewee, and we also used the language we had learned from RPA research to minimize social dissonance (Myers & Newman, 2007). Data collection continued until a level of saturation was felt to be reached to represent various ”voices” (Myers & Newman, 2007). Confidentiality of disclosures was provided by recording the interview locally on a secure laptop, deleting the video side of the recording immediately after the interview as unneeded and sending the transcriptions over a secure connection to the provider who did the transcribing and had signed a non-disclosure agreement (Myers & Newman, 2007). We checked our understanding with the interviewee many times during the interview to ensure that we had understood them correctly as everyone is an interpreter (Myers & Newman, 2007). We also oriented before each interview by going through the interview structure and focusing on the goals of the interview to situate ourselves as actors in the interview (Myers & Newman, 2007). The interviews were conducted in 2023 and consisted exclusively of Finnish-speaking organizational members working with RPA and were conducted in Finnish. The self-reported gender distribution in the data was 12 males and 10 females. 18 of the interviewees had higher education (upper or lower university degree, doctorate) and the rest had vocational school education. The professional titles, to name a few, included Sales Manager, IT Director, Senior RPA Developer and Invoicing Expert. The age of the interviewees ranged from 26 to 63 with the mean age of interviewees being at 40,5 years old, the average working experience in the industry being about 16 years and experience with average experience with RPA being at 4 years. The interviews lasted 53 minutes on average. A data of over 130 000 words was gathered through transcription of recorded interviews. 3.2 Data analysis The unit of analysis was the individual subjective experience of (techno)stress regarding the use of RPA. We also were interested in differentiating occupational stress from technostress and observed the complex interplay between the two phenomena. There is not a single right way to conduct a qualitative analysis, but we followed guidelines and procedures (Charmaz, 2014; Lune & Berg, 2017; Patton, 2014) as closely as possible to move between the text and the analysis of theoretical concepts. The analysis process was iterative as we felt that it gave us the possibility to apply our growing understanding to the interview text and gain more out of it. However, there is no clear end of data collection and beginning of data analysis in qualitative research. The interviews were transcribed from the recordings. The main phases of the analysis itself were based on content analysis phases (Lune & Berg, 2017). We went through the transcriptions to establish 32 Many people reported that the RPA had brought real benefits to the team, and the general feeling during the interviews seemed to be that the RPA was a positive thing for the team or group of workers. Some interviewees had difficulties in recognizing the stressful parts of the RPA because their feeling was so positive about the RPA. Work tasks are becoming more meaningful all the time, and people are no longer willing to do repetitive routine work. Instead, people's job tasks are being reshaped and made more rewarding. Well, exactly that, freeing up time for other tasks where human brains are really needed, for problem-solving and more demanding work. So, freeing up time from routine, repetitive tasks to do something more useful, so to speak. Everything is useful, of course, but still, where we can invest more effort to move things forward. 4.3 Emergence of technostress and interaction of RPA characteristics, technostress and occupational stress RPA lifecycle became apparent during the interviews. The RPA itself as a technology seems to start affecting the organization in which it is implemented prior to being concrete technology in use as the awareness of the technology itself is enough to start the stress processes in the organizational members. Each lifecycle phase has the chance of eliciting stress from the organizational member even before a contact with the technology itself has been established. As the process to build and implement RPA takes some time, the different phases or maturities of RPA cause different forms of stress. Sometimes the two forms of occupational stress and technostress are inseparable as well. A situation might cause both kinds of stress as they happen at the same time or lead into one another. So, it caused a kind of, well, maybe a unique kind of heart palpitations because you have to get it done as quickly as possible, and then all the other tasks are waiting at the same time. So, maybe the irritation came from not having a dedicated resource for that. But yes, I did feel a sense of inadequacy because everything had to be done at once. When there's just too much at once, it creates a pressure or stress that starts to become overwhelming. Figure 2 illustrates the dynamics of emergence of technostress in different phases of the RPA lifecycle which has been roughly divided into three parts as portrayed by our interviews. The layers represent the maturity of the RPA as a technology as it advances through the lifecycle, but another dimension is the proximity that an organizational member has to the technology. A developer is near the technology as long as it exists while a team member in which RPA was implemented in might not be as near to the technology as the manager/champion that is responsible for monitoring the technology and coordinating with the developers in the events of malfunction. The layers (time) and proximity have some interaction as well but are separate enough as constructs as well to make the distinction. The 33 technostress starts with the chance of RPA being applied to the work near the organizational member and continues to evolve from there. FIGURE 2 The layered viewpoint of stress in interaction with the RPA 4.3.1 Awareness of the RPA The stress of the RPA usually started with the announcement that some tasks in a team would be handed over to RPA. Many interviewees mentioned fears based on preconceptions about losing jobs before the RPA was in use. The idea itself of having to utilize RPA started to generate job insecurity and negative feelings in some instances. Notable is that there, at this point, has not been any direct interaction with the technology other than just the knowledge of it existing. Probably no one here would start using a robot or something like that if there were negative thoughts about it. Or if someone feared that bringing in a robot would take away their jobs, that the robots would end up doing all our work. 34 In some cases, the SME did not have much knowledge in advance and were just thrown into the situation in which they have to start cooperating with the developer without being given any heads up about the process to be properly motivated. This can be quite a shock for the SME who must handle the situation as well as their own fears and insecurities at the same time. Unfortunately, there have been instances where the decision to automate has been made by someone higher up and then, in the worst case, just informed the expert that they have a Teams meeting on Wednesday to show their work for automation. The expert is then faced with a situation where they are very confused about what is happening, what is expected of them, and why they now have to share every detail of their work with an unknown partner. 4.3.2 Technostress and occupational stress before the RPA is implemented The stakeholders responsible for defining the RPA at the preliminary stages of RPA maturity seemed to have mostly occupational stress related to the RPA. Most often they were the ones that had to face the job insecurity caused by the idea of allocating some tasks done by human beings to the RPA. In some cases the occupational stress (job insecurity) acted as a technostress creator (technoinsecurity). Or then, when you are defining, well this doesn't relate to the robot's operation, but to stress in general, that you are defining a process with an expert who is genuinely on the verge of tears and with a trembling voice asks if they are going to lose their job now that their work is being automated. So those are perhaps somewhat unpleasant situations for me, where you just have to try to communicate very clearly what we are doing. The defining phase of RPA also includes capturing the process of doing a task which is often done under a tight schedule, for example because the SMEs do not have a lot of time to give to the person doing the definition. This non-allocation of resources to the definition task had a stressful effect on both developers and end users In these situations, it's that you want to develop something, you have questions, you want to go over something with the customer, but they don't have the time. They agreed to do it, but they don't actually have the time to spend on it, which is frustrating. Like, 'Yes, I would do something, but I can't because I need you now.' So, those who commit need to be committed during the development phase and then for the maintenance afterward. Well, primarily, I was probably irritated, from the perspective that I still have to spend time on this. Of course, like everyone else, my workdays are very busy, and you kind of think that once you do the initial work, maybe one or two rounds of corrections, ideally just one round of corrections, that's acceptable. But if it extends beyond that, it starts to get irritating. I was thinking, oh my goodness, are there still more of these, and now this requires more work and effort from me, and I really don't have the time. On the other hand, the SMEs that give information on the processes to be automated might not be properly motivated for the task because of the felt threat that the RPA brings to the situation or because being a SME for the RPA project has 35 not been resourced which leaves the SME’s own work undone and leads into occupational stress through workload. And the fact that whenever an SME is involved in such a robotics project, it is essentially an additional task for them. They still have their regular day-to-day job that they do every day. But then they are, well, sometimes you could say, forced to participate in such a project. In order to automate their work, they have to be involved in this extra project. And sometimes there are situations where some individuals are so tied up or so busy with their own work that they don't have time to help me with the automation, which then also slows down my work. So, it comes from the fact that they have to stretch themselves beyond their regular job, where they might already be busy, to this additional project. Sometimes the projects could not be completed because the solution was deemed impossible to do or the technology had not matured enough yet which led to frustration. In cases where the definition and conceptualizing part of the RPA project failed to deliver results, the RPA project might have been cancelled. In these cases, some stress experiences were possible as well. Even though these cases were rare, they had the ability to produce stress symptoms to the interviewees. It is debatable if this can be called technostress. The project would not be canceled if the technology would not exist as the project itself would not exist then, but the stress experience did not come from interaction with the technology itself. Well, those are situations where everyone is frustrated, having spent time and effort first identifying the development target, defining it, developing it, and then realizing that it’s not taking off. Clearly, everyone is very disappointed by the situation. (...) It could be that someone is cursing to a friend somewhere, saying, 'Damn, that person didn't know what they were doing' or something like that. The developers are next in line in the RPA implementation. They start to develop the RPA solution for the team and task at hand after the process has been captured to certain degree. At the development stage of RPA, the occupational stress can be seen as being more prevalent, though of course other sources of technostress than RPA can be present. For the RPA solution to be functional the definition part has to be done well, so the developers rely on the work done by the person doing the definitions with the SMEs. (...) when in business they come up with the idea to automate something, it should have been ready by last Wednesday. And then there's constant pressure afterward, asking about the status. The same goes for the definition side, where the definition documentation should be completed and on the desk very quickly. So, perhaps the schedule pressure is the most challenging. The developers reported ethical stress for example as they feel responsibility for the reliability and functionality of the solution to be developed. A wish that some developers shared was that the work they are doing would be functional and helpful to the people that use the RPA down the line in their own work. At the same time the data that the RPA handles may be very sensitive which leads to a pressure felt by the developer to do things right so that potential problems can be averted in advance. 36 The stress is a real source of pressure when you know that you haven't had a lot of test material for developing the process, and then the situation comes where it's going into production. And then it starts processing real data, real people, real people's data, which can even affect their everyday lives. One interesting aspect of felt stress in relation to RPA with the developers was the felt ownership of the RPA in question. Many developers were able to make distinction between a challenge stressor and a hindrance stressor in relation to the ownership of the RPA. If the RPA was developed by someone else, the situation was more often felt as a hindrance whereas if the RPA was developed by the developer the situation was more often appraised as a motivating challenge. Another way of looking at the situation is to think that the work on RPA that is not done by the same person feels less rewarding which activates the effort-reward imbalance. The developers felt more responsibility over the robot when it was developed by themselves. Working on an RPA that did not feel to be own was felt as a less rewarding experience. Well, of course, it means that I am responsible for it working correctly. That's what it fundamentally means, like owning any project. Admittedly, those situations when an old automation isn't working, has crashed, or something, and you have to start investigating it, it does bring a bit of a cold sweat immediately. Especially if the developer is no longer with the company, and you've secretly hoped that nothing would ever go wrong with it, and then something does, and you have to start looking into it, yeah, it's not fun. It's much harder when you haven't written the code yourself. It's much more burdensome because you don't really know how much time it will take to fix something when you don't... You first have to familiarize yourself with the process, which you didn't create, before you can even start fixing anything. If you had made it yourself, you could figure out what's wrong much more quickly. In some cases, anthropomorphism was leveraged to make the acceptance of the technology an easier process. However, there were organizations in which the RPA was only given a code and was seen as a method of achieving the automation and lessening the workload in the team. These anthropomorphic features include a picture of the robot, a name and human-like dialogue when the RPA communicates about the tasks it performed. Often the attitude towards RPA became more positive after implementation as the effects of having an RPA in the team became more concrete and the baseless worries were shown to be untrue. In other cases, the stress transformed as for example the job insecurity became stress about the unreliability of the RPA. Well, probably what I said, that it didn't happen with us, but it was probably just like, if a robot comes, will the work decrease, and then people will be laid off. And I felt that sometimes it was already... It sometimes sounded like an overreaction [laughs], that we can't even start planning a robot if there's a fear that it will reduce something, like should we start co-determination negotiations just in case if someone says the word 'robot' out loud in some department. Some interesting phenomena in relation to building and implementing RPA were the unrealistic expectations that started to shape during the conceptual phase of 37 the RPA lifecycle as the expectations for the RPA swung from extreme job insecurity (“we will be replaced”) to unrealistic expectations (“it will be same as a human colleague”). Some fears were in relation to the RPA taking over the system and doing damage in a very autonomous way close to what the worst fears about AI have been. Some indication was that the anthropomorphism of the RPA was one driver for the unrealistic expectations. If the RPA was given a name, perhaps even a picture was drawn of it and the communication was close to how humans would report what it had done, these factors had the chance to increase the expectations that the team members had for the automation. Or like, what if the robot goes haywire and sends out a hundred invoices or sends all our data to competitors? All sorts of things like that come up... We've seen movies from the '80s where some mechanical robot goes crazy and starts throwing dough around, so those kinds of things also influence this, making people wonder if this is some kind of Robocop or something. And then, in my previous company, which was a consulting firm, they had branded their unattended robot as Pertti-robot, with an image that made it look like [an approachable person]. And we talked about it, and the clients somehow adopted the idea that Pertti does this and that, which perhaps further creates the impression that it can somehow deduce a bit more [than it does]. Well, often it's like, 'Oh, so this is what the robot is like, it doesn't know what it's doing.' And then you might get a fairly frustrated message, like, 'Well, this is exactly what we expected.' There's a certain level of technophobia or disbelief that the robot can actually do the job, and situations like this just reinforce that. And then you sometimes hear, when some processes have been defined, that it can be stressful and painful for those experts because every rule needs to be mapped out. In one definition meeting, a client exclaimed, 'Is the robot really so dumb that it needs to be taught everything? 4.3.3 Technostress and occupational stress during and after the RPA is implemented The implementation and upkeep phases of the RPA cause many of the technostress experiences to the people in touch with the RPA. This is also the phase where the occupational stress and technostress have the most interaction with each other as well and the distinctions become harder to make. Majority of the technostress' experiences were related to the situations when the RPA broke down or did not do what it was supposed to do. These situations of unreliability were the major component in RPA-induced technostress and most of the stressful situations regarding the RPA were connected to moments of non-function. Often when the user/developer must be in contact with the RPA it often means that something has not gone in a way that it was planned to go. In these cases, the existence of RPA often means more workload, disruptions to the planned workday, schedule failures and need to relearn the manual method for performing the automated processes. And then suddenly you realize that it's on a page where it shouldn't be. So, something unexpected has already happened, and it's gone to the wrong place. Often at that point, 38 the situation arises where the next button the robot is supposed to press isn't found on that wrong page, and it stops, saying, 'Okay, I didn't find this button.' But there's definitely a bit of panic, like, what's happening, what is it doing? In many cases this has the chance of rousing occupational stress as well because the workload is suddenly increased and the autonomy on the use of time for an individual worker decreases as the automation has not handled the tasks given to it. This finding is in line with job demands and resources: when the demands increase suddenly and the resources lessen, the occupational stress increases. If they are done poorly, it can result in more manual work than there was originally. Well, certainly something related to the quality of the automation, and by that, I mean being really sure that the robot is doing the right things. Just because if it's running overnight and processing 2000 different tasks and they all go wrong, it can be very fatal and especially labor-intensive to fix afterward. So, the danger I see is that it might accidentally process the wrong person's data in the wrong way, and if I think about it in the healthcare field, for example, it would be a catastrophe if that happened. Well, often it's like, oh, so this is what the robot is like, it doesn't know what it's doing. And then you might get a fairly frustrated message, like, 'Well, this is exactly what we expected.' If I had to describe it in two words, it would be frustrated and demanding. The reasons for sudden RPA unreliability were related to many causes. In the case of unattended RPA one of the reasons behind sudden malfunction could be issues with server connection, expired licenses of the target systems or changes in access for the RPA to different parts of the system. Updates to the target system were also mentioned often. All RPA had the tendency to be vulnerable to system/interface updates in the target systems that they operated in. In cases where the target system was being updated and a heads up was given about the updates to the team that maintains the RPA the unreliability issues were less severe. When the updates were “sudden” in the eyes of the RPA team a major malfunction could happen as the RPA could not operate the target system successfully anymore. The centrality of the system also mattered as some systems were such that many RPA used it in the company. Updates in such a system caused “a massmalfunction event” which of course triggered both heightened levels of technoand occupational stress. These events also had a human component as sometimes the people who were being updated on upcoming changes were not the same people that maintained the RPAs and when communication failed between such people it had effects on the unreliability of the RPA. RPA developers sometimes maintained a stance that the RPA itself often did what it was supposed to do, but the systems that they were supposed to use changed which led to the RPA failure. But then in some cases, like if it's a business where the first robot has been made, they might not necessarily know to inform us when there's an update to a system they use. So, it happens that suddenly it gets updated, and then the robotics team hasn't been able to test it in advance [...] if the robot is, for example, slowing down because the system isn't working, this is something that should have been highlighted better. If the system is lagging, the robot can't use it any faster than a human because it has to wait for the system to function. 39 One interesting aspect of adopting RPA to the team was the loss of or rusting of the skills needed to conduct the task that the RPA was used to automate that we will name rustification. This phenomenon happened especially in situations where the RPA had been in use for some time and then malfunctioned for one reason or another. In some of these cases, especially if the process that the RPA was responsible for was time-critical, the human team members had to fill in for the RPA. The skills and know-how of how to conduct the process to accomplish the tasks might have been forgotten or the people that knew how to conduct the process might have moved on which led to a sudden situation where a new task had to be learned in a very short time. For the person that filled in for the RPA this caused disruptions to their own work which led to heightened experience of occupational stress. Well, possibly, the more these repetitive tasks get automated, it feels like the underlying expertise might disappear. We have certain tasks that have been automated for years, and no one has done them manually, so in some way, the knowledge and skills needed to change or develop that process might also be lost. So, the thing is, when something is left for someone else to worry about and it's no longer part of my daily routine, I will forget this task. I have work instructions, but it's no longer part of my everyday life. My daily routine becomes monitoring the work process and doing other tasks. I understand this very well; it becomes stressful because I no longer know or remember, and I always have to recall and read the instructions, check, and see how it was done in this case. In some cases, you have no idea what has been done before the error occurred, so you don't know where to pick up the work and start doing it. Another interesting phenomenon of how the RPA linked to technoand occupational stress experiences was that it caused more intense workdays. One of the core ideas of adopting RPA is that it replaces monotonous, rule-based work that frees up workers time to do more mentally challenging work. However, to some interviewees it also meant that the working days became on average more intense because for some people having easy work during the working day also means a relief from the intensity of work. When the more challenging, problem-solving and creative work took up more of the working day, it was felt in some instances to be more cognitively demanding and draining. Another viewpoint on the issue though is that the monotonous and mechanical work that should be automated requires the worker to be attentive and precise even if the work is mechanical which could in turn be cognitively draining as well. Additionally in some cases the RPA, especially when not working correctly, had a chance of producing more manual work instead and coupled with deadlines had a chance of making working days more intense. This could be seen as both technostress (”techno-intensification”) as well as occupational stress. The downside for me is that... or what I've noticed before, is that no one can constantly do intellectually challenging work all the time. There need to be those lulls where it's nice to type something simple into Excel or respond to emails, tasks that don't require a lot of mental capacity. And if we start from the premise that robots do all the easy stuff, it was presented positively, I remember when it was being sold, like, isn't it nice now that you'll have robots as coworkers doing all the unnecessary tasks? You won't 40 have to type this and that. Yes, but it also means that when people only have challenging tasks, the work can become a bit more burdensome. Well, it is quite a lot to ask if you have to do very demanding work for eight hours a day. In reality, no one can actually sustain that amount of highly demanding cognitive work with the same efficiency from morning to evening. It's more like the tasks that are being automated might require you to be sharp the entire time you're doing them, but it still takes hours. If you have to do such sharp work for eight hours, it's incredibly exhausting, having to carefully copy from one field to another. And you can't mess up, because if you do, the company might lose ten thousand euros right away. To some the increase of stress from the work might come from the loss of balancing work. For some the repetitive tasks are something that they actively seek out from the work to balance out the cognitively demanding work that is part of their job description. Some people actually enjoy those copy-paste tasks. And there are employees who still want to do everything manually and say that these routine tasks are the best part of their job. Like, 'I can switch off my brain, do the work, and go home. Why on earth would I want to do some analysis or think deeply?' It's quite difficult to do very challenging cognitive work for 7.5 hours straight. So, it would actually be good to have moments in between where you do more routine tasks. Often the consultants and developers that worked with RPA had the idea that the adoption of RPA did not replace any workers and that the experiences of insecurity towards automation were unfounded. For most cases it seems to be in line with the thoughts of the consultants and developers. However, at least one instance was in the data set where a manager had to let go of a team because automation replaced the work that the team was doing. For the manager the situation caused negative emotions and negative experience. One of the worst experiences is probably the disappointment that comes when work ends. I guess it can be... but it surely is a really big disappointment for most people, even if you can process it and understand that it's not because of you, that this time it was due to the work ending. You do take it personally, and it does make you feel really bad, really down. Some techno-invasions were mentioned. In some cases, the interviewee had to check on the RPA out of office hours just because of distrust in the technology, and in extreme cases it caused even sleep disturbances. In one interview for example the RPA was responsible for sending a text message to a cell phone if an invoice is unchecked or not accepted yet. The text message was sent daily until the situation was handled. So, if the RPA does not function properly in the case and the text message is not sent, as the invasion becomes lesser the stress experience is lesser as well. So, sometimes it was like you had to check it yourself at night to see how it was going. (...) if you don't approve an invoice, you get a text message from the robot every day reminding you to approve the invoice. And there was an issue with the text message 41 service interface, so no messages were sent all summer. Surprisingly, no one reported missing their text messages. I feel like people were just happy not to receive those robot messages during the summer Techno-complexity seemed to be present as well, linked to complex technological solutions to make the robot work. This has most to do with the many different systems that are connected to the successful implementation of RPA as the problems could arise from any of the interconnected systems. SMEs have very little knowledge on the architecture and technicalities of the RPA, and such are completely reliant on the developers to fix the malfunction. If I say, for example, here's a data lake, there's a virtual machine, and there's a bot, and now you need to go to Dataprix and do this, that, and the other, they immediately panic and say they don't understand anything The stress symptoms that organizational members reported in relation to RPA were minor, but present. Experiences of emotional difficulties like feelings of frustration and annoyance were present when the RPA did not function as it should. How to put it, well, it's probably a general state of irritation and the kind of feeling that makes you want to curse when an issue arises. Well, it's more of a feeling of pressure and a bit of irritation. Feelings of pressure and experiences of occupational stress increased in these situations as well. A lot of the technical problems with RPA directly fed into the occupational stress in addition to the technostress which in combination led to unpleasant experiences. This has an interplay with the criticality of RPA as well and turns into occupational stress as well. Well, it does bring a sense of failure and the desire to get the job done right, and then maybe stress about the next run, wondering what will go wrong this time and if we really fixed it. And of course, if it's something very urgent or important, it often occupies your mind during your free time, thinking, okay, did I do this right, will the next run succeed for sure? Well, probably a sense of frustration. And of course, there's also worry or concern about what if the entire change of month, for example, is spent dealing with this. Sometimes worrying increased which as well crept outside of working time for the organizational members. This could be seen as distrust towards the technology as well, so if the RPA is malfunction-prone and there is a distrust towards the technology, it turns into worry and as such into stress. It feels like it's never going to end, that there's always something new coming up. It starts to get frustrating, and I feel like that's when you start thinking about it more outside of work, like before going to bed or something like that (...) Even though I shouldn't stress so much, it affects my sleep, for example, or I keep thinking about it if I can't solve something. And then I get a bit irritable if I feel stuck with something, like if I just can't get the robot to work. 48 We had a strong drive to make these robots, but we couldn't move forward without the information management unit's help. We needed them to help us get things like user accounts, and we had to ask for them a thousand times. So, for it to work correctly and well, it requires a lot of proper actions from the surrounding stakeholders, both from the system provider who makes updates and from other people who prepare things so that the robot can fetch the correct information from the right place. They need to have done their work correctly in the first place. It requires a lot of stakeholder collaboration for the robot to function correctly and well in the middle of everything. We should get information early enough that, hey, we are planning a company-wide automation trial or a software robotics pilot or project. Communicate openly to everyone. Then, those it particularly concerns, the end users and their supervisors, and maybe their supervisors or the management who make decisions and procure these things, should all be involved in the project. Managing expectations was seen to be an important part of the process as well. Some interviewees had the thought that clear communication of what RPA is, and is not, was seen to lessen the change resistance and stress that the end users might feel when the RPA is discussed. Finding the internal champions in the organization was felt to be important as well so that the teams could have an internal person who sells the idea that automation is a good thing for the team as the workload will be less. Having the end user team be involved throughout the process makes the implementation of the RPA less threatening and stressful even after implementation, like in the scenarios where the RPA malfunctions. Well, at least when we start considering robots, it's important to convey that the robot is our friend, it's here to help. If we start from the point of view of what work can be taken away to make you more efficient, it's like a red flag, and no one wants to reveal any [laughs] task that makes them feel useless. So, starting with the idea that the robot is here to help so you can focus on doing enjoyable things is definitely one key point. Internal discussions have been held to understand what the robot is and what it will be doing, that's clear. If there are still internal discussions to be had and there might be some opponents or skeptics, those should definitely be addressed before the implementation. Because even small setbacks can cause a lot of discontent. It doesn't work that way, even though we tried to explain to them that the robot still needs a supervisor who oversees its work and monitors it, and that it still takes time from people. So, that's one thing that needs to be understood and there needs to be training on what it means for a robot to do the work. Various technical aspects were brought out as well. As the malfunctioning RPA was a major source of stress for the workers in the organizations, the resilience of the RPA and the agreements for running the RPA were seen as important parts of the less stressful RPA. Also, an important part of this was how the RPA is developed/run from the organizational perspective. Identifying sensible places where RPA could be applied as well was seen as important from the get-go as not finishing projects led to frustrations as well. As with all software the documentation was seen as important as well, especially in cases where there is turnover of employees and thus loss of knowledge about the automated process. 49 We use development sprints, two-week sprints, and at the beginning of each sprint, we define what everyone will be doing during the sprint. We allocate a certain amount of time for each person to put out fires. There are these points that are assigned to each task, and we allocate a certain number of story points for putting out fires. When planning the sprints, we don't take on too much work. We plan the work so that there is realistically enough time and bandwidth to do it. And then there's always the option to acquire more servers, but it's always a bit of a question of whether it's cost-effective to get a new server and license just to automate one thing. And I think the other risk is related to the type of maintenance agreement made for the robots. In my experience, very few organizations build robots themselves; they are usually purchased from another provider. And then, the type of contract you have with that provider is important. And then the implementation, it's critical to identify the areas where the robot can be beneficial. I don't know how well the robotics team, which practically implements it, has insights, but it broadly involves the entire organization. People who do odd, somewhat silly manual tasks might then realize that a robot could handle part of it. Documentation is done properly, and when the documentation exists, then someone other than the original developer can make corrections. Organizational culture was relevant as well because through the culture new ideas and executions can be safely tried. As RPA is relatively new technology some things are still tried for the first time and in these moments, especially because implementing RPA is a complex process, some degree of safety from repercussions if some things will not go as planned is important to the people participating in the RPA project. One aspect of this culture would be the ownership that should stay with the organization even though the team developing the RPA might be a third-party organization. And there should be an open culture where, if something goes wrong, there's no finger-pointing, like 'Hey, this went wrong because of you,' but rather, 'Hey, we can learn something from this,' and then together we figure out what we can learn and hopefully apply it. Then again, what protects us is also a certain pragmatic attitude that a software robot is just code, and there's a reason why something isn't working. So, we fix the code, and then everything starts working again. How can we do things differently and foster a culture of experimentation, so that... if this is still new in some places, let's start experimenting. Let's see what comes of it, and if nothing comes of it, that's okay. We've tried it, and now we know it doesn't suit us. That's definitely one important aspect. A couple of interviewees saw the definition part of the process especially important. Finding reasonable cases for the RPA from a business perspective saves time and resources in a cost-efficient manner. Citizen developers, a newer perspective in the field of RPA where end users are taught to build RPA directly, were seen as an important resource for doing the definition as close to the automated process as possible. 50 Probably going through the tasks team by team. Or thinking about what is done in each team, why things are done the way they are, and if there are any tasks where we could consider having a robot help with certain tasks? Many interviewees had the idea that inside the organization there should be knowledge sharing between teams and groups to better utilize the RPA. The method of sharing varied a little: some wished for workshops where others wished for best practices to be shared in a one-way fashion. Learning from different use cases seemed to lead to better utilization of RPA in different parts of the organization and less effort to make it so. This was seen to have an educative side as well to inform yet passive stakeholders about the possibilities of utilizing the RPA to make automation have better penetration at the organization. Actually, I would hope that our RPA team would hold an information session or something like that where they would explain what robots we currently have in the company. 51 In this chapter the results of the study are discussed and commented on, especially the dynamics between the RPA, technostress and occupational stress. Theoretical contributions and practical implications are reflected upon, and connections to prior literature are drawn. Limitations and suggestions are also brought up for the future researchers to continue from. Lastly some concluding remarks are presented. 5.1 Research contributions This study had a goal of increasing the visibility of the complexity of implementing technology at the workplace and the intertwined nature of different types of stress that a technology at work can cause to the employees using it. Work can be a source of stress, but so can technology, and when the two are combined it seems to create different mechanisms for the stress to form (figure 3). The two pathways can be exemplified. In the pathway 1 the RPA could create technostress through a malfunction (techno-unreliability), which then led to increased workload and decreased control over the situation (occupational stress). In the pathway 2, for example, plans to implement RPA could lead to job insecurity increasing (occupational stress), and this would then act as a technostress creator (techno-insecurity). While the two have been separately studied, there has been little research examining the interaction and dynamics between the two (Dragano & Lunau, 2020). The RPA as a technology is a relatively young technology in their present form, but the use of RPA has been steadily increasing and, in many organizations, there are RPA already implemented or being implemented. Even though the RPA as technology is becoming more widespread there is not that much research about the effects that the RPA has on human beings and the work itself (Venermo et al., 2022). Technostress has been mapped very well in the layer of interaction with the technology (Ragu-Nathan et al., 2008; Salo et al., 2019; Salo et al., 2020; Salo et al., 2022; Siitonen, 2021; Tarafdar et al., 2019; Tarafdar et al., 2013; Tarafdar 5 DISCUSSION 52 et al., 2007; Tarafdar et al., 2010), but the wider context and further reaching dynamics seem to be often missing from the consideration. RPA as a technology itself has some RPA-specific themes to it like the amount of interaction that is expected with the technology. RPA can cause disruptions to work for people not in direct contact with the technology as well. This study had five contributions in total. FIGURE 3 The dynamic between RPA, technostress and occupational stress First, what became apparent from the data was that the technology started to create stress even before it existed in the organization and that the proximity to the RPA caused stress differently in different layers mentioned before. The technostress emerged differently in different phases of the RPA lifecycle. This layered approach to technostress formation is a novel one since most of the studies have been focusing on direct interaction with the technology (Ayyagari et al., 2011; Fischer & Riedl, 2017; Ragu-Nathan et al., 2008; Tarafdar et al., 2007; Tarafdar et al., 2010). Awareness of the technology was enough to create stress for some employees through the fear of losing a job (techno-insecurity) as the technology would replace humans, and this fear was not completely unfounded as became apparent from the interviews although this specific outcome to implementation of RPA as a technology seemed to be rare. Awareness of RPA working as a manager of the work to be done by humans was seen as a stressful experience as well which led into insubordination from the employees. The technical experts on the side of the team responsible for defining, conceptualizing and building the RPA were the ones who faced this uncertainty from the employees at this preliminary stage and had to deal with it. One part of the indirect stress that the technology caused was the increased demand for SMEs time usage through the additional task of mapping out the work process for the technical person. After awareness another layer was the coexistence. Having RPA in the team could cause stress to 53 the team members not in direct relation to the RPA through the disruptions to planned work in the event of RPA malfunction. If the RPA malfunctioned, as in did not do what it was supposed to do, it could lead into a situation where the work that the RPA was supposed to do was distributed to the team to be done, especially if the RPA was responsible for critical processes that had to be done with a tight deadline. Another example is the layoffs that RPA caused. If the RPA had been in use for longer periods of time, rustification of skills needed to conduct the work that was automated might have happened which as well increased the demands for conducting the work as the process had to be relearned for it to be conducted. The layer of use interaction was present in this study as well, usually being strongest during and after the implementation of the RPA. Unclear communication, malfunction in the RPA and difficult interactions between the end users and the technical people behind fixing the RPA were sources of stress. Again, the criticality of the RPA affected the amount of stress that malfunctions generated. Techno-invasions happened as well in the form of text messages received when the RPA was functioning properly and reminding people of the invoices left unchecked. Second, this study contributed to the research by linking different experiences of stress, especially technostress, to the RPA lifecycle. The maturity is closely related to the layers of awareness, coexistence and interaction, but it is not the same thing. For example, the maturity of RPA reflected on the number of malfunctions and exceptions that the RPA encountered. For example, less maturity in the same phase led to more malfunctions which meant more stutters in the work and after a while most malfunctions and exceptions were ironed out which led to less stressful moments. All of that happened in the layer of implementation, or the use of technology. The layer of awareness is linked to the earlier maturity of the technology since at that stage fears of losing a job were still unfounded (and mostly were unfounded at the later stages as well). RPA lifecycle and the different layers are both ways of looking at the stress in a bigger picture rather than just the direct interaction with the technology. Although the study of the organizational mitigation processes did not bring much new to the literature (Hung et al., 2011; Pflügner et al., 2020; Ragu-Nathan et al., 2008; Szalma & Hancock, 2007; Tarafdar et al., 2015; Tarafdar et al., 2011; Tu et al., 2005), it did show that the same kind of mitigation techniques used with other technologies apply to the RPA as well. Different mitigation techniques should be applied in different parts of the RPA lifecycle as well. Especially at the start, to mitigate stress in the awareness phase, clear lines of communication between the developers and end users are important to handle the insecurities that arise through the thought of automation of work. In turn, for example, pre-implementation requires resource allocation for both sides to map out the work process to be automated. After implementation clear roles and responsibilities are important for the smooth functioning of the RPA, as well as technical help and emotional support for the situations where the RPA malfunctions. Third, different stakeholders seemed to experience stress in different ways as well. The stress emerged differently depending on the viewpoint you have on 54 the technology. There have been some studies that take these differing viewpoints on technology into account on stress coping. (Salo et al., 2020). This study however argues that there might be different experiences of stress as well depending on the perspective you have on the technology. A division to end users and technical expert perspectives was made to handle the stress on the different sides of the continuum. The end user perspective is more concerned about the flow of the work and to be able to think the RPA as little as possible. This involves trusting the technology as well. The technical stakeholders are more concerned about the functionality of the RPA and that it benefits the end users as much as possible without too many troubles. End users felt, for example, techno-insecurity and increased workload/demand in events of RPA malfunction whereas technical experts had to face difficult emotions, strained interactions with the end users and ethical stress from building RPA that would work for the end users. Fourth, some characteristics of RPA became visible through our findings. Although some studies have been conducted on human-RPA interaction and the characteristics of the technology involved, these findings add new understanding to the literature (Ayyagari et al., 2011; Siitonen, 2021; Venermo et al., 2022). Criticality of the RPA modulates the amount of stress felt. Rustification of competence in the team through the loss of ability to quickly perform tasks that were automated is another one. Technological dependence on other systems is also something that is strongly related to RPA as a technology as RPA cannot function by itself, it needs to operate in target systems and so the stability of the target systems and access authorization to them are important to consider. The contact with RPA is also very limited in normal cases as they are designed to be automation in the purest form, so in comparison with many other technologies, the less you must deal with the RPA the better. RPA as a technology does not try to be used in direct interaction with the organizational members at least in the unattended form. The working days were made more intense in some cases through the adoption of the RPA as well which is an interesting look on how technology might affect us. This is one way to link technology with the broader job stress literature as well (Mauno et al., 2023). Finally, looking at how technostress and occupational stress intermix is yet another contribution in this study. Some effort has been put into looking at the two classes of stress together (Bondanini et al., 2020), but there is room for more findings. Our findings implicate that RPA causes stress directly, but also indirectly through the effect it has on occupational stress like increasing demands of the job (control-demand-theory, job resources and demands) (Karasek & Theorell, 1990; Schaufeli, & Bakker, 2004), increasing the effort required to do a job (effortreward imbalance) (Siegrist, 1996), creating tasks that feel like hindrances (Cavanaugh et al., 2000; Podsakoff et al., 2007) and causing disruptions in the flow of work for everyone affected for example in the events of malfunction. Developers’ viewpoint on technical stress is one way to connect technology with technostress and occupational stress, but also a good example of the difficulty of making distinctions (Selart & Johansen, 2011; Ulrich et al., 2007). All of the stress experiences mentioned in the study are not directly technostress-related, but 55 without the existence of the technology those experiences would not exist either. Some new possible technostress creators were also identified, like techno-rustification and techno-intensification. Rustification refers to the loss of skills due to automation which leads to higher stress load in events of malfunction whereas techno-intensification refers to more intense working days when the easier tasks have been automated. Technology seems to be able to produce stress directly, but also through subtle interactions and dynamics that indirectly cause stress as well. 5.2 Practical implications The main practical contribution of this study is to widen the understanding on how exactly the technology we employ at work causes stress from different points of view and from different relational distances to the technology. Even being aware of the future plans of implementing automation technology at the organization has the potential to start causing stress to the people who are thought to be near the technology. Even in the planning phase the technology starts to cause stress in different ways, depending on your perspective. Traditionally the technostress literature considers only the direct interaction with the technology, but the ripple effects of the stress can be seen to have effect further away than just in the direct interaction interface. The stress also takes different forms in different stages of the RPA lifecycle. The perspective you have, whether it is a developer/designer one or end user one, causes different kinds of stress in different phases of the RPA lifecycle as well. Taking this into consideration in the implementation process would benefit the employees that undergo the adoption of RPA and through that the organization as well since lesser stress has wellbeing benefits for the employees of the organization. The key here seems to be opening lines of communication as early as possible and involving the team that is targeted for automation in the process without just being thrown into the situation without prior knowledge. There are some RPA specific technological characteristics that are important to note which could help developers and designers make better RPA for the end users. One is the minimal interaction that is the expectation with RPA as a technology, and the more interaction happens, the more it relates to the RPA malfunctioning in some way that is both a technostressor and an occupational stressor. In the events of malfunction clear communication from the RPA to the organizational members on what went wrong is important. The availability of technical help is also an important factor. Other characteristics of RPA include the rustification of skills needed to conduct the process that was automated with RPA in the first place. Rustification makes the team using RPA more vulnerable to other types of stress in the event of malfunction since it causes the rapid need to relearn the automated process which is an additional task for the end user. Taking rustification into account by the organization implementing RPA would make working during malfunction events more efficient. Documentation of the automated work process seems to be important here in order to minimize the 56 harm that is caused. Considering that RPA has the possibility of increasing intensification of work is important for the continued wellbeing of employees. Modifying work to counterbalance this effect could have preventative effects that benefit the organization. The organizational mitigation techniques that this study brought up were in line with prior research. However, it is beneficial to know that RPA technology does not seem to differ in that sense from many other technologies. End users require support for the use, especially in the event of malfunction, and the technical people working around the RPA require the share of best practices and enough resources to meet the challenges that malfunctioning RPA might cause. By planning for this in the early stages of adopting RPA to the team the organization can mitigate a lot of the stress felt by the different stakeholders and ease, in part, the overall stress load that the organizational members experience. Knowledge transfer and sharing inside other organization about the ways in which automation could be used seemed to be especially helpful for many. 5.3 Limitations and future topics This study has several limitations to consider. First, stress is a multilevel phenomenon with different sources, effects and outcomes on human beings. Interviews may lead to loss of subjective information about stress (Kopp et al., 2010). Although interviewing is one of the appropriate ways to capture subjective experience of stress, interviewing does have problems as a data gathering method as well. Eliciting for example is a skill and the data can be as good as the questions that have been asked from the interviewee (Myers, 2020). Listening is another skill needed in quality data gathering through interviews as through listening the interviewer is able to spot the important parts of what is being said and direct the discussion towards the most important parts through intelligent questions (Chrzanowska, 2002). Second, separating occupational stress from the technostress is a real challenge, and sometimes artificial as well. For example, when RPA malfunctions, it is a technostressor when the technology does not work as intended, but at the same time causes disruptions in planning of work and causes tighter deadlines which can be counted as occupational stressors as well. Third, most interviewees experienced RPA in a positive light whereas we tried to capture the negative experiences of stress that it may cause. Exploring the theme of RPA in a more balanced manner could capture the stress experience that RPA causes in a more holistic way. Fourth, our study only included Finnish participants and so represents a narrow population in that sense. There could be some differences in how the RPA is applied or how mature the processes for adopting RPA are in different countries. Fifth, our study data included unattended RPA in majority and as such only represents the challenges and hindrances that come with that kind of application of the technology. Attended RPA could have different mechanisms and characteristics through which stress experience happens. Sixth, more occupational stress theories could be considered when studying the 57 interaction between technostress and occupational stress. Finally, our study did try to link technostress and occupational stress to the broader context of overall stress load, but other measuring methods like physiological measurements or questionnaires were left out and as such the data gathered represents only a narrow view of the stress in general. Seventhly, the small sample sizes could be prone to biases, for example choosing organizations where there is particularly large amount of problems with the functionality of the RPA. Future possibilities for research are possible through our findings. First, the different stakeholders that experience the stress in the same situations in different ways could be one future study direction. The layers of stress in which the stress is generated in combination with the perspectives could add a complex understanding of the phenomena. Applying the layered viewpoint approach to other technologies could be fruitful in generating new understanding on how technology affects us as human beings. Second, adding more occupational stress theories to the mix to be used as lenses through which the interaction with technostress is observed has the potential to add to the research. There are many more occupational stress theories that are not covered by this research. Thirdly, mixing other methods for capturing the stress and the subjective experience of it has the potential to increase our understanding of the stress. Finally, the RPA itself is an ever-evolving field and this study only captured the present state in which the field of RPA was in during the study. More research should be applied to the RPA technology itself. Building different kind of RPA to help users and studying them in more controlled environment, while synthetic in setting, would add to the understanding on what characteristics of RPA generate stress and how they differ in different forms of RPA. 64 Kedziora, D., & Penttinen, E. (2021). Governance models for robotic process automation: The case of Nordea Bank. Journal of Information Technology Teaching Cases, 11(1), 20-29. Kelliher, C., & Anderson, D. (2010). Doing more with less? Flexible working practices and the intensification of work. Human Relations, 63(1), 83-106. Kivimäki, M., Vartia-Väänänen, M., Elovainio, M., Vahtera, J. & Virtanen, M. (2000). Työpaikkakiusaaminen ja sairauspoissaolot sairaalahenkilöstön keskuudessa. Yhteiskuntapolitiikka, 65(4), 327-331. Kivimäki, M., Virtanen, M., Vartia, M., Elovainio, M., Vahtera, J., & KeltikangasJärvinen, L. (2003). Workplace bullying and the risk of cardiovascular disease and depression. Occupational and Environmental Medicine, 60(10), 779-783. Kopp, M. S., Thege, B. K., Balog, P., Stauder, A., Salavecz, G., Rózsa, S., Purebl, G. & Ádám, S. (2010). Measures of stress in epidemiological research. Journal of Psychosomatic Research, 69(2), 211-225. Kykyri, V. L., Karvonen, A., Wahlström, J., Kaartinen, J., Penttonen, M., & Seikkula, J. (2017). Soft prosody and embodied attunement in therapeutic interaction: A multimethod case study of a moment of change. Journal of Constructivist Psychology, 30(3), 211-234. La Torre, G., Esposito, A., Sciarra, I. & Chiappetta, M. (2018). Definition, symptoms and risk of techno-stress: A systematic review. International Archives of Occupational and Environmental Health, 92(1), 13-35. Lampi, A., Venermo, K., Salo, M., & Pirkkalainen, H. (2022). “It is better than working with a person”: Affective cues and responses to robots at work. In P. Bednar, A. S. Islind, H. Vallo-Hult, A. Nolte, M. Rajanen, F. Zaghloul, A. Ravarini, & A. M. Braccini (Eds.), Proceedings of the 8th International Workshop on Socio-Technical Perspective in Information Systems Development (STPIS 2022), Reykjavik, Iceland (208-221). Lathers, C. M., & Schraeder, P. L. (2006). Stress and sudden death. Epilepsy & Behavior, 9(2), 236-242. Lazarus, R. S. (1966). Some principles of psychological stress and their relation to dentistry. Journal of Dental Research, 45(6), 1620-1626. Lazarus, R. S. (1971). The concepts of stress and disease. Society, stress and disease, 1, 53-58. London: Oxford University. Lazarus, R. S., & Folkman, S. (1984). Stress, appraisal, and coping. New York: Springer publishing company. Le Fevre, M., Matheny, J., & Kolt, G. S. (2003). Eustress, distress, and interpretation in occupational stress. Journal of Managerial Psychology, 18(7), 726-744. 65 Logan, J. G., & Barksdale, D. J. (2008). Allostasis and allostatic load: expanding the discourse on stress and cardiovascular disease. Journal of Clinical Nursing, 17(7b), 201-208. Lune, H., & Berg, B. L. (2017). Qualitative research methods for the social sciences. England: Pearson. Maier, C., Laumer, S., Eckhardt, A. & Weitzel, T. (2015). Giving too much social support: Social overload on social networking sites. European Journal of Information Systems, 24(5), 447-464. Makkonen, M., Salo M. & Pirkkalainen H. (2022). What makes a (ro)bot smart? Examining the antecedents of perceived intelligence in the context of using physical robots, software robots, and chatbots at work. The 14th Mediterranean Conference on Information Systems (MCIS). Catanzaro, Italy, October 14-15, 2022. Maslach, C., & Leiter, M. P. (2016). Understanding the burnout experience: recent research and its implications for psychiatry. World Psychiatry, 15(2), 103-111. Mauno, S., Herttalampi, M., Minkkinen, J., Feldt, T., & Kubicek, B. (2023). Is work intensification bad for employees? A review of outcomes for employees over the last two decades. Work & Stress, 37(1), 100-125. McCrae, R. R., & Costa Jr, P. T. (1986). Personality, coping, and coping effectiveness in an adult sample. Journal of Personality, 54(2), 385-404. McCrae, R. R., Costa Jr, P. T., & Busch, C. M. (1986). Evaluating comprehensiveness in personality systems: The California Q‐Set and the five‐factor model. Journal of Personality, 54(2), 430-446. McDowell, I. (2010). Measures of self-perceived well-being. Journal of Psychosomatic Research, 69(1), 69-79. McEwen, B. S. (2002). Sex, stress and the hippocampus: allostasis, allostatic load and the aging process. Neurobiology of Aging, 23(5), 921-939. McEwen, B. S., & Seeman, T. (1999). Protective and Damaging Effects of Mediators of Stress: Elaborating and Testing the Concepts of Allostasis and Allostatic Load. Annals of the New York Academy of Sciences, 896(1), 3047. Melville, N., Kraemer, K., & Gurbaxani, V. (2004). Information technology and organizational performance: An integrative model of IT business value. MIS Quarterly, 28(2), 283-322 Mendling, J., Decker, G., Hull, R., Reijers, H. A., & Weber, I. (2018). How do machine learning, robotic process automation, and blockchains affect the human factor in business process management?. Communications of the Association for Information Systems, 43(1), 19. 66 Moffitt, K. C., Rozario, A. M., & Vasarhelyi, M. A. (2018). Robotic process automation for auditing. Journal of Emerging Technologies in Accounting, 15(1), 1-10. Moore, J. E. (2000). One road to turnover: An examination of work exhaustion in technology professionals. MIS Quarterly, 24(1), 141-168. Mourey, J. A., Olson, J. G., & Yoon, C. (2017). Products as Pals: engaging with anthropomorphic products mitigates the effects of social exclusion. Journal of Consumer Research, 44(2), 414–431. Myers, M. D. (2020). Qualitative research in business & management (Third edition.). California, USA: SAGE Publications Ltd. Myers, M. D., & Newman, M. (2007). The qualitative interview in IS research: Examining the craft. Information and Organization, 17(1), 2-26. Nieuwenhuijsen, K., Bruinvels, D., & Frings-Dresen, M. (2010). Psychosocial work environment and stress-related disorders, a systematic review. Occupational Medicine, 60(4), 277-286. Noble, R. E. (2002). Diagnosis of stress. Metabolism-Clinical and Experimental, 51(6), 37-39. Paluch, S., Tuzovic, S., Holz, H. F., Kies, A., & Jörling, M. (2022). “My colleague is a robot”– exploring frontline employees' willingness to work with collaborative service robots. Journal of Service Management, 33(2) 363–388. Patton, M. Q. (1990). Qualitative evaluation and research methods. Los Angeles: SAGE Publications. Patton, M. Q. (2014). Qualitative research & evaluation methods. Los Angeles: SAGE Publications. Pearlin, L. I., Menaghan, E. G., Lieberman, M. A., & Mullan, J. T. (1981). The stress process. Journal of Health and Social Behavior, 337-356. Pentland, B. T. (1999). Building process theory with narrative: From description to explanation. Academy of Management Review, 24(4), 711-724. Pflügner, K., Reis, L., Maier, C. & Weitzel, T. (2020). Communication Measures to Reduce Techno-Invasion and Techno-Overload: A Qualitative Study Uncovering Positive and Adverse Effects. Proceedings of the Computers and People Research Conference, 114-122 Pirkkalainen, H., Salo, M., Tarafdar, M., & Makkonen, M. (2019). Deliberate or instinctive? Proactive and reactive coping for technostress. Journal of Management Information Systems, 36(4), 1179-1212. Podsakoff, N. P., LePine, J. A., & LePine, M. A. (2007). Differential challenge stressor-hindrance stressor relationships with job attitudes, turnover intentions, turnover, and withdrawal behavior: a meta-analysis. Journal of Applied Psychology, 92(2), 438. 67 Qiu, L., & Benbasat, I. (2009). Evaluating anthropomorphic product recommendation agents: a social relationship perspective to designing information systems. Journal of Management Information Systems, 25(4), 145– 181. Quick, J. C., & Spielberger, C. D. (1994). Walter Bradford Cannon: pioneer of stress research. International Journal of Stress Management, 1(2), 141-143. Ragu-Nathan, T. S., Tarafdar, M., Ragu-Nathan, B. S., & Tu, Q. (2008). The consequences of technostress for end users in organizations: Conceptual development and empirical validation. Information Systems Research, 19(4), 417-433. Riedl, R., Kindermann, H., Auinger, A., & Javor, A. (2012). Technostress from a neurobiological perspective. Business & Information Systems Engineering, 4(2), 61-69. Salanova, M., Llorens, S., & Cifre, E. (2013). The dark side of technologies: Technostress among users of information and communication technologies. International Journal of Psychology, 48(3), 422-436. Salo, M., Makkonen, M., & Hekkala, R. (2020). The interplay of IT users’ coping strategies: uncovering momentary emotional load, routes, and sequences. MIS Quarterly, 44(3). Salo, M., Pirkkalainen, H., & Koskelainen, T. (2019). Technostress and social networking services: Explaining users' concentration, sleep, identity, and social relation problems. Information Systems Journal, 29(2), 408-435. Salo, M., Pirkkalainen, H., Chua, C. E. H. & Koskelainen, T. (2022). Formation and Mitigation of Technostress in the Personal Use of IT. MIS Quarterly, 46(2), 1073. Santos, F., Pereira, R., & Vasconcelos, J. B. (2020). Toward robotic process automation implementation: an end-to-end perspective. Business Process Management Journal, 26(2), 405-420. Schachter, S., & Singer, J. (1962). Cognitive, social, and physiological determinants of emotional state. Psychological Review, 69(5), 379. Schaufeli, W. B., & Bakker, A. B. (2004). Job demands, job resources, and their relationship with burnout and engagement: A multi‐sample study. Journal of Organizational Behavior 25(3), 293-315. Schwarz, A., Chin, W. W., Hirschheim, R., & Schwarz, C. (2014). Toward a process-based view of information technology acceptance. Journal of Information Technology, 29(1), 73-96. Seiffer, A., Gnewuch, U. & Maedche, A. (2021). Understanding Employee Responses to Software Robots: A Systematic Literature Review. The Proceedings of the 42nd International Conference on Information Systems (ICIS). Austin, Texas, USA, , December 12-15, 2021. 68 Selart, M., & Johansen, S. T. (2011). Ethical decision making in organizations: The role of leadership stress. Journal of Business Ethics, 99, 129-143. Selye, H. (1950). Stress and the general adaptation syndrome. British Medical Journal, 1(4667), 1383. Selye, H. (1956). The stress of life. New York: McGraw-Hill. Servoz, M. (2019). AI, the future of work? : work of the future! : on how artificial intelligence, robotics and automation are transforming jobs and the economy in Europe. European Commission, European Political Strategy Centre: Publications Office. Retrieved from (29.1.2024) https://data.europa.eu/doi/10.2872/913422. Shu, Q., Tu, Q. & Wang, K. (2011). The impact of computer self-efficacy and technology dependence on computer-related technostress: A social cognitive theory perspective. International Journal of Human-Computer Interaction, 27(10), 923-939. Siegrist, J. (1996). Adverse health effects of high-effort/low-reward conditions. Journal of Occupational Health Psychology, 1(1), 27. Siitonen, V. (2021). Work-based use of Smart Personal Assistants and their impact on technostress (Master’s Thesis). University of Jyvaskylä. Retrieved from http://urn.fi/URN:NBN:fi:jyu-202106023390 Sinokki, M., Hinkka, K., Ahola, K., Gould, R., Puukka, P., Lönnqvist, J., & Virtanen, M. (2010). Social support as a predictor of disability pension: the Finnish Health 2000 study. Journal of Occupational and Environmental Medicine, 733-739. Sinokki, M., Hinkka, K., Ahola, K., Koskinen, S., Kivimäki, M., Honkonen, T., Puukka, P., Klaukka, T., Lönnqvist, J. & Virtanen, M. (2009). The association of social support at work and in private life with mental health and antidepressant use: the Health 2000 Study. Journal of Affective Disorders, 115(1-2), 36-45. Smith, M. J., Conway, F. T., & Karsh, B. T. (1999). Occupational stress in human computer interaction. Industrial Health, 37(2), 157-173. Srivastava, S. C., Chandra, S., & Shirish, A. (2015). Technostress creators and job outcomes: theorising the moderating influence of personality traits. Information Systems Journal, 25(4), 355-401. Stock, R. M. (2015). Is boreout a threat to frontline employees' innovative work behavior?. Journal of Product Innovation Management, 32(4), 574-592. Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T. & Reijers, H. A. (2020). Robotic process automation: contemporary themes and challenges. Computers in Industry, 115, 103162. 69 Szalma, J. L., & Hancock, P. (2007). Task loading and stress in human-computer interaction: Theoretical frameworks and mitigation strategies. In The Human-Computer Interaction Handbook (pp. 141-158). Florida, USA: CRC Press. Tams, S., Thatcher, J. & Grover, V. (2018). Concentration, competence, confidence, and capture: An experimental study of age, interruption-based technostress and task performance. Journal of the Association for Information Systems, 19(9), 857-908. Tarafdar, M., Cooper, C. L., & Stich, J. F. (2019). The technostress trifecta‐ techno eustress, techno distress and design: Theoretical directions and an agenda for research. Information Systems Journal, 29(1), 6-42. Tarafdar, M., Gupta, A. & Turel, O. (2013). The dark side of information technology use. Information Systems Journal, 23(3), 269-275. Tarafdar, M., Pirkkalainen, H., Salo, M., & Makkonen, M. (2020). Taking on the "Dark Side"--Coping With Technostress. IT Professional, 22(6), 82-89. Tarafdar, M., Pullins, E. B., & Ragu‐Nathan, T. S. (2015). Technostress: negative effect on performance and possible mitigations. Information Systems Journal, 25(2), 103-132. Tarafdar, M., Tu, Q., & Ragu-Nathan, T. S. (2010). Impact of Technostress on End-User Satisfaction and Performance. Journal of Management Information Systems, 27(3), 303-334. Tarafdar, M., Tu, Q., Ragu-Nathan, B. S., & Ragu-Nathan, T. S. (2007). The Impact of Technostress on Role Stress and Productivity. Journal of Management Information Systems, 24(1), 301–328. Tarafdar, M., Tu, Q., Ragu-Nathan, T. S., & Ragu-Nathan, B. S. (2011). Crossing to the dark side: examining creators, outcomes, and inhibitors of technostress. Communications of the ACM, 54(9), 113-120. Taylor, S. E. (2010). Mechanisms linking early life stress to adult health outcomes. Proceedings of the National Academy of Sciences, 107(19), 85078512. Theorell, T., Orth-Gomér, K., & Eneroth, P. (1990). Slow-reacting immunoglobulin in relation to social support and changes in job strain: a preliminary note. Psychosomatic Medicine, 52(5), 511–516 Touré-Tillery, M., & McGill, A. L. (2015). Who or What to Believe: Trust and the Differential Persuasiveness of Human and Anthropomorphized Messengers. Journal of Marketing, 79(4), 94-110. Tu, Q., Tarafdar, M., Ragu-Nathan, T. S., & Ragu-Nathan, B. S. (2008). Improving end-user satisfaction through techno-stress prevention: some empirical evidences. American Conference on Information Systems (AMCIS) 2008 Proceedings, 236. 70 Tu, Q., Wang, K., & Shu, Q. (2005). Computer-related technostress in China. Communications of the ACM, 48(4), 77-81. Ulrich, C., O’donnell, P., Taylor, C., Farrar, A., Danis, M., & Grady, C. (2007). Ethical climate, ethics stress, and the job satisfaction of nurses and social workers in the United States. Social Science & Medicine, 65(8), 1708-1719. Van der Aalst, W. M., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269-272. Van der Heijden, H. (2012). User acceptance of electronic commerce: contributions from the Bled eConference. BLED 2012, Special Issue, Paper 11. Van Veldhoven, M. (2014). Quantitative job demands. In M. Peeters, J. De Jonge, & T. Taris (Eds.), An introduction to contemporary work psychology (117–143). New Jersey, USA: Wiley-Blackwell Venermo, K., Lampi, A., Salo, M. & Pirkkalainen, H. (2022). Employees’ challenges and needs for reskilling when working with software robots. The 14th Mediterranean Conference on Information Systems (MCIS), Catanzaro, Italy, October 14-15, 2022. Waizenegger, L., & Techatassanasoontorn, A. A. (2022). When robots join our team: A configuration theory of employees’ perceptions of and reactions to Robotic Process Automation. Australasian Journal of Information Systems, 26. Waytz, A., Heafner, J., & Epley, N. (2014). The mind in the machine: anthropomorphism increases trust in an autonomous vehicle. Journal of Experimental Social Psychology, 52, 113–117. Wewerka, J., & Reichert, M. (2023). Robotic process automation-a systematic mapping study and classification framework. Enterprise Information Systems, 17(2), 1986862. World Economic Forum (2020). The Future of Jobs Report 2020. Retrieved from (5.8.2023) http://www3.weforum.org/docs/WEF_Future_of_Jobs_2020 World Health Organization. (2022). Mental Health. Retrieved from (5.8.2023) https://www.who.int/health-topics/mental-health#tab=tab_2 World Health Organization. (2023). Stress. Retrieved from (10.8.2024) https://www.who.int/news-room/questions-and-answers/item/stress Yam, K. C., Tang, P. M., Jackson, J. C., Su, R., & Gray, K. (2023). The rise of robots increases job insecurity and maladaptive workplace behaviors: Multimethod evidence. Journal of Applied Psychology, 108(5), 850. Zapf, D., Semmer, N., & Johnson, S. (2014). Qualitative demands at work. In M. Peeters, J. De Jonge, & T. Taris (Eds.), An introduction to contemporary work psychology (144–169). New Jersey, USA: Wiley-Blackwell. 71 APPENDIX 1 EXAMPLE INTERVIEW QUESTIONS Introduction Introduction, purpose of the study, removal of personal and direct identification information from responses, background information form check, permission to record Background Can you start by telling me about yourself and your work? What is your job description like? What kind of tasks does your work include? Experience with RPA To what extent are you involved with Robotic Process Automation at work? How has Robotic Process Automation started to appear in your own work? How does Robotic Process Automation affect your own work? Stress experiences with RPA What concerns do you have related to the tasks involving Robotic Process Automation? What kind of possible strain does Robotic Process Automation cause in you? What feelings or bodily sensations have you experienced in stressful situations? How have these stressful situations reflected in your work? How does the use of Robotic Process Automation affect the stress you experience at work? Characteristics of RPA What Robotic Process Automation features cause you the most strain? What Robotic Process Automation features benefit you the most in your work? What Robotic Process Automation features protect you from strain or relieve you from strain? Mitigation of stress How has the organization protected employees from the strain caused by Robotic Process Automation? What do you think the organization could do more to protect against strain? What benefits do you see automation/robotics bringing to the organization? Conclusion Is there anything else you would like to say or that comes to mind that was not mentioned earlier? Any other interviewees you know that work with Robotic Process Automation?