Contents Introduction
The COVID-19 pandemic Work-from-Home (WFH) situation is largely over, as far as pandemic-related restrictions are concerned, allowing employees to once again return to the office. However, remote work continues to be common in software organizations, despite it no longer being necessary. Many organizations currently find themselves somewhere between fully remote and fully on-site modes of working. Mixing on-site work with remote work, both on the level of individual employees and teams, has become known as work-from-anywhere or hybrid work [1] (although the concepts are defined differently across research papers, as we discuss later).
During the pandemic WFH situation, research interest in remote work surged as remote work suddenly became a critical issue for numerous organizations. This was also the case in SE, where various studies on remote work in software development, and more widely in relation to knowledge work, were conducted. Most commonly, these studies focused on either the productivity (e.g., [2], [3]) or well-being (e.g., [4], [5]) of software developers and other employees (or both) in a fully remote work setting. Consequently, much is now known about how software developers feel about remote work, such as what factors positively or negatively influence remote work experiences in a fully remote setting (e.g., [2], [3] [4]). However, while pandemic time WFH studies in SE list various positive and negative factors associated with remote work, many of them may have been related to the unique, fully remote pandemic WFH context, and may be less relevant in the current situation.
Despite many studies published during the pandemic discussing issues related to remote work, such as feelings of social isolation [6], [7], it would seem that many would rather keep working at least partially remotely going forward [8]. Existing studies have begun to explore ways in which companies could bring employees back to the office voluntarily [9]. As it is argued that up to 40% of those currently working remotely would rather switch employers if forced to go back to working fully on-site [10], it seems that mandating fully on-site work is not feasible at present. Currently, various different modes of working exist, often concurrently within the same organization and even the same teams, ranging from fully remote to fully on-site, and anything in-between [1].
This situation presents novel challenges, as well as opportunities, for software organizations. For example, while remote work is often associated with feelings of social isolation among developers, working on-site on some days can arguably alleviate such feelings. Similarly, remote work days may help introverted employees recover from taxing on-site days in an open-plan office. In this fashion, it can be possible for the different modes of working to compliment each other, perhaps both on the level of individual employees as well as entire development teams. In addition to asking the question of how to best entice developers to return to the office, it might also worth asking what could be done to best leverage hybrid work in SE to make the most of it.
In this paper, we look at hybrid work, or work-from-anywhere, from the point of view of software developers and their preferences and work practices. By means of a case study based on semi-structured interviews (n=10), we explore hybrid work with a focus on individual developers. Our aim on a general level is to understand how developers feel about mixing remote work and office work, and how they prefer to organize their work when being able to choose freely between either. Better understanding why developers prefer remote work or why they do not want to come to the office may also help in coming up with ways to incentivize on-site work [9]. By exploring how developers organize their work in a flexible WFA setting, we also wish to understand what types of work practices could be utilized to leverage hybrid work in SE. More specifically, we tackle the following Research Questions (RQs):
RQ1: What factors influence the work mode preferences of software developers, and why?
RQ2: How could alternating between remote work and working on-site alleviate the challenges associated with each work mode while leveraging the benefits of both?
The rest of this paper is structured as follows. In Section II, we discuss the theoretical background of the study through extant research and related work. In Section III, we present the research methodology of the empirical study presented in this paper. In Section IV, we present our results. In Section V, we discuss the practical and theoretical implications of our results, as well as threats to the validity of this study. Section VI concludes the paper and provides future research suggestions.
Background and Related Work
In this section, we discuss the theoretical background of this study. In Section II-A, we discuss remote work in SE. In Section II-B, we discuss work-from-anywhere (or hybrid work), with a focus on more recent, post-pandemic studies on WFA in SE.
A. Remote Work in Software Engineering
Remote work plays a notable role in hybrid work or work-from-anywhere, as it remains less studied than on-site work, even though numerous studies on remote work were published in SE during the pandemic. Historically, the main question posed in relation to remote work has been how productive remote work is compared to working on-site (and this remained a topic of interest during the pandemic as well). While remote work has also been referred to as telecommuting [11] and telework [12] in existing studies, remote work or WFH have become more prominent constructs in SE research.
Prior to the COVID-19 pandemic, WFH was relatively rare in practice, [13] in spite of its argued benefits. Much of the grey literature at the time argued against WFH by, e.g., claiming that WFH reduced productivity due to lazy employees [14]. On the contrary, studies at the time associated WFH with increased productivity [14] and cost savings [12], although Bloom [14] highlights that not everyone has the discipline required for remote work, and not everyone even wishes to work remotely in the first place. However, it should be noted that many of these pre-pandemic studies on WFH were not SE studies and did not focus on software development.
During the pandemic, on the other hand, numerous SE studies on remote work were carried out. As mentioned in the introduction, these studies generally focused on productivity and well-being of individual developers, although some studies on SE practices and team aspects can also be identified. First, in terms of productivity, Neumann et al. [15] conducted a multiple case study and report no notable change in productivity in fully remote work. Russo et al. [3], based on a survey, argue that developers are more focused in remote work and spend less time in meetings. Canna et al. [4] claim that the fully remote pandemic WFH context initially had no impact on productivity, but later increased developer productivity once the developers grew more used to working remotely. Smite et al. [2] highlight that productivity in remote work can vary greatly between individuals, with some more productive in a remote work setting and some less productive, thus supporting the prior notion of Bloom [14].
Secondly, in terms of well-being, Ralph et al. [16] argue that developer well-being and productivity are closely related in remote work (a finding that is supported by a study of Graziotin et al. [17] not related to remote work specifically). Canna et al. [4] list various factors that negatively impacted developer well-being in the pandemic WFH setting, including: balancing work and child care at home, concerns about family safety, data privacy and code security, connection costs, and bad home office conditions. Venumuddala and Kamath [18] reported decreased well-being as a result of the pandemic situation, which in and of itself caused distress. Silveira et al. [5] discusses sleep quality, exercise, decision latitude, and work-life balance as well-being related issues in a fully remote settings. Finally, one of the main well-being related challenges with fully remote work would seem to be a lack of social contact and informal social conversations [6], [7], which is discussed in various remote work studies.
Thirdly, in relation to SE practices, Mendonça et al. [19] discuss how the fully remote situation resulted in lessened collaboration between the developers and the stakeholders, resulting in challenges in requirements elicitation. The study also discusses communication tools used to facilitate communication in the fully remote setting. Marek et al. [20] studied the impact of fully remote work on agile, reporting no change due to the geographically distributed teams already working in a manner that supported remote work. Smite et al. [21] reported a decrease in pair programming in the pandemic WFH situation.
Going forward, fully remote work seems to be making room for mixing of work modes both on an individual level as well as across teams. With remote work no longer being mandatory but simply an option (which many developers seem to prefer [22]), this new situation raises new questions in SE, as we discuss next.
B. Related Work: Work-From-Anywhere or Hybrid Work in Software Engineering
Alternating between remote work and working at the office is not a novel phenomenon as such, and neither are flexible work hours, and the combination of these comprises what is now typically referred to as work-from-anywhere or hybrid work. Prior to the pandemic, flexible work arrangements (flextime and compressed work week) were typically associated with balancing work and family demands [23]. The concept of Work-from-Anywhere (alongside the idea of remote work as discussed in Section II-A) has also been around far before the pandemic [24], although seldom discussed, especially in SE, until recently. While in Section II-A we discussed remote work related studies in SE, which are arguably also closely related to the current WFA trend, in this section we specifically look at studies investigating WFA in SE, which are currently still few in number.
In relation to the concept of hybrid work itself, Smite et al. [9] point out that the term hybrid work can be misleading. While it is often used to describe freedom of choice, there is no guarantee that a developer with the option to work remotely or on-site is going to work in a hybrid manner, as opposed to working either entirely remote or entirely on-site. They also highlight that this applies to teams as well. For this reason, Smite et al. [9] prefer the concept Work-from-Anywhere. However, the concept of WFA does not seem to be unproblematic either, as, e.g., Choudhury et al. [25] associate it geographic flexibility by definition. Acknowledging the issues with the concept of hybrid work discussed by Smite et al. [9], we nonetheless use the concept hybrid work in this paper, as we feel that it echoes with our aim of understanding how the work modes could best be combined in SE, even though individual employees may prefer to work fully remotely when given the choice.
In practice, hybrid work comprises a plethora of different work modes, especially when looking at software teams. In this regard, Smite et al. [1] present a typology of software teams based on how their members work in terms of geographical distribution and modes of working in WFA or hybrid work settings. This typology considers both the aspect of work location (hybrid, on-site, geographically distributed), as well as work hours (synchronous, core hours/meetings, asynchronous).
Additionally, we are able to identify some studies more directly related to this paper. In particular Smite et al. [9] investigated ways to motivate employees to visit offices more in a WFA setting, including reasons that motivate remote work. These reasons for working include commute, being able to focus more easily at home, having a good home office, convenience, routines and habits, and having lots of meetings that are carried out digitally anyway, while social interaction was one of the main reasons for visiting the office. We discuss these in more depth in relation to our own results in Section V. In another study Smite et al. [22] take on a more quantitative approach in studying work mode preferences, highlighting that employees have diverse preferences, and calling for flexibility from organizations, while also providing some insights into the current state of practice (i.e., what are companies currently doing when it comes to work modes). The paper provides some insights into what types of employees typically choose which work modes, which we also discuss in relation to our findings in Section V.
Smite et al. [8] further discuss productivity in relation to WFA, expanding on their prior findings from [2]. They further underline the potential benefits of WFA in that it lets those wishing to work remotely do so, while those who feel that they are not productive at home, or simply do not want to work from home, are able to work on-site. They argue that, because of this, WFA really may increase productivity, whereas the productivity impact of fully remote work can be harder to discern due to differences between individual employees.
Study Design
This study was carried out as a single case study where data was collected through semi-structured interviews with 10 software developers. In this section, we discuss the research methodology of the study as follows. In Section III-A, we present the case company. In Section III-B, we discuss the data collection approach. In Section III-C, we discuss the data analysis approach.
A. Case Company and Study Context
The respondents were all from the same company, but from different software teams and from multiple different business units. The company in question, henceforth Company A, is a large multinational Finnish software company with 1000+ employees spread across multiple locations in different countries.
Prior to the pandemic, remote work was not common in Company A, although some individual employees may have occasionally worked remotely. Company A was largely organized around everyone working physically on-site at this time. At the start of the pandemic, Company A shifted nearly completely into remote work mode, which lasted until early 2022, nearly two years in total. Only larger project meetings were occasionally held F2F during those two years.
Overall, Finland had a strict approach to COVID-19 lockdowns, and consequently the national remote work recommendations continued well into 2021. In many cases, such as in the case of Company A, remote work continued even though it was no longer legally mandated or officially recommended. During the spring of 2022, employees finally started considering returning to the office, and the company made some attempts to encourage them to do so. However, at the time of the interviews conducted for this study, in the autumn of 2022, the company was still highly flexible in this regard and individual employees worked as they best saw fit. While the company had made company-level recommendations for remote work and office work ratios, these were not applied in individual teams and some individuals continued to work fully remotely. We felt that this made the company an interesting case in this regard, as it was almost entirely up to the employees to organize their own work arrangements based on personal preferences.
B. Data Collection
Data for this study was collected through semi-structured interviews, utilizing a purposive sampling strategy [26], [27] to ensure a diverse range of experiences and perspectives on hybrid work. Purposive or purposeful sampling is a common sampling strategy in qualitative research such as this study [26]. Ten software professionals (Table 1) were interviewed regarding their experiences with hybrid work. The sampling aimed to include participants with varied profiles in terms of job titles, work experience, life situations, and gender. Thus, even more specifically, this sampling strategy is in line with what is described as “heterogeneity sampling” by Baltes & Ralph [26].
We deliberately included both junior and senior developers to examine how experience impacts the perception of hybrid work. Respondents ranged from having a (programming) work history of 1 year to over 30 years. Life situations and gender were also considered; we interviewed participants who were single, married, with or without children, as well as 6 males and 4 females. In terms of job roles, our selection was limited to roles that involve substantial coding activities, such as Software Architect and Scrum Master, thereby excluding roles like business analysts to maintain focus on software development.
The interview questions, broadly speaking, focused on understanding how they preferred to work and why, as well as what they thought worked or did not work when it came to remote and office work. We also wished to understand what kind of work practices could make hybrid work more successful by, e.g., leveraging the benefits of both remote and office work. The interview instrument in its entirety (translated into English) can be found in the Appendix. This instrument is discussed in more detail below.
First, we asked some background questions (“A. Background Information” in the Appendix) to give further context to the rest of the answers. We asked about the job (programming) experience of the respondents, based on what was discussed earlier in this subsection. We then asked about the current projects and teams of the participants, in order to better understand their current work context. Finally, we asked about their current work mode preferences, so as to get a clear idea of how they currently worked in terms of remote and on-site work.
Secondly, we asked general questions about their work (“B. Current Work Situation” Overall in the Appendix). In doing so, we wanted to understand whether issues related to work modes (remote/hybrid/office) were considered impactful by the respondents.
Thirdly, we asked about the typical on-site and remote work days of the respondents (“C. Typical Work Day” in the appendix). Existing research argues that “tasks with vague requirements are performed collocated while individual tasks requiring focus are best performed at home” [28], highlighting how hybrid work arrangements can be leveraged in SE. We wanted to further our understanding of what this means in practice through these questions.
Fourthly, we wanted to better understand how developers feel about the two work modes, remote and on-site work, in the context of hybrid work (“D. Remote Work” and “E. On-Site Work” in the Appendix). Research carried out during the pandemic, for example, noted that remote work was associated with feelings of isolation and loneliness. We wanted to understand how the new hybrid work context where (fully) remote work was no longer mandatory had perhaps changed how developers felt about the two work modes. Moreover, existing research has begun explore why individuals prefer different work modes [9]. We also wanted to better understand the reasons behind these preferences through these questions.
Fifthly, we explored the use of SE methods and practices in the hybrid work context (“F. Software Development Practices/Methods” in the Appendix). Some existing papers have explored how remote work impacts agile (e.g., [29]). In terms of individual SE practices, (remote) pair programming, for example, is considered to be a practice that can make remote work more social [21]. Consequently, we wanted to explore what the respondents thought about their current work practices and the method they used in the context of hybrid work. For example, whether the respondents and their teams had made adjustments to their work practices to better suit hybrid work.
Finally, we explored the personal preferences of the respondents by asking what they would truly prefer, if given complete freedom to do anything within the organization (e.g., re-organizing teams based on their own whims, etc.). The aim of these questions was to further understand the preferences of the respondents and to explore any issues that may have otherwise gone unmentioned. These questions were intended to expand on already discussed topics (e.g., remote or on-site challenges) by asking questions from a different point of view.
The interviews were conducted remotely through video conferencing software (Microsoft Teams). The interviews were conducted in Finnish and had an average duration (recorded data) of 58 minutes, ranging between 40 minutes and 1 hour and 11 minutes. Only the interview audio was recorded for analysis.
These audio recordings were transcribed using an AI speech recognition software (OpenAI Whisper [30]) running locally. The resulting AI transcripts were then used in conjunction with the recordings themselves to analyze the data. While the AI transcription introduced some errors, the resulting text was understandable, and the audio recordings could be used as supporting data where necessary. Most importantly, the resulting transcripts could be used to code the data, as we discuss below.
C. Data Analysis
To analyze the data (interview transcripts), we utilized thematic analysis. We utilized inductive coding due to the relative novelty of the phenomenon. The process was carried out iteratively, with the codes and themes updated as the analysis progressed. As seen in Table 2, the resulting themes were quite general in nature, while the individual codes were kept granular. This was done to support to exploratory approach of the study, as we wished to also report individual accounts that were considered interesting, either for theory or practice. The analysis in practice was carried out using ATLAS.ti to assign codes and themes to the interview transcripts.
This coding process was carried out by the first author. Prior to the analysis, the two authors sat down and discussed the interviews and reflected on the upcoming analysis process together. Some potential codes and themes, as well as phenomena of potential interest, were discussed. Then, following the thematic analysis, the authors once again sat down and discussed the resulting codes and themes and confirmed the final set of themes.
In Table 2, we present an overview of the codes and themes. The table contains all the themes, the number of unique codes within each theme, as well as examples of the codes included in each theme. However, for the clarity of the paper, the themes were not directly used as (sub)sections while reporting the results. Moreover, it should be noted that there was some overlap in the codes in practice. For example, depending on the context of the discussion during the interview, the issue of commute being time-consuming could be considered a remote work benefit or an on-site work challenge.
Results
In this section, we present the results of the study. The section is organized as follows. In Section IV-A, we discuss factors the developers felt most hindered or facilitated their work currently. In Section IV-B, we discuss factors that affected the work mode choice of the respondents, including the perceived benefits and challenges associated with both on-site and remote work, focusing on individual developers. In Section IV-C, we discuss remote work from the point of view of software development teams. In Section IV-D, we discuss how hybrid work, i.e., mixing on-site and remote work, could provide benefits in software development, based on our data. Section IV-E summarizes our key findings.
A. What Currently Makes Work Easier or Harder for Developers?
At the start of the interviews, we asked the respondents to tell us what currently facilitates and hinders their work the most. Based on the responses, work mode (remote/hybrid/office) related issues did not seem to have a major impact on the work of the respondents currently. The full list of factors, both negative and positive, is summarized in Table 3.
1) Factors Facilitating Work
Most respondents discussed factors related to team work and communication as the ones that most facilitated their work currently. Communication was discussed both in relation to internal team communication as well as communication inside the company overall, such as being able to get a hold of people in general in a timely manner.
2) Factors Hindering Work
Factors negatively impacting the work of the respondents were more varied than the ones facilitating work. However, most of the issues discussed by the respondents were communication-related once again, with the most commonly discussed one being meetings. In addition to communication-related issues, task prioritization, both on a personal level and project level, was considered difficult.
The respondents, overall, did not seem to consider WFA a notable issue in their day-to-day work. Only one respondent explicitly mentioned that the possibility of remote work notably improved their work performance currently. Despite the respondents later during the interviews discussing various challenges and benefits of different work modes, these seemed to not be particularly notable issues from the point of view of the respondents, given that the majority of the most notable factors currently negatively or positively affecting their work were not related to work modes.
3) Finding 1
When WFA is organized in a satisfactory manner, developers seem to not consider work mode related issues highly impactful in their day-to-day work.
However, many of the factors in Table 3 are (or can be) still related to WFA, as we also discuss in the remainder of this section. In particular, some of the issues related to communication were ultimately further discussed by the respondents when the interview questions shifted to discuss WFA directly.
B. Factors Influencing Work Mode Choices of Developers
As the respondents were free to choose their own work mode in Company A, we wanted to understand the factors affecting the work mode choice of each respondent. In Table 4 we provide an overview of the work mode of each respondent. Overall, there were more respondents who worked primarily remotely. Even the respondents who regularly worked on-site appreciated the possibility of remote work days, to the point where no respondent regularly worked five days a week on-site. Thus, every respondent seemed to take advantage of WFA in their own way.
The reasons behind the work mode choices were various. In Section IV-B 1) we discuss factors driving developers to work remotely, while in Section IV-B 2) we discuss challenges associated with remote work. In Section IV-B 3) we discuss factors driving developers to work on-site, while in Section IV-B 4) we discuss challenges associated with on-site work in a WFA context. Here, we focus on individual developers, while Section IV-C takes on a software team-focused view.
1) Factors Driving Developers to Work Remotely
Remote work was generally motivated by perceived increased productivity and an increased work-life balance. However, the preferences of the respondents varied, and there were often two sides to the same coin. These were often influenced by not only personal preferences but personal attributes or life situations as well. For example, while someone living alone may find it easier to focus at home than in an open-plan office, someone with little children at home may prefer working on-site for the same reason. I.e., the same factors may motivate different work modes for different individuals.
Productivity: Various factors related to productivity were discussed by the respondents. These were primarily related to time management and having a better physical work environment.
One general issue related to time management was related to flexible work hours, which were perceived to be far more flexible remotely than on-site, leading to productivity gains while working remotely. One would still have to attend dailies during morning hours, but past these core meetings, it was possible to simply work 4 hours in the morning and 4 hours in the evening, for example. To this end, the respondents noted that breaks felt more productive (e.g., due to being able to do house chores in-between work tasks), and were consequently more inclined to take breaks to maximize productivity. This was considered particularly impactful in situations where they were unable to progress (e.g., due to waiting for a response to a problem), as they could simply stop working until the issue was resolved, and continue later during the day.
“It’s nice to take a little break and go pet my cat, if I’ve had a hard time with work, so I get to have a little break, and it’s probably a bit more effective, that break. [
“Also that freedom to work whenever you’re feeling most awake and energetic.” [R8]
On-site, on the other hand, the hours spent at the office were work hours even if work was not actually progressing. Breaks were not considered as beneficial for productivity, and the participants did not typically take longer breaks while on-site. Moreover, on-site days took place during typical office hours. Morning meetings made it so one had to be at the office early, followed by 8 hours of work. The respondents also felt peer pressure to work typical office hours on-site.
“Well it’s like in a way a lot stricter, because there’s like this rhythm that I’ve noticed, like how it usually goes when people go to the office. There’s that peer pressure, and even though there’s no one telling us to like be at work by 8:30, you still end up going there when other people go there [
Finding 2: In practice, flexible work hours can be more flexible remotely than on-site.
In addition to time management benefits, office environment was a common reason for preferring remote work. Many respondents working primarily remotely preferred their home office to the company one(s). For the most part, this was due to the home office environment being considered more peaceful and silent. With no other people around or less other people around, noise, visual noise, and interruptions were rare. Open-plan offices were considered particularly problematic in this regard. Some respondents also emphasized having better equipment at home (desk, screen, etc.).
Finally, remote work days were considered particularly useful for situations where the developers had clear work tasks in mind, especially if they were ones that could be completed alone. I.e., working remotely was good for “getting things done”.
Finding 3: Those who prefer remote work associate it with increased productivity.
Work-Life Balance and Well-Being: Aside from productivity, the respondents emphasized the positive impact remote work had on their personal lives and well-being. This was largely a result of simply having more spare time, as well as the ability to alternate between work and spare time due to flexible work hours. In this regard, the major time savings came from not having to commute and not having to spend as much time making oneself presentable for work (makeup etc.), in addition to being able to do chores during breaks throughout the workday, or by leveraging flexible work hours to run errands. Aside from taking up time, commute was also simply considered mentally tiring.
“If your thoughts just aren’t there, then usually taking your mind off work to do something physical. It’s a lot easier [at home] to do something that feels like, somehow productive or useful. That you don’t just like sit around on the couch doing nothing, but you do something that gives you more spare time in the evening.” [R9].
Additionally, however, some of the respondents also highlighted that remote work days were helpful for introverts, who might feel drained by continuous on-site work. Working remotely with minimal social interaction on some days could help such developers recharge socially, positively contributing to their well-being. In a similar vein, remote work days can be particularly beneficial to those with difficulties waking up early, as not having to commute and spend as long preparing for work in the morning results in more sleep.
Finding 4: Those who prefer remote work consider it to increase their work-life balance and well-being, primarily as a result of having more spare time.
Other Reasons for Working Remotely: In addition to personal productivity or well-being, some miscellaneous factors prompting remote work days were mentioned by the respondents. First, there is no point going to the office if one’s calendar is full of digital meetings for the day anyway. Secondly, if you’re mildly ill, you can safely work remotely without potentially infecting your coworkers. Thirdly, bad weather makes remote work preferable.
While the respondents who worked primarily remotely had their reasons for preferring remote work, as discussed above, they nonetheless did not necessarily consider working on-site to have any particularly terrible downsides. In this regard, one of the respondents summarized their sentiments in an interesting fashion: “I wouldn’t see them as downsides [of on-site work]
2) Remote Work Challenges
Most of the challenges associated with remote work that the respondents brought up were more related to team work than them as individuals (and these are discussed in Section IV-C)). Nonetheless, two main types of challenges were identified for individuals as well: lack of social interaction, and issues related to the home office environment.
a: Home office issues
Issues related to home office spaces were key reasons for some respondents to prefer on-site work. One issue can be the lack of a suitable office space at home, as, e.g., some may prefer to have a separate room to work in. Family members may also make it harder to focus on work at home for some, with especially little children being a potential source of interruptions throughout the day while working remotely. One of the respondents even remarked having worked (alone) at the company offices during the pandemic regulations due to such issues.
b: Lack of social interaction
Some of the respondents thought back to the fully remote pandemic time work mode and mentioned it having been mentally taxing. However, they felt that this was no longer a relevant issue for them, as they could now simply go to the office on some days to interact with their co-workers face-to-face. This was one of the most commonly mentioned benefits of hybrid work. Moreover, some of the respondents did work practically fully remotely (Table 4), and did not feel that this was an issue for them. Overall, however, the lack of social interaction compared to on-site work was considered more of an issue in relation to team work than personal well-being.
“Many times those people who irregularly just go to the office every now and then, they often have this like, ‘well it’s kind of nice here now that I came here, but it’s just so difficult to go somewhere in the morning when you’re used to not having to anymore’. I’ve heard this from multiple people. Clearly many people have this kind of need anyway that there should sometimes be something [social interaction].” [R2].
3) Factors Driving Developers to Work On-Site
Most of the respondents working primarily remotely did not work fully remotely (Table 4), and thus could discuss reasons for occasionally going to the office as well, in addition to those that actively preferred working on-site. Those that primarily worked on-site largely did so due to home office conditions that made on-site work preferable. Additionally, one respondent underlined that working on-site was preferable because they felt that it was important to feel like they were working due to being physically at work.
a: Social interaction
The biggest reason for on-site days among the mostly remote respondents was social interaction. While especially more senior developers regularly felt like they could properly engage in small-talk with their co-workers remotely as well, most still preferred to occasionally drop by at the office for social interaction. Meeting F2F was considered especially important for building new social relationships.
Those that worked mostly remotely typically considered on-site days to be primarily about social interaction, and went to the office with the explicit goal of talking to people more than usual. These respondents placed emphasis on the importance of lunches and coffee breaks as social events, and mentioned taking breaks on-site just to chat with people. Though mostly chitchat, such chats could also have an impact on productivity when work-related topics were discussed. These respondents seemed to accumulate a type of “social debt” during their remote work days, which then resulted in the occasional on-site day on which the debt was realized. In some cases, the developers set up on-site days beforehand to ensure that (more) other people were also present at the office on the same day.
Finding 5: WFA can help alleviate the issues associated with fully remote work.
b: Productivity
Whereas the ones working primarily remotely largely associated remote work with productivity, there were ways in which on-site work was also considered to facilitate productivity. Tasks or issues that required input from others were occasionally considered to be better accomplished at the office (as we discuss in more detail in Section IV-C)). For example, junior developers had an easier time asking for help with broader questions at the office, while questions posed via chat had to be more specific. Additionally, some felt more productive in general while working on-site. Those that preferred the company offices to their (lack of a) home office felt more productive on-site. In addition, one respondent considered it simply easier to stay focused on working while at the office. For some individuals, it may be difficult to stay disciplined and focused on work while working remotely.
“Well, first off, it’s a different environment here at the office. At least for me personally it’s very important that I’m somewhere else than at home when I work. [
Finding 6: Those who prefer working on-site consider it to increase their productivity.
4) On-Site Work Challenges
The perceived drawbacks of working on-site were largely the inverse of the benefits of remote work: less spare time due to having to commute, less flexible work hours, harder time focusing than at home, etc. Overall, these seemed to be inconveniences rather than outright issues for most. For example, bad parking possibilities were one such inconvenience.
a: Office spaces
The largest issues the respondents discussed in relation to on-site work were related to the physical office spaces. In this case, open-plan offices were considered by many to hinder work due to noise and visual noise. One of the respondents discussed having had a better on-site experience with an office room of their own in years past before Company A adopted an open-plan space, and noted that perhaps they would be more inclined to go to the office again if they had a room of their own.
On the contrary, however, many mentioned that working in an open-plan office was now more comfortable due to WFA. With less people at the office, there were consequently less distractions as well. This was considered particularly positive by those who regularly worked on-site, although most respondents saw the lack of people as a problem as well.
b: WFA means less people on-site
Social interaction was considered one of the reasons to occasionally work at the office for those primarily working remotely, and was also considered important by those who regularly worked there. However, with many working remotely on any given day, the offices were increasingly empty, resulting in less (F2F) social interaction for those at the office. This was also seen as a vicious cycle issue: with less people at the office, those looking to drop by at the office for social interaction were less likely to do so, further contributing to the problem.
“When they asked me about this, like how I want to work after COVID, I said that I’d like to be at the office 1–2 times a week just for the social aspect. And I tried to do that for like 1,5 months. I went there two times a week, but then I noticed after the holidays when I went there again that it was pointless, because it’s virtually just me and the security here
c: Finding 7
Social interaction is one main reasons for developers to come to the office in a WFA context, and empty offices make this less fruitful.
C. Remote Work Challenges and Benefits for Software Teams
Based on the respondents’ input, remote work was considered preferable – by those that did prefer it – due to its effects on personal productivity and well-being. On-site work, on the other hand, was often regarded as being potentially better for team work, although with geographically distributed teams it was never (fully) possible in the first place in Company A. Indeed, as the teams of the respondents were all geographically distributed to some extent, with at least one team member from each team working on a different site, the respondents were all using remote work practices within their teams (digital meetings etc.). There were nonetheless various instances where the respondents discussed on-site work facilitating work when tasks required input from other people, be it individual teammates or people from other teams.
1) Remote Work Challenges for Software Teams
a: Onboarding new employees
This was an issue discussed by both junior developers themselves as well as some more senior developers. Multiple senior developers felt that it was easy to communicate (incl. chitchat) and work with familiar teammates even fully remotely. On the other hand, with less familiar co-workers communication was more formal and strict. With digital communication lacking various non-verbal cues, especially over pure text, even simply telling a joke to an unfamiliar co-worker may feel more daunting, making it harder to bond remotely, and thus making it harder for new employees to become a part of the team in more than just name. This can also make it harder for new employees to ask and receive help.
“Social interaction doesn’t get properly started right away. Like finding the sense of humor
“When you talk to people from a different city over Teams, it’s more taxing and demanding mentally, the social aspect. It’s easier and quicker to get to know people and befriend people and do team building live. The amount of feedback you get is so much bigger and it makes the process much easier.” [R4].
b: Team building
For the same reasons discussed above in relation to onboarding new employees, team building can also be more challenging remotely. Whereas developers previously familiar with each other seem to have less communication issues remotely, previously unfamiliar developers may struggle to bond virtually.
“It definitely helps [that we previously worked together physically], because now we know each other so well. If a completely new team started working [fully] remotely, it’d no doubt be more difficult.” [R10].
c: Finding 8
Face-to-face interaction is important for getting to know people, making onboarding new employees and team building challenging remotely.
d: Communication between team
Communication between teams was considered to be an issue in particular when working remotely. Multiple respondents discussed the role of spontaneous small-talk on-site in relation to knowledge transfer between teams, which was not happening remotely. While individual teams had various communication channels and tools, practices for communicating outside the borders of one’s own team were lacking.
“Now that we’re remote, we don’t really talk to people outside our own team. At the office you see other people here, so you end up talking to them. [
e: Facilitating social interaction remotely
The lack of social interaction, and especially informal communication, is a recurring challenge in remote work, as has already been highlighted in the preceding challenges as well. However, tackling this issue seems to be equally challenging. For example, having video feed on during conference calls may help with the lack of informal communication, but many respondents discussed preferring to not have their cameras on regardless, as doing so would necessitate having to look their best, and was considered more inconvenient than beneficial.
The respondents discussed ways in which their teams or Company A had tried to facilitate social interaction remotely through existing practices (e.g., virtual coffee breaks) during the fully remote pandemic situation, but felt that none of them had had enough of an impact. For example, while said virtual coffee breaks had drawn in people, it had mostly been the same ones every day, lacking a wider impact. The respondents felt that, instead of trying to make remote work more social, this issue would be best tackled by having on-site days.
f: Self-organizing teams are important
In a remote setting, self-organizing teams become more important, although this was only brought up by one respondent in relation to what they thought made their work flow well currently.
g: Setting up meetings
WFA and flexible work hours make it more difficult to set up ad hoc meetings. One of your team members may simply be outside running errands at any given time, making it challenging to set up meetings on the fly. However, people at Company A have generally been helpful by setting their status to ‘away’ when away.
h: Asking questions can be more difficult
The respondents felt that it was occasionally hard to reach some people (primarily business analysts) for questions remotely. For urgent questions, email and chat messages were not considered urgent enough, and directly calling someone was not considered a suitable course of action, or at least it was never considered an option. It was considered more straightforward to simply barge into someone’s office with an urgent question on-site. In this regard, it was considered more difficult to determine whether someone was actually busy remotely or not, as the ‘busy’ status could mean many things, while on-site one could actually see what the situation was.
“Sometimes it’s hard to reach people because you don’t know if they’re actually there at the computer or if they’re like in a car driving and only on Teams on their phone. If you were on-site, you could see like, that they’re sitting there and go poke them.” [R1].
“They couldn’t like run away, if you went to them for help physically, like they couldn’t avoid it like on Teams, when you could just march to their office and talk to them, which made getting help a lot faster too.” [R7].
i: Finding 9
Collaboration and communication with coworkers outside one’s own team is negatively impacted by primarily remote work.
2) Remote Work Benefits for Software Teams
For the most part, remote work was seen as a challenge for software teams, and its benefits were mostly felt by individuals rather than teams. Some potential benefits related to teams could be identified by the respondents, although whether they are actual benefits or simply things that work well enough compared to on-site work is not always clear.
a: Internal team communication
Using a team-wide chat as the main communication channel for teams may improve communication within teams, as all team members receive the same messages and see the same conversations in real-time. Overall, most respondents felt that they had no notable issues communicating with their teammates remotely, as far as work-related communication was concerned.
b: A digital kanban is always up-to-date
A physical one may update with more delays, although it is hardly uncommon to use a digital kanban in any case today.
c: Finding 10
Internal team communication does not always seem notably impacted in mostly remote work.
d: Tacit knowledge
Both junior developers we interviewed seemed particularly fond of screen sharing as a way of learning from their seniors. When asking for help, they often ended up in a teams call with another developer, who then proceeded to share their screen while explaining. This led to the junior developers seeing various tricks and tools they were unaware of, which they could then ask about during the call.
“But then when you see the ways how the other person has organized the environment or moves between environments, which you see well in a video call [screen share] like that, and sometimes I feel like I should record these since it would be very useful learning material. [
e: Finding 11
Tacit knowledge seems to also transfer remotely between software developers.
On the contrary, however, our data provided at least on example of remote work negatively impacting knowledge transfer in relation to domain knowledge. One junior developer highlighted how remote work and on-site work can differ when it comes to task-related communication even inside teams. Though the respondents overall felt that communication within their teams worked well even remotely, miscellaneous work-related communication may suffer:
“[on-site] I might find an opportunity to ask questions that aren’t exactly related to problem-solving but are more general, explorative questions, like what is a contra account. On my team people know these things, so I can ask them more easily on-site, instead of, like, calling someone just to ask what is a contra account, which probably won’t happen
D. Leveraging WFA: Synergy Benefits of Mixing Remote and On-Site Work in Software Development
a: Have designated on-site days
There seemed to be a consensus among the respondents that having an occasional on-site day was desirable, but that going to the office was pointless if there were no other people there. While the respondents had tried to set up office days within their teams and between teams, they had struggled to do so on a regular basis. Many hoped that there would be a top-down recommendation for such days, but also hoped that they would not be fully mandatory. This way those primarily working remotely could best leverage the social aspect of on-site days, which they felt was the main reason they would want to go the office every now and then to begin with.
b: Keep both remote and on-site Work Possible
The respondents nearly unanimously felt that remote work should remain as an option. The ones primarily working remotely considered it very important, while those only occasionally working remotely still considered it good for work-life balance to have the option to work remotely on some days. On the other hand, all but one respondent also considered on-site work important, as purely remote work was considered mentally taxing by most due to the lack of informal social interaction. More importantly, some individuals simply prefer working on-site due to personal attributes, such as having no suitable home office, or having a hard time staying disciplined at home.
c: Leveraging different work modes for different work tasks
Many respondents felt that remote work was particularly suited for situations where they had a clear to-do list, or when they were particularly busy; i.e., for “getting things done”. Conversely, on-site work could be leveraged for tasks requiring collaboration. The respondents also suggested having thematic days such as testing days to draw people to the office with a clear goal in mind while also leveraging the fact that everyone would be on-site.
d: WFA can make offices more pleasant to work in
With many working remotely, offices consequently become more silent, potentially making them more desirable working spaces. With offices seeing less use on an average day, it might be possible to also redesign some spaces to better support the new realities of WFA. However, paying for mostly empty offices is not necessarily ideal for a company.
E. Summary of Results
In Table 5 we summarize the findings we have highlighted previously in this section. These findings present various points of view to work-from-anywhere in software development. In Section V, we discuss the implications of these findings in relation to existing literature, as well as their practical implications.
Moreover, we conceptualize the model depicted in Figure 1 based on our results. The figure depicts the factors influencing the work mode choices of the respondents, the potential work modes, and their impacts. In combination with our findings in Table 5, this provides a summarizing overview of our findings. Based on Figure 5, we are able to pinpoint some potential avenues for future research on hybrid work in SE, as we discuss next.
Factors motivating the work mode choices of software developers and the (self-reported) impacts of those work mode choices.
Discussion
Overall, one currently prominent challenge in hybrid work or WFA is motivating employees to occasionally come to the office [9]. Smite et al. [9] began to explore what motivates remote work in developers to tackle this issue. In this paper, we have explored what motivates both remote and on-site work to shed further light on this phenomenon. As some existing papers have highlighted [2], [8], [14], some individuals are more productive when working remotely, while others would rather work at the office and may struggle to stay disciplined at home. This is also supported by our findings. While some of our respondents preferred to work remotely for better productivity and work-life balance, some preferred to work on-site the same reasons. Perhaps interestingly, complaints about blurred boundaries between work hours and spare time often seen during the pandemic WFH context [8] were absent in our study, underlining that those choosing to continue working remotely had perhaps grown more than used to it by now.
While many of the factors motivating the work mode choices of software developers that we uncovered (Figure 1) (and that are discussed in existing studies [9]) are not something companies could ultimately hope to affect, some of our findings could be leveraged to also motivate developers to occasionally work on-site in hybrid work settings. In this regard, the key interplay between remote work and on-site work for developers working remotely seemed to be about social interaction. In fully remote work during the COVID-19 pandemic, one notable issue was the lack of social interaction [6], [7]. Our respondents mentioned primarily going to the office specifically to interact with their coworkers F2F, in order to alleviate this issue associated with remote work. From the point of view of individual well-being, WFA may be preferable to fully remote work in this fashion. However, remote work remains a challenge from the point of view of teamwork and collaboration [8], [31] based on our data as well. While occasional on-site workdays could alleviate this issue, getting developers to show up on-site remains a challenge in achieving this.
Existing research has suggested that the two work modes (remote and on-site) could be leveraged to increase productivity, with remote work better suited for individual tasks requiring focus, and on-site work more suited for tasks requiring collaboration [22]. The developers we interviewed, however, did not consider their remote and on-site days to differ in terms of work tasks. Remote work was simply considered even more beneficial for productivity when there were clear tasks to work on. Only one respondent mentioned that on-site days were useful for asking non-urgent, less specific questions, which they might not ask at all when remote. In this regard, better understanding what types of tasks exactly could be better carried out on-site might be helpful in motivating developers to come to the office. This requires further research into hybrid work in SE specifically, as many existing studies simply look at knowledge workers in general.
In SE, communication remains key due to its team-centric nature. Our results indicate that remote work does not seem to negatively affect communication and collaboration inside individual software teams. On the other hand, our data and existing studies point towards collaboration between teams suffering from remote work, with teams becoming more siloed [31]. WFA could, however, help in this regard as well, if on-site days are successfully utilized to combat this.
One key challenge in terms of communication in remote work is the onboarding of new employees, which was found to be a challenge in studies conducted during the COVID-19 pandemic WFH situation [32], [33]. This was still perceived as a challenge by our respondents as well, even in a hybrid work setting. More experienced developers who were familiar with their co-workers found mostly remote work largely unproblematic in terms of communication, while new employees may struggle to become a part of the team. However, with WFA once again making on-site work possible as well, it is possible to combine good remote work onboarding practices with on-site ones. The respondents in our study emphasized that on-site days should be more frequent when onboarding new teammates.
In this regard, tacit knowledge transfer has also been regularly discussed as one potential issue in remote work. However, the junior software developers we interviewed did not seem concerned in this regard. Both junior developers felt that remote collaboration helped with learning good practices, and felt that they were receiving help as needed and learning as a result. In particular, practices such as collaborating through screen share or pair programming can be helpful in this regard. It seems that the digital nature of programming work alleviates this issue in SE. However, on-site work may still play an important role for junior developers in getting to know their colleagues, which seems more challenging remotely than on-site.
Finally, though we received some initial insights into how hybrid work may impact software development practices in particular (e.g., the above example about screen sharing and pair programming), we feel that this is something future research should focus on in particular when studying hybrid work in SE. Software development, among other things, is what is unique to SE compared to other knowledge work, making it something studies from other fields looking at hybrid work are unlikely to provide insights into. Some existing studies have discussed how remote work impacts SE practice (e.g., pair programming [21], developer and stakeholder communication [19], which some of our respondents also considered negatively impacted, or even agile in general [20]), but we feel that much work remains to be done in this regard. It is arguably possible that there is, in fact, little impact to be found, but this is also something that has to be established first.
A. Practical Implications
1) Keep Both On-Site and Remote Work Possible
Different people prefer different work modes. Some are more productive at home, while others feel more productive at the office and may not have a suitable home office. Some may struggle to stay focused and disciplined when working at home. Those that do like working remotely seem to have grown increasingly attached to remote work, to the point where many would rather quit than go back to working fully on-site [10].
However, having half-empty offices that you still pay rent for is another issue. This could be alleviated by downsizing offices, rather than entirely getting rid of them, while encouraging people to occasionally come to the office. Remote work is considered to be mentally taxing by many, as a result of the lack of (informal) social interaction with colleagues. This issue can be alleviated through WFA, as developers are able to occasionally work on-site and see their colleagues F2F, further underlining the continued usefulness of office spaces.
2) Set Up On-Site Days
Tell people when to come to the office. The main reason developers working remotely come to the office is to talk to their coworkers F2F. If there is no one else at the office when the developer does show up, this will make it feel like a pointless visit. Even having one day a week where office presence is recommended may help in this regard. Teams may struggle to do this on their own. Consider also leveraging on-site days by having developers focus on tasks that would benefit from closer collaboration.
3) Use Events to Get People to the Office
Events such as quarterly plannings or retrospectives are likely to bring developers to the office. This way you can also make the most out of it when people do come to the office. Have meetings and events that would benefit from having developers physically present. Consider setting up, e.g., testing days on-site. This can also be one way to make on-site days more focused on collaborative activities.
4) Place More Emphasis on Onboarding New Employees
Remote work is easier for senior developers working with familiar teammates. New employees have a harder time getting familiar with their teammates in a remote setting and becoming a part of the team in more than just name. One solution could be to have a period of prioritized on-site work within the team when a new employee joins the team. Another solution could be to employ a work buddy system. Finally, collaborative practices such as pair programming may be helpful in this regard.
B. Limitations
Explorative qualitative research has well-known limitations relating to descriptive, interpretive, and theoretical validity [34]. The generalizability of the results and potential bias need to be considered as well.
In this study, we have utilized a single case study to delve into what we consider to be a novel phenomenon. While numerous studies on remote work were published during the COVID-19 pandemic WFH situation, hybrid work or work-from-anywhere is currently an emerging and topical issue for many software organizations, making it, we argue, a novel topic. While our single case study approach is nonetheless a limitation, we consider the novelty of the topic to partly justify it.
Moreover, we conducted an in-depth case study with interviews with 10 respondents of varying profiles, at a company we considered to be an interesting case for studying the topic (due to Company A’s policy where developers were free to select their own work mode). This, we feel, supported our aim of understanding what motivates the work mode choices of software developers, even though they were all from Company A. The respondents were also a very diverse group of people (life situation, gender, experience, etc.), which we feel contributes to making our findings interesting. On the other hand, we feel that our single case study approach presents limitations in terms of studying SE work practices in particular, as different organizations may have varying work practices for their software teams, resulting in more variety on the level of individual developers as well.
In terms of bias in qualitative research, we attempted to mitigate bias by having two researchers actively participating in the data collection, analysis, and reporting. Some additional discussion about the results was also conducted with a representative of the company who was working on their hybrid model planning project. We feel that the combination of the first author being an academic researcher and the second author being experienced in the software industry helped to ensure the interpretative validity to some extent, although a larger sample size might be preferable nonetheless. Within the context of this one case, we felt that we achieved data saturation with our research instrument, and felt that further data collection was not needed.
When considering theoretical validity the fact that only people from the same company were included (although from various business units, multiple teams and roles) should be kept in mind. As our goal was to explore a novel phenomenon, we chose to accept this limitation as it also gave some cohesion to the answers of the respondents. However, drawing generalizable conclusions from these results to other types of organizations may require caution in some regards.
Finally, there are limitations to the data analysis approach we have utilized. Through thematic analysis, we have aimed to analyze the qualitative data in a systematic fashion. However, reporting the results through the themes and codes always involves some summarization on our part that omits some details and individual accounts. While we have included any individual accounts we thought were of interest from the point of view of our study, this process is ultimately still subjective.
Conclusion
In this study, we looked at WFA from the point of view of software developers through a single case study. We interviewed ten software developers with varying backgrounds, both in terms of personal attributes, personal life, and work experience. The study had two aims. First, we explored what factors influence the work mode choices of software developers when they are free to choose between remote and on-site work, and what benefits they consider each work mode to have. Secondly, we explored how on-site and remote work could be leveraged together in hybrid work or work-from-anywhere to alleviate the issues associated with each work mode (remote and on-site) while leveraging the benefits of both.
In terms of the first goal, we found various factors that influenced the preferences of software developers. In terms of overall work mode of choice, there were clearly some who preferred on-site work and some who preferred remote work, for the same reasons, with some more productive on-site and some more productive remotely. We also uncovered various reasons developers alternated between the two modes of working on individual days. These are summarized in Figure 1.
In terms of the second goal, we provided some initial insights into how the two work modes supported each other. For example, developers largely working remotely commonly liked to occasionally have an on-site day that was largely dedicated to social interaction with colleagues, whereas purely remote work was considered oppressive due to feelings of social isolation. WFA did not seem to have notable implications for software development practices in the case company, however, with nearly all tasks being done digitally by default.
As WFA continues to remain common, we feel that further studies investigating how WFA could be leveraged in SE are needed. Despite on-site work becoming more common again, little is currently known about how remote work and on-site work could be combined to potentially increase productivity or to provide other benefits, and specifically in relation to SE methods and practices.
We summarize our key takeaways as follows (see also Figure 1 and Table 5): (1) the pandemic WFH context was not a suitable setting for developing lasting hybrid work practice recommendations due to its unique and fully remote nature, (2) WFA seems to be a natural modus operandi for software professionals, and the key challenges they now face in their work seem to be related to other issues than work mode ones, and (3) software companies need to fine-tune their post-pandemic hybrid work models informed by the practical recommendations emerging from the growing body of research on hybrid work and WFA.
Finally, we recommend the following future research directions. Overall, we recommend further studies into hybrid work from the point of view of SE practices and methods specifically. While hybrid work (and remote work) have been topics of interest across disciplines, it is the SE practice that sets SE work apart from other types of remote work. Existing studies have begun to explore, e.g., how well different agile practices work remotely [29] and what types of SE tasks are carried out remotely and which are better carried out on-site [28], but much work still remains to be done in understanding how to best organize SE in a hybrid environment.
Appendix. Interview Instrument
Appendix. Interview Instrument
The interviews of this study were conducted in a semi-structured fashion and in Finnish. Thus, the questions below (translated into English here) were asked of each respondent, alongside various additional questions asked based on the individual responses of the respondents.
Background Information
What is your job title? What about your role in practice?
How many years of relevant job experience do you have? Or, in other words, how long have you been getting paid for programming?
What kind of team and/or projects are you currently working on? We are mostly interested in team size and the number of projects.
Are you currently working primarily remotely or on-site? What is the ratio of remote days and on-site days? For example, 60/40, 80/20, etc.
Current Work Situation Overall
What things currently most hinder you work overall? Anything that comes into mind.
What things currently most facilitate or improve your work overall? Anything that comes into mind.
Typical Work Day
What is your typical work day like when you work remotely?
What is your typical work day like when you work on-site?
Remote Work
What are the biggest positives of remote work?
What are the biggest negatives of remote work?
On-Site Work
What are the biggest positives of working on-site?
What are the biggest negatives of working on-site?
Software Development Practices / Method
Are you using any established software engineering method in your team(s)?
Potential additional questions: have you come up with any practices of your own? Are you using the method by the book or have you tailored it in some way? Do you reflect on your work practices in retrospectives?
Personal Preferences
If you could freely decide, and had absolute power over the company to decide how work is organized, how would you prefer to work?
If you could freely decide, and had absolute power over the company to decide how work is organized, what do you think would be the best way to organize work in terms of productivity?