Software development is a fast-growing market that is heavily tied to information technology (IT) use. Despite the high utilization of IT and high stress levels of software developers, research has largely neglected the effect of IT use on stress experienced by software developers. To address this gap in the research, we employ the concept of technostress. Prior technostress research has found many technostress-creating factors that cause severe negative consequences for both organizations and their employees. Despite these advancements, little is known about how technostress emerges in different organizational contexts and the underlying factors behind the technostress creators in these contexts. We conducted a qualitative study using the critical incident technique to uncover these factors and relevant technostress creators in the context of software development. We utilized a questionnaire with open-ended and closed-ended questions to collect descriptions of technostress experiences from 406 software developers. The current research identifies 21 influencing factors and 10 technostress creators to be relevant in software development, hence contributing to the technostress literature. We also contribute to software development research by explaining how the use of IT contributes to the stress experienced by software developers.
Software development is an important aspect of modern technology-driven business and is quickly
becoming one of the biggest markets in the world [
The ever-increasing focus on IT use has sparked a light on the plethora of negative aspects of IT use
in organizations including constant availability, hard-to-use technologies, and the fast pace of
technological change [
1); saima.e.ritonummi@student.jyu.fi (A.
2); (A. 3);
2022 Copyright for this paper by its authors.
encounter the highest levels of occupational stress compared with other occupations [
Despite the high utilization of IT, need for extensive technical knowledge, and high stress levels of
software developers [
We conducted a qualitative study using the critical incident technique (CIT) [18] to build an understanding of technostress in the context of software development. The CIT is a research method for data collection and analysis to understand human behavior through critical events from the perspective of the respondent [18, 19]. We used the CIT to bring forth the voice of the respondents and understand the software developers’ technostress experiences as described in their own words [19]. We collected 406 critical incident descriptions from those working in software development utilizing an online questionnaire with open-ended and closed-ended questions. Based on our findings, software developers experience technostress caused by multiple technostress creators, such as techno-overload, techno-uncertainty, and technology malfunctions. Some of the underlying factors in the IT use environment affecting technostressors are, for example, poor documentation, merge conflicts, and multitasking.
Our research contributes to both the technostress and software development literature. When it comes to the technostress literature, our study introduces the emergence of technostress in a previously unmapped context. We identify the relevant technostressors, such as techno-complexity and technouncertainty, and their underlying factors, in the context of software development, which broadens the understanding of these technostressors in different contexts of IT use [e.g., 4, 5, 8, 20]. By addressing the underlying factors affecting the technostressors, we contribute to an area of technostress research which has often been left uninvestigated in prior work [17]. Regarding the software development literature, our study begins to explain how the use of IT contributes to the high stress levels experienced by software developers. As a practical implication, our study recognizes technostress-creating IT use practices, suggesting actions to take to avoid them in software development work.
Lazarus and Folkman define stress as a “relationship between the person and the environment that is appraised by the person as taxing or exceeding his or her resources and endangering his or her wellbeing” [21 p. 19]. In other words, both the imbalance between an individual and their surroundings and the individual’s interpretations of what they find taxing affect whether an individual finds a particular event stressful or not [22]. This definition follows the transactional view of stress introduced in the field of psychology. Following the transactional view of stress, two important concepts can be realized: stressors and strains. Stressors are those factors causing stress to an individual, and strains are the consequences or outcomes of the stressors [21, 22]. It is important to note that stress is a highly subjective experience, and two individuals can perceive the same situation in different ways, seeing it as either negative stress (distress) or positive stress (eustress) [23, 24, 25]. In the current study, we focus on negative stress (distress) because of its harmful consequences on those working with IT in the organizational context [e.g., 4, 9, 26, 27]. 2.1.
Technostress is defined as stress caused by the use of IT [
Techno-overload refers to situations in which users must work harder and longer because of the
demands imposed by IT use [27]. IT professionals have been found to experience overload caused by
IT use for multiple reasons, including multitasking, productivity demands, and information load [
The hectic and unpredictable work environment can introduce a feeling of techno-invasion. The line
between work and free time can become blurry because of both the pressure of constant availability and
work IT making its way into the daily lives of employees [27, 32]. Thus, maintaining the distinction
between a work role and family role can become increasingly difficult, leading to increased turnover
intention and burnout [33]. This pressure of conflicting demands between work and family, which has
only been exacerbated by the growing ease of working from home and IT use, can also introduce stress
caused by work–home conflict [
The constant change in IT has introduced its own problems to employees in organizations. The constant change and learning of new IT can create techno-uncertainty among users, making them hesitant about learning and using new IT. With the constant introduction of new IT, learned skills can become obsolete and make users feel frustrated and anxious [30]. Learning new IT can also take a significant amount of time and feel increasingly complex and difficult [31]. The difficulty of using and learning IT is referred to as techno-complexity [27]. Complexity can make employees feel inadequate and question their skills in using IT, leading to frustration and helplessness. IT professionals have also been found to experience technostress caused by techno-insecurity. Here, techno-insecurity refers to one’s fear of losing their job because of being replaced by more skilled IT users [30].
IT malfunctions have been found to cause technostress through systems breakdowns and
unreliability [
IT use has increased the number of interruptions users encounter in their work and interruptions
have been connected to technostressors such as techno-overload [
Finally, the use of IT has been connected to role stress caused by role ambiguity [
Technostress can have many adverse consequences (strains) which can be either behavioral,
psychological, or physiological [22]. The behavioral strains found in previous technostress research
include, for example, absenteeism, turnover, and decreased use intention [
Software development is often considered a hectic area of work with tight schedules, changing
requirements, and a need for deep technical knowledge [
Rajeswari and Anantharaman [
Other studies have also found developers experiencing stress because of overload caused by high
workloads or difficulties balancing the demands of work and family [
Software development work is highly subject to change and, thus, requires the ability to adapt to and
tolerate change [
Software development can also be highly subject to interruptions that cause delays in one’s
workflow. Dealing with interruptions has been found to be an issue inside software development teams
[
With large, complex projects, software developers can also be required to perform different tasks
and roles. Winderler, Maurping, and Venkatesh [
Occupational stress experienced by software developers has been connected to a variety of adverse
outcomes for both developers and organizations. Sonnentag et al. [
In summary, only a few connections to IT use have been made in the occupational stress literature among software developers. To the best of our knowledge, there is no research employing the concept of technostress in the context of software development. With the high utilization of IT in software development work, it is important to consider the effects of IT use on stress as experienced by those working in software development. Next, we present the design and results of our CIT study to identify the key technostressors and underlying factors affecting the emergence of these technostressors.
We needed rich data to understand the emergence of technostress in software development work.
Thus, we used the CIT to collect self-reported descriptions of the technostress experienced by software
developers in their work. The CIT is a qualitative research method that consists of “a set of procedures”
for collecting and analyzing human behavior through critical incidents as reported by participants [18
p. 327]. The CIT is based on inspecting the phenomenon from the respondent’s perspective, giving the
respondent the freedom to decide the incident they feel is the most relevant for the phenomenon under
interest [19]. Hence, in the current study, the CIT allowed the developers to bring forth their real-life
experiences for an in-depth understanding of the phenomenon without restricting them to a specific
framework or terminology [
We collected our data via an online questionnaire that included both open-ended questions to
describe the critical stressful incident in detail and closed-ended questions to further evaluate the impact
and outcomes of the incident. Adapting the formatting used in previous CIT studies [e.g., 59, 63, 66],
we asked the respondents to recall “an exceptionally burdensome/stressful experience related to the use
of technology or software in their work.” We instructed the respondents to take their time when recalling
the incident so as to increase the accuracy of the incident descriptions and minimize recall bias [
In the first phase of data collection, we created a pilot study in which we contacted software development organizations both in Finland and internationally. We asked the organizations to distribute the questionnaire to their software developers. In total, we received 63 full responses. The pilot study was conducted between December 2021 and February 2022. The respondents were able to answer the questionnaire in both Finnish and English. Based on the pilot study, the quality and detail of the incident descriptions were redeemed sufficient. Only minor changes to the questionnaire were made when moving to the next phase of data collection.
Primary data collection was conducted using the online research platform Prolific between March 2022 and April 2022. Online research platforms such as Prolific have been found to be useful in collecting reliable data in large quantities [see 67, 68]. We used the prescreening criteria provided by Prolific to gather data from those working in the software-intensive industry sector2, including software, information services, and video games. Respondents fulfilling the prescreening criteria were able to answer the questionnaire on a first come, first served basis. To identify those working in software development, we asked the respondents to describe their role in the industry and their job titles. To enhance the quality of the responses, we used two attention check questions, as suggested by Prolific, to ensure that the respondents understood what they were being asked in the questionnaire. We also set criteria to accept only responses from those with an approval rate of 97 or higher and a minimum of 20 previous submissions on the platform.
In total, we received 447 responses (including responses from the pilot study) from those working
in software development of which 406 were included in the final sample (the exclusion criteria are
discussed in the following section). Of those included in the sample, 312 were men, 89 were female,
four were other genders, and one preferred not to disclose their gender. The age range of the sample
was between 18 and 73 years old, with an average age of 31 years. In total, 39 different nationalities
were present in the data, with the most common being Portuguese (n=64), Finnish (n=59), British
(n=35), Polish (n=32), Italian (n=29), and South African (n=27). Of the 406 respondents, 327 reported
having a bachelor's degree or higher. Most respondents (84.7%) were working full- or part-time
software development jobs in an organization. Some (9.6%) were working as freelancers or
entrepreneurs in software development, and some (4.9%) were primarily students, with most of them
having part-time employment in a software development organization. A summary of the respondents’
background information is presented in Table 1.
2 The data collection was done as a part of a larger inquiry focusing on those working in the area of software intensive industry. Software
intensive industry can be defined as the area of industry in which the dependability, utilization, and rate of change of software is high [
When going through the incident descriptions, we used a content analysis approach in our analysis.
We adapted the suggestions for content analysis presented by Berg [
In the first phase of analysis, two of the authors read through the data to identify incident descriptions to be included in the final data sample. In practice, this was done by going through the data and establishing possible exclusion criteria. For an incident description to be included in the final sample, it had to include a clear description of the incident, with sufficient detail of what happened and why it was critical [19]. Thus, 17 incident descriptions were excluded because of the reported strain being either “fairly low” or “very low” (on a 5-point scale), and four were excluded because of overall insufficient incident descriptions3. Additionally, the incident had to be relevant to the context of our study, namely, the use of IT in the context of software development work. Thus, 15 incident descriptions were excluded because of the incident not involving the use of IT and five because of the incident not being related to the work context. In total, 41 incident descriptions were excluded from the analysis. This left us with 406 out of 447 incident descriptions to be analyzed in the final stage.
In the second phase of our analysis, one of the authors went through the incident descriptions to identify the potential factors affecting the emergence of technostressors in software development work. In practice, one of the authors went through 100 incident descriptions, forming preliminary data-driven categories utilizing open coding. Open coding was utilized as different factors can appear as threatening depending on the environment that the individual operates in [24] and only using codes from prior research could have limited our ability to uncover the factors specific to software development. The categories were then labeled based on the factors identified in the IT use environment that emerged from the data. For example, incidents describing issues with using IT caused by documentation were put under a category labeled as “poor documentation”. Labels from prior research were also used if the results included similar findings. For example, incidents describing software crashes and hardware failures were put under a category labeled “system breakdowns” [present in e.g., 34].
After this, the data were reread by the same author, during which all the incident descriptions were
coded into the established preliminary categories. During the coding process, we constantly compared
the new findings to our established categories to verify the categories [
Finally, the established categories of factors were compared with each other and with findings from
prior research to link the factors to different technostress creators [
In the closed-ended questions, to create an overview of the characteristics of the incidents, we asked the respondents to provide the level of strain, length, and date of the incidents. Most of the respondents described the strain caused by the incident to be either “fairly high” (n=165) or “very high” (n=161), with 80 respondents describing the strain as “moderate.” Less than half of the respondents (n=143) described a more acute incident lasting less than 24 hours, whereas over half of the respondents (n=257) described an incident lasting more than this time frame, with many incidents lasting over a month (n=73). This would imply that technostress experienced by software developers is not only caused by acute IT use-related issues but also by more chronic stressful incidents from using IT in their work. This could also partly explain the high number of incidents that occurred over a month ago (n=292) relative to answering the questionnaire. As discussed earlier, critical incidents can also be easier to remember, and a highly stressful experience can linger in the mind for a long time. An overview of the technostress incident characteristics is presented in Table 2.
Overall, our results show that multiple factors in the IT use environment affect the technostress creators and, hence, technostress experienced by software developers in their work. The incident descriptions included stress caused by technostress creators, such as usability issues, interruptions, and techno-uncertainty. The software development-related factors in the IT use environment affecting technostress creators were, for example, poor documentation, poor code quality, rapid technological change, and multitasking. The respondents also described different kinds of strains that they suffered from, including negative emotions such as frustration, anger, and helplessness, and negative effects on, for example, their work motivation, productivity, well-being, and work quality. Some also described far-reaching consequences for their well-being, which left them thinking about quitting their job or experiencing long-lasting exhaustion or burnout. Next, we go over the factors in the IT use environment and technostress creators identified in the incident descriptions affecting the emergence of technostress in the software developers' use of IT. The main results are summarized at the end of this section in Table 3. 4.1.
Many of the respondents reported that complex and hard-to-use systems affect the stress caused by usability issues. Hard-to-use systems slowed the work pace and caused frustration. As some described, figuring out how to use the system took longer than the actual work task itself. Working with complex systems made doing smaller, simpler tasks take more troublesome, increasing the possibility of making mistakes in the software development process. Some respondents described these kinds of systems to include tedious design choices that made the system more difficult to use and that using the system required either trial and error or workarounds to perform the task. In the following example, a developer described the stress caused by the use of a program that was aimed at helping the software development team keep track of the progress of their projects: The program was too complex, required too many inputs for it to produce a work structure. It was developed to help us track our progress better as a team, but it took more time figuring it out than doing the actual work.
One aspect of stress caused by usability issues brought up in the incident descriptions was working with old and legacy systems. The developers described how working with legacy technologies caused a variety of problems because of the technologies being hard to understand and not used often anymore. It was described as difficult to create workflows with legacy systems and programming languages because solutions needed to be pondered from an “old point of view.” Older systems were also often described as slow, cumbersome, and more complex compared with newer systems, as demonstrated by the following example:
We have some older products that are developed in C++, which is an older language. Dealing with this language and this older project has always been very slow and cumbersome compared with newer languages such as C#. Whenever I have to deal with this project, it seems like it is always a pain to compile and do things that are much simpler in the newer projects.
Documentation was mentioned as an important part of the software development process. Poor documentation was described as hindering the use and development of otherwise usable systems by making their use more cumbersome. In a way, documentation was seen as a user manual of sorts to understand how to use the systems and the code on which they were built. Thus, poor documentation made the use of systems more difficult, time-consuming, and, in some cases, even impossible. If the documentation were lacking, it could leave the developer alone with the problem that they were trying to solve.
The fact that there is no documentation or help on the web for what I was doing and so I had to try to solve the problem all by myself and try to figure out why I was having terrible performance.
Poor code quality was also referred to as a factor causing usability issues. Bad quality code made the systems harder to understand and use, producing issues similar to poor documentation. Issues took longer to solve, leaving developers frustrated and angry about the time wasted to figure out the system. Sometimes, the work had to be started over, and all progress was lost because of issues with the quality of the code.
E2E tests in cypress were failing a lot, I was doing an investigation of the issues and if possible, also fixes. But tests were very poorly written … difficult to understand and even more difficult to fix … After some time, you just realized that the best thing would be to delete all of it and start over. 4.2.
Learning new IT was often described as frustrating and difficult. When it came to learning new IT, the respondents also had to learn new ways of working, which affected the overall software development process and their productivity. The developers described that the hectic work environment with the pressure of deadlines and tight schedules increased the pressure to learn new IT quickly and efficiently. Learning also took its toll on the respondents. Learning new IT was often described as exhausting because of the increased workload (linking it closely with techno-overload), the number of technologies to learn, and the pace of change. One respondent described having to work “double the hours,” and another “thought about quitting the job” because of excessive learning tasks. The stress caused by learning was described by one of the respondents as follows: Web apps aren’t my field, but I was forced to learn everything in 1 week only. For this reason, I had to study and work for about 20 hours a day, from morning to night. It was totally too hard for me.
Another aspect closely related to learning was technological change. The developers described that it was difficult to get used to the pace of change and that software development was too focused on adopting new IT over productivity. For example, one of the respondents described being stressed by “the constant change of (technical) frameworks” and suffering from “change fatigue.” The constant change in IT was often described as a trigger for learning and many developers described that they were not listened to when changes in IT were being made. The constant change in IT could also invalidate earlier learning activities, which made the work feel pointless.
The focus (of software development) is on developing the tools for development … The appearance of solutions and the trendiness of the technologies take precedence. … As a developer, this causes frustration and the work to feel pointless. … The time invested in learning them (new tools and systems) is wasted when they are discarded and moved on to the next trending technology. 4.3.
Many respondents mentioned experiencing overload and exhaustion because of the piling up of work and overtime. Multiple smaller factors were mentioned as affecting the piling up of work caused by IT use, such as fixing broken IT, learning new IT, the complexity of the IT used, and strict deadlines. Many respondents described having to work off hours, which they reported to cause many well-beingrelated issues, such as lack of sleep, restlessness, and even burnout. Some respondents also described that there was just too much to do, and the workload was becoming too much, leaving them overwhelmed and exhausted. For example, one developer described a project in which they had too much to do with the IT in question:
I had a lot to code, from the temperature control to the gas flow inside the oven. … This was all done in a few weeks, leaving me feeling burnout. I worked a lot of extra hours for the project to be successful and on time.
… almost no sleep, cognitive impairment due to sleep deprivation, stress, and exhaustion. Feelings of helplessness and frustration.
Specific taxing tasks when using IT were also recognized as an aspect of stress caused by technooverload. These kinds of tasks were described by the respondents as being mentally draining and difficult, which required, for example, a lot of creativity and problem-solving skills. Another aspect described by the respondents was that these tasks had to be completed swiftly in a limited amount of time which increased the pressure put onto the developers. One of the respondents described an exceptionally taxing task with a Java application when working as a coding instructor, as follows: I don't exactly recall the project details, but I was required by a student to assist them in building a project using Java. It was a burdensome experience as it required a lot of creativity, out-of-the-box thinking and extensive knowledge of Java. The project problem did not have an immediate solution I could think of, and every part of it required significant mental effort.
Less-mentioned techno-overload-creating factors were multitasking and information load. Software developers mentioned having to work on multiple projects at the same time, with many projects using different tools and technologies. Working with different technologies required doing different tasks simultaneously, increasing the risk of experiencing fatigue, and being exhausted. For example, one of the respondents described experiencing stress and eye strain caused by working on multiple tasks and monitors simultaneously:
I have been asked to handle many open tickets due to bugs on the main platform. The time to complete the operation was really short and, in the meantime, I had to continue with a task assigned to me. I use two monitors at work, my eyes got tired.
A few respondents also described incidents in which they were flooded with information. The understanding of large and complex systems was mentioned as requiring a lot of information to take in, leaving the developers overwhelmed and exhausted because of information overload. For example, one of the developers described working on a web application as follows:
I worked many hours a day to finish on time, and I was very stressed because there was a lot of information to process. ... Besides the lack of time, web development is a heavy and complex task, because you have to process a lot of data … 4.4.
Insufficient IT use skills affected the stress caused by role overload and role ambiguity. Many respondents described incidents in which they had to perform a variety of roles that were not their area of expertise while using IT they had limited experience working with. Sometimes, it was assumed that the developers could handle new IT and fill in a variety of roles in the software development process. The lack of skills and resulting workload had a negative effect on the respondents, decreasing productivity and increasing role overload. In the following example, a web developer described an incident in which they were tasked to work as a graphics designer with limited knowledge of the tools, in addition to their usual job description:
I was tasked to make animations for a website, I am not a graphics designer, I am a website developer hence I did not find it amusing at all. I do like seeing ideas into life, yes, but I prefer doing that with code, not with graphics designing skills that I barely possess.
The developers also described incidents in which they had to work with limited knowledge and a lack of technological skills to perform the tasks in their usual role description. These incidents were often related to having to work with IT that the developers had no prior experience using and were common among those who had just started out in a new position. Limited knowledge with the IT and the role made the work feel burdensome and frustrating and many developers described being stressed by having no idea what they were supposed to be doing. This resulted in some doubting their IT use skills and even their ability to work as a developer because of role ambiguity, as demonstrated by the following quote:
The fact that I wasn’t used to the particular software nor languages in hand. This already had me kind of frustrated, so when we couldn’t figure out what was the problem for some time, I was really struggling and felt like I didn’t know enough for the job. 4.5.
A few respondents mentioned work IT invading their free time and constant availability as a source of stress linked to work–home conflict. The respondents described constant connectivity through different IT as enabling—and in a way requiring— them to be constantly available. One reason for this kind of requirement was mentioned as being the increasing competition in the software development sector. Constant availability was seen as blurring the boundaries between work and personal time due to having to work off hours, leaving respondents frustrated, angry, and exhausted, which can also be linked to techno-overload. In the example, a respondent described how the pressure of constant connectivity through IT forced them to work on their personal time:
Now a days with internet-enabled phones we are fully connected. However, the same thing can be burdensome when you really want to have quite time with friends and family. … As competition increases, one needs to become more and more responsive even after office hours and on weekends. We went camping with friends. The plan was to have some isolation from work and have personal fun time. However, the production system had an issue and I got immediate chat and lots of emails. I had to spend close to 4 hours on that till the issue got resolved. 4.6.
The respondents described different kinds of interruptions caused by IT use. Interruptions were found to be stressful because of them disturbing the development workflow in an already hectic work environment. Interruptions were their own technostress creator because of some respondents reporting stress solely caused by interruptions, but they were also closely connected as a factor with other technostress creators, such as IT malfunctions and techno-overload. Examples of interruptions caused by technical issues were the downtime of a system or IT not functioning properly.
Getting stuck not being able to work for an entire day because the backend wouldn’t work was incredibly frustrating.
These kinds of issues were often not resolvable by the developers, which caused some to feel helpless. The respondents described having to wait for the issue to be resolved before they could continue their work and having to claw back the time that was wasted, leading to extended workdays. On the other hand, in some cases, the respondents felt like they could solve the issue and found themselves looking for the solution, wasting time, and unable to continue with their primary work tasks.
I spent the whole day trying to submit one piece of code (because of faulty validation checks), ending up running the code/content validation builds time after time after time. Sounds like a chill day, but I also have to take into account the knock-on effect that has on the other work I need to complete, and the effect that has on people who need to use my work. Hell.
Interruptions were also caused by the use of certain IT in the software development process. This kind of IT was used for communication between team members and in performing development activities such as testing and implementation. The respondents described the reasons behind these kinds of interruptions as how the IT was used rather than the IT on its own. These reasons included restrictions based on IT use and how communication was arranged between team members. One of the respondents described being constantly disturbed by others through internal communication channels, and in the following example, another described their work being delayed because of the restrictions placed on the use of their testing environment only once a day:
There were manual jobs included in the application that enabled the system to run the transactions automatically at a certain point in time of the day. … As a tester, I needed the jobs and transactions to run as soon as possible for testing purposes. Instead, I had to wait for the jobs to finish …
The final cause of interruptions mentioned by the respondents was merge conflicts. Merge conflicts were stressful because of them taking a significant amount of time to resolve and running the risk of deleting work in progress. Merge conflicts were reported as hampering productivity and causing helplessness and exhaustion among the respondents. I recently had a situation where I had to merge my work into a branch someone else had also made changes to, so I was faced with a huge merge conflict, which took me a lot of time to unpick. 4.7.
On their own, system breakdowns, such as crashes and hardware failures were mentioned as a common source of stress caused by IT malfunctions. System breakdowns were also often mentioned with many other technostress creators, such as interruptions and techno-overload. Crashes and hardware failures were described as making the development process more tedious and exhausting because of catching up, especially if work progress had been lost in the crash.
I was working on our internal tool. Suddenly, the tool crashed, and all my progress was gone. I had to start the task from the beginning, which wasted a lot of my time.
Common aspects of buggy and unreliable software were poor system performance and glitches, leading to difficulties in performing the tasks the software was intended to be used for. Some respondents described stress as being caused by long-lasting issues related to the unreliable behavior of the software that should have been resolved a long time ago. Yet that still hindered the use of IT and workflow. Buggy and unreliable software were also mentioned, with stress caused by other technostress creators, such as usability issues and interruptions. Overall, bugs and unreliability caused frustration and hindered the respondents’ ability to perform their work tasks.
My whole team is working from home. We had an issue where this internal software developed a bug where it wouldn’t update what co-workers were uploading what they had done throughout the day. … When this happened, nobody had any clue what had been done. 4.8.
IT not fitting the needs of the user or solution was described by many as a source of stress caused by misfit. IT–user misfit caused a plethora of different issues, also linking it with other technostress creators such as techno-overload and IT malfunctions. The respondents described incidents in which they had to work with IT that did not fit the purpose of the work they were doing, causing frustration and the work feeling tedious and pointless. Both forms of IT-user misfit resulted in tasks taking a lot of extra time, causing exhaustion and an increased pace of work. The right tools that fit the needs of the user and the task were seen as an essential part of productivity to enable task performance and avoid costly mistakes and workarounds in the development process. One respondent described a stressful incident in which the computer they had to work on did not meet the specifications necessary for their work, resulting in workarounds and unstable performance:
The programs I develop handle lots of data, and when I started out, my company computer had less than the ideal amount of RAM, making the workflow laggy and I was even forced to have to use 2 different computers at once, so that the company computer did not crash because of too many applications being open. ... So trying to develop code and have many applications open at once was frustrating and took a lot of time. Lots of crashes happened.
Another aspect of IT–user misfit was incompatibility between different technologies. Issues with incompatibility were described as making the user experience more stressful and creating technical difficulties such as crashes. Incompatibilities led to wasting developers’ time, having to use workarounds, or the IT not fulfilling the tasks it was meant to perform. … The stressful part was that there was no compatibility between Visual Studio 2019 and Crystal Reports, so my user experience when manipulating reports was exponentially more stressful, like the VS19 would crash randomly, features of CR would be unavailable or impossible to use. 4.9.
The use of IT intended for monitoring was also mentioned by a few respondents as a cause of stress. Monitoring and controlling the respondents’ use of IT was seen as particularly stressful by the few who mentioned these kinds of incidents. Monitoring made the respondents feel uncomfortable and pressured which affected their productivity, sense of privacy, and work motivation. The use of monitoring software was also enforced, so the respondents had no say in whether they wanted to use that kind of software or not. For example, one respondent described having to use software intended for monitoring:
The boss wanted to measure how much time we spent on the computer and what we did during it, so they installed that monitoring software for the 8 hours every day, and if you don’t type, it sent you alerts and took screenshots for a company server. I felt hyper watched.
Work–home conflict (techno-invasion) Interruptions
The aim of our study was to examine the emergence of technostress in the previously unmapped
context of software development. We used the CIT to build an understanding of the technostress
creators and context-specific factors of software development that contribute to the technostress
creators experienced by software developers. This approach contributes to the call for research
examining technostress through a more context-focused lens in the organizational environment [
We contribute to technostress research in the following ways: First, we recognize multiple factors
in the software development IT use environment that contribute to the emergence of technostress
creators and technostress in the context of software development. These include, for example, poor
documentation, poor code quality, and working with older or legacy technologies for
technocomplexity, merge conflicts for interruptions, and the effect of the hectic and volatile nature of software
development on techno-overload and techno-uncertainty. Examining the specific factors underlying
technostress creators has often been overlooked in current technostress research [17]. Thus, our findings
provide new dimensions for the inspection of these technostressors for future studies. For future
research, we suggest that the software development factors and their effect on technostress creators
could be further validated using a quantitative approach. Second, our study extends the overall body of
knowledge about technostress in an organizational environment. We have found many previously
studied technostress creators, such as techno-overload, techno-uncertainty, and usability issues, to be
relevant in the context of software development as well. These findings further enhance the relevancy
of these technostress creators in the organizational context of IT use [e.g., 4, 5, 9, 29, 31]. We also have
connected a less-studied technostress creator of monitoring suggested by Fischer et al. [35] to the
emergence of technostress in software development work. Additionally, we found IT–user misfit to
contribute to technostress experienced by software developers. This result contradicts previous findings
because the fit between technology and the task has mostly been considered as a technostress inhibiting
factor [
Our research also contributes to the software development literature, specifically to the research on
occupational stress experienced by software developers in their work. First, the impact of IT use on
stress experienced by software developers has rarely been mentioned in relation to other occupational
stressors [
Our findings can also be linked to ideas of the socio-technical approach to systems design. Based on
our results, failing to optimize the needs between human and technical factors [
Our study also has practical implications that should be taken into consideration in organizations engaged in software development. First, the realization of technostress in the software development context shows the struggles and frustration that developers face in adapting to the fast pace of technological change and resulting issues with using IT. The constant adoption of new trending technologies can break the workflow of developers, causing change fatigue and excessive workloads. More problems arise if the adopted IT does not fit the needs of the user or the tasks they are trying to accomplish. Thus, we recommend that software development organizations listen to the needs of their developers and make them more involved in the selection of tools and technologies that best suit the purpose of the development task. The pace of change should also be kept reasonable to avoid adverse outcomes, such as lowered productivity and negatively impacted well-being of developers.
Second, it became evident in the incident descriptions that developers are sometimes thought of as fluid technology users who can be put into performing a variety of roles using different technologies. However, this is often seen as an irritating practice that can cause stress, frustration, and confusion among developers, hampering both their motivation and productivity. Organizations should make sure that developers have a clear understanding of the role and demands of their work to avoid excessive overload and multitasking caused by the use of IT.
Third, developers face interruptions caused by the use of IT and suffer from harmful IT use practices, such as monitoring and the use of work IT in their personal time. Developers should be given quiet time to focus on their work without disturbances and should not feel obligated to be connected to their work IT in their free time. We encourage software development organizations and individuals working in software development to avoid these harmful IT use practices and apply clear policies on using IT to avoid excessive interruptions and work–home conflict.
Finally, the presented factors affecting the emergence of technostress in software development could help software developers to recognize these factors in their own organizational IT use environment. Recognizing these factors and the possible technostress caused by them could help software developers to point out these issues and drive towards fixing them, improving their well-being and quality of work. Fixing these issues could not only alleviate the adverse outcomes of technostress, but also improve the atmosphere of the working environment of the organization. 5.3.
As with all research, we recognize important limitations with our study. First, the use of CIT has
limitations that should be discussed. Even though CIT has been found reliable for collecting accurate
incident descriptions [
Software development is an important part of modern organizations’ business. It is key that software development produces high-quality software and that this process goes hand in hand with the happiness and well-being of those working in the field of software development. In the current study, we employed the concept of technostress and saw how many factors can endanger the well-being of software developers and affect the productivity of both developers and organizations alike. Understanding these issues is crucial to avoiding them in the future and figuring out ways to decrease the impact of unhealthy IT use practices in software development work.
The authors would like to thank the anonymous reviewers for their helpful comments in improving the quality of the paper. This research has been funded by the Foundation for Economic Education, Finland, and partially by the Academy of Finland (341359).
[16] T. Furuyama, Y. Arai, K. Iio, Analysis of fault generation caused by stress during software development, Journal of Systems Software 38 (1997) 13–25. doi:10.1016/s0164-1212(97)000642. [17] M. Salo, H. Pirkkalainen, C. E. H. Chua, T. Koskelainen, Formation and Mitigation of Technostress in the Personal Use of IT, MIS Quarterly 46 (forthcoming, 2022). doi:10.25300/MISQ/2022/14950. [18] J. C. Flanagan, The critical incident technique, Psychological Bulletin 51 (1954) 327–358.
doi:10.1037/h0061470. [19] D. D. Gremler, The critical incident technique in service research, Journal of Service Research 7 (2004) 65–89. doi:10.1177/1094670504266138. [20] A. M. Fuglseth, Ø. Sørebø, The effects of technostress within the context of employee use of ICT,
Computers in Human Behavior 40 (2014) 161–170. doi:10.1016/j.chb.2014.07.040. [21] R. S. Lazarus, S. Folkman, Stress, appraisal, and coping, Springer Publishing Company, New
York, NY, 1984. [22] C. L. Cooper, P. J. Dewe, M. P. O'Driscoll, Job-Related Sources of Strain, in: Organizational stress: A Review and Critique of Theory, Research, and Applications, Sage Publications Inc., Thousand Oaks, CA, pp. 27–60, 2001. doi: 10.4135/9781452231235.n2. [23] R. S. Lazarus, From Psychological Stress to the Emotions: A History of Changing Outlooks,
Annual Review of Psychology 44 (1993) 1–22. doi:10.1146/annurev.ps.44.020193.000245 [24] M. Le Fevre, J. Matheny, G. S. Kolt, Eustress, distress, and interpretation in occupational stress,
Journal of Managerial Psychology 18 (2003) 726–744. doi:10.1108/02683940310502412. [25] C.B. Califf, S. Sarker, S. Sarker, The Bright and Dark Sides of Technostress: A Mixed-Methods Study Involving Healthcare IT, MIS Quarterly 44 (2020) 809–856. doi:10.25300/misq/2020/14818. [26] P. Borle, K. Reichel, F. Niebuhr, S. Voelter-Mahlknecht, How Are Techno-Stressors Associated With Mental Health and Work Outcomes? A Systematic Review of Occupational Exposure to Information and Communication Technologies within the Technostress Model, International Journal of Environmental Research and Public Health 18 (2021) 8673. doi:10.3390/ijerph18168673. [27] M. Tarafdar, Q. Tu, B. S. Ragu-Nathan, T. S. Ragu-Nathan, The Impact of Technostress on Role Stress and Productivity, Journal of Management Information Systems 24 (2007) 301–328. doi:10.2753/mis0742-1222240109. [28] C. Salazar-Concha, P. Ficapal-Cusí, J. Boada-Grau, L. J. Camacho, Analyzing the evolution of technostress: A science mapping approach, Heliyon 7 (2021) 1–15. doi:10.1016/j.heliyon.2021.e06726. [29] A. S. Nisafani, G. Kiely, C. Mahony, Workers' technostress: a review of its causes, strains, inhibitors, and impacts, Journal of Decision Systems 29 (2020) 243–258. doi:10.1080/12460125.2020.1796286. [30] M. Tarafdar, Q. Tu, B. S. Ragu-Nathan, T. S. Ragu-Nathan, Crossing to the dark side: Examining Creators, Outcomes, and Inhibitors of Technostress, Communications of the ACM 54 (2011) 113– 120. doi:10.1145/1995376.1995403. [31] C. Sellberg, T. Susi, Technostress in the office: a distributed cognition perspective on human– technology interaction, Cognition, Technology & Work 16 (2014) 187–201. doi:10.1007/s10111013-0256-9. [32] H. Yun, W. J. Kettinger, C. C. Lee, A new open door: The smartphone's impact on work-to-life conflict, stress, and resistance, International Journal of Electronic Commerce 16 (2012) 121–152. doi:10.2753/jec1086-4415160405. [33] K. J. Harris, R. B. Harris, M. Valle, J. Carlson, D. S. Carlson, S. Zivnuska, B. Wiley, Technostress and the entitled employee: impacts on work and family, Information Technology & People 35 (2022) 1073–1095. doi:10.1108/itp-07-2019-0348. [34] R. Riedl, H. Kindermann, A. Auinger, A. Javor, Technostress from a Neurobiological Perspective,
Business & Information Systems Engineering 4 (2012) 61–69. doi:10.1007/s12599-012-0207-7. [35] T. Fischer, A. Pehböck, R. Riedl, Is the technostress creators inventory still an up-to-date measurement instrument? Results of a large-scale interview study, in: Proceedings of the 14th International Conference on Wirtschaftsinformatik. Siegen, 2019, pp. 1834–1845. Appendix A: Questionnaire questions regarding the critical incident using IT
Burdensome/stressful experience Please take a moment to recall an exceptionally burdensome/stressful experience related to the use of technology or software in your work.
You can take a few minutes to recall. This time is allowed for in the duration of the survey. Technology and/or software that was involved in the experience: What exactly made the experience so burdensome/stressful? (e.g., what were you attempting to do with the technology/software and how was it related to your work tasks?) [open question]