{"paper_id":"3ed21615-efe2-4828-8db2-86fcce145dd2","body_text":"When Coordination Goes Wrong: The Challenge of Configuring Malleable Technologies in Teams | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article When Coordination Goes Wrong: The Challenge of Configuring Malleable Technologies in Teams Rosa Fabricius Zhang, Charlotte Jonasson, Jesper Aagaard This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-7489297/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 11 You are reading this latest preprint version Abstract The introduction of malleable technologies offers new opportunities to continuously adapt technical systems to the dynamics of evolving teamwork. These open-ended technologies enable users to co-define system capabilities through configurations. However, while configurations of malleable technologies are central to achieving the promised task-technology fit, whether team members accomplish in coordinating such technology configurations to suit the collective team remains underexplored in the current literature. Drawing on a nine-month qualitative field study at a Scandinavian IT company, this study investigates the process of malleable technology configurations in teams (specifically, digital project management tools). Using the theory of situated knowledge, we show that the team coordination of technology configurations is hindered by three emerging understandings within teams—assumed symmetry, assumed intentionality, and assumed adequacy. These divergent, yet simultaneously valid knowledge claims emerge from the sociomaterial interplay between malleable technologies and differently positioned team members and constrain their ability to engage in configurations meaningful to the collective team. By unpacking the process of configurations in teams, our study explains why malleable technologies do not always lead to the intended positive outcome of continued technological support but can instead entail time-consuming challenges in ensuring team usability. Malleable technology groupware technology configuration coordination situated knowledge ethnography Figures Figure 1 Figure 2 1. Introduction Digital technologies have profoundly shaped the nature of teamwork, enhancing collaboration and the organization of tasks (Larson and DeChurch 2020 ). Yet, to ensure their continued usefulness, such technologies should ideally evolve alongside the changing dynamics of teamwork, and, thus, malleable technologies have gained increasing traction in collaborative settings over the years (Richter and Riemer 2013 ; Mousavidin and Silva 2017 ; Larsen-Ledet and Borowski 2021 ; Hunger and Hirlehei 2013 ; Tenório, Pinto, and Bjørn 2018). Malleable technologies are general-purpose technologies that allow ordinary users to modify or configure their capabilities according to user preferences (Lehrig, Krancher, and Dibbern 2019 ; Richter and Riemer 2013 ; Schmitz, Teng, and Webb 2016). Because of their openness and lack of specific purpose, configuration – the material (re)arrangement of technological elements in a digital technology, is necessary to realize the value of malleable technologies in their local contexts (Majchrzak et al. 2000 ; M.C. Moon, Hills, and Demiris 2018; Wiegel et al. 2019 ; Ellingsen, Hertzum, and Melby 2022 ). In team settings, because of the strong technological interdependence among team members, this process should ideally involve coordination to ensure configurations resulting from the management of individual dependencies to the shared technological systems (Domingos and Martins 1997; Pipek and Kahler 2006 ). We refer to this idealized form of configuration in teams that shows considerations for the different needs and preferences of team members as team coordinated technology configuration . However, despite its importance for unlocking the potential of team usability of malleable technologies, the process of configuration has received limited scholarly attention (Cabitza and Simone 2017 ; Mousavidin and Silva 2017 ). This gap is problematic, as without a processual understanding of whether team members coordinate configurations in practice, we risk overlooking how and why the implementations of malleable technologies may not always result in an evolving technological system tailored to the changing team needs (see e.g., Germonprez and Zigurs 2009; Huysman et al. 2003 ; Wulf 1999 ). According to Richter and Riemer ( 2013 ), malleable technologies introduce a radically different adaptation process based on bottom-up, voluntary, and explorative dynamics that challenge the existing theories on technology change, focusing on top-down, planned, and prescribed implementation. Their highly unpredictable adaptation process further underscores the need to understand the emergence of coordinating such configurations through bottom-up interactions. Mousavidin and Silva ( 2017 ) reach similar conclusions in their literature review and call for in-depth field studies investigating the social and organizational dynamics shaping the configuration process of malleable technologies. In this paper, we examine how team dynamics influence team coordinated technology configurations of digital project management tools. Thus, our study is guided by the following research question: How do team members’ socio-material interactions influence their coordination of malleable technology configurations? Drawing on empirical data collected through a nine-month qualitative field study at a team-based IT company in Scandinavia, we study the configuration process of digital project management tools (DPMTs) in software development teams, particularly Atlassian Jira and Azure DevOps Server. DPMTs are a form of malleable technology widely used across various team contexts to support the planning and distribution of work (Raith, Richter, and Lindermeier 2017 ; Zhang 2024 ). Adopting the theoretical lens of situated knowledge, we find that new configurations are obstructed by three emerging understandings of current configurations in teams: assumed symmetry, assumed intentionality , and assumed adequacy . Mediated by the distinct interplay between team organization and malleable technology, these understandings give rise to misalignment, compromise, and passivity – impeding the coordination of new configurations. Our findings demonstrate the essential, yet complicated work involved in technology configurations in teams, and highlight how this work shapes the effects of malleable technologies in collaborative work. Consequently, we unpack the socio-material “enactments” of malleable technologies and demonstrate how technology malleability can complicate, rather than facilitate, task-technology fit in teams. In doing so, we contribute to the field of CSCW by illuminating the implications of malleable technologies for cooperative work from users’ perspectives (E. Moon and Howison 2024), and providing new concepts guiding the appropriation and management of malleable technologies in team organizations (Richter and Riemer 2013 ). The rest of this paper is structured as follows: First, we review the literature on malleable technologies in team settings. Second, we introduce the theoretical framework of situated knowledge. Third, we describe our methodology and present the study findings. Fourth, we discuss the theoretical contributions and practical implications and highlight directions for future research. 2. Literature background 2.1 Malleable technologies and teamwork Malleability is a quality of technology design that allows the digital technologies to be configured by end-users within the context of use to support a wide variety of work practices without changing the software source code (Richter and Riemer 2013 ; Mousavidin and Silva 2017 ). This characteristic distinguishes malleable technologies from traditional digital systems, where post-implementation changes are typically costly and require extensive collaboration between users and suppliers (see e.g., Fleck 1994 ). Given that group interactions and requirements are often hard to predict (Lyytinen, Maaranen, and Knuuttila 1993), the field of CSCW has long viewed malleability as a key requirement for groupware – digital technologies that support interpersonal processes in collaborative work, as malleability enables teams to continuously adapt technologies to align with their evolving practices and preferences (Cabitza and Simone 2013 ; Mandviwalla and Olfman 1994 ; Slagter, Biemans, and Hofte 2001; Wulf, Stiemerling, and Pfeifer 1999 ; Wulf 1999 ). Nevertheless, this malleability also implies that such technologies are general-purpose tools that, by themselves, are incomplete and ill-suited for any specific context of use (Fleck 1993 ; Mousavidin and Silva 2017 ; Peine, Rollwagen, and Neven 2014). This intrinsic openness mirrors the biological notion of altriciality , which refers to species—such as humans—whose offspring are born in an underdeveloped state. While this early-stage incompleteness fosters adaptability, it also entails a deep dependence on caregivers. Similarly, configuring malleable technologies is not merely optional – it is often indispensable for making these technologies useful for the local context (Majchrzak et al. 2000 ; M.C. Moon, Hills, and Demiris 2018; Wiegel et al. 2019 ). This is confirmed by empirical studies demonstrating that the positive impact of malleable technologies on teamwork is contingent upon making configurations supporting team tasks and communication – i.e., establishing task-technology fit (see e.g., Correa and Selbach 2021 ; Magnus Li and Nielsen 2019 ; Slagter, Biemans, and Hofte 2001; Sommerville 2008 ; Wulf, Stiemerling, and Pfeifer 1999 ). However, task-technology fit does not automatically come with the implementation of malleable technologies in teams. For example, Huysman et al. ( 2003 ) find that configuration efforts often cease shortly after implementation of malleable technologies and appear to be path dependent for each team. Wulf ( 1999 ) finds that team members frequently struggle to comprehend the configurations made by others. This is not least the case in a context with relatively loose governance of configurations (cf. Shaikh and Henfridsson 2017 ), a common condition in teams enjoying relatively great autonomy (Mathieu et al. 2019 ). As existing studies (Germonprez and Zigurs 2009; Majchrzak et al. 2000 ; Thomas and Bostrom 2010 ; J. P. Bansler and Havn 2006 ) mainly focus on the outcome of configuration, treating the antecedent process as a black box, we still lack the theoretical explanation of why malleable technologies do not always yield successful configurations that support team needs. 2.2 The role of coordination in the configuration of malleable technologies in teams When configurations take place in a team setting, they should ideally be a collaborative effort, with members jointly identifying and implementing suitable configurations (Pipek and Kahler 2006 ). This is especially important when malleable technologies are used as groupware, because such tools create a high degree of technological interdependence among users, so they cannot reject a shared configuration without losing access to essential functionality (Pipek and Kahler 2006 ). Moreover, because team members often diverge in their information and goals (also known as information asymmetry and goal asymmetry) (Edmondson, Roberto, and Watkins 2003 ; Pearsall and Venkataramani 2015), the configuration process should ideally involve all team members to ensure technology usability. Thus, team coordination has been suggested as an essential activity in technology configurations (Domingos and Martins 1997; MacLean et al. 1990 ; Pipek and Kahler 2006 ). Coordination refers to the set of activities that ensure individuals work interdependently according to defined plans, rules, and roles to reach common goals (Bailey, Leonardi, and Chong 2010 ; Faraj and Xiao 2006 ; Okhuysen and Bechky 2009 ). In team settings, where multiple individuals contribute to a shared task, coordination is required to produce a positive outcome (Mathieu et al. 2019 ). This is also expected in relation to the configurations of malleable technologies, which should ideally be based on collective goal setting and decisions resulting from the management of individual dependencies to the shared technological systems (Malone and Crowston 1994 ; Pipek and Kahler 2006 ). It is suggested that appointing a local expert responsible for coordination may benefit the configuration process of malleable technologies (Slagter, Biemans, and Hofte 2001; Pipek and Kahler 2006 ). This, however, requires that such an expert can create a balance between the evolving technology and organization (Griffith, Sawyer, and Poole 2019 ). To highlight the collaborative character of this idealized form of configuration in teams, we refer to them as team coordinated technology configurations. This distinction is necessary, as the theoretical influence of coordination on malleable technology configuration has yet to be examined empirically, and such coordination can be difficult to achieve for at least two reasons. First, because configuration can be executed by single users, it does not technically presuppose coordination. Second, reaching consensus on a configuration solution that suits all team members can be challenging, especially in teams with diverse needs and practices. Moreover, as there is a dearth of studies examining the process of team configurations of malleable technologies (Mousavidin and Silva 2017 ; Cabitza and Simone 2017 ), it remains unclear whether and how coordination of the ongoing configurations takes place and how this influences the ongoing fit between technology and team. 3. Situated knowledge This paper investigates how teams engage in the ongoing process of configuring their malleable technologies. To do so, we adopt the lens of situated knowledge theory. This perspective (Gherardi 2008 ; Haraway 1988 ) conceptualizes knowledge not as a static possession, but as a dynamic, socially embedded accomplishment, termed ‘knowing’. Knowing emerges through active participation in a web of relationships among people, artifacts, and practices (Gherardi 2001 ; Orlikowski 2002 ). It is materially grounded in the body of the knower, shaped by discourse, and situated within specific historical and physical contexts (Gherardi 2008 ). Digital technology plays a central role in this process, serving as a material scaffold for organizational knowing. Orlikowski ( 2006 ) describes technologies as the “scaffolding of knowledgeability” (p. 462): they structure, guide, and at times discipline human activity. Yet, their role is often easy to overlook, as once knowledge is enacted, the scaffolds that supported its formation become obsolete. By foregrounding the situated nature of knowledge, we aim to move beyond the conventional view of knowledge as an internal, cognitive representation. We instead propose two key shifts. First, knowledge is embodied—partial, material, and technologically mediated (Dreyfus and Dreyfus 1986; Haraway 1988 ; Orlikowski 2006 ). Second, knowledge is collective—cultural, historical, and publicly observable (Lave and Wenger 1991 ; Wittgenstein 1954 /2009). Together, these shifts suggest that knowing is an active, situated practice carried out by individuals within specific sociomaterial contexts (Haraway 1988 ; Orlikowski 2002 ; Orlikowski and Scott 2008 ). This partiality is both a limitation—introducing bias and constraint—and a resource, enabling specific forms of insight and capability (Simandan 2019 ). Emphasizing the embeddedness of knowing also raises a crucial question: how do multiple situated knowledges relate to one another? Are they complementary, conflicting, parallel, or intersecting? Law ( 2000 ) introduces the concept of knowing-as-displacing to describe the inevitable tension that arises from the coexistence of multiple knowledge-in-practice. Because each enactment of knowing is partial and situated, there can be simultaneously valid, yet divergent, knowledge claims. Technology further amplifies this multiplicity by enabling diverse knowledge locations (Bruni, Gherardi, and Parolin 2007). This plurality can give rise to coordination challenges: different knowings may coexist but remain incommensurate, never fully reconciled (Barley, Treem, and Kuhn 2017 ). These questions of multiplicity and coherence only become more salient in team settings and lie at the heart of our inquiry—and we will return to them in due course. 4. Methodology 4.1 Research design and context To investigate the research question, we conducted a qualitative field study (Spradley 1979 , 2011 ) at a Scandinavian IT company guided by a critical realism-inspired view of human-technology relations (Kempton 2022 ; Leonardi 2013 ). This approach was particularly suitable to examine practices of work as situated in sociomaterial assemblages (Blomberg and Karasti 2013 ), which is useful for outlining the multiplicity of knowing complicating the configuration of malleable technologies in teams. We purposefully sampled the field organization InnoSoft (pseudonym) as the place to conduct this study. In many ways, InnoSoft provided the theoretically ideal condition for team coordinated technology configurations. As a small organization with a flat hierarchy, the work teams at InnoSoft have a large degree of freedom to define their own work process and choose their own groupware. Although the two standard DPMTs (particularly, Atlassian Jira and Azure DevOps) at InnoSoft were furnished with default settings, there was no officially prescribed way of using these tools, and the teams were permitted both technically and organizationally to configure these tools as they liked. Moreover, since the teams at InnoSoft were software development teams, even the project managers who did not necessarily have a software education were decently technically skilled compared to the public. Thus, the InnoSoft teams possessed the autonomy, control over technology, and basic technological knowledge that should, in theory, empower them to engage in team coordinated technology configurations of malleable technologies (Lehrig, Krancher, and Dibbern 2015; MacLean et al. 1990 ; Richter and Riemer 2013 ). This is supported by the general attitude of DPMTs as ‘flexible tools’ shared by many employees of InnoSoft. Although the malleability of DPMTs can be different depending on the specific version of these tools, the currently popular DPMTs generally offer users plenty of possibilities for making configurations (Arya and Kulkarni 2024 ; Buturugă, Gogoi, and Prodan 2016; Jira 2024 ). While it is beyond the scope of this paper to outline all the configuration possibilities of Atlassian Jira or Azure DevOps, we will provide two concrete examples to illustrate the kind of configurations involved in the current study. The first example is related to the task-creation feature of DPMTs, which leads to a new interface containing a predefined template of a task with both mandatory and optional text fields. The quantity and the order of these text fields can be configured. Moreover, the teams can also create or remove categories used to specify, e.g., issue type and components (see picture 1). The purpose of configuring such a predefined template of task creation is to ensure that the tasks are created consistently, containing all the necessary information, and that the teams can use the filter feature to quickly locate the tasks of interest. Picture 1: An example of a task creation interface in Atlassian Jira. (Source : https://www.softwaretestinghelp.com/atlassian-jira-tutorial-3/ ) The second example is related to moving tasks on the task boards of DPMTs to update work status (see picture 2). This can be, e.g., moving a task from the column of ‘To Do’ to ‘Doing’ to indicate the start of a task. It is possible to configure various automations in relation to such movements, and a common automation for the aforementioned movement is automatically assigning the issue to the user who has moved the task. The rationale of this configuration is to save additional work of subsequently having to assign the task to oneself. Picture 2: An example of updating work status on a digital task board in Azure DevOps (Source : https://learn.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops&tabs=basic-process ) 4.2 Data collection This study was a part of a larger qualitative field study examining the use of DPMTs and collaboration in software development teams. The malleability of DPMTs, particularly the frustrations over the configurations of these tools, emerged as a theme of great importance to the team members’ collaboration early in the data collection process. The field work was conducted by the first author under the close guidance of the second and the third author. Within InnoSoft, seven software development teams were selected in collaboration with the gatekeeper based on the principle of maximizing variation (Flick 2018 ). This resulted in the inclusion of teams with different team sizes and different lengths of collaboration history. The first author followed these teams over nine months (May 2022 -January 2023) using participant observation and semi-structured interviews. When possible and allowed, she also collected screenshots of the DPMTs used in the teams as digital documents. For an overview of the data sources, see Table 1 . Table 1 An overview of the data sources Data source Description 720 pages of field notes in Microsoft Word (single-spaced 11-point Calibri) Based on 75 days of participant observation performed on the following occasions: - Observing individual team members working at the office (40 days) - Breaks and meals in the office lounge (10 days) - Daily team status meetings (50) - Team evaluation meetings (10) - Team planning meetings (15) - Team review meetings (15) - Weekly company meetings (15) - Other meetings (10) 22 Semi-structured interviews Lasting 30 to 90 minutes with team members of different positions and seniority. - Team members with leadership functions (e.g., project managers, scrum masters): 8 - Ordinary team members (e.g., front-end developers, business analysts): 14 400 pages of digital documents Consisting of, among other things: - Screenshots of the DPMTs used in the project - E-mail and chat correspondence between team members - Minutes of meetings - Company newsletters The overall procedure of the field work resembled the guidelines suggested by Spradley ( 2011 , 1979 ). The first author started with descriptive observations to familiarise herself with the language and life of software development teams at InnoSoft and their overall use of DPMTs. This was followed by more focused observations, which sought to elucidate how the configurations of DPMTs influence the practices of team members at different occasions of work, e.g., in meetings, working in pairs, and working individually. During participant observations, the first author noted down questions and observations, which she then used to conduct informal interviews when suitable opportunities arose. Such informal interviews lasted between 3 to 45 minutes; however, they were mostly kept around 10 minutes for the sake of the participants. While being in the field, the first author conducted detailed and verbatim jottings of the observed events, which she then wrote into field notes as soon as possible after returning from the field. After progressing into more focused observations, the first author started to contact team members to schedule semi-structured interviews. Contrary to the informal interviews conducted in situ, these semi-structured interviews were performed at company meeting rooms or via videoconferencing while the participants worked from home. Thus, they allowed the team members more privacy and time to explain and elaborate on their thoughts and experiences regarding the configurations of DPMTs without the risk of other team members overhearing the conversation. The interview guide was informed by the insights gained during participant observation and tailored to suit each interviewee’s team membership, job position, and seniority. However, it also contained generic and open questions to allow the exploration of topics of interest to the participants. Because InnoSoft teams were organized in different ways, and team members did not have clear-cut job titles, to ensure the confidentiality of the participants, we simplified the job roles into two categories in Table 1 . Combining participant observation and semi-structured interviews offered us the opportunity for method and data-source triangulations (Carter et al. 2014 ) and was essential for uncovering the different perspectives and sometimes contradicting understandings regarding DPMT configurations within a software development team. 4.3 Data analysis We followed the structure of thematic analysis (Braun and Clarke 2006 ), which provided a systematic and theoretically flexible approach for analysing qualitative data. The first phase of familiarizing yourself with data was commenced soon after the collection of the first field notes, where initial ideas were noted down to help adapt the data collection strategies ongoingly. It was at this stage that we became aware of the seemingly contradictory relationship between, on the one hand, the potential malleability of DPMTs, and on the other, the actual frustrations and struggles team members experienced in their daily use of DPMTs. To investigate this discrepancy more closely, the first author conducted inductive coding of the entire dataset guided by attention towards the team members’ different attitudes, experiences, and understandings of DPMTs. Following the recommendation of Braun and Clarke ( 2022 ), this inductive coding was repeated a few times to ensure the consistency of codes without undermining the diversity of meanings contained in the dataset. All three authors participated in the next analytic phase of searching, reviewing, and defining themes. This was conducted in an iterative manner, where we moved back and forth between these three steps. Here, we also started with an inductive approach, where we grouped codes based on their broader thematic similarity. However, to make sense of these inductively identified themes, we conducted a comprehensive review of the literature regarding malleable technologies and configurations in teams. By comparing our initial themes with the existing literature (among others, Mousavidin and Silva 2017 ; Richter and Riemer 2013 ; Schmitz, Teng, and Webb 2016), we realized that our data provides a processual view on the configuration of malleable technology in teams that was sought after in the current literature. By further refining the themes into three to identify the central mechanisms impeding team coordinated technology configurations, we come to realize the centrality of knowing, particularly the multiplicity and displacement of knowing, in explaining these processes. As this insight emerged, we consulted the literature on situated knowledge (among others, Gherardi 2008 ; Haraway 1988 ; Orlikowski 2006 ) to further refine the three themes into the current version. Table 2 provides examples of data excerpts underpinning the three themes. Table 2 Examples of data excerpts underpinning the three themes Examples of data excerpt The final themes (Field note taken while observing individual team members working at the office) Bob asked Charlie whether he had administrator access to project Alpha’s DPMT. Charlie was quite convinced that he was not the administrator for project Alpha’s DPMT. Bob went out of the office, and shortly after, he came in again. Bob went over to Thorvald, a former developer on project Alpha: “Can you give me more access to [DPMT]?” Thorvald: “No, I cannot, I am only a guest.” Bob: “It just said that you are an administrator.” Charlie: “Is it really me, who is the administrator?” Assumed symmetry - Misalignment (Formal interview with an ordinary user) James: ‘You get used to it. I’ve worked with it (DPMT) for many years now. It’s frustrating that when I need to select components, I have to choose from a list of 40, even though we only use three of them. It shouldn’t be such a struggle; it should just be easy to use. […] Unfortunately, we’re impacted by components from other projects. That’s just the way it is.’ Assumed intentionality - Compromises (Formal interview with an ordinary user) Mike: ‘I have to admit, at some point I just said, okay, this is how they (the team) do it. I am not set on this project to clean up their [DPMT], so I just take it as it is.’ Assumed adequacy - Passivity 5. Findings 5.1 Assumed symmetry – Misalignment Similar to many other organizations concerned with information and data security, the software teams of InnoSoft adhere to the principle of ‘least privilege’ when managing access to groupware such as DPMTs. This principle prescribes a cautious approach to software access management, where individuals only receive the minimum level of access required to perform their job functions effectively. The team members are well aware of the security reasons behind the differentiation of technology access and the logic of the least privilege principle: Steve: ‘So that's also why we don't give people access to everything, because I might end up having access to delete the entire project. I could end up deleting it, maybe... So, one should only give access to what is needed.’ (interview) Therefore, only a few selected individuals within each team, the so-called ‘super users’, have access, or the behavioral capability to configure their teams’ DPMT: Carl: ‘Actually, I recently became a super user in [team X], and I therefore have some extra privileges, such as being allowed to make automation and stuff like that on our [task] board. I was just appointed the one who received these privileges and can do this if there is a need for something. It is called “super user”.’ (interview) The remaining team members typically commence with the minimum level of access, which means that they can only use and see DPMTs as these tools are configured, either by default or by the super users. These team members usually refer to themselves as ‘the rest of us’ or ‘ not super users’, which we, for the sake of simplicity, refer to as ordinary users. The teams themselves do not expect that the differentiation of technology access will pose any challenge for configuring DPMTs, because ordinary users arguably still can make use of technology malleability by requesting a super user to make configurations on their behalf. This belief is particularly supported by the fact that in InnoSoft, super users do not necessarily possess more formal power than ordinary users (e.g., by officially holding a higher position), and the teams generally strive towards self-management. However, because the interfaces of DPMTs appear differently depending on your level of access, the differentiation of access creates two different ways of experiencing the groupware for super users and ordinary users, unbeknownst to the team members. Unaware of the differences between their perspectives, both parties encounter difficulties in comprehending the other party’s user experience, which impedes meaningful coordination. This is reflected in the following interview with software developer Steve, who describes the challenge of being an ordinary user in a team. Steve: ‘Sometimes, it is rather confusing. There was once this project, where I had to… It was really annoying that I couldn’t see logs, for example, because… Apparently, I didn’t have access to it. So, I sat there for a long time and thought, “Why couldn’t I see logs here?”’ The researcher: ‘You can’t see logs if you…?’ Steve: ‘Sometimes, it again depends on which access you have. So, there had been a few times when I couldn’t see why I couldn’t see it. So I went to Dean, and it turned out that he could see it because he had more access to it than I had.’ The researcher: ‘Okay, so maybe you thought in the beginning that you just can’t see logs in this tool?’ Steve: ‘Yeah, so I had thought that, yes, so and so, why can’t I find my way around in here? Or that I had been stupid, right? It turned out that it was simply because I didn’t have access.’ In this incident, neither Steve nor his super user colleague Dean was initially aware that the problems Steve encountered were caused by his limited access. However, this was only discovered as Steve directly compared his perspective of the groupware with Dean’s. This demonstrates how a distinct knowing of assumed symmetry is enacted in the context of dissimilar user positions and the belief of equal technology access and capabilities. By expecting the others’ experience as not identical, but similar to their own, this assumed symmetry makes super users interpret their additional behavioral capabilities as common options for all team members. For ordinary users, this assumed symmetry hinders them from realizing and discovering alternative configuration solutions that may benefit their work. At the team level, this assumed symmetry results in a misalignment , where users talk past each other and fail to recognize their disparities of perspectives and experiences with the malleable groupware that are simultaneously valid. This lack of coordination between perspectives is problematic, because the configurations of DPMTs become more a reflection of the personal preferences of the super users, as the ordinary users cease their involvement when realizing their inability. This is reflected in the following comment of ordinary user Percy when talking about a feature of DPMT that irritates him: Percy: ‘I could have just asked Raymond (super user) to do it. But the thing is, I haven't really bothered to move forward with it. When I realized I couldn't, I said, \"Fuck it,\" and moved on to do something else.’ (interview) This theme shows that the differentiation of access creates dissimilar positions (super user vs ordinary user) of experiencing the malleable groupware that cannot be grasped by any single user alone. Unaware of the diversity in perspectives, the individual team members develop a knowing of assumed symmetry, where they expect the others’ experience with the technology as close to their own. At the team level, this results in a misalignment, where the disparities of perspectives and the struggles of ordinary users are ignored. 4.2 Assumed intentionality – Compromises Consistent with theoretical predictions in CSCW literature, team members at InnoSoft generally expect that malleable technologies such as DPMTs offer better support for teamwork because of their malleability. However, they also recognize that even malleable technologies cannot provide a perfect fit for every team process. Firstly, despite their malleability, DPMTs are built upon technical assumptions that are not subject to configuration, as in the end, these tools are intended for managing projects and not, e.g., sharing documents. This means that sometimes the process of configuration involves choosing between several imperfect solutions within the given malleability of a DPMT that only partially fits with the current workflow: James: ‘When we develop a feature, we have to develop it for both Android and iOS; however, sometimes we don’t do it in the same sprint, and we of course want to have only one (task) description for both tasks. However, if you do it as two sub-tasks under the same description, then we have to have both tasks in the same sprint. If we instead choose to clone one task, so there are two, one for iOS and one for Android, then we have suddenly two tasks with descriptions that need to be maintained, or one with a description and one without, so you need to find back to the description. It is very stupid. It is weird that they haven’t fixed it yet. We are not the only ones who develop for both Android and iOS.’ (field note) Secondly, even when a feature can be configured to perfectly match the team-specific workflow, this configuration solution may not suit the needs or preferences of all team members equally. As everybody in the team shares the configuration results, sometimes team members may have to endure obstructive configuration results to accommodate the needs of others: Steve: ‘It is a very annoying configuration, and it really confuses me. However, the others find it super nice. So, they (the team) said to me, “Well, you can just ignore it.”’ (interview) This means, despite malleability, the team members frequently endure small inconveniences and annoyances in their everyday work with DPMTs, which are not caused by the lack of possible reconfiguration (malleability) but rather by different preferences among the team members. This reality challenges the task of proposing new configuration solutions, as team members need to navigate a distinction between changeable features and features, they need to compromise on. This distinction is far from self-evident, as it requires knowing the local configuration history of the malleable technology – how the system has been adapted over time and why. For team members who simply were not there when configuration decisions were made, such knowledge is impossible to obtain without assistance. Since teams in InnoSoft frequently undergo staff changes and rotations, the reasons behind the existing configuration results of DPMTs tend to become products of team members’ own guesswork. Many choose to give the existing configuration results the benefit of the doubt, as illustrated in the following example: Oliver: ‘I suspect that they had already tried these different things, and also this (alternative) that I just proposed, and then it showed that for many people it simply didn’t work. So, I am not at all in doubt that a lot of thought had been put into how to do it, and then they had decided to go with the least evil way. At least, this is what I suspect, without knowing.’ (interview) Oliver’s account illustrates what we term a knowing of assumed intentionality , where team members individually rationalize existing configuration results as deliberate and reasonable choices conducted by someone in the past, despite not knowing the exact reason. This knowing helps the team members to accept that the current configuration solution does not fit their preferred way of working and adapt their own processes accordingly. However, although assumptions of certain configuration solutions being somehow valuable to someone in the team minimize potential conflicts in teams, they also prevent team members from critically questioning the existing configuration solutions and tolerate obstructive features, even when it is unnecessary. This becomes evident when joining the perspectives of team members together. In the following case, James comes to assume, mistakenly, that the default setting of his team’s DPMT is a result of a deliberate configuration process made by Ethan, who has been on the project from the beginning: James: ‘I wasn’t here when they started this project. But I think it is probably Ethan, as a developer, for example, who said, “We had done this in other projects, so let’s do it here as well”. It is probably them who use the [tool] on a daily basis, who have asked for configuring things this way, or have chosen to configure things as we used to do it.’ (interview) However, in a separate interview, when Ethan was asked about the same configuration solutions, he replied: ‘No, I wouldn’t say that we have prioritized it, it just ended up like this.’ This discrepancy reveals how assumed intentionality prevents team members from coordinating their understanding of what features can be changed in their teams. By unquestionably accommodating ‘each other’, the current configurations are preserved through ongoing compromises at the team level. This theme illustrates how the unavoidable differences in preferences among the team members, combined with the uncertainty around the local configuration history, give rise to a knowing of assumed intentionality among team members. This knowing allows them to rationalize obstructive configuration solutions and helps them adapt to imperfect systems. However, it also impedes the coordination between team members on what features can be changed in their teams. As a result, this knowing contributes to conserving the existing and sometimes dysfunctional configurations through ongoing compromises. 4.3 Assumed adequacy – Passivity Similar to many other software development teams, none of the team members in InnoSoft consider configuring DPMTs a part of their core job duties, not even the super users. These tools are adopted to support the teams’ task management and coordination needs. Hence, they should minimize their workload, not increase it. This fundamental assumption regarding DPMTs renders time spent studying, discussing, or configuring DPMTs illegitimate and bothersome. As explained by super user Samuel: Samuel: ‘You have to be careful not to use your entire work time on [DPMT] looking at stuff. At least if you are a developer, then you should only log on to [DPMT] to find out what you should work on and then go work on your code. At least I will try to avoid using too much time on administrating [DPMT].’ (interview) However, as the two previous themes already demonstrate, configuring malleable technologies often requires far more time and effort than a simple ‘quick in and out’. To discover the needs for new configuration solutions, teams must overcome misalignments and compromises caused by assumed symmetry and assumed intentionality. Afterwards, more effort is needed to identify alternative configuration options and agree on a single configuration solution, which best accommodates the team’s diverse needs – a process that becomes even more complicated when there are divergent opinions involved. Given this, team members often feel an implicit expectation from each other to have a ready-made configuration solution before initiating the configuration process at the team level, a condition that is seldom met: Jack: ‘Because you always have to, if you come up with such a suggestion, then you always have to also solve it in one way or another. So, if you don’t know the [DPMT] well enough for doing that, then it is also a bit difficult to pitch for a change.’ (interview) Exactly because some inconveniences and annoyances with DPMTs are unavoidable, as described in theme 2, having the alternative configuration solution ready is seen as necessary to ensure that the configuration process will result in something feasible and desirable, rather than futile and unproductive attempts. Nevertheless, this condition is seldom met, as most of the team members do not feel that they have the time or responsibility to explore the abundant amounts of configuration options offered by DPMTs and figure out the best alternative configuration solution. As a result, most of the time, the team members choose to tolerate that the malleable technology does not perfectly align with their desired workflow, despite the availability of other configuration options, which potentially may improve the situation: Benedict: ‘I know that we are not doing it perfectly, right? But we are trying our best, and it works well enough for us. We have the columns we need, and we have the labels we need.’ (interview) Thus, while the team members acknowledge that improvements are technically and theoretically possible, the effort required to configure and achieve a better fit between technology and practice is perceived as too burdensome, time-consuming, and beyond their role. This leads to the development of what we term an assumed adequacy – an acceptance of the current configuration solutions as ‘good enough’ despite the shortcomings. This knowing helps the team members tolerate the many default configuration solutions that come along with their DPMTs and only secure the minimum technological support necessary for their work. However, by helping individuals to privately settle for imperfect tools and avoiding unproductive complaints in team discussions, assumed adequacy essentially prevents the coordination of configuration satisfaction in teams. This hinders the team from realizing the extent of shared dissatisfaction as well as the many everyday workarounds team members perform to counteract some of the default configurations. Overlooking the needs of initiating the configuration process, the existing configuration solutions are preserved in a passivity , where the team is unable to make use of the malleability of the groupware nor ask for help from external resources: James: ‘So… There are some [DPMT] administrators (in the organization), however… I don’t think that they will do anything unless the project teams approach them and tell them what they want. However, as a team member working on a project, we don’t really know what exactly is possible, because we don’t know the tools well enough.’ (interview) While this passivity may not cause immediate, visible harm, it ultimately sustains the default configuration solutions provided by IT administrators and perpetuates the technological inefficiencies in the organization. In sum, this theme shows how the discrepancy between the expectation of configuring DPMTs as a quick, simple task and the reality of its demanding, complex nature fosters a knowing of assumed adequacy in individual team members. This knowing helps them accept the malleable technologies as already good enough for supporting their work, despite the bothersome default configurations, and renounce their responsibilities to improve the shared groupware. However, by preventing configuration (dis)satisfaction, this knowing creates a passivity at the team level regarding the use of malleability in groupware. Neither conducting the configurations themselves nor asking others to do it, the malleability of DPMTs essentially becomes a superficial decoration, providing symbolic flexibility to the teams’ practices. 6. Discussion In this paper, we examined how team dynamics influence the coordination of malleable technology configurations. Focusing particularly on the varying perceptions of – and interactions between team members and technology, our findings demonstrate that team members develop certain knowings of current configurations – assumed symmetry, assumed intentionality, and assumed adequacy – which they consider to be shared understandings in the team. However, drawing on the notion of knowing-as-displacing (Law 2000 ), these knowings – assumptions of current configurations veil tensions between team members’ diverse access to and needs for configurations, and thereby, further coordination attempts are dissipated. Emerging from the distinctive sociomaterial interplay between malleable technologies and team organizations, these knowings create the challenges of misalignment, compromise, and passivity that, instead of ensuring team coordinated technology configurations, impede the utilization of technology malleability. An overview of the three knowings influencing the process of malleable technology configuration in teams can be found in Table 3 . Table 3 The process of technology configuration in teams Assumptions of the present configurations in teams The underlying sociomaterial dynamics Emergent challenges to future configurations in teams Assumed symmetry Material: Technology behaves differently based on access levels. Social: Teams overlook how access asymmetry shapes user experience. Misalignment : Members assume shared capabilities. Super users overlook limits; ordinary users disengage from suggesting changes. Assumed intentionality Material: All members share the same configuration results. Social: Uncertainty about the reasons behind existing setups. Compromise : Members treat current configurations as deliberate. This reduces conflict but inhibits reflection and change. Assumed adequacy Material: Configuration is time-consuming and complex. Social: Seen as outside core job duties and not worth the effort. Passivity : Members accept “good enough” setups. The cost and ambiguity of change deter deeper engagement. 6.1 Theoretical contributions In the following, we highlight three important theoretical contributions our paper makes to the CSCW research on the implications of malleable technologies. First, we explain why and how the use of malleable technologies for teamwork does not always lead to the intended positive outcome of continuous technological support but can instead entail time-consuming challenges in ensuring team usability. Previous studies highlight the importance of configurations in obtaining the ongoing task-technology fit promised by malleable technologies (see e.g., Correa and Selbach 2021 ; Magnus Li and Nielsen 2019 ; Slagter, Biemans, and Hofte 2001; Sommerville 2008 ; Wulf, Stiemerling, and Pfeifer 1999 ). Our study goes further to illuminate the processes that precede these configuration outcomes and explain why they do not always result in success (e.g., Germonprez and Zigurs 2009; Huysman et al. 2003 ; Wulf 1999 ). Specifically, using the theory of situated knowledge, we show how configurations in teams require the integration of divergent, yet simultaneously valid knowledge claims that emerge from the active participation of team members in the sociomaterial interplay between malleable technologies and team organizations (Gherardi 2001 ; Orlikowski 2002 ). However, because such enactments of knowings are not always visible to others, constrained by their sociomaterial situatedness, recognizing this plurality of knowledge in teams becomes the first challenge for teams having to coordinate their technology configurations. By unpacking the extensive work involved in configuring malleable technologies in team settings, our study aligns with literature highlighting the new user roles and responsibilities that come with the implementation of such technologies (Correa and Selbach 2021 ; Peine, Rollwagen, and Neven 2014; Richter and Riemer 2013 ; Magnus Li 2021 ). However, by questioning the reasonableness and feasibility of expecting teams to provide this necessary configurational work, we offer a more critical reading of this shifting user role, challenging the optimistic narrative of users as “active co-creators of technology\" (Peine, Rollwagen, and Neven 2014, p.199). Second, we show that a knowledge-as-displacement (Law 2000 ) characterizes team members’ assumptions of present configurations in teams, which helps explain why they may overlook the fact that configurations are left insufficiently coordinated. By highlighting the limitations of any single perspective in fully comprehending and representing the complex context of team and malleable technology use, our findings support the essential role of coordination in collaborative technology configurations, as proposed in prior studies (Domingos and Martins 1997; MacLean et al. 1990 ; Pipek and Kahler 2006 ). Nevertheless, we also demonstrate that such coordination is neither simple nor straightforward and may require systematic effort and external guidance, as individual knowings often appear perfectly rational within their own sociomaterial context and only reveal their incoherence when juxtaposed. This embeddedness not only conceals the need for coordination but also increases the difficulty of reconciliation. The risk of unknowingly displacing or marginalizing some members’ experiences and knowledge claims in favour of others provides a theoretical explanation for why increasing awareness of diverse team technology usage and needs can enhance the quality of technology configuration (Thomas and Bostrom 2010 ). This resonates with the broader research on knowledge-intensive collaboration with an absence of hierarchy, where the perspectives of different communities of knowing cannot simply be combined (Lindberg et al. 2024 ; Boland and Tenkasi 1995 ). However, our study provides additional insights by showing that this can also be the case within the same community of knowing, where individuals are situated differently in the sociomaterial context. This might silently damage their ability to narrate a unified experience towards other knowledge communities and collaborate with them. Third, we demonstrate that team-level dynamics create qualitatively different challenges for technology configurations than similar configurations at the individual level (e.g., Lehrig, Krancher, and Dibbern 2017 , 2019 ; Mackay 1991 ; Shao and Li 2022 ; Schmitz, Teng, and Webb 2016; Weinert et al. 2020 ). Previous studies have demonstrated how the collaborative use of malleable technologies can introduce divergent interests, routines, and understandings, complicating the configuration process (Cabitza and Simone 2017 ; Lehrig, Krancher, and Dibbern 2015; Mousavidin and Silva 2017 ; Pipek and Kahler 2006 ). Such potential goal asymmetry in social collaboration is especially an eminent problem for technology configurations at the organizational or group level (Jørgen P. Bansler 2021 ; Cresswell et al. 2017 ; M.C. Moon, Hills, and Demiris 2018; Ellingsen, Hertzum, and Melby 2022 ), leading to Mousavidin and Silva ( 2017 ) proposing high technology malleability as a critical resource for enhancing task-technology fit in organizations. This aligns with recent developments in malleable technology design that aim to increase the built-in malleability to accommodate potentially incompatible needs (Correa and Selbach 2021 ; Magnus Li 2021 ; Magnus Li and Nielsen 2019 ; Magnus Li 2019 ). However, zooming in on technology configurations as team processes, our study identifies a different barrier to collaborative configuration: overcoming the information asymmetry amplified by the situatedness and displacement of knowing enabled by malleable technologies. Our findings indicate that team members, at least in our study, do not necessarily lack the willingness to accommodate one another. Rather, they can lack the awareness of the limitations of their own knowledge and the perspectives of others, which impedes the effective utilization of technology malleability. This insight is especially relevant to the literature, as it underscores the need to expand the current focus on developing more comprehensive technology malleability with an equal focus on facilitating meta-awareness on team technology use, through, e.g., the incorporation of coordination mechanisms (Schmidt and Simonee 1996; Grinter 1996 ; Cabitza and Simone 2012). Such a reconceptualization of technology malleability that shows consideration for the limitations of situated cognitions can be the key to improving the general usability of malleable groupware. 6.2 Practical implications Our study provides several practical implications relevant for both the users and the developers of malleable technologies. For organizations implementing malleable technologies to support collaborative work, our study indicates that the continuous task-technology fit promised by technology malleability is a price that needs to be redeemed through difficult and time-consuming teamwork. Because configurations at the team level not only need to overcome the challenges and barriers already known from individual configurations (see e.g., Mackay 1991 ) but also require addressing the information and goal asymmetry amplified by the situatedness and displacement of knowing enabled by malleable technologies. Thus, it is necessary for practitioners to first consider whether the work of configuring malleable technology is worth the benefit these tools provide, and secondly, dedicate time and resources to utilizing technology malleability in teams. For organizations, this may involve recognizing configurational work as a part of employee responsibility and providing mandatory team training on technology configuration that moves beyond simple instruction on system functionalities. Moreover, our study highlights the limitations of single perspectives (e.g., super user) in recognizing the needs and solutions of new configurations in teams, hence the importance of team coordinated technology configurations. However, managers and team leaders should not assume that such initiatives will naturally occur bottom-up and converge toward optimal outcomes simply by giving teams the autonomy to do so (e.g., Lehrig, Krancher, and Dibbern 2015; Leonardi 2011 ). By identifying the three knowledge assumptions, we show that team members may overestimate shared understanding of technological use, misinterpret uncoordinated outcomes as intentional, or prematurely accept suboptimal configurations as sufficient. Thus, fostering digital leadership (Müller et al. 2024 ; Cortellazzo, Bruni, and Zampieri 2019 ) and digital culture (Grover, Tseng, and Pu 2022 ; Jensen et al. 2023 ) becomes even more relevant with the implementation of malleable technologies, where organizations should ensure that teams create ongoing opportunities for reflection and knowledge exchange regarding the shared malleable groupware to surface potential private misunderstandings and misalignments across team members. For the system designers and software developers of malleable technologies for collaborative work, our study calls attention to the limitations of assuming users can easily utilize technology malleability to create a better task-technology fit simply by having the technological capability to do so. While current design paradigms often emphasize user empowerment and co-creation, our study shows that configuration work in teams is complex, time-consuming, and socially demanding – a messy and difficult task nobody really wants or has time to do. Thus, it is necessary to complement the efforts to increase technological malleability with new solutions to promote meta-awareness of technology use, which can help bridge the information asymmetries inherent in collective work and reduce the difficulty of team coordinated technology configuration. 7. Limitations and future research Our study has several limitations that also present opportunities for future research. First, the context of our research provides potential boundary conditions of the generalisability of our study’s findings and contributions. By focusing on self-managing IT teams characterized by low hierarchy, high team autonomy, and high technological proficiency, our study may have underplayed the potential impact of leadership, IT governance, and technological skills in shaping the configuration process in team settings. Future studies could focus on teams with clearer hierarchical structures and varying technological proficiency to understand how these factors influence the team members’ perception of malleable technology use, and the emergence of team coordinated technology configurations. Second, beyond DPMTs, there are other forms of malleable technologies essential for teamwork. These malleable technologies, such as enterprise communication platforms (e.g., Slack) or enterprise resource planning systems (e.g., SAP), can be used for different purposes than DPMTs in cooperative work and may offer other forms of technology malleability. These can create a dissimilar sociomaterial context for technology configurations, which may give rise to other forms of knowings in teams. While we do not expect such differences to change the fundamental challenges related to team coordinated technology configurations identified in our study, these differences may give rise to other forms of bottom-up interactions influencing the configuration process of shared technologies. This could be investigated by future studies. Third, while our focus on naturally emergent, unsuccessful cases provides valuable insights into the potential pitfalls of configurations as team practices, we cannot claim that the three identified assumptions are the only barriers to configuring malleable technologies in team settings. Likewise, we cannot assert that overcoming these assumptions is sufficient to ensure improved utilization of technology malleability. Given the complexity of configuring malleable technologies in teams, we suggest that future research adopt action research methods to outline the process of team coordinated technology configurations and identify relevant triggers, resources, and barriers. Such research would undoubtedly bring great value to both theories and practices. Four, by focusing on the knowledge and cognition of individual team members, our study did not account for other contextual factors that may shape team configuration practices. Factors such as silence and voice in teams (Van Dyne, Ang, and Botero 2003) or organizational digital culture (Grover, Tseng, and Pu 2022 ) may contribute to the emergence of the assumptions identified in our study. These potential influences warrant further exploration. Five, we observed varied emotional responses among team members regarding the (non-)configurations of their malleable groupware – some experienced greater challenges than others. These individual differences were not explained in our study. Future research could investigate how team members emotionally respond to insufficiently coordinated configurations and how these responses affect their personal well-being. Such work may provide new insights into the literature on technostress – stress experienced by users of information and communication technologies (Ragu-Nathan et al. 2008 ). Declarations Declaration of Interest statement: None Clinical trial number not applicable Funding statement: The authors received no specific funding for this article. Author Contribution R.F.Z: Conceptualization, Methodology, Formal Analysis, Investigation, Writing - Original Draft, Writing - Review & Editing, Project administration.C.J.: Methodology, Formal Analysis, Supervision, Writing - Review & Editing.J.A.: Formal Analysis, Supervision, Writing - Review & Editing Acknowledgement We are grateful to Jacob Klitmøller and the participants of the workshop “Practice Theory and the Digital” at Lancaster University for their valuable comments on an earlier draft of our paper. We also extend our sincere gratitude to the managers and employees of the field organization for their support and participation in this study. References Arya, S., and M. S. Kulkarni. 2024. \"A Comprehensive Study of Agile Project Management Tools.\" 2024 4th International Conference on Innovative Practices in Technology and Management (ICIPTM), Noida, India. Bailey, Diane E., Paul M. Leonardi, and Jan Chong. 2010. \"Minding the gaps: Understanding technology interdependence and coordination in knowledge work.\" Organization Science 21 (3): 713-730. https://doi.org/10.1287/orsc.1090.0473. Bansler, J. P., and Erling Havn. 2006. \"Sensemaking in Technology-Use Mediation: Adapting Groupware Technology in Organizations.\" Computer Supported Cooperative Work (CSCW) 15 (1): 55-91. https://doi.org/10.1007/s10606-005-9012-x. https://doi.org/10.1007/s10606-005-9012-x. Bansler, Jørgen P. 2021. \"Challenges in user-driven optimization of EHR: A case study of a large Epic implementation in Denmark.\" International Journal of Medical Informatics 148: 104394. https://doi.org/https://doi.org/10.1016/j.ijmedinf.2021.104394. https://www.sciencedirect.com/science/article/pii/S1386505621000204. Barley, William C., Jeffrey W. Treem, and Timothy Kuhn. 2017. \"Valuing Multiple Trajectories of Knowledge: A Critical Review and Agenda for Knowledge Management Research.\" Academy of Management Annals 12 (1): 278-317. https://doi.org/10.5465/annals.2016.0041. https://doi.org/10.5465/annals.2016.0041. Blomberg, Jeanette, and Helena Karasti. 2013. \"Reflections on 25 Years of Ethnography in CSCW.\" Computer Supported Cooperative Work (CSCW) 22 (4): 373-423. https://doi.org/10.1007/s10606-012-9183-1. https://doi.org/10.1007/s10606-012-9183-1. Boland, Richard J., and Ramkrishnan V. Tenkasi. 1995. \"Perspective Making and Perspective Taking in Communities of Knowing.\" Organization Science 6 (4): 350-372. https://doi.org/10.1287/orsc.6.4.350. https://doi.org/10.1287/orsc.6.4.350. Braun, Virginia, and Victoria Clarke. 2006. \"Using thematic analysis in psychology.\" Qualitative Research in Psychology 3 (2): 77-101. https://doi.org/10.1191/1478088706qp063oa. https://www.tandfonline.com/doi/abs/10.1191/1478088706qp063oa. --. 2022. Thematic analysis : a practical guide . London: SAGE Publications Ltd. Bruni, Attila, Silvia Gherardi, and Laura Lucia Parolin. 2007. \"Knowing in a System of Fragmented Knowledge.\" Mind, Culture, and Activity 14 (1-2): 83-102. https://doi.org/10.1080/10749030701307754. https://doi.org/10.1080/10749030701307754. Buturugă, Oana Cristina, Vasile Mirel Gogoi, and Ioana Alexandra Prodan. 2016. \"Agile Project Management Tools.\" Economy informatics 16 (1): 19-26. Cabitza, Federico, and Carla Simone. 2012. \"Affording Mechanisms: An Integrated View of Coordination and Knowledge Management.\" Computer Supported Cooperative Work (CSCW) 21 (2): 227-260. https://doi.org/10.1007/s10606-011-9153-z. https://doi.org/10.1007/s10606-011-9153-z. --. 2013. \"Computational Coordination Mechanisms: A tale of a struggle for flexibility.\" Computer Supported Cooperative Work (CSCW) 22 (4): 475-529. https://doi.org/10.1007/s10606-013-9187-5. https://doi.org/10.1007/s10606-013-9187-5. --. 2017. \"Malleability in the Hands of End-Users.\" In New Perspectives in End-User Development , edited by Fabio Paternò and Volker Wulf, 137-163. Cham: Springer International Publishing. Carter, N., D. Bryant-Lukosius, A. DiCenso, J. Blythe, and A. J. Neville. 2014. \"The use of triangulation in qualitative research.\" Oncol Nurs Forum 41 (5): 545-7. https://doi.org/10.1188/14.Onf.545-547. Correa, Claiton Marques , and Silveira. Milene Selbach. 2021. \"End-User Highlighted: featuring tailorable systems development.\" Proceedings of the XX Brazilian Symposium on Human Factors in Computing Systems, Virtual Event, Brazil. https://doi.org/10.1145/3472301.3484332. Cortellazzo, Laura, Elena Bruni, and Rita Zampieri. 2019. \"The Role of Leadership in a Digitalized World: A Review.\" Frontiers in Psychology Volume 10 - 2019. https://doi.org/10.3389/fpsyg.2019.01938. https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2019.01938. Cresswell, Kathrin M., Lisa Lee, Hajar Mozaffar, Robin Williams, Aziz Sheikh, and Nihr ePrescribing Programme Team on behalf of the. 2017. \"Sustained User Engagement in Health Information Technology: The Long Road from Implementation to System Optimization of Computerized Physician Order Entry and Clinical Decision Support Systems for Prescribing in Hospitals in England.\" Health Services Research 52 (5): 1928-1957. https://doi.org/https://doi.org/10.1111/1475-6773.12581. https://doi.org/10.1111/1475-6773.12581. Domingos, Henrique João L., and José A. Legatheaux Martins. 1997. \"Coordination and Tailorability Issues in the design of a Generic Large Scale Groupware Platform.\" ACM - GROUP’97, Phoenix, Arizona Dreyfus, Hubert L. , and Stuart E. Dreyfus. 1986. Mind over machine : the power of human intuition and expertise in the era of the computer . New York: Free Press. Edmondson, Amy C., Michael A. Roberto, and Michael D. Watkins. 2003. \"A dynamic model of top management team effectiveness: managing unstructured task streams.\" The Leadership Quarterly 14 (3): 297-325. https://doi.org/https://doi.org/10.1016/S1048-9843(03)00021-3. https://www.sciencedirect.com/science/article/pii/S1048984303000213. Ellingsen, Gunnar, Morten Hertzum, and Line Melby. 2022. \"The Tension between National and Local Concerns in Preparing for Large-Scale Generic Systems in Healthcare.\" Computer Supported Cooperative Work (CSCW) 31 (3): 411-441. https://doi.org/10.1007/s10606-022-09424-9. https://doi.org/10.1007/s10606-022-09424-9. Faraj, Samer, and Yan Xiao. 2006. \"Coordination in Fast-Response Organizations.\" Management Science 52 (8): 1155-1169. http://www.jstor.org/stable/20110591. Fleck, James. 1993. \"Configurations: Crystallizing contingency.\" International Journal of Human Factors in Manufacturing 3 (1): 15-36. https://doi.org/https://doi.org/10.1002/hfm.4530030104. https://doi.org/10.1002/hfm.4530030104. --. 1994. \"Learning by trying: the implementation of configurational technology.\" Research Policy 23 (6): 637-652. https://doi.org/https://doi.org/10.1016/0048-7333(94)90014-0. https://www.sciencedirect.com/science/article/pii/0048733394900140. Flick, Uwe. 2018. Designing qualitative research . Second edition. ed. The SAGE qualitative research kit. Los Angeles: Sage. Germonprez, Matt, and Ilze Zigurs. 2009. \"Task, technology, and tailoring in communicative action: An in-depth analysis of group communication.\" Information and Organization 19 (1): 22-46. https://doi.org/https://doi.org/10.1016/j.infoandorg.2008.03.002. https://www.sciencedirect.com/science/article/pii/S1471772708000134. Gherardi, Silvia. 2001. \"From Organizational Learning to Practice-Based Knowing.\" Human Relations 54 (1): 131-139. https://doi.org/10.1177/0018726701541016. https://journals.sagepub.com/doi/abs/10.1177/0018726701541016. --. 2008. \"Situated Knowledge and Situated Action: What do Practice-Based Studies Promise?\" In The SAGE Handbook of New Approaches in Management and Organization , edited by Daved; Barry and Hans Hansen. Griffith, Terri L., John E. Sawyer, and M. Scott Poole. 2019. \"Systems savvy: Practical intelligence for transformation of sociotechnical systems.\" Group Decision and Negotiation 28 (3): 475-499. https://doi.org/10.1007/s10726-019-09619-4. Grinter, Rebecca E. 1996. \"Supporting articulation work using software configuration management systems.\" Computer Supported Cooperative Work (CSCW) 5 (4): 447-465. https://doi.org/10.1007/BF00136714. https://doi.org/10.1007/BF00136714. Grover, Varun, Shih-Lun Tseng, and Wenxi Pu. 2022. \"A theoretical perspective on organizational culture and digitalization.\" Information & Management 59 (4): 103639. https://doi.org/https://doi.org/10.1016/j.im.2022.103639. https://www.sciencedirect.com/science/article/pii/S0378720622000519. Haraway, Donna. 1988. \"Situated Knowledges: The Science Question in Feminism and the Privilege of Partial Perspective.\" Feminist Studies 14 (3): 575-599. https://doi.org/10.2307/3178066. http://www.jstor.org.ez.statsbiblioteket.dk/stable/3178066. Hunger, Axel, and Angela Hirlehei. 2013. \"Supporting Globally Distributed Work - Cultural Adaptivity Meets Groupware Tailorability.\" Cross-Cultural Design. Cultural Differences in Everyday Life, Berlin, Heidelberg. Huysman, Marleen, Charles Steinfield, Chyng-Yang Jang, Kenneth David, Mirjam Huis in 't Veld, Jan Poot, and Ingrid Mulder. 2003. \"Virtual Teams and the Appropriation of Communication Technology: Exploring the Concept of Media Stickiness.\" Computer Supported Cooperative Work (CSCW) 12 (4): 411-436. https://doi.org/10.1023/A:1026145017609. https://doi.org/10.1023/A:1026145017609. Jensen, Rikke Amalie Agergaard; , Charlotte; Jonasson, Martin; Gartmeier, and Jaana Parviainen. 2023. \"Learning from errors in digital patient communication: professionals’ enactment of negative knowledge and digital ignorance in the workplace.\" Journal of Workplace Learning 35 (5): 432–449. https://doi.org/https://doi.org/10.1108/JWL-12-2022-0177. Jira, Atlassian. 2024. \"Great outcomes start with Jira.\" Accessed August 12. https://www.atlassian.com/software/jira. Kempton, Alexander Moltubakk. 2022. \"The digital is different: Emergence and relationality in critical realist research.\" Information and Organization 32 (2): 100408. https://doi.org/https://doi.org/10.1016/j.infoandorg.2022.100408. https://www.sciencedirect.com/science/article/pii/S1471772722000215. Larsen-Ledet, Ida, and Marcel Borowski. 2021. \"“It Looks Like You Don’t Agree”: Idiosyncratic Practices and Preferences in Collaborative Writing.\" Proceedings of the 32nd Australian Conference on Human-Computer Interaction, Sydney, NSW, Australia. https://doi.org/10.1145/3441000.3441032. Larson, Lindsay, and Leslie A. DeChurch. 2020. \"Leading teams in the digital age: Four perspectives on technology and what they mean for leading teams.\" The Leadership Quarterly 31 (1): 101377. https://doi.org/https://doi.org/10.1016/j.leaqua.2019.101377. https://www.sciencedirect.com/science/article/pii/S104898431830835X. Lave, J., and E. Wenger. 1991. Situated Learning: Legitimate Peripheral Participation. : Cambridge University Press. Law, John. 2000. \"Comment on Suchman, and Gherardi and Nicolini: Knowing as Displacing.\" Organization 7 (2): 349-354. https://doi.org/10.1177/135050840072009. https://journals.sagepub.com/doi/abs/10.1177/135050840072009. Lehrig, Tim, Oliver Krancher, and Jens Dibbern. 2015. \"The Evolution of Routines under Flexible Information Technology.\" ECIS 2015 Research-in-Progress Papers. --. 2017. \"How Users Perceive and Actualize Affordances: An Exploratory Case Study of Collaboration Platforms.\" Thirty Eighth International Conference on Information Systems, Korea. --. 2019. \"Affordance Perceptions under Malleable Information Technology: A Social Cognitive Theory Perspective.\" Fortieth International Conference on Information Systems, Munich. Leonardi, Paul M. 2011. \"When Flexible Routines Meet Flexible Technologies: Affordance, Constraint, and the Imbrication of Human and Material Agencies.\" MIS Quarterly 35 (1): 147-167. https://doi.org/10.2307/23043493. http://www.jstor.org/stable/23043493. --. 2013. \"Theoretical foundations for the study of sociomateriality.\" Information and Organization 23 (2): 59-76. https://doi.org/https://doi.org/10.1016/j.infoandorg.2013.02.002. https://www.sciencedirect.com/science/article/pii/S1471772713000067. Li, Magnus. 2019. \"An Approach to Addressing the Usability and Local Relevance of Generic Enterprise Software.\" Selected Papers of the IRIS. --. 2021. \"Generic Enterprise Software Implementation as Context for User-Oriented Design: Three Conditions and their Implications for Vendors.\" 12th Scandinavian Conference on Information Systems. Li, Magnus , and Petter Nielsen. 2019. \"Making Usable Generic Software. A Matter of Global or Local Design?\" 10th Scandinavian Conference on Information Systems, Nokia, Finland. Lindberg, Aron, Nicholas Berente, James Howison, and Kalle Lyytinen. 2024. \"Discursive Modulation in Open Source Software: How Online Communities Shape Novelty and Complexity1.\" Management Information Systems Quarterly 48 (4): 1395-1422. https://doi.org/10.25300/MISQ/2023/16872. https://doi.org/10.25300/MISQ/2023/16872. Lyytinen, Kalle, Petri Maaranen, and Juha Knuuttila. 1993. \"Groups are not always the same.\" Computer Supported Cooperative Work (CSCW) 2 (4): 261-284. https://doi.org/10.1007/BF00805694. https://doi.org/10.1007/BF00805694. Mackay, Wendy E. 1991. \"Triggers and barriers to customizing software.\" Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, New Orleans, Louisiana, USA. https://doi.org/10.1145/108844.108867. MacLean, Allan, Kathleen Carter, Lennart Lövstrand, and Thomas Moran. 1990. \"User-tailorable systems: pressing the issues with buttons.\" Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Seattle, Washington, USA. https://doi.org/10.1145/97243.97271. Majchrzak, Ann, Ronald E. Rice, Arvind Malhotra, Nelson King, and Sulin Ba. 2000. \"Technology Adaptation: The Case of a Computer-Supported Inter-Organizational Virtual Team.\" MIS Quarterly 24 (4): 569-600. https://doi.org/10.2307/3250948. http://www.jstor.org/stable/3250948. Malone, Thomas W., and Kevin Crowston. 1994. \"The interdisciplinary study of coordination.\" ACM Comput. Surv. 26 (1): 87–119. https://doi.org/10.1145/174666.174668. https://doi.org/10.1145/174666.174668. Mandviwalla, Munir, and Lorne Olfman. 1994. \"What do groups need? A proposed set of generic groupware requirements.\" ACM Trans. Comput.-Hum. Interact. 1 (3): 245–268. https://doi.org/10.1145/196699.196715. https://doi.org/10.1145/196699.196715. Mathieu, John E, Peter T Gallagher, Monique A Domingo, and Elizabeth A Klock. 2019. \"Embracing complexity: Reviewing the past decade of team effectiveness research.\" Annual Review of Organizational Psychology and Organizational Behavior 6 (1): 17-46. Moon, Eunyoung, and James Howison. 2024. \"A dynamic perspective on software modularity in open source software (OSS) development: A configurational approach.\" Information and Organization 34 (1): 100499. https://doi.org/https://doi.org/10.1016/j.infoandorg.2023.100499. https://www.sciencedirect.com/science/article/pii/S1471772723000532. Moon, Mark Chun, Rebecca Hills, and George Demiris. 2018. \"Understanding optimisation processes of electronic health records (EHRs) in select leading hospitals: a qualitative study.\" BMJ Health & Care Informatics 25 (2): 109. https://doi.org/10.14236/jhi.v25i2.1011. http://informatics.bmj.com/content/25/2/109.abstract. Mousavidin, Elham, and Leiser Silva. 2017. \"Theorizing the configuration of modifiable off-the-shelf software.\" Information Technology & People 30 (4): 887-909. https://doi.org/10.1108/ITP-07-2014-0140. https://doi.org/10.1108/ITP-07-2014-0140. Müller, Sune Dueholm, Henrike Konzag, Jeppe Agger Nielsen, and Hafdís Bergsdóttir Sandholt. 2024. \"Digital transformation leadership competencies: A contingency approach.\" International Journal of Information Management 75: 102734. https://doi.org/https://doi.org/10.1016/j.ijinfomgt.2023.102734. https://www.sciencedirect.com/science/article/pii/S0268401223001159. Okhuysen, Gerardo A., and Beth A. Bechky. 2009. \"Coordination in organizations: An integrative perspective.\" The Academy of Management Annals 3 (1): 463-502. https://doi.org/10.1080/19416520903047533. Orlikowski, Wanda J. 2002. \"Knowing in Practice: Enacting a Collective Capability in Distributed Organizing.\" Organization science (Providence, R.I.) 13 (3): 249-273. https://doi.org/10.1287/orsc.13.3.249.2776. --. 2006. \"Material knowing: the scaffolding of human knowledgeability.\" European Journal of Information Systems 15 (5): 460-466. https://doi.org/10.1057/palgrave.ejis.3000639. https://doi.org/10.1057/palgrave.ejis.3000639. Orlikowski, Wanda J., and Susan V. Scott. 2008. \"Sociomateriality: Challenging the Separation of Technology, Work and Organization.\" Academy of Management Annals 2 (1): 433-474. https://doi.org/10.5465/19416520802211644. https://doi.org/10.5465/19416520802211644. Pearsall, Matthew J., and Vijaya Venkataramani. 2015. \"Overcoming asymmetric goals in teams: The interactive roles of team learning orientation and team identification.\" Journal of Applied Psychology 100 (3): 735-748. https://doi.org/10.1037/a0038315. Peine, Alexander, Ingo Rollwagen, and Louis Neven. 2014. \"The rise of the “innosumer”—Rethinking older technology users.\" Technological Forecasting and Social Change 82: 199-214. https://doi.org/https://doi.org/10.1016/j.techfore.2013.06.013. https://www.sciencedirect.com/science/article/pii/S004016251300139X. Pipek, Volkmar, and Helge Kahler. 2006. \"Supporting Collaborative Tailoring.\" In End User Development , edited by Henry Lieberman, Fabio Paternò and Volker Wulf, 315-345. Dordrecht: Springer Netherlands. Ragu-Nathan, T. S., Monideepa Tarafdar, Bhanu S. Ragu-Nathan, and Qiang Tu. 2008. \"The Consequences of Technostress for End Users in Organizations: Conceptual Development and Empirical Validation.\" Information Systems Research 19 (4): 417-433. https://doi.org/10.1287/isre.1070.0165. https://doi.org/10.1287/isre.1070.0165. Raith, Florian, Ingo Richter, and Robert Lindermeier. 2017. \"How Project-management-tools are used in Agile Practice.\" the 21st International Database Engineering & Applications Symposium, Bristol, United Kingdom. Richter, Alexander, and Kai Riemer. 2013. \"Malleable end-user software.\" Business & Information Systems Engineering 5: 195-197. https://doi.org/https://doi.org/10.1007/s12599-013-0260-x. Schmidt, Kjeld, and Carla Simonee. 1996. \"Coordination mechanisms: Towards a conceptual foundation of CSCW systems design.\" Computer Supported Cooperative Work (CSCW) 5 (2): 155-200. https://doi.org/10.1007/BF00133655. https://doi.org/10.1007/BF00133655. Schmitz, Kurt W, James TC Teng, and Kimberly J Webb. 2016. \"Capturing the Complexity of Malleable IT Use.\" Mis Quarterly 40 (3): 663-686. https://doi.org/https://doi.org/10.25300/MISQ/2016/40.3.07. Shaikh, Maha, and Ola Henfridsson. 2017. \"Governing open source software through coordination processes.\" Information and Organization 27 (2): 116-135. https://doi.org/https://doi.org/10.1016/j.infoandorg.2017.04.001. https://www.sciencedirect.com/science/article/pii/S1471772716301816. Shao, Zhen, and Xixi Li. 2022. \"The influences of three task characteristics on innovative use of malleable IT: An extension of adaptive structuration theory for individuals.\" Information & Management 59 (3): 103597. https://doi.org/https://doi.org/10.1016/j.im.2022.103597. https://www.sciencedirect.com/science/article/pii/S037872062200009X. Simandan, Dragos. 2019. \"Revisiting positionality and the thesis of situated knowledge.\" Dialogues in Human Geography 9 (2): 129-149. https://doi.org/10.1177/2043820619850013. https://journals.sagepub.com/doi/abs/10.1177/2043820619850013. Slagter, R., M. Biemans, and H. ter Hofte. 2001. \"Evolution in use of groupware: facilitating tailoring to the extreme.\" Proceedings Seventh International Workshop on Groupware. CRIWG 2001. Sommerville, I. 2008. \"Construction by Configuration: Challenges for Software Engineering Research and Practice.\" 19th Australian Conference on Software Engineering (aswec 2008). Spradley, James P. 1979. The ethnographic interview . The development research sequence. Belmont, CA: Wadsworth Group - Thomson Learning. --. 2011. Participant observation . Australia: Wadsworth, Thomson Learning. Tenório, Nelson, Danieli Pinto, and Pernille Bjørn. 2018. \"Accountability in Brazilian Governmental Software Project: How Chat Technology Enables Social Translucence in Bug Report Activities.\" Computer Supported Cooperative Work (CSCW) 27 (3): 715-740. https://doi.org/10.1007/s10606-018-9326-0. https://doi.org/10.1007/s10606-018-9326-0. Thomas, D. M., and R. P. Bostrom. 2010. \"Team leader strategies for enabling collaboration technology adaptation: team technology knowledge to improve globally distributed systems development work.\" European Journal of Information Systems 19 (2): 223-237. https://doi.org/10.1057/ejis.2010.14. https://doi.org/10.1057/ejis.2010.14. Weinert, Christoph, Christian Maier, Sven Laumer, and Tim Weitzel. 2020. \"IS Reappraisal and Technology Adaptation Behaviors: A Longitudinal Study During an IS Implementation.\" SIGMIS Database 51 (4): 11–39. https://doi.org/10.1145/3433148.3433151. https://doi.org/10.1145/3433148.3433151. Wiegel, Valeri, Abby King, Hajar Mozaffar, Kathrin Cresswell, Robin Williams, and Aziz Sheik. 2019. \"A systematic analysis of the optimization of computerized physician order entry and clinical decision support systems: A qualitative study in English hospitals.\" Health Informatics Journal 26 (2): 1118-1132. https://doi.org/10.1177/1460458219868650. https://doi.org/10.1177/1460458219868650. Wittgenstein, Ludwig. 1954/2009. Philosophical investigations . Wiley-Blackwell. Wulf, Volker. 1999. \"“Let's see your search-tool!”—collaborative use of tailored artifacts in groupware.\" Proceedings of the 1999 ACM International Conference on Supporting Group Work, Phoenix, Arizona, USA. https://doi.org/10.1145/320297.320303. Wulf, Volker, Oliver Stiemerling, and Andreas Pfeifer. 1999. \"Tailoring groupware for different scopes of validity.\" Behaviour & Information Technology 18 (3): 199-212. https://doi.org/10.1080/014492999119084. https://doi.org/10.1080/014492999119084. Zhang, Yibin Fabricius. 2024. \"Too little or too much transparency? Influencing accountability in project management through the practices of using digital technologies.\" International Journal of Project Management 42 (6): 102636. https://doi.org/https://doi.org/10.1016/j.ijproman.2024.102636. https://www.sciencedirect.com/science/article/pii/S0263786324000784. Additional Declarations No competing interests reported. Cite Share Download PDF Status: Under Review Version 1 posted Editorial decision: Revision requested 10 Feb, 2026 Reviews received at journal 14 Jan, 2026 Reviews received at journal 05 Jan, 2026 Reviews received at journal 16 Dec, 2025 Reviewers agreed at journal 11 Nov, 2025 Reviewers agreed at journal 11 Nov, 2025 Reviewers agreed at journal 17 Oct, 2025 Reviewers invited by journal 15 Oct, 2025 Editor assigned by journal 02 Oct, 2025 Submission checks completed at journal 09 Sep, 2025 First submitted to journal 29 Aug, 2025 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {\"props\":{\"pageProps\":{\"initialData\":{\"identity\":\"rs-7489297\",\"acceptedTermsAndConditions\":true,\"allowDirectSubmit\":false,\"archivedVersions\":[],\"articleType\":\"Research Article\",\"associatedPublications\":[],\"authors\":[{\"id\":534012076,\"identity\":\"7b95373e-81e6-464d-8439-3487f02b98e6\",\"order_by\":0,\"name\":\"Rosa Fabricius Zhang\",\"email\":\"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAsklEQVRIiWNgGAWjYLCCDzAGzwEidTDOIFkLMw9JWszb2x9+tt1Rl9jAfsaA4c0ZIrTInDljLJ175nBiA0+OAeOcG0RokZDIYZDObTuQ2MCQY8DM84GwDqCW9Me/LduADuN/Q7SWBDNpxjbmxAYJkC1EOYznjJll75nDxm0SzwoOziHG+xLs7Y9v/NxRJ9vPn7zxwZtjRGgBA8YGBsc2IH2AWA1gLfbEqx4Fo2AUjIIRBwC47zYvouwQsQAAAABJRU5ErkJggg==\",\"orcid\":\"\",\"institution\":\"Aarhus University\",\"correspondingAuthor\":true,\"prefix\":\"\",\"firstName\":\"Rosa\",\"middleName\":\"Fabricius\",\"lastName\":\"Zhang\",\"suffix\":\"\"},{\"id\":534012077,\"identity\":\"643f01fb-9f09-4f75-83f1-fc8fe4e69512\",\"order_by\":1,\"name\":\"Charlotte Jonasson\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Aarhus University\",\"correspondingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Charlotte\",\"middleName\":\"\",\"lastName\":\"Jonasson\",\"suffix\":\"\"},{\"id\":534012078,\"identity\":\"53cf5e20-aac1-4495-9f4a-ad41c1a2b33b\",\"order_by\":2,\"name\":\"Jesper Aagaard\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Aarhus University\",\"correspondingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Jesper\",\"middleName\":\"\",\"lastName\":\"Aagaard\",\"suffix\":\"\"}],\"badges\":[],\"createdAt\":\"2025-08-29 14:08:15\",\"currentVersionCode\":1,\"declarations\":\"\",\"doi\":\"10.21203/rs.3.rs-7489297/v1\",\"doiUrl\":\"https://doi.org/10.21203/rs.3.rs-7489297/v1\",\"draftVersion\":[],\"editorialEvents\":[],\"editorialNote\":\"\",\"failedWorkflow\":false,\"files\":[{\"id\":94680994,\"identity\":\"13c81ffb-7613-40e4-a2ee-1976688da730\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"docx\",\"order_by\":0,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":307523,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"Manuscript.docx\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/2b6c2035841cbbe04084adc5.docx\"},{\"id\":94680993,\"identity\":\"aab71617-e171-444e-bbea-e48feb5f85a2\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"json\",\"order_by\":1,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":5299,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"a6ffc37bccff4fbebce930afd6d2b3a3.json\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/67bc9ec3873830f3876c1ab3.json\"},{\"id\":94680992,\"identity\":\"12f2d8df-081b-42e9-b07d-7aa3dbba2767\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"xml\",\"order_by\":2,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":197397,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"a6ffc37bccff4fbebce930afd6d2b3a31enriched.xml\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/236cc5c00871204493fa81a0.xml\"},{\"id\":94680988,\"identity\":\"9c056abc-2d8f-4472-b9c9-10215b9ba2c3\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"jpeg\",\"order_by\":3,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":30455,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"floatimage1.jpeg\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/6d0a9806c9e9d8c34bf26c24.jpeg\"},{\"id\":94728356,\"identity\":\"934c292e-bfc4-4a75-9344-ea55ae960472\",\"added_by\":\"auto\",\"created_at\":\"2025-10-30 07:03:37\",\"extension\":\"png\",\"order_by\":4,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":20914,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"floatimage2.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/e02c8dd36d34bf0454e45c18.png\"},{\"id\":94680989,\"identity\":\"01c4c0a9-612c-4b18-a621-00f36c9b3aed\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"png\",\"order_by\":5,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":21880,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"Onlinefloatimage1.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/5bfb92658d083ccd84ff978c.png\"},{\"id\":94728110,\"identity\":\"b0e41d11-bb9c-4be2-af79-64b5de38c64a\",\"added_by\":\"auto\",\"created_at\":\"2025-10-30 07:03:05\",\"extension\":\"png\",\"order_by\":6,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":8104,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"Onlinefloatimage2.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/ce00a329a29973ca5c88ea49.png\"},{\"id\":94680995,\"identity\":\"352510f5-e040-4b1f-ab52-0c686a2f0771\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"xml\",\"order_by\":7,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":193928,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"a6ffc37bccff4fbebce930afd6d2b3a31structuring.xml\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/9223fd5a2ea67e197d92b73a.xml\"},{\"id\":94680996,\"identity\":\"2ca4f29d-9ed4-47b9-8664-7b8d851b9a62\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"html\",\"order_by\":8,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"acdc-reference\",\"size\":210614,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"earlyproof.html\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/ef1e29e9a153c1773bd7eaf9.html\"},{\"id\":94680986,\"identity\":\"e5a5bc79-3f12-4621-93f4-ec611451a530\",\"added_by\":\"auto\",\"created_at\":\"2025-10-29 14:50:10\",\"extension\":\"jpeg\",\"order_by\":1,\"title\":\"Figure 1\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":71625,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003ePicture 1: An example of a task creation interface in Atlassian Jira. (Source: https://www.softwaretestinghelp.com/atlassian-jira-tutorial-3/)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"floatimage1.jpeg\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/c209aeec4abfd94b861278f9.jpeg\"},{\"id\":94728195,\"identity\":\"619bf503-b963-4ddd-8464-f78ae60075e9\",\"added_by\":\"auto\",\"created_at\":\"2025-10-30 07:03:19\",\"extension\":\"png\",\"order_by\":2,\"title\":\"Figure 2\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":22293,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003ePicture 2: An example of updating work status on a digital task board in Azure DevOps (Source: https://learn.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops\\u0026amp;tabs=basic-process)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"floatimage2.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/c2bbde62847737ea260b5ce2.png\"},{\"id\":94731078,\"identity\":\"c5235ec7-885b-40d6-987a-39619ba10b18\",\"added_by\":\"auto\",\"created_at\":\"2025-10-30 07:07:20\",\"extension\":\"pdf\",\"order_by\":0,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"manuscript-pdf\",\"size\":987639,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"manuscript.pdf\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-7489297/v1/22af381e-b3e7-445d-8950-23eb591f0769.pdf\"}],\"financialInterests\":\"No competing interests reported.\",\"formattedTitle\":\"When Coordination Goes Wrong: The Challenge of Configuring Malleable Technologies in Teams\",\"fulltext\":[{\"header\":\"1. Introduction\",\"content\":\"\\u003cp\\u003eDigital technologies have profoundly shaped the nature of teamwork, enhancing collaboration and the organization of tasks (Larson and DeChurch \\u003cspan citationid=\\\"CR40\\\" class=\\\"CitationRef\\\"\\u003e2020\\u003c/span\\u003e). Yet, to ensure their continued usefulness, such technologies should ideally evolve alongside the changing dynamics of teamwork, and, thus, \\u003cem\\u003emalleable technologies\\u003c/em\\u003e have gained increasing traction in collaborative settings over the years (Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Larsen-Ledet and Borowski \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Hunger and Hirlehei \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Ten\\u0026oacute;rio, Pinto, and Bj\\u0026oslash;rn 2018). Malleable technologies are general-purpose technologies that allow ordinary users to modify or configure their capabilities according to user preferences (Lehrig, Krancher, and Dibbern \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Schmitz, Teng, and Webb 2016). Because of their openness and lack of specific purpose, \\u003cem\\u003econfiguration\\u003c/em\\u003e \\u0026ndash; the material (re)arrangement of technological elements in a digital technology, is necessary to realize the value of malleable technologies in their local contexts (Majchrzak et al. \\u003cspan citationid=\\\"CR55\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e; M.C. Moon, Hills, and Demiris 2018; Wiegel et al. \\u003cspan citationid=\\\"CR85\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Ellingsen, Hertzum, and Melby \\u003cspan citationid=\\\"CR9\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e). In team settings, because of the strong technological interdependence among team members, this process should ideally involve \\u003cem\\u003ecoordination\\u003c/em\\u003e to ensure configurations resulting from the management of individual dependencies to the shared technological systems (Domingos and Martins 1997; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). We refer to this idealized form of configuration in teams that shows considerations for the different needs and preferences of team members as \\u003cem\\u003eteam coordinated technology configuration\\u003c/em\\u003e.\\u003c/p\\u003e\\u003cp\\u003eHowever, despite its importance for unlocking the potential of team usability of malleable technologies, the process of configuration has received limited scholarly attention (Cabitza and Simone \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e). This gap is problematic, as without a processual understanding of whether team members coordinate configurations in practice, we risk overlooking how and why the implementations of malleable technologies may not always result in an evolving technological system tailored to the changing team needs (see e.g., Germonprez and Zigurs 2009; Huysman et al. \\u003cspan citationid=\\\"CR35\\\" class=\\\"CitationRef\\\"\\u003e2003\\u003c/span\\u003e; Wulf \\u003cspan citationid=\\\"CR87\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e). According to Richter and Riemer (\\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e), malleable technologies introduce a radically different adaptation process based on bottom-up, voluntary, and explorative dynamics that challenge the existing theories on technology change, focusing on top-down, planned, and prescribed implementation. Their highly unpredictable adaptation process further underscores the need to understand the emergence of coordinating such configurations through bottom-up interactions. Mousavidin and Silva (\\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e) reach similar conclusions in their literature review and call for in-depth field studies investigating the social and organizational dynamics shaping the configuration process of malleable technologies.\\u003c/p\\u003e\\u003cp\\u003eIn this paper, we examine how team dynamics influence team coordinated technology configurations of digital project management tools. Thus, our study is guided by the following research question: \\u003cem\\u003eHow do team members\\u0026rsquo; socio-material interactions influence their coordination of malleable technology configurations?\\u003c/em\\u003e Drawing on empirical data collected through a nine-month qualitative field study at a team-based IT company in Scandinavia, we study the configuration process of digital project management tools (DPMTs) in software development teams, particularly Atlassian Jira and Azure DevOps Server. DPMTs are a form of malleable technology widely used across various team contexts to support the planning and distribution of work (Raith, Richter, and Lindermeier \\u003cspan citationid=\\\"CR71\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Zhang \\u003cspan citationid=\\\"CR89\\\" class=\\\"CitationRef\\\"\\u003e2024\\u003c/span\\u003e). Adopting the theoretical lens of situated knowledge, we find that new configurations are obstructed by three emerging understandings of current configurations in teams: \\u003cem\\u003eassumed symmetry, assumed intentionality\\u003c/em\\u003e, and \\u003cem\\u003eassumed adequacy\\u003c/em\\u003e. Mediated by the distinct interplay between team organization and malleable technology, these understandings give rise to misalignment, compromise, and passivity \\u0026ndash; impeding the coordination of new configurations. Our findings demonstrate the essential, yet complicated work involved in technology configurations in teams, and highlight how this work shapes the effects of malleable technologies in collaborative work. Consequently, we unpack the socio-material \\u0026ldquo;enactments\\u0026rdquo; of malleable technologies and demonstrate how technology malleability can complicate, rather than facilitate, task-technology fit in teams. In doing so, we contribute to the field of CSCW by illuminating the implications of malleable technologies for cooperative work from users\\u0026rsquo; perspectives (E. Moon and Howison 2024), and providing new concepts guiding the appropriation and management of malleable technologies in team organizations (Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e).\\u003c/p\\u003e\\u003cp\\u003eThe rest of this paper is structured as follows: First, we review the literature on malleable technologies in team settings. Second, we introduce the theoretical framework of situated knowledge. Third, we describe our methodology and present the study findings. Fourth, we discuss the theoretical contributions and practical implications and highlight directions for future research.\\u003c/p\\u003e\"},{\"header\":\"2. Literature background\",\"content\":\"\\u003cdiv id=\\\"Sec3\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e2.1 Malleable technologies and teamwork\\u003c/h2\\u003e\\u003cp\\u003eMalleability is a quality of technology design that allows the digital technologies to be configured by end-users within the context of use to support a wide variety of work practices without changing the software source code (Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e). This characteristic distinguishes malleable technologies from traditional digital systems, where post-implementation changes are typically costly and require extensive collaboration between users and suppliers (see e.g., Fleck \\u003cspan citationid=\\\"CR25\\\" class=\\\"CitationRef\\\"\\u003e1994\\u003c/span\\u003e). Given that group interactions and requirements are often hard to predict (Lyytinen, Maaranen, and Knuuttila 1993), the field of CSCW has long viewed malleability as a key requirement for groupware \\u0026ndash; digital technologies that support interpersonal processes in collaborative work, as malleability enables teams to continuously adapt technologies to align with their evolving practices and preferences (Cabitza and Simone \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Mandviwalla and Olfman \\u003cspan citationid=\\\"CR25\\\" class=\\\"CitationRef\\\"\\u003e1994\\u003c/span\\u003e; Slagter, Biemans, and Hofte 2001; Wulf, Stiemerling, and Pfeifer \\u003cspan citationid=\\\"CR88\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e; Wulf \\u003cspan citationid=\\\"CR87\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e).\\u003c/p\\u003e\\u003cp\\u003eNevertheless, this malleability also implies that such technologies are general-purpose tools that, by themselves, are incomplete and ill-suited for any specific context of use (Fleck \\u003cspan citationid=\\\"CR24\\\" class=\\\"CitationRef\\\"\\u003e1993\\u003c/span\\u003e; Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Peine, Rollwagen, and Neven 2014). This intrinsic openness mirrors the biological notion of \\u003cem\\u003ealtriciality\\u003c/em\\u003e, which refers to species\\u0026mdash;such as humans\\u0026mdash;whose offspring are born in an underdeveloped state. While this early-stage incompleteness fosters adaptability, it also entails a deep dependence on caregivers. Similarly, configuring malleable technologies is not merely optional \\u0026ndash; it is often indispensable for making these technologies useful for the local context (Majchrzak et al. \\u003cspan citationid=\\\"CR55\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e; M.C. Moon, Hills, and Demiris 2018; Wiegel et al. \\u003cspan citationid=\\\"CR85\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e). This is confirmed by empirical studies demonstrating that the positive impact of malleable technologies on teamwork is contingent upon making configurations supporting team tasks and communication \\u0026ndash; i.e., establishing task-technology fit (see e.g., Correa and Selbach \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Magnus Li and Nielsen \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Slagter, Biemans, and Hofte 2001; Sommerville \\u003cspan citationid=\\\"CR79\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e; Wulf, Stiemerling, and Pfeifer \\u003cspan citationid=\\\"CR88\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e).\\u003c/p\\u003e\\u003cp\\u003eHowever, task-technology fit does not automatically come with the implementation of malleable technologies in teams. For example, Huysman et al. (\\u003cspan citationid=\\\"CR35\\\" class=\\\"CitationRef\\\"\\u003e2003\\u003c/span\\u003e) find that configuration efforts often cease shortly after implementation of malleable technologies and appear to be path dependent for each team. Wulf (\\u003cspan citationid=\\\"CR87\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e) finds that team members frequently struggle to comprehend the configurations made by others. This is not least the case in a context with relatively loose governance of configurations (cf. Shaikh and Henfridsson \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e), a common condition in teams enjoying relatively great autonomy (Mathieu et al. \\u003cspan citationid=\\\"CR58\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e). As existing studies (Germonprez and Zigurs 2009; Majchrzak et al. \\u003cspan citationid=\\\"CR55\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e; Thomas and Bostrom \\u003cspan citationid=\\\"CR83\\\" class=\\\"CitationRef\\\"\\u003e2010\\u003c/span\\u003e; J. P. Bansler and Havn \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e) mainly focus on the outcome of configuration, treating the antecedent process as a black box, we still lack the theoretical explanation of why malleable technologies do not always yield successful configurations that support team needs.\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec4\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e2.2 The role of coordination in the configuration of malleable technologies in teams\\u003c/h2\\u003e\\u003cp\\u003eWhen configurations take place in a team setting, they should ideally be a collaborative effort, with members jointly identifying and implementing suitable configurations (Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). This is especially important when malleable technologies are used as groupware, because such tools create a high degree of technological interdependence among users, so they cannot reject a shared configuration without losing access to essential functionality (Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). Moreover, because team members often diverge in their information and goals (also known as information asymmetry and goal asymmetry) (Edmondson, Roberto, and Watkins \\u003cspan citationid=\\\"CR21\\\" class=\\\"CitationRef\\\"\\u003e2003\\u003c/span\\u003e; Pearsall and Venkataramani 2015), the configuration process should ideally involve all team members to ensure technology usability.\\u003c/p\\u003e\\u003cp\\u003eThus, team coordination has been suggested as an essential activity in technology configurations (Domingos and Martins 1997; MacLean et al. \\u003cspan citationid=\\\"CR54\\\" class=\\\"CitationRef\\\"\\u003e1990\\u003c/span\\u003e; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). Coordination refers to the set of activities that ensure individuals work interdependently according to defined plans, rules, and roles to reach common goals (Bailey, Leonardi, and Chong \\u003cspan citationid=\\\"CR2\\\" class=\\\"CitationRef\\\"\\u003e2010\\u003c/span\\u003e; Faraj and Xiao \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e; Okhuysen and Bechky \\u003cspan citationid=\\\"CR63\\\" class=\\\"CitationRef\\\"\\u003e2009\\u003c/span\\u003e). In team settings, where multiple individuals contribute to a shared task, coordination is required to produce a positive outcome (Mathieu et al. \\u003cspan citationid=\\\"CR58\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e). This is also expected in relation to the configurations of malleable technologies, which should ideally be based on collective goal setting and decisions resulting from the management of individual dependencies to the shared technological systems (Malone and Crowston \\u003cspan citationid=\\\"CR25\\\" class=\\\"CitationRef\\\"\\u003e1994\\u003c/span\\u003e; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). It is suggested that appointing a local expert responsible for coordination may benefit the configuration process of malleable technologies (Slagter, Biemans, and Hofte 2001; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). This, however, requires that such an expert can create a balance between the evolving technology and organization (Griffith, Sawyer, and Poole \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e). To highlight the collaborative character of this idealized form of configuration in teams, we refer to them as team coordinated technology configurations.\\u003c/p\\u003e\\u003cp\\u003eThis distinction is necessary, as the theoretical influence of coordination on malleable technology configuration has yet to be examined empirically, and such coordination can be difficult to achieve for at least two reasons. First, because configuration can be executed by single users, it does not technically presuppose coordination. Second, reaching consensus on a configuration solution that suits all team members can be challenging, especially in teams with diverse needs and practices. Moreover, as there is a dearth of studies examining the process of team configurations of malleable technologies (Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Cabitza and Simone \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e), it remains unclear whether and how coordination of the ongoing configurations takes place and how this influences the ongoing fit between technology and team.\\u003c/p\\u003e\\u003c/div\\u003e\"},{\"header\":\"3. Situated knowledge\",\"content\":\"\\u003cp\\u003eThis paper investigates how teams engage in the ongoing process of configuring their malleable technologies. To do so, we adopt the lens of situated knowledge theory. This perspective (Gherardi \\u003cspan citationid=\\\"CR29\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e; Haraway \\u003cspan citationid=\\\"CR33\\\" class=\\\"CitationRef\\\"\\u003e1988\\u003c/span\\u003e) conceptualizes knowledge not as a static possession, but as a dynamic, socially embedded accomplishment, termed \\u0026lsquo;knowing\\u0026rsquo;. Knowing emerges through active participation in a web of relationships among people, artifacts, and practices (Gherardi \\u003cspan citationid=\\\"CR28\\\" class=\\\"CitationRef\\\"\\u003e2001\\u003c/span\\u003e; Orlikowski \\u003cspan citationid=\\\"CR64\\\" class=\\\"CitationRef\\\"\\u003e2002\\u003c/span\\u003e). It is materially grounded in the body of the knower, shaped by discourse, and situated within specific historical and physical contexts (Gherardi \\u003cspan citationid=\\\"CR29\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e). Digital technology plays a central role in this process, serving as a material scaffold for organizational knowing. Orlikowski (\\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e) describes technologies as the \\u0026ldquo;scaffolding of knowledgeability\\u0026rdquo; (p. 462): they structure, guide, and at times discipline human activity. Yet, their role is often easy to overlook, as once knowledge is enacted, the scaffolds that supported its formation become obsolete.\\u003c/p\\u003e\\u003cp\\u003eBy foregrounding the situated nature of knowledge, we aim to move beyond the conventional view of knowledge as an internal, cognitive representation. We instead propose two key shifts. First, knowledge is embodied\\u0026mdash;partial, material, and technologically mediated (Dreyfus and Dreyfus 1986; Haraway \\u003cspan citationid=\\\"CR33\\\" class=\\\"CitationRef\\\"\\u003e1988\\u003c/span\\u003e; Orlikowski \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). Second, knowledge is collective\\u0026mdash;cultural, historical, and publicly observable (Lave and Wenger \\u003cspan citationid=\\\"CR41\\\" class=\\\"CitationRef\\\"\\u003e1991\\u003c/span\\u003e; Wittgenstein \\u003cspan citationid=\\\"CR86\\\" class=\\\"CitationRef\\\"\\u003e1954\\u003c/span\\u003e/2009). Together, these shifts suggest that knowing is an active, situated practice carried out by individuals within specific sociomaterial contexts (Haraway \\u003cspan citationid=\\\"CR33\\\" class=\\\"CitationRef\\\"\\u003e1988\\u003c/span\\u003e; Orlikowski \\u003cspan citationid=\\\"CR64\\\" class=\\\"CitationRef\\\"\\u003e2002\\u003c/span\\u003e; Orlikowski and Scott \\u003cspan citationid=\\\"CR66\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e). This partiality is both a limitation\\u0026mdash;introducing bias and constraint\\u0026mdash;and a resource, enabling specific forms of insight and capability (Simandan \\u003cspan citationid=\\\"CR77\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e).\\u003c/p\\u003e\\u003cp\\u003eEmphasizing the embeddedness of knowing also raises a crucial question: how do multiple situated knowledges relate to one another? Are they complementary, conflicting, parallel, or intersecting? Law (\\u003cspan citationid=\\\"CR42\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e) introduces the concept of knowing-as-displacing to describe the inevitable tension that arises from the coexistence of multiple knowledge-in-practice. Because each enactment of knowing is partial and situated, there can be simultaneously valid, yet divergent, knowledge claims. Technology further amplifies this multiplicity by enabling diverse knowledge locations (Bruni, Gherardi, and Parolin 2007). This plurality can give rise to coordination challenges: different knowings may coexist but remain incommensurate, never fully reconciled (Barley, Treem, and Kuhn \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e). These questions of multiplicity and coherence only become more salient in team settings and lie at the heart of our inquiry\\u0026mdash;and we will return to them in due course.\\u003c/p\\u003e\"},{\"header\":\"4. Methodology\",\"content\":\"\\u003cdiv id=\\\"Sec7\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e4.1 Research design and context\\u003c/h2\\u003e\\u003cp\\u003eTo investigate the research question, we conducted a qualitative field study (Spradley \\u003cspan citationid=\\\"CR80\\\" class=\\\"CitationRef\\\"\\u003e1979\\u003c/span\\u003e, \\u003cspan citationid=\\\"CR81\\\" class=\\\"CitationRef\\\"\\u003e2011\\u003c/span\\u003e) at a Scandinavian IT company guided by a critical realism-inspired view of human-technology relations (Kempton \\u003cspan citationid=\\\"CR38\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e; Leonardi \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e). This approach was particularly suitable to examine practices of work as situated in sociomaterial assemblages (Blomberg and Karasti \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e), which is useful for outlining the multiplicity of knowing complicating the configuration of malleable technologies in teams.\\u003c/p\\u003e\\u003cp\\u003eWe purposefully sampled the field organization InnoSoft (pseudonym) as the place to conduct this study. In many ways, InnoSoft provided the theoretically ideal condition for team coordinated technology configurations. As a small organization with a flat hierarchy, the work teams at InnoSoft have a large degree of freedom to define their own work process and choose their own groupware. Although the two standard DPMTs (particularly, Atlassian Jira and Azure DevOps) at InnoSoft were furnished with default settings, there was no officially prescribed way of using these tools, and the teams were permitted both technically and organizationally to configure these tools as they liked. Moreover, since the teams at InnoSoft were software development teams, even the project managers who did not necessarily have a software education were decently technically skilled compared to the public. Thus, the InnoSoft teams possessed the autonomy, control over technology, and basic technological knowledge that should, in theory, empower them to engage in team coordinated technology configurations of malleable technologies (Lehrig, Krancher, and Dibbern 2015; MacLean et al. \\u003cspan citationid=\\\"CR54\\\" class=\\\"CitationRef\\\"\\u003e1990\\u003c/span\\u003e; Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e). This is supported by the general attitude of DPMTs as \\u0026lsquo;flexible tools\\u0026rsquo; shared by many employees of InnoSoft.\\u003c/p\\u003e\\u003cp\\u003eAlthough the malleability of DPMTs can be different depending on the specific version of these tools, the currently popular DPMTs generally offer users plenty of possibilities for making configurations (Arya and Kulkarni \\u003cspan citationid=\\\"CR1\\\" class=\\\"CitationRef\\\"\\u003e2024\\u003c/span\\u003e; Buturugă, Gogoi, and Prodan 2016; Jira \\u003cspan citationid=\\\"CR37\\\" class=\\\"CitationRef\\\"\\u003e2024\\u003c/span\\u003e). While it is beyond the scope of this paper to outline all the configuration possibilities of Atlassian Jira or Azure DevOps, we will provide two concrete examples to illustrate the kind of configurations involved in the current study.\\u003c/p\\u003e\\u003cp\\u003eThe first example is related to the task-creation feature of DPMTs, which leads to a new interface containing a predefined template of a task with both mandatory and optional text fields. The quantity and the order of these text fields can be configured. Moreover, the teams can also create or remove categories used to specify, e.g., issue type and components (see picture 1). The purpose of configuring such a predefined template of task creation is to ensure that the tasks are created consistently, containing all the necessary information, and that the teams can use the filter feature to quickly locate the tasks of interest.\\u003c/p\\u003e\\u003cp\\u003e\\u003c/p\\u003e\\u003cp\\u003e\\u003cem\\u003ePicture 1: An example of a task creation interface in Atlassian Jira. (Source\\u003c/em\\u003e: \\u003cspan class=\\\"ExternalRef\\\"\\u003e\\u003cspan class=\\\"RefSource\\\"\\u003ehttps://www.softwaretestinghelp.com/atlassian-jira-tutorial-3/\\u003c/span\\u003e\\u003cspan address=\\\"https://www.softwaretestinghelp.com/atlassian-jira-tutorial-3/\\\" targettype=\\\"URL\\\" class=\\\"RefTarget\\\"\\u003e\\u003c/span\\u003e\\u003c/span\\u003e\\u003cem\\u003e)\\u003c/em\\u003e\\u003c/p\\u003e\\u003cp\\u003eThe second example is related to moving tasks on the task boards of DPMTs to update work status (see picture 2). This can be, e.g., moving a task from the column of \\u0026lsquo;To Do\\u0026rsquo; to \\u0026lsquo;Doing\\u0026rsquo; to indicate the start of a task. It is possible to configure various automations in relation to such movements, and a common automation for the aforementioned movement is automatically assigning the issue to the user who has moved the task. The rationale of this configuration is to save additional work of subsequently having to assign the task to oneself.\\u003c/p\\u003e\\u003cp\\u003e\\u003c/p\\u003e\\u003cp\\u003e\\u003cem\\u003ePicture 2: An example of updating work status on a digital task board in Azure DevOps (Source\\u003c/em\\u003e: \\u003cspan class=\\\"ExternalRef\\\"\\u003e\\u003cspan class=\\\"RefSource\\\"\\u003ehttps://learn.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops\\u0026amp;tabs=basic-process\\u003c/span\\u003e\\u003cspan address=\\\"https://learn.microsoft.com/en-us/azure/devops/boards/get-started/plan-track-work?view=azure-devops\\u0026amp;tabs=basic-process\\\" targettype=\\\"URL\\\" class=\\\"RefTarget\\\"\\u003e\\u003c/span\\u003e\\u003c/span\\u003e\\u003cem\\u003e)\\u003c/em\\u003e\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec8\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e4.2 Data collection\\u003c/h2\\u003e\\u003cp\\u003eThis study was a part of a larger qualitative field study examining the use of DPMTs and collaboration in software development teams. The malleability of DPMTs, particularly the frustrations over the configurations of these tools, emerged as a theme of great importance to the team members\\u0026rsquo; collaboration early in the data collection process.\\u003c/p\\u003e\\u003cp\\u003eThe field work was conducted by the first author under the close guidance of the second and the third author. Within InnoSoft, seven software development teams were selected in collaboration with the gatekeeper based on the principle of maximizing variation (Flick \\u003cspan citationid=\\\"CR26\\\" class=\\\"CitationRef\\\"\\u003e2018\\u003c/span\\u003e). This resulted in the inclusion of teams with different team sizes and different lengths of collaboration history. The first author followed these teams over nine months (May \\u003cspan citationid=\\\"CR9\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e-January 2023) using participant observation and semi-structured interviews. When possible and allowed, she also collected screenshots of the DPMTs used in the teams as digital documents. For an overview of the data sources, see Table\\u0026nbsp;\\u003cspan refid=\\\"Tab1\\\" class=\\\"InternalRef\\\"\\u003e1\\u003c/span\\u003e.\\u003c/p\\u003e\\u003cp\\u003e\\u003cdiv class=\\\"gridtable\\\"\\u003e\\u003ctable float=\\\"Yes\\\" id=\\\"Tab1\\\" border=\\\"1\\\"\\u003e\\u003ccaption language=\\\"En\\\"\\u003e\\u003cdiv class=\\\"CaptionNumber\\\"\\u003eTable 1\\u003c/div\\u003e\\u003cdiv class=\\\"CaptionContent\\\"\\u003e\\u003cp\\u003eAn overview of the data sources\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/caption\\u003e\\u003ccolgroup cols=\\\"2\\\"\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c1\\\" colnum=\\\"1\\\"\\u003e\\u003c/div\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c2\\\" colnum=\\\"2\\\"\\u003e\\u003c/div\\u003e\\u003cthead\\u003e\\u003ctr\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eData source\\u003c/p\\u003e\\u003c/th\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eDescription\\u003c/p\\u003e\\u003c/th\\u003e\\u003c/tr\\u003e\\u003c/thead\\u003e\\u003ctbody\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e720 pages of field notes in Microsoft Word (single-spaced 11-point Calibri)\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eBased on 75 days of participant observation performed on the following occasions:\\u003c/p\\u003e\\u003cp\\u003e- Observing individual team members working at the office (40 days)\\u003c/p\\u003e\\u003cp\\u003e- Breaks and meals in the office lounge (10 days)\\u003c/p\\u003e\\u003cp\\u003e- Daily team status meetings (50)\\u003c/p\\u003e\\u003cp\\u003e- Team evaluation meetings (10)\\u003c/p\\u003e\\u003cp\\u003e- Team planning meetings (15)\\u003c/p\\u003e\\u003cp\\u003e- Team review meetings (15)\\u003c/p\\u003e\\u003cp\\u003e- Weekly company meetings (15)\\u003c/p\\u003e\\u003cp\\u003e- Other meetings (10)\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e22 Semi-structured interviews\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eLasting 30 to 90 minutes with team members of different positions and seniority.\\u003c/p\\u003e\\u003cp\\u003e- Team members with leadership functions (e.g., project managers, scrum masters): 8\\u003c/p\\u003e\\u003cp\\u003e- Ordinary team members (e.g., front-end developers, business analysts): 14\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e400 pages of digital documents\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eConsisting of, among other things:\\u003c/p\\u003e\\u003cp\\u003e- Screenshots of the DPMTs used in the project\\u003c/p\\u003e\\u003cp\\u003e- E-mail and chat correspondence between team members\\u003c/p\\u003e\\u003cp\\u003e- Minutes of meetings\\u003c/p\\u003e\\u003cp\\u003e- Company newsletters\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003c/tbody\\u003e\\u003c/colgroup\\u003e\\u003c/table\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eThe overall procedure of the field work resembled the guidelines suggested by Spradley (\\u003cspan citationid=\\\"CR81\\\" class=\\\"CitationRef\\\"\\u003e2011\\u003c/span\\u003e, \\u003cspan citationid=\\\"CR80\\\" class=\\\"CitationRef\\\"\\u003e1979\\u003c/span\\u003e). The first author started with descriptive observations to familiarise herself with the language and life of software development teams at InnoSoft and their overall use of DPMTs. This was followed by more focused observations, which sought to elucidate how the configurations of DPMTs influence the practices of team members at different occasions of work, e.g., in meetings, working in pairs, and working individually. During participant observations, the first author noted down questions and observations, which she then used to conduct informal interviews when suitable opportunities arose. Such informal interviews lasted between 3 to 45 minutes; however, they were mostly kept around 10 minutes for the sake of the participants. While being in the field, the first author conducted detailed and verbatim jottings of the observed events, which she then wrote into field notes as soon as possible after returning from the field.\\u003c/p\\u003e\\u003cp\\u003eAfter progressing into more focused observations, the first author started to contact team members to schedule semi-structured interviews. Contrary to the informal interviews conducted in situ, these semi-structured interviews were performed at company meeting rooms or via videoconferencing while the participants worked from home. Thus, they allowed the team members more privacy and time to explain and elaborate on their thoughts and experiences regarding the configurations of DPMTs without the risk of other team members overhearing the conversation. The interview guide was informed by the insights gained during participant observation and tailored to suit each interviewee\\u0026rsquo;s team membership, job position, and seniority. However, it also contained generic and open questions to allow the exploration of topics of interest to the participants. Because InnoSoft teams were organized in different ways, and team members did not have clear-cut job titles, to ensure the confidentiality of the participants, we simplified the job roles into two categories in Table\\u0026nbsp;\\u003cspan refid=\\\"Tab1\\\" class=\\\"InternalRef\\\"\\u003e1\\u003c/span\\u003e.\\u003c/p\\u003e\\u003cp\\u003eCombining participant observation and semi-structured interviews offered us the opportunity for method and data-source triangulations (Carter et al. \\u003cspan citationid=\\\"CR15\\\" class=\\\"CitationRef\\\"\\u003e2014\\u003c/span\\u003e) and was essential for uncovering the different perspectives and sometimes contradicting understandings regarding DPMT configurations within a software development team.\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec9\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e4.3 Data analysis\\u003c/h2\\u003e\\u003cp\\u003eWe followed the structure of thematic analysis (Braun and Clarke \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e), which provided a systematic and theoretically flexible approach for analysing qualitative data. The first phase of familiarizing yourself with data was commenced soon after the collection of the first field notes, where initial ideas were noted down to help adapt the data collection strategies ongoingly. It was at this stage that we became aware of the seemingly contradictory relationship between, on the one hand, the potential malleability of DPMTs, and on the other, the actual frustrations and struggles team members experienced in their daily use of DPMTs. To investigate this discrepancy more closely, the first author conducted inductive coding of the entire dataset guided by attention towards the team members\\u0026rsquo; different attitudes, experiences, and understandings of DPMTs. Following the recommendation of Braun and Clarke (\\u003cspan citationid=\\\"CR9\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e), this inductive coding was repeated a few times to ensure the consistency of codes without undermining the diversity of meanings contained in the dataset.\\u003c/p\\u003e\\u003cp\\u003eAll three authors participated in the next analytic phase of searching, reviewing, and defining themes. This was conducted in an iterative manner, where we moved back and forth between these three steps. Here, we also started with an inductive approach, where we grouped codes based on their broader thematic similarity. However, to make sense of these inductively identified themes, we conducted a comprehensive review of the literature regarding malleable technologies and configurations in teams. By comparing our initial themes with the existing literature (among others, Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Schmitz, Teng, and Webb 2016), we realized that our data provides a processual view on the configuration of malleable technology in teams that was sought after in the current literature. By further refining the themes into three to identify the central mechanisms impeding team coordinated technology configurations, we come to realize the centrality of knowing, particularly the multiplicity and displacement of knowing, in explaining these processes. As this insight emerged, we consulted the literature on situated knowledge (among others, Gherardi \\u003cspan citationid=\\\"CR29\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e; Haraway \\u003cspan citationid=\\\"CR33\\\" class=\\\"CitationRef\\\"\\u003e1988\\u003c/span\\u003e; Orlikowski \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e) to further refine the three themes into the current version. Table\\u0026nbsp;\\u003cspan refid=\\\"Tab2\\\" class=\\\"InternalRef\\\"\\u003e2\\u003c/span\\u003e provides examples of data excerpts underpinning the three themes.\\u003c/p\\u003e\\u003cp\\u003e\\u003cdiv class=\\\"gridtable\\\"\\u003e\\u003ctable float=\\\"Yes\\\" id=\\\"Tab2\\\" border=\\\"1\\\"\\u003e\\u003ccaption language=\\\"En\\\"\\u003e\\u003cdiv class=\\\"CaptionNumber\\\"\\u003eTable 2\\u003c/div\\u003e\\u003cdiv class=\\\"CaptionContent\\\"\\u003e\\u003cp\\u003eExamples of data excerpts underpinning the three themes\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/caption\\u003e\\u003ccolgroup cols=\\\"2\\\"\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c1\\\" colnum=\\\"1\\\"\\u003e\\u003c/div\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c2\\\" colnum=\\\"2\\\"\\u003e\\u003c/div\\u003e\\u003cthead\\u003e\\u003ctr\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eExamples of data excerpt\\u003c/p\\u003e\\u003c/th\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eThe final themes\\u003c/p\\u003e\\u003c/th\\u003e\\u003c/tr\\u003e\\u003c/thead\\u003e\\u003ctbody\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e(Field note taken while observing individual team members working at the office)\\u003c/p\\u003e\\u003cp\\u003eBob asked Charlie whether he had administrator access to project Alpha\\u0026rsquo;s DPMT. Charlie was quite convinced that he was not the administrator for project Alpha\\u0026rsquo;s DPMT.\\u003c/p\\u003e\\u003cp\\u003eBob went out of the office, and shortly after, he came in again. Bob went over to Thorvald, a former developer on project Alpha: \\u0026ldquo;Can you give me more access to [DPMT]?\\u0026rdquo;\\u003c/p\\u003e\\u003cp\\u003eThorvald: \\u0026ldquo;No, I cannot, I am only a guest.\\u0026rdquo;\\u003c/p\\u003e\\u003cp\\u003eBob: \\u0026ldquo;It just said that you are an administrator.\\u0026rdquo;\\u003c/p\\u003e\\u003cp\\u003eCharlie: \\u0026ldquo;Is it really me, who is the administrator?\\u0026rdquo;\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eAssumed symmetry - Misalignment\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e(Formal interview with an ordinary user)\\u003c/p\\u003e\\u003cp\\u003eJames: \\u0026lsquo;You get used to it. I\\u0026rsquo;ve worked with it (DPMT) for many years now. It\\u0026rsquo;s frustrating that when I need to select components, I have to choose from a list of 40, even though we only use three of them. It shouldn\\u0026rsquo;t be such a struggle; it should just be easy to use. [\\u0026hellip;] Unfortunately, we\\u0026rsquo;re impacted by components from other projects. That\\u0026rsquo;s just the way it is.\\u0026rsquo;\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eAssumed intentionality - Compromises\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003e(Formal interview with an ordinary user)\\u003c/p\\u003e\\u003cp\\u003eMike: \\u0026lsquo;I have to admit, at some point I just said, okay, this is how they (the team) do it. I am not set on this project to clean up their [DPMT], so I just take it as it is.\\u0026rsquo;\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eAssumed adequacy - Passivity\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003c/tbody\\u003e\\u003c/colgroup\\u003e\\u003c/table\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003c/div\\u003e\"},{\"header\":\"5. Findings\",\"content\":\"\\u003cdiv id=\\\"Sec11\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e5.1 Assumed symmetry \\u0026ndash; Misalignment\\u003c/h2\\u003e\\u003cp\\u003eSimilar to many other organizations concerned with information and data security, the software teams of InnoSoft adhere to the principle of \\u0026lsquo;least privilege\\u0026rsquo; when managing access to groupware such as DPMTs. This principle prescribes a cautious approach to software access management, where individuals only receive the minimum level of access required to perform their job functions effectively. The team members are well aware of the security reasons behind the differentiation of technology access and the logic of the least privilege principle:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eSteve: \\u0026lsquo;So that's also why we don't give people access to everything, because I might end up having access to delete the entire project. I could end up deleting it, maybe... So, one should only give access to what is needed.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eTherefore, only a few selected individuals within each team, the so-called \\u0026lsquo;super users\\u0026rsquo;, have access, or the behavioral capability to configure their teams\\u0026rsquo; DPMT:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eCarl: \\u0026lsquo;Actually, I recently became a super user in [team X], and I therefore have some extra privileges, such as being allowed to make automation and stuff like that on our [task] board. I was just appointed the one who received these privileges and can do this if there is a need for something. It is called \\u0026ldquo;super user\\u0026rdquo;.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eThe remaining team members typically commence with the minimum level of access, which means that they can only use and see DPMTs as these tools are configured, either by default or by the super users. These team members usually refer to themselves as \\u0026lsquo;the rest of us\\u0026rsquo; or \\u0026lsquo;\\u003cem\\u003enot\\u003c/em\\u003e super users\\u0026rsquo;, which we, for the sake of simplicity, refer to as ordinary users. The teams themselves do not expect that the differentiation of technology access will pose any challenge for configuring DPMTs, because ordinary users arguably still can make use of technology malleability by requesting a super user to make configurations on their behalf. This belief is particularly supported by the fact that in InnoSoft, super users do not necessarily possess more formal power than ordinary users (e.g., by officially holding a higher position), and the teams generally strive towards self-management.\\u003c/p\\u003e\\u003cp\\u003eHowever, because the interfaces of DPMTs appear differently depending on your level of access, the differentiation of access creates two different ways of experiencing the groupware for super users and ordinary users, unbeknownst to the team members. Unaware of the differences between their perspectives, both parties encounter difficulties in comprehending the other party\\u0026rsquo;s user experience, which impedes meaningful coordination. This is reflected in the following interview with software developer Steve, who describes the challenge of being an ordinary user in a team.\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eSteve: \\u0026lsquo;Sometimes, it is rather confusing. There was once this project, where I had to\\u0026hellip; It was really annoying that I couldn\\u0026rsquo;t see logs, for example, because\\u0026hellip; Apparently, I didn\\u0026rsquo;t have access to it. So, I sat there for a long time and thought, \\u0026ldquo;Why couldn\\u0026rsquo;t I see logs here?\\u0026rdquo;\\u0026rsquo;\\u003c/p\\u003e\\u003cp\\u003eThe researcher: \\u0026lsquo;You can\\u0026rsquo;t see logs if you\\u0026hellip;?\\u0026rsquo;\\u003c/p\\u003e\\u003cp\\u003eSteve: \\u0026lsquo;Sometimes, it again depends on which access you have. So, there had been a few times when I couldn\\u0026rsquo;t see why I couldn\\u0026rsquo;t see it. So I went to Dean, and it turned out that he could see it because he had more access to it than I had.\\u0026rsquo;\\u003c/p\\u003e\\u003cp\\u003eThe researcher: \\u0026lsquo;Okay, so maybe you thought in the beginning that you just can\\u0026rsquo;t see logs in this tool?\\u0026rsquo;\\u003c/p\\u003e\\u003cp\\u003eSteve: \\u0026lsquo;Yeah, so I had thought that, yes, so and so, why can\\u0026rsquo;t I find my way around in here? Or that I had been stupid, right? It turned out that it was simply because I didn\\u0026rsquo;t have access.\\u0026rsquo;\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eIn this incident, neither Steve nor his super user colleague Dean was initially aware that the problems Steve encountered were caused by his limited access. However, this was only discovered as Steve directly compared his perspective of the groupware with Dean\\u0026rsquo;s. This demonstrates how a distinct knowing of \\u003cem\\u003eassumed symmetry\\u003c/em\\u003e is enacted in the context of dissimilar user positions and the belief of equal technology access and capabilities. By expecting the others\\u0026rsquo; experience as not identical, but similar to their own, this assumed symmetry makes super users interpret their additional behavioral capabilities as common options for all team members. For ordinary users, this assumed symmetry hinders them from realizing and discovering alternative configuration solutions that may benefit their work.\\u003c/p\\u003e\\u003cp\\u003eAt the team level, this assumed symmetry results in a \\u003cem\\u003emisalignment\\u003c/em\\u003e, where users talk past each other and fail to recognize their disparities of perspectives and experiences with the malleable groupware that are simultaneously valid. This lack of coordination between perspectives is problematic, because the configurations of DPMTs become more a reflection of the personal preferences of the super users, as the ordinary users cease their involvement when realizing their inability. This is reflected in the following comment of ordinary user Percy when talking about a feature of DPMT that irritates him:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003ePercy: \\u0026lsquo;I could have just asked Raymond (super user) to do it. But the thing is, I haven't really bothered to move forward with it. When I realized I couldn't, I said, \\\"Fuck it,\\\" and moved on to do something else.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eThis theme shows that the differentiation of access creates dissimilar positions (super user vs ordinary user) of experiencing the malleable groupware that cannot be grasped by any single user alone. Unaware of the diversity in perspectives, the individual team members develop a knowing of assumed symmetry, where they expect the others\\u0026rsquo; experience with the technology as close to their own. At the team level, this results in a misalignment, where the disparities of perspectives and the struggles of ordinary users are ignored.\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec12\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e4.2 Assumed intentionality \\u0026ndash; Compromises\\u003c/h2\\u003e\\u003cp\\u003eConsistent with theoretical predictions in CSCW literature, team members at InnoSoft generally expect that malleable technologies such as DPMTs offer better support for teamwork because of their malleability. However, they also recognize that even malleable technologies cannot provide a perfect fit for every team process. Firstly, despite their malleability, DPMTs are built upon technical assumptions that are not subject to configuration, as in the end, these tools are intended for managing projects and not, e.g., sharing documents. This means that sometimes the process of configuration involves choosing between several imperfect solutions within the given malleability of a DPMT that only partially fits with the current workflow:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eJames: \\u0026lsquo;When we develop a feature, we have to develop it for both Android and iOS; however, sometimes we don\\u0026rsquo;t do it in the same sprint, and we of course want to have only one (task) description for both tasks. However, if you do it as two sub-tasks under the same description, then we have to have both tasks in the same sprint. If we instead choose to clone one task, so there are two, one for iOS and one for Android, then we have suddenly two tasks with descriptions that need to be maintained, or one with a description and one without, so you need to find back to the description. It is very stupid. It is weird that they haven\\u0026rsquo;t fixed it yet. We are not the only ones who develop for both Android and iOS.\\u0026rsquo; (field note)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eSecondly, even when a feature can be configured to perfectly match the team-specific workflow, this configuration solution may not suit the needs or preferences of all team members equally. As everybody in the team shares the configuration results, sometimes team members may have to endure obstructive configuration results to accommodate the needs of others:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eSteve: \\u0026lsquo;It is a very annoying configuration, and it really confuses me. However, the others find it super nice. So, they (the team) said to me, \\u0026ldquo;Well, you can just ignore it.\\u0026rdquo;\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eThis means, despite malleability, the team members frequently endure small inconveniences and annoyances in their everyday work with DPMTs, which are not caused by the lack of possible reconfiguration (malleability) but rather by different preferences among the team members. This reality challenges the task of proposing new configuration solutions, as team members need to navigate a distinction between changeable features and features, they need to compromise on. This distinction is far from self-evident, as it requires knowing the local configuration history of the malleable technology \\u0026ndash; how the system has been adapted over time and why. For team members who simply were not there when configuration decisions were made, such knowledge is impossible to obtain without assistance. Since teams in InnoSoft frequently undergo staff changes and rotations, the reasons behind the existing configuration results of DPMTs tend to become products of team members\\u0026rsquo; own guesswork. Many choose to give the existing configuration results the benefit of the doubt, as illustrated in the following example:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eOliver: \\u0026lsquo;I suspect that they had already tried these different things, and also this (alternative) that I just proposed, and then it showed that for many people it simply didn\\u0026rsquo;t work. So, I am not at all in doubt that a lot of thought had been put into how to do it, and then they had decided to go with the least evil way. At least, this is what I suspect, without knowing.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eOliver\\u0026rsquo;s account illustrates what we term a knowing of \\u003cem\\u003eassumed intentionality\\u003c/em\\u003e, where team members individually rationalize existing configuration results as deliberate and reasonable choices conducted by someone in the past, despite not knowing the exact reason. This knowing helps the team members to accept that the current configuration solution does not fit their preferred way of working and adapt their own processes accordingly.\\u003c/p\\u003e\\u003cp\\u003eHowever, although assumptions of certain configuration solutions being somehow valuable to someone in the team minimize potential conflicts in teams, they also prevent team members from critically questioning the existing configuration solutions and tolerate obstructive features, even when it is unnecessary. This becomes evident when joining the perspectives of team members together. In the following case, James comes to assume, mistakenly, that the default setting of his team\\u0026rsquo;s DPMT is a result of a deliberate configuration process made by Ethan, who has been on the project from the beginning:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eJames: \\u0026lsquo;I wasn\\u0026rsquo;t here when they started this project. But I think it is probably Ethan, as a developer, for example, who said, \\u0026ldquo;We had done this in other projects, so let\\u0026rsquo;s do it here as well\\u0026rdquo;. It is probably them who use the [tool] on a daily basis, who have asked for configuring things this way, or have chosen to configure things as we used to do it.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eHowever, in a separate interview, when Ethan was asked about the same configuration solutions, he replied: \\u0026lsquo;No, I wouldn\\u0026rsquo;t say that we have prioritized it, it just ended up like this.\\u0026rsquo;\\u003c/p\\u003e\\u003cp\\u003eThis discrepancy reveals how assumed intentionality prevents team members from coordinating their understanding of what features can be changed in their teams. By unquestionably accommodating \\u0026lsquo;each other\\u0026rsquo;, the current configurations are preserved through ongoing \\u003cem\\u003ecompromises\\u003c/em\\u003e at the team level.\\u003c/p\\u003e\\u003cp\\u003eThis theme illustrates how the unavoidable differences in preferences among the team members, combined with the uncertainty around the local configuration history, give rise to a knowing of assumed intentionality among team members. This knowing allows them to rationalize obstructive configuration solutions and helps them adapt to imperfect systems. However, it also impedes the coordination between team members on what features can be changed in their teams. As a result, this knowing contributes to conserving the existing and sometimes dysfunctional configurations through ongoing compromises.\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec13\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e4.3 Assumed adequacy \\u0026ndash; Passivity\\u003c/h2\\u003e\\u003cp\\u003eSimilar to many other software development teams, none of the team members in InnoSoft consider configuring DPMTs a part of their core job duties, not even the super users. These tools are adopted to support the teams\\u0026rsquo; task management and coordination needs. Hence, they should minimize their workload, not increase it. This fundamental assumption regarding DPMTs renders time spent studying, discussing, or configuring DPMTs illegitimate and bothersome. As explained by super user Samuel:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eSamuel: \\u0026lsquo;You have to be careful not to use your entire work time on [DPMT] looking at stuff. At least if you are a developer, then you should only log on to [DPMT] to find out what you should work on and then go work on your code. At least I will try to avoid using too much time on administrating [DPMT].\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eHowever, as the two previous themes already demonstrate, configuring malleable technologies often requires far more time and effort than a simple \\u0026lsquo;quick in and out\\u0026rsquo;. To discover the needs for new configuration solutions, teams must overcome misalignments and compromises caused by assumed symmetry and assumed intentionality. Afterwards, more effort is needed to identify alternative configuration options and agree on a single configuration solution, which best accommodates the team\\u0026rsquo;s diverse needs \\u0026ndash; a process that becomes even more complicated when there are divergent opinions involved. Given this, team members often feel an implicit expectation from each other to have a ready-made configuration solution before initiating the configuration process at the team level, a condition that is seldom met:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eJack: \\u0026lsquo;Because you always have to, if you come up with such a suggestion, then you always have to also solve it in one way or another. So, if you don\\u0026rsquo;t know the [DPMT] well enough for doing that, then it is also a bit difficult to pitch for a change.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eExactly because some inconveniences and annoyances with DPMTs are unavoidable, as described in theme 2, having the alternative configuration solution ready is seen as necessary to ensure that the configuration process will result in something feasible and desirable, rather than futile and unproductive attempts. Nevertheless, this condition is seldom met, as most of the team members do not feel that they have the time or responsibility to explore the abundant amounts of configuration options offered by DPMTs and figure out the best alternative configuration solution. As a result, most of the time, the team members choose to tolerate that the malleable technology does not perfectly align with their desired workflow, despite the availability of other configuration options, which potentially may improve the situation:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eBenedict: \\u0026lsquo;I know that we are not doing it perfectly, right? But we are trying our best, and it works well enough for us. We have the columns we need, and we have the labels we need.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eThus, while the team members acknowledge that improvements are technically and theoretically possible, the effort required to configure and achieve a better fit between technology and practice is perceived as too burdensome, time-consuming, and beyond their role. This leads to the development of what we term an \\u003cem\\u003eassumed adequacy\\u003c/em\\u003e \\u0026ndash; an acceptance of the current configuration solutions as \\u0026lsquo;good enough\\u0026rsquo; despite the shortcomings. This knowing helps the team members tolerate the many default configuration solutions that come along with their DPMTs and only secure the minimum technological support necessary for their work.\\u003c/p\\u003e\\u003cp\\u003eHowever, by helping individuals to privately settle for imperfect tools and avoiding unproductive complaints in team discussions, assumed adequacy essentially prevents the coordination of configuration satisfaction in teams. This hinders the team from realizing the extent of shared dissatisfaction as well as the many everyday workarounds team members perform to counteract some of the default configurations. Overlooking the needs of initiating the configuration process, the existing configuration solutions are preserved in a \\u003cem\\u003epassivity\\u003c/em\\u003e, where the team is unable to make use of the malleability of the groupware nor ask for help from external resources:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eJames: \\u0026lsquo;So\\u0026hellip; There are some [DPMT] administrators (in the organization), however\\u0026hellip; I don\\u0026rsquo;t think that they will do anything unless the project teams approach them and tell them what they want. However, as a team member working on a project, we don\\u0026rsquo;t really know what exactly is possible, because we don\\u0026rsquo;t know the tools well enough.\\u0026rsquo; (interview)\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cp\\u003eWhile this passivity may not cause immediate, visible harm, it ultimately sustains the default configuration solutions provided by IT administrators and perpetuates the technological inefficiencies in the organization.\\u003c/p\\u003e\\u003cp\\u003eIn sum, this theme shows how the discrepancy between the expectation of configuring DPMTs as a quick, simple task and the reality of its demanding, complex nature fosters a knowing of assumed adequacy in individual team members. This knowing helps them accept the malleable technologies as already good enough for supporting their work, despite the bothersome default configurations, and renounce their responsibilities to improve the shared groupware. However, by preventing configuration (dis)satisfaction, this knowing creates a passivity at the team level regarding the use of malleability in groupware. Neither conducting the configurations themselves nor asking others to do it, the malleability of DPMTs essentially becomes a superficial decoration, providing symbolic flexibility to the teams\\u0026rsquo; practices.\\u003c/p\\u003e\\u003c/div\\u003e\"},{\"header\":\"6. Discussion\",\"content\":\"\\u003cp\\u003eIn this paper, we examined how team dynamics influence the coordination of malleable technology configurations. Focusing particularly on the varying perceptions of \\u0026ndash; and interactions between team members and technology, our findings demonstrate that team members develop certain knowings of current configurations \\u0026ndash; assumed symmetry, assumed intentionality, and assumed adequacy \\u0026ndash; which they consider to be shared understandings in the team. However, drawing on the notion of knowing-as-displacing (Law \\u003cspan citationid=\\\"CR42\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e), these knowings \\u0026ndash; assumptions of current configurations veil tensions between team members\\u0026rsquo; diverse access to and needs for configurations, and thereby, further coordination attempts are dissipated. Emerging from the distinctive sociomaterial interplay between malleable technologies and team organizations, these knowings create the challenges of misalignment, compromise, and passivity that, instead of ensuring team coordinated technology configurations, impede the utilization of technology malleability. An overview of the three knowings influencing the process of malleable technology configuration in teams can be found in Table\\u0026nbsp;\\u003cspan refid=\\\"Tab3\\\" class=\\\"InternalRef\\\"\\u003e3\\u003c/span\\u003e.\\u003c/p\\u003e\\u003cp\\u003e\\u003cdiv class=\\\"gridtable\\\"\\u003e\\u003ctable float=\\\"Yes\\\" id=\\\"Tab3\\\" border=\\\"1\\\"\\u003e\\u003ccaption language=\\\"En\\\"\\u003e\\u003cdiv class=\\\"CaptionNumber\\\"\\u003eTable 3\\u003c/div\\u003e\\u003cdiv class=\\\"CaptionContent\\\"\\u003e\\u003cp\\u003eThe process of technology configuration in teams\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/caption\\u003e\\u003ccolgroup cols=\\\"3\\\"\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c1\\\" colnum=\\\"1\\\"\\u003e\\u003c/div\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c2\\\" colnum=\\\"2\\\"\\u003e\\u003c/div\\u003e\\u003cdiv align=\\\"left\\\" class=\\\"colspec\\\" colname=\\\"c3\\\" colnum=\\\"3\\\"\\u003e\\u003c/div\\u003e\\u003cthead\\u003e\\u003ctr\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eAssumptions of the present configurations in teams\\u003c/p\\u003e\\u003c/th\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eThe underlying sociomaterial dynamics\\u003c/p\\u003e\\u003c/th\\u003e\\u003cth align=\\\"left\\\" colname=\\\"c3\\\"\\u003e\\u003cp\\u003eEmergent challenges to future configurations in teams\\u003c/p\\u003e\\u003c/th\\u003e\\u003c/tr\\u003e\\u003c/thead\\u003e\\u003ctbody\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eAssumed symmetry\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eMaterial: Technology behaves differently based on access levels.\\u003c/p\\u003e\\u003cp\\u003eSocial: Teams overlook how access asymmetry shapes user experience.\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c3\\\"\\u003e\\u003cp\\u003e\\u003cb\\u003eMisalignment\\u003c/b\\u003e: Members assume shared capabilities. Super users overlook limits; ordinary users disengage from suggesting changes.\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eAssumed intentionality\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eMaterial: All members share the same configuration results.\\u003c/p\\u003e\\u003cp\\u003eSocial: Uncertainty about the reasons behind existing setups.\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c3\\\"\\u003e\\u003cp\\u003e\\u003cb\\u003eCompromise\\u003c/b\\u003e: Members treat current configurations as deliberate. This reduces conflict but inhibits reflection and change.\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003ctr\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c1\\\"\\u003e\\u003cp\\u003eAssumed adequacy\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c2\\\"\\u003e\\u003cp\\u003eMaterial: Configuration is time-consuming and complex.\\u003c/p\\u003e\\u003cp\\u003eSocial: Seen as outside core job duties and not worth the effort.\\u003c/p\\u003e\\u003c/td\\u003e\\u003ctd align=\\\"left\\\" colname=\\\"c3\\\"\\u003e\\u003cp\\u003e\\u003cb\\u003ePassivity\\u003c/b\\u003e: Members accept \\u0026ldquo;good enough\\u0026rdquo; setups. The cost and ambiguity of change deter deeper engagement.\\u003c/p\\u003e\\u003c/td\\u003e\\u003c/tr\\u003e\\u003c/tbody\\u003e\\u003c/colgroup\\u003e\\u003c/table\\u003e\\u003c/div\\u003e\\u003c/p\\u003e\\u003cdiv id=\\\"Sec15\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e6.1 Theoretical contributions\\u003c/h2\\u003e\\u003cp\\u003eIn the following, we highlight three important theoretical contributions our paper makes to the CSCW research on the implications of malleable technologies.\\u003c/p\\u003e\\u003cp\\u003eFirst, we explain why and how the use of malleable technologies for teamwork does not always lead to the intended positive outcome of continuous technological support but can instead entail time-consuming challenges in ensuring team usability. Previous studies highlight the importance of configurations in obtaining the ongoing task-technology fit promised by malleable technologies (see e.g., Correa and Selbach \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Magnus Li and Nielsen \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Slagter, Biemans, and Hofte 2001; Sommerville \\u003cspan citationid=\\\"CR79\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e; Wulf, Stiemerling, and Pfeifer \\u003cspan citationid=\\\"CR88\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e). Our study goes further to illuminate the processes that precede these configuration outcomes and explain why they do not always result in success (e.g., Germonprez and Zigurs 2009; Huysman et al. \\u003cspan citationid=\\\"CR35\\\" class=\\\"CitationRef\\\"\\u003e2003\\u003c/span\\u003e; Wulf \\u003cspan citationid=\\\"CR87\\\" class=\\\"CitationRef\\\"\\u003e1999\\u003c/span\\u003e). Specifically, using the theory of situated knowledge, we show how configurations in teams require the integration of divergent, yet simultaneously valid knowledge claims that emerge from the active participation of team members in the sociomaterial interplay between malleable technologies and team organizations (Gherardi \\u003cspan citationid=\\\"CR28\\\" class=\\\"CitationRef\\\"\\u003e2001\\u003c/span\\u003e; Orlikowski \\u003cspan citationid=\\\"CR64\\\" class=\\\"CitationRef\\\"\\u003e2002\\u003c/span\\u003e). However, because such enactments of knowings are not always visible to others, constrained by their sociomaterial situatedness, recognizing this plurality of knowledge in teams becomes the first challenge for teams having to coordinate their technology configurations. By unpacking the extensive work involved in configuring malleable technologies in team settings, our study aligns with literature highlighting the new user roles and responsibilities that come with the implementation of such technologies (Correa and Selbach \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Peine, Rollwagen, and Neven 2014; Richter and Riemer \\u003cspan citationid=\\\"CR13\\\" class=\\\"CitationRef\\\"\\u003e2013\\u003c/span\\u003e; Magnus Li \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e). However, by questioning the reasonableness and feasibility of expecting teams to provide this necessary configurational work, we offer a more critical reading of this shifting user role, challenging the optimistic narrative of users as \\u0026ldquo;active co-creators of technology\\\" (Peine, Rollwagen, and Neven 2014, p.199).\\u003c/p\\u003e\\u003cp\\u003eSecond, we show that a knowledge-as-displacement (Law \\u003cspan citationid=\\\"CR42\\\" class=\\\"CitationRef\\\"\\u003e2000\\u003c/span\\u003e) characterizes team members\\u0026rsquo; assumptions of present configurations in teams, which helps explain why they may overlook the fact that configurations are left insufficiently coordinated. By highlighting the limitations of any single perspective in fully comprehending and representing the complex context of team and malleable technology use, our findings support the essential role of coordination in collaborative technology configurations, as proposed in prior studies (Domingos and Martins 1997; MacLean et al. \\u003cspan citationid=\\\"CR54\\\" class=\\\"CitationRef\\\"\\u003e1990\\u003c/span\\u003e; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). Nevertheless, we also demonstrate that such coordination is neither simple nor straightforward and may require systematic effort and external guidance, as individual knowings often appear perfectly rational within their own sociomaterial context and only reveal their incoherence when juxtaposed. This embeddedness not only conceals the need for coordination but also increases the difficulty of reconciliation. The risk of unknowingly displacing or marginalizing some members\\u0026rsquo; experiences and knowledge claims in favour of others provides a theoretical explanation for why increasing awareness of diverse team technology usage and needs can enhance the quality of technology configuration (Thomas and Bostrom \\u003cspan citationid=\\\"CR83\\\" class=\\\"CitationRef\\\"\\u003e2010\\u003c/span\\u003e). This resonates with the broader research on knowledge-intensive collaboration with an absence of hierarchy, where the perspectives of different communities of knowing cannot simply be combined (Lindberg et al. \\u003cspan citationid=\\\"CR51\\\" class=\\\"CitationRef\\\"\\u003e2024\\u003c/span\\u003e; Boland and Tenkasi \\u003cspan citationid=\\\"CR7\\\" class=\\\"CitationRef\\\"\\u003e1995\\u003c/span\\u003e). However, our study provides additional insights by showing that this can also be the case within the same community of knowing, where individuals are situated differently in the sociomaterial context. This might silently damage their ability to narrate a unified experience towards other knowledge communities and collaborate with them.\\u003c/p\\u003e\\u003cp\\u003eThird, we demonstrate that team-level dynamics create qualitatively different challenges for technology configurations than similar configurations at the individual level (e.g., Lehrig, Krancher, and Dibbern \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e, \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Mackay \\u003cspan citationid=\\\"CR53\\\" class=\\\"CitationRef\\\"\\u003e1991\\u003c/span\\u003e; Shao and Li \\u003cspan citationid=\\\"CR76\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e; Schmitz, Teng, and Webb 2016; Weinert et al. \\u003cspan citationid=\\\"CR84\\\" class=\\\"CitationRef\\\"\\u003e2020\\u003c/span\\u003e). Previous studies have demonstrated how the collaborative use of malleable technologies can introduce divergent interests, routines, and understandings, complicating the configuration process (Cabitza and Simone \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Lehrig, Krancher, and Dibbern 2015; Mousavidin and Silva \\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; Pipek and Kahler \\u003cspan citationid=\\\"CR65\\\" class=\\\"CitationRef\\\"\\u003e2006\\u003c/span\\u003e). Such potential goal asymmetry in social collaboration is especially an eminent problem for technology configurations at the organizational or group level (J\\u0026oslash;rgen P. Bansler \\u003cspan citationid=\\\"CR4\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Cresswell et al. \\u003cspan citationid=\\\"CR18\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e; M.C. Moon, Hills, and Demiris 2018; Ellingsen, Hertzum, and Melby \\u003cspan citationid=\\\"CR9\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e), leading to Mousavidin and Silva (\\u003cspan citationid=\\\"CR14\\\" class=\\\"CitationRef\\\"\\u003e2017\\u003c/span\\u003e) proposing high technology malleability as a critical resource for enhancing task-technology fit in organizations. This aligns with recent developments in malleable technology design that aim to increase the built-in malleability to accommodate potentially incompatible needs (Correa and Selbach \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Magnus Li \\u003cspan citationid=\\\"CR49\\\" class=\\\"CitationRef\\\"\\u003e2021\\u003c/span\\u003e; Magnus Li and Nielsen \\u003cspan citationid=\\\"CR45\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e; Magnus Li \\u003cspan citationid=\\\"CR48\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e). However, zooming in on technology configurations as team processes, our study identifies a different barrier to collaborative configuration: overcoming the information asymmetry amplified by the situatedness and displacement of knowing enabled by malleable technologies. Our findings indicate that team members, at least in our study, do not necessarily lack the willingness to accommodate one another. Rather, they can lack the awareness of the limitations of their own knowledge and the perspectives of others, which impedes the effective utilization of technology malleability. This insight is especially relevant to the literature, as it underscores the need to expand the current focus on developing more comprehensive technology malleability with an equal focus on facilitating meta-awareness on team technology use, through, e.g., the incorporation of coordination mechanisms (Schmidt and Simonee 1996; Grinter \\u003cspan citationid=\\\"CR31\\\" class=\\\"CitationRef\\\"\\u003e1996\\u003c/span\\u003e; Cabitza and Simone 2012). Such a reconceptualization of technology malleability that shows consideration for the limitations of situated cognitions can be the key to improving the general usability of malleable groupware.\\u003c/p\\u003e\\u003c/div\\u003e\\u003cdiv id=\\\"Sec16\\\" class=\\\"Section2\\\"\\u003e\\u003ch2\\u003e6.2 Practical implications\\u003c/h2\\u003e\\u003cp\\u003eOur study provides several practical implications relevant for both the users and the developers of malleable technologies.\\u003c/p\\u003e\\u003cp\\u003eFor organizations implementing malleable technologies to support collaborative work, our study indicates that the continuous task-technology fit promised by technology malleability is a price that needs to be redeemed through difficult and time-consuming teamwork. Because configurations at the team level not only need to overcome the challenges and barriers already known from individual configurations (see e.g., Mackay \\u003cspan citationid=\\\"CR53\\\" class=\\\"CitationRef\\\"\\u003e1991\\u003c/span\\u003e) but also require addressing the information and goal asymmetry amplified by the situatedness and displacement of knowing enabled by malleable technologies. Thus, it is necessary for practitioners to first consider whether the work of configuring malleable technology is worth the benefit these tools provide, and secondly, dedicate time and resources to utilizing technology malleability in teams. For organizations, this may involve recognizing configurational work as a part of employee responsibility and providing mandatory team training on technology configuration that moves beyond simple instruction on system functionalities.\\u003c/p\\u003e\\u003cp\\u003eMoreover, our study highlights the limitations of single perspectives (e.g., super user) in recognizing the needs and solutions of new configurations in teams, hence the importance of team coordinated technology configurations. However, managers and team leaders should not assume that such initiatives will naturally occur bottom-up and converge toward optimal outcomes simply by giving teams the autonomy to do so (e.g., Lehrig, Krancher, and Dibbern 2015; Leonardi \\u003cspan citationid=\\\"CR46\\\" class=\\\"CitationRef\\\"\\u003e2011\\u003c/span\\u003e). By identifying the three knowledge assumptions, we show that team members may overestimate shared understanding of technological use, misinterpret uncoordinated outcomes as intentional, or prematurely accept suboptimal configurations as sufficient. Thus, fostering digital leadership (M\\u0026uuml;ller et al. \\u003cspan citationid=\\\"CR62\\\" class=\\\"CitationRef\\\"\\u003e2024\\u003c/span\\u003e; Cortellazzo, Bruni, and Zampieri \\u003cspan citationid=\\\"CR17\\\" class=\\\"CitationRef\\\"\\u003e2019\\u003c/span\\u003e) and digital culture (Grover, Tseng, and Pu \\u003cspan citationid=\\\"CR32\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e; Jensen et al. \\u003cspan citationid=\\\"CR36\\\" class=\\\"CitationRef\\\"\\u003e2023\\u003c/span\\u003e) becomes even more relevant with the implementation of malleable technologies, where organizations should ensure that teams create ongoing opportunities for reflection and knowledge exchange regarding the shared malleable groupware to surface potential private misunderstandings and misalignments across team members.\\u003c/p\\u003e\\u003cp\\u003eFor the system designers and software developers of malleable technologies for collaborative work, our study calls attention to the limitations of assuming users can easily utilize technology malleability to create a better task-technology fit simply by having the technological capability to do so. While current design paradigms often emphasize user empowerment and co-creation, our study shows that configuration work in teams is complex, time-consuming, and socially demanding \\u0026ndash; a messy and difficult task nobody really wants or has time to do. Thus, it is necessary to complement the efforts to increase technological malleability with new solutions to promote meta-awareness of technology use, which can help bridge the information asymmetries inherent in collective work and reduce the difficulty of team coordinated technology configuration.\\u003c/p\\u003e\\u003c/div\\u003e\"},{\"header\":\"7. Limitations and future research\",\"content\":\"\\u003cp\\u003eOur study has several limitations that also present opportunities for future research.\\u003c/p\\u003e\\u003cp\\u003eFirst, the context of our research provides potential boundary conditions of the generalisability of our study\\u0026rsquo;s findings and contributions. By focusing on self-managing IT teams characterized by low hierarchy, high team autonomy, and high technological proficiency, our study may have underplayed the potential impact of leadership, IT governance, and technological skills in shaping the configuration process in team settings. Future studies could focus on teams with clearer hierarchical structures and varying technological proficiency to understand how these factors influence the team members\\u0026rsquo; perception of malleable technology use, and the emergence of team coordinated technology configurations.\\u003c/p\\u003e\\u003cp\\u003eSecond, beyond DPMTs, there are other forms of malleable technologies essential for teamwork. These malleable technologies, such as enterprise communication platforms (e.g., Slack) or enterprise resource planning systems (e.g., SAP), can be used for different purposes than DPMTs in cooperative work and may offer other forms of technology malleability. These can create a dissimilar sociomaterial context for technology configurations, which may give rise to other forms of knowings in teams. While we do not expect such differences to change the fundamental challenges related to team coordinated technology configurations identified in our study, these differences may give rise to other forms of bottom-up interactions influencing the configuration process of shared technologies. This could be investigated by future studies.\\u003c/p\\u003e\\u003cp\\u003eThird, while our focus on naturally emergent, unsuccessful cases provides valuable insights into the potential pitfalls of configurations as team practices, we cannot claim that the three identified assumptions are the only barriers to configuring malleable technologies in team settings. Likewise, we cannot assert that overcoming these assumptions is sufficient to ensure improved utilization of technology malleability. Given the complexity of configuring malleable technologies in teams, we suggest that future research adopt action research methods to outline the process of team coordinated technology configurations and identify relevant triggers, resources, and barriers. Such research would undoubtedly bring great value to both theories and practices.\\u003c/p\\u003e\\u003cp\\u003eFour, by focusing on the knowledge and cognition of individual team members, our study did not account for other contextual factors that may shape team configuration practices. Factors such as silence and voice in teams (Van Dyne, Ang, and Botero 2003) or organizational digital culture (Grover, Tseng, and Pu \\u003cspan citationid=\\\"CR32\\\" class=\\\"CitationRef\\\"\\u003e2022\\u003c/span\\u003e) may contribute to the emergence of the assumptions identified in our study. These potential influences warrant further exploration.\\u003c/p\\u003e\\u003cp\\u003eFive, we observed varied emotional responses among team members regarding the (non-)configurations of their malleable groupware \\u0026ndash; some experienced greater challenges than others. These individual differences were not explained in our study. Future research could investigate how team members emotionally respond to insufficiently coordinated configurations and how these responses affect their personal well-being. Such work may provide new insights into the literature on technostress \\u0026ndash; stress experienced by users of information and communication technologies (Ragu-Nathan et al. \\u003cspan citationid=\\\"CR70\\\" class=\\\"CitationRef\\\"\\u003e2008\\u003c/span\\u003e).\\u003c/p\\u003e\"},{\"header\":\"Declarations\",\"content\":\"\\u003ch2\\u003eDeclaration of Interest statement:\\u0026nbsp;\\u003c/h2\\u003e\\n\\u003cp\\u003eNone\\u003c/p\\u003e\\n\\u003ch2\\u003eClinical trial number\\u003c/h2\\u003e\\n\\u003cp\\u003enot applicable\\u003c/p\\u003e\\n\\u003ch2\\u003eFunding statement:\\u003c/h2\\u003e\\n\\u003cp\\u003eThe authors received no specific funding for this article.\\u003c/p\\u003e\\n\\u003ch2\\u003eAuthor Contribution\\u003c/h2\\u003e\\n\\u003cp\\u003eR.F.Z: Conceptualization, Methodology, Formal Analysis, Investigation, Writing - Original Draft, Writing - Review \\u0026amp; Editing, Project administration.C.J.: Methodology, Formal Analysis, Supervision, Writing - Review \\u0026amp; Editing.J.A.: Formal Analysis, Supervision, Writing - Review \\u0026amp; Editing\\u003c/p\\u003e\\n\\u003ch2\\u003eAcknowledgement\\u003c/h2\\u003e\\n\\u003cp\\u003eWe are grateful to Jacob Klitm\\u0026oslash;ller and the participants of the workshop \\u0026ldquo;Practice Theory and the Digital\\u0026rdquo; at Lancaster University for their valuable comments on an earlier draft of our paper. We also extend our sincere gratitude to the managers and employees of the field organization for their support and participation in this study.\\u003c/p\\u003e\"},{\"header\":\"References\",\"content\":\"\\u003col\\u003e\\n\\u003cli\\u003eArya, S., and M. S. Kulkarni. 2024. \\u0026quot;A Comprehensive Study of Agile Project Management Tools.\\u0026quot; 2024 4th International Conference on Innovative Practices in Technology and Management (ICIPTM), Noida, India.\\u003c/li\\u003e\\n\\u003cli\\u003eBailey, Diane E., Paul M. Leonardi, and Jan Chong. 2010. \\u0026quot;Minding the gaps: Understanding technology interdependence and coordination in knowledge work.\\u0026quot; \\u003cem\\u003eOrganization Science\\u003c/em\\u003e 21 (3): 713-730. https://doi.org/10.1287/orsc.1090.0473.\\u003c/li\\u003e\\n\\u003cli\\u003eBansler, J. P., and Erling Havn. 2006. \\u0026quot;Sensemaking in Technology-Use Mediation: Adapting Groupware Technology in Organizations.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 15 (1): 55-91. https://doi.org/10.1007/s10606-005-9012-x. https://doi.org/10.1007/s10606-005-9012-x.\\u003c/li\\u003e\\n\\u003cli\\u003eBansler, J\\u0026oslash;rgen P. 2021. \\u0026quot;Challenges in user-driven optimization of EHR: A case study of a large Epic implementation in Denmark.\\u0026quot; \\u003cem\\u003eInternational Journal of Medical Informatics\\u003c/em\\u003e 148: 104394. https://doi.org/https://doi.org/10.1016/j.ijmedinf.2021.104394. https://www.sciencedirect.com/science/article/pii/S1386505621000204.\\u003c/li\\u003e\\n\\u003cli\\u003eBarley, William C., Jeffrey W. Treem, and Timothy Kuhn. 2017. \\u0026quot;Valuing Multiple Trajectories of Knowledge: A Critical Review and Agenda for Knowledge Management Research.\\u0026quot; \\u003cem\\u003eAcademy of Management Annals\\u003c/em\\u003e 12 (1): 278-317. https://doi.org/10.5465/annals.2016.0041. https://doi.org/10.5465/annals.2016.0041.\\u003c/li\\u003e\\n\\u003cli\\u003eBlomberg, Jeanette, and Helena Karasti. 2013. \\u0026quot;Reflections on 25 Years of Ethnography in CSCW.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 22 (4): 373-423. https://doi.org/10.1007/s10606-012-9183-1. https://doi.org/10.1007/s10606-012-9183-1.\\u003c/li\\u003e\\n\\u003cli\\u003eBoland, Richard J., and Ramkrishnan V. Tenkasi. 1995. \\u0026quot;Perspective Making and Perspective Taking in Communities of Knowing.\\u0026quot; \\u003cem\\u003eOrganization Science\\u003c/em\\u003e 6 (4): 350-372. https://doi.org/10.1287/orsc.6.4.350. https://doi.org/10.1287/orsc.6.4.350.\\u003c/li\\u003e\\n\\u003cli\\u003eBraun, Virginia, and Victoria Clarke. 2006. \\u0026quot;Using thematic analysis in psychology.\\u0026quot; \\u003cem\\u003eQualitative Research in Psychology\\u003c/em\\u003e 3 (2): 77-101. https://doi.org/10.1191/1478088706qp063oa. https://www.tandfonline.com/doi/abs/10.1191/1478088706qp063oa.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2022. \\u003cem\\u003eThematic analysis : a practical guide\\u003c/em\\u003e. London: SAGE Publications Ltd.\\u003c/li\\u003e\\n\\u003cli\\u003eBruni, Attila, Silvia Gherardi, and Laura Lucia Parolin. 2007. \\u0026quot;Knowing in a System of Fragmented Knowledge.\\u0026quot; \\u003cem\\u003eMind, Culture, and Activity\\u003c/em\\u003e 14 (1-2): 83-102. https://doi.org/10.1080/10749030701307754. https://doi.org/10.1080/10749030701307754.\\u003c/li\\u003e\\n\\u003cli\\u003eButurugă, Oana Cristina, Vasile Mirel Gogoi, and Ioana Alexandra Prodan. 2016. \\u0026quot;Agile Project Management Tools.\\u0026quot; \\u003cem\\u003eEconomy informatics\\u003c/em\\u003e 16 (1): 19-26.\\u003c/li\\u003e\\n\\u003cli\\u003eCabitza, Federico, and Carla Simone. 2012. \\u0026quot;Affording Mechanisms: An Integrated View of Coordination and Knowledge Management.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 21 (2): 227-260. https://doi.org/10.1007/s10606-011-9153-z. https://doi.org/10.1007/s10606-011-9153-z.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2013. \\u0026quot;Computational Coordination Mechanisms: A tale of a struggle for flexibility.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 22 (4): 475-529. https://doi.org/10.1007/s10606-013-9187-5. https://doi.org/10.1007/s10606-013-9187-5.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2017. \\u0026quot;Malleability in the Hands of End-Users.\\u0026quot; In \\u003cem\\u003eNew Perspectives in End-User Development\\u003c/em\\u003e, edited by Fabio Patern\\u0026ograve; and Volker Wulf, 137-163. Cham: Springer International Publishing.\\u003c/li\\u003e\\n\\u003cli\\u003eCarter, N., D. Bryant-Lukosius, A. DiCenso, J. Blythe, and A. J. Neville. 2014. \\u0026quot;The use of triangulation in qualitative research.\\u0026quot; \\u003cem\\u003eOncol Nurs Forum\\u003c/em\\u003e 41 (5): 545-7. https://doi.org/10.1188/14.Onf.545-547.\\u003c/li\\u003e\\n\\u003cli\\u003eCorrea, Claiton Marques , and Silveira. Milene Selbach. 2021. \\u0026quot;End-User Highlighted: featuring tailorable systems development.\\u0026quot; Proceedings of the XX Brazilian Symposium on Human Factors in Computing Systems, Virtual Event, Brazil. https://doi.org/10.1145/3472301.3484332.\\u003c/li\\u003e\\n\\u003cli\\u003eCortellazzo, Laura, Elena Bruni, and Rita Zampieri. 2019. \\u0026quot;The Role of Leadership in a Digitalized World: A Review.\\u0026quot; \\u003cem\\u003eFrontiers in Psychology\\u003c/em\\u003e Volume 10 - 2019. https://doi.org/10.3389/fpsyg.2019.01938. https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2019.01938.\\u003c/li\\u003e\\n\\u003cli\\u003eCresswell, Kathrin M., Lisa Lee, Hajar Mozaffar, Robin Williams, Aziz Sheikh, and Nihr ePrescribing Programme Team on behalf of the. 2017. \\u0026quot;Sustained User Engagement in Health Information Technology: The Long Road from Implementation to System Optimization of Computerized Physician Order Entry and Clinical Decision Support Systems for Prescribing in Hospitals in England.\\u0026quot; \\u003cem\\u003eHealth Services Research\\u003c/em\\u003e 52 (5): 1928-1957. https://doi.org/https://doi.org/10.1111/1475-6773.12581. https://doi.org/10.1111/1475-6773.12581.\\u003c/li\\u003e\\n\\u003cli\\u003eDomingos, Henrique Jo\\u0026atilde;o L., and Jos\\u0026eacute; A. Legatheaux Martins. 1997. \\u0026quot;Coordination and Tailorability Issues in the design of a Generic Large Scale Groupware Platform.\\u0026quot; ACM - GROUP\\u0026rsquo;97, Phoenix, Arizona \\u003c/li\\u003e\\n\\u003cli\\u003eDreyfus, Hubert L. , and Stuart E. Dreyfus. 1986. \\u003cem\\u003eMind over machine : the power of human intuition and expertise in the era of the computer\\u003c/em\\u003e. New York: Free Press.\\u003c/li\\u003e\\n\\u003cli\\u003eEdmondson, Amy C., Michael A. Roberto, and Michael D. Watkins. 2003. \\u0026quot;A dynamic model of top management team effectiveness: managing unstructured task streams.\\u0026quot; \\u003cem\\u003eThe Leadership Quarterly\\u003c/em\\u003e 14 (3): 297-325. https://doi.org/https://doi.org/10.1016/S1048-9843(03)00021-3. https://www.sciencedirect.com/science/article/pii/S1048984303000213.\\u003c/li\\u003e\\n\\u003cli\\u003eEllingsen, Gunnar, Morten Hertzum, and Line Melby. 2022. \\u0026quot;The Tension between National and Local Concerns in Preparing for Large-Scale Generic Systems in Healthcare.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 31 (3): 411-441. https://doi.org/10.1007/s10606-022-09424-9. https://doi.org/10.1007/s10606-022-09424-9.\\u003c/li\\u003e\\n\\u003cli\\u003eFaraj, Samer, and Yan Xiao. 2006. \\u0026quot;Coordination in Fast-Response Organizations.\\u0026quot; \\u003cem\\u003eManagement Science\\u003c/em\\u003e 52 (8): 1155-1169. http://www.jstor.org/stable/20110591.\\u003c/li\\u003e\\n\\u003cli\\u003eFleck, James. 1993. \\u0026quot;Configurations: Crystallizing contingency.\\u0026quot; \\u003cem\\u003eInternational Journal of Human Factors in Manufacturing\\u003c/em\\u003e 3 (1): 15-36. https://doi.org/https://doi.org/10.1002/hfm.4530030104. https://doi.org/10.1002/hfm.4530030104.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 1994. \\u0026quot;Learning by trying: the implementation of configurational technology.\\u0026quot; \\u003cem\\u003eResearch Policy\\u003c/em\\u003e 23 (6): 637-652. https://doi.org/https://doi.org/10.1016/0048-7333(94)90014-0. https://www.sciencedirect.com/science/article/pii/0048733394900140.\\u003c/li\\u003e\\n\\u003cli\\u003eFlick, Uwe. 2018. \\u003cem\\u003eDesigning qualitative research\\u003c/em\\u003e. Second edition. ed.\\u003cem\\u003eThe SAGE qualitative research kit.\\u003c/em\\u003e Los Angeles: Sage.\\u003c/li\\u003e\\n\\u003cli\\u003eGermonprez, Matt, and Ilze Zigurs. 2009. \\u0026quot;Task, technology, and tailoring in communicative action: An in-depth analysis of group communication.\\u0026quot; \\u003cem\\u003eInformation and Organization\\u003c/em\\u003e 19 (1): 22-46. https://doi.org/https://doi.org/10.1016/j.infoandorg.2008.03.002. https://www.sciencedirect.com/science/article/pii/S1471772708000134.\\u003c/li\\u003e\\n\\u003cli\\u003eGherardi, Silvia. 2001. \\u0026quot;From Organizational Learning to Practice-Based Knowing.\\u0026quot; \\u003cem\\u003eHuman Relations\\u003c/em\\u003e 54 (1): 131-139. https://doi.org/10.1177/0018726701541016. https://journals.sagepub.com/doi/abs/10.1177/0018726701541016.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2008. \\u0026quot;Situated Knowledge and Situated Action: What do Practice-Based Studies Promise?\\u0026quot; In \\u003cem\\u003eThe SAGE Handbook of New Approaches in Management and Organization\\u003c/em\\u003e, edited by Daved; Barry and Hans Hansen.\\u003c/li\\u003e\\n\\u003cli\\u003eGriffith, Terri L., John E. Sawyer, and M. Scott Poole. 2019. \\u0026quot;Systems savvy: Practical intelligence for transformation of sociotechnical systems.\\u0026quot; \\u003cem\\u003eGroup Decision and Negotiation\\u003c/em\\u003e 28 (3): 475-499. https://doi.org/10.1007/s10726-019-09619-4.\\u003c/li\\u003e\\n\\u003cli\\u003eGrinter, Rebecca E. 1996. \\u0026quot;Supporting articulation work using software configuration management systems.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 5 (4): 447-465. https://doi.org/10.1007/BF00136714. https://doi.org/10.1007/BF00136714.\\u003c/li\\u003e\\n\\u003cli\\u003eGrover, Varun, Shih-Lun Tseng, and Wenxi Pu. 2022. \\u0026quot;A theoretical perspective on organizational culture and digitalization.\\u0026quot; \\u003cem\\u003eInformation \\u0026amp; Management\\u003c/em\\u003e 59 (4): 103639. https://doi.org/https://doi.org/10.1016/j.im.2022.103639. https://www.sciencedirect.com/science/article/pii/S0378720622000519.\\u003c/li\\u003e\\n\\u003cli\\u003eHaraway, Donna. 1988. \\u0026quot;Situated Knowledges: The Science Question in Feminism and the Privilege of Partial Perspective.\\u0026quot; \\u003cem\\u003eFeminist Studies\\u003c/em\\u003e 14 (3): 575-599. https://doi.org/10.2307/3178066. http://www.jstor.org.ez.statsbiblioteket.dk/stable/3178066.\\u003c/li\\u003e\\n\\u003cli\\u003eHunger, Axel, and Angela Hirlehei. 2013. \\u0026quot;Supporting Globally Distributed Work - Cultural Adaptivity Meets Groupware Tailorability.\\u0026quot; Cross-Cultural Design. Cultural Differences in Everyday Life, Berlin, Heidelberg.\\u003c/li\\u003e\\n\\u003cli\\u003eHuysman, Marleen, Charles Steinfield, Chyng-Yang Jang, Kenneth David, Mirjam Huis in \\u0026apos;t Veld, Jan Poot, and Ingrid Mulder. 2003. \\u0026quot;Virtual Teams and the Appropriation of Communication Technology: Exploring the Concept of Media Stickiness.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 12 (4): 411-436. https://doi.org/10.1023/A:1026145017609. https://doi.org/10.1023/A:1026145017609.\\u003c/li\\u003e\\n\\u003cli\\u003eJensen, Rikke Amalie Agergaard; , Charlotte; Jonasson, Martin; Gartmeier, and Jaana Parviainen. 2023. \\u0026quot;Learning from errors in digital patient communication: professionals\\u0026rsquo; enactment of negative knowledge and digital ignorance in the workplace.\\u0026quot; \\u003cem\\u003eJournal of Workplace Learning\\u003c/em\\u003e 35 (5): 432\\u0026ndash;449. https://doi.org/https://doi.org/10.1108/JWL-12-2022-0177.\\u003c/li\\u003e\\n\\u003cli\\u003eJira, Atlassian. 2024. \\u0026quot;Great outcomes start with Jira.\\u0026quot; Accessed August 12. https://www.atlassian.com/software/jira.\\u003c/li\\u003e\\n\\u003cli\\u003eKempton, Alexander Moltubakk. 2022. \\u0026quot;The digital is different: Emergence and relationality in critical realist research.\\u0026quot; \\u003cem\\u003eInformation and Organization\\u003c/em\\u003e 32 (2): 100408. https://doi.org/https://doi.org/10.1016/j.infoandorg.2022.100408. https://www.sciencedirect.com/science/article/pii/S1471772722000215.\\u003c/li\\u003e\\n\\u003cli\\u003eLarsen-Ledet, Ida, and Marcel Borowski. 2021. \\u0026quot;\\u0026ldquo;It Looks Like You Don\\u0026rsquo;t Agree\\u0026rdquo;: Idiosyncratic Practices and Preferences in Collaborative Writing.\\u0026quot; Proceedings of the 32nd Australian Conference on Human-Computer Interaction, Sydney, NSW, Australia. https://doi.org/10.1145/3441000.3441032.\\u003c/li\\u003e\\n\\u003cli\\u003eLarson, Lindsay, and Leslie A. DeChurch. 2020. \\u0026quot;Leading teams in the digital age: Four perspectives on technology and what they mean for leading teams.\\u0026quot; \\u003cem\\u003eThe Leadership Quarterly\\u003c/em\\u003e 31 (1): 101377. https://doi.org/https://doi.org/10.1016/j.leaqua.2019.101377. https://www.sciencedirect.com/science/article/pii/S104898431830835X.\\u003c/li\\u003e\\n\\u003cli\\u003eLave, J., and E. Wenger. 1991. \\u003cem\\u003eSituated Learning: Legitimate Peripheral Participation.\\u003c/em\\u003e: Cambridge University Press.\\u003c/li\\u003e\\n\\u003cli\\u003eLaw, John. 2000. \\u0026quot;Comment on Suchman, and Gherardi and Nicolini: Knowing as Displacing.\\u0026quot; \\u003cem\\u003eOrganization\\u003c/em\\u003e 7 (2): 349-354. https://doi.org/10.1177/135050840072009. https://journals.sagepub.com/doi/abs/10.1177/135050840072009.\\u003c/li\\u003e\\n\\u003cli\\u003eLehrig, Tim, Oliver Krancher, and Jens Dibbern. 2015. \\u0026quot;The Evolution of Routines under Flexible Information Technology.\\u0026quot; ECIS 2015 Research-in-Progress Papers.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2017. \\u0026quot;How Users Perceive and Actualize Affordances: An Exploratory Case Study of Collaboration Platforms.\\u0026quot; Thirty Eighth International Conference on Information Systems, Korea.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2019. \\u0026quot;Affordance Perceptions under Malleable Information Technology: A Social Cognitive Theory Perspective.\\u0026quot; Fortieth International Conference on Information Systems, Munich.\\u003c/li\\u003e\\n\\u003cli\\u003eLeonardi, Paul M. 2011. \\u0026quot;When Flexible Routines Meet Flexible Technologies: Affordance, Constraint, and the Imbrication of Human and Material Agencies.\\u0026quot; \\u003cem\\u003eMIS Quarterly\\u003c/em\\u003e 35 (1): 147-167. https://doi.org/10.2307/23043493. http://www.jstor.org/stable/23043493.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2013. \\u0026quot;Theoretical foundations for the study of sociomateriality.\\u0026quot; \\u003cem\\u003eInformation and Organization\\u003c/em\\u003e 23 (2): 59-76. https://doi.org/https://doi.org/10.1016/j.infoandorg.2013.02.002. https://www.sciencedirect.com/science/article/pii/S1471772713000067.\\u003c/li\\u003e\\n\\u003cli\\u003eLi, Magnus. 2019. \\u0026quot;An Approach to Addressing the Usability and Local Relevance of Generic Enterprise Software.\\u0026quot; Selected Papers of the IRIS.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2021. \\u0026quot;Generic Enterprise Software Implementation as Context for User-Oriented Design: Three Conditions and their Implications for Vendors.\\u0026quot; 12th Scandinavian Conference on Information Systems.\\u003c/li\\u003e\\n\\u003cli\\u003eLi, Magnus , and Petter Nielsen. 2019. \\u0026quot;Making Usable Generic Software. A Matter of Global or Local Design?\\u0026quot; 10th Scandinavian Conference on Information Systems, Nokia, Finland.\\u003c/li\\u003e\\n\\u003cli\\u003eLindberg, Aron, Nicholas Berente, James Howison, and Kalle Lyytinen. 2024. \\u0026quot;Discursive Modulation in Open Source Software: How Online Communities Shape Novelty and Complexity1.\\u0026quot; \\u003cem\\u003eManagement Information Systems Quarterly\\u003c/em\\u003e 48 (4): 1395-1422. https://doi.org/10.25300/MISQ/2023/16872. https://doi.org/10.25300/MISQ/2023/16872.\\u003c/li\\u003e\\n\\u003cli\\u003eLyytinen, Kalle, Petri Maaranen, and Juha Knuuttila. 1993. \\u0026quot;Groups are not always the same.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 2 (4): 261-284. https://doi.org/10.1007/BF00805694. https://doi.org/10.1007/BF00805694.\\u003c/li\\u003e\\n\\u003cli\\u003eMackay, Wendy E. 1991. \\u0026quot;Triggers and barriers to customizing software.\\u0026quot; Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, New Orleans, Louisiana, USA. https://doi.org/10.1145/108844.108867.\\u003c/li\\u003e\\n\\u003cli\\u003eMacLean, Allan, Kathleen Carter, Lennart L\\u0026ouml;vstrand, and Thomas Moran. 1990. \\u0026quot;User-tailorable systems: pressing the issues with buttons.\\u0026quot; Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Seattle, Washington, USA. https://doi.org/10.1145/97243.97271.\\u003c/li\\u003e\\n\\u003cli\\u003eMajchrzak, Ann, Ronald E. Rice, Arvind Malhotra, Nelson King, and Sulin Ba. 2000. \\u0026quot;Technology Adaptation: The Case of a Computer-Supported Inter-Organizational Virtual Team.\\u0026quot; \\u003cem\\u003eMIS Quarterly\\u003c/em\\u003e 24 (4): 569-600. https://doi.org/10.2307/3250948. http://www.jstor.org/stable/3250948.\\u003c/li\\u003e\\n\\u003cli\\u003eMalone, Thomas W., and Kevin Crowston. 1994. \\u0026quot;The interdisciplinary study of coordination.\\u0026quot; \\u003cem\\u003eACM Comput. Surv.\\u003c/em\\u003e 26 (1): 87\\u0026ndash;119. https://doi.org/10.1145/174666.174668. https://doi.org/10.1145/174666.174668.\\u003c/li\\u003e\\n\\u003cli\\u003eMandviwalla, Munir, and Lorne Olfman. 1994. \\u0026quot;What do groups need? A proposed set of generic groupware requirements.\\u0026quot; \\u003cem\\u003eACM Trans. Comput.-Hum. Interact.\\u003c/em\\u003e 1 (3): 245\\u0026ndash;268. https://doi.org/10.1145/196699.196715. https://doi.org/10.1145/196699.196715.\\u003c/li\\u003e\\n\\u003cli\\u003eMathieu, John E, Peter T Gallagher, Monique A Domingo, and Elizabeth A Klock. 2019. \\u0026quot;Embracing complexity: Reviewing the past decade of team effectiveness research.\\u0026quot; \\u003cem\\u003eAnnual Review of Organizational Psychology and Organizational Behavior\\u003c/em\\u003e 6 (1): 17-46.\\u003c/li\\u003e\\n\\u003cli\\u003eMoon, Eunyoung, and James Howison. 2024. \\u0026quot;A dynamic perspective on software modularity in open source software (OSS) development: A configurational approach.\\u0026quot; \\u003cem\\u003eInformation and Organization\\u003c/em\\u003e 34 (1): 100499. https://doi.org/https://doi.org/10.1016/j.infoandorg.2023.100499. https://www.sciencedirect.com/science/article/pii/S1471772723000532.\\u003c/li\\u003e\\n\\u003cli\\u003eMoon, Mark Chun, Rebecca Hills, and George Demiris. 2018. \\u0026quot;Understanding optimisation processes of electronic health records (EHRs) in select leading hospitals: a qualitative study.\\u0026quot; \\u003cem\\u003eBMJ Health \\u0026amp;amp;amp; Care Informatics\\u003c/em\\u003e 25 (2): 109. https://doi.org/10.14236/jhi.v25i2.1011. http://informatics.bmj.com/content/25/2/109.abstract.\\u003c/li\\u003e\\n\\u003cli\\u003eMousavidin, Elham, and Leiser Silva. 2017. \\u0026quot;Theorizing the configuration of modifiable off-the-shelf software.\\u0026quot; \\u003cem\\u003eInformation Technology \\u0026amp; People\\u003c/em\\u003e 30 (4): 887-909. https://doi.org/10.1108/ITP-07-2014-0140. https://doi.org/10.1108/ITP-07-2014-0140.\\u003c/li\\u003e\\n\\u003cli\\u003eM\\u0026uuml;ller, Sune Dueholm, Henrike Konzag, Jeppe Agger Nielsen, and Hafd\\u0026iacute;s Bergsd\\u0026oacute;ttir Sandholt. 2024. \\u0026quot;Digital transformation leadership competencies: A contingency approach.\\u0026quot; \\u003cem\\u003eInternational Journal of Information Management\\u003c/em\\u003e 75: 102734. https://doi.org/https://doi.org/10.1016/j.ijinfomgt.2023.102734. https://www.sciencedirect.com/science/article/pii/S0268401223001159.\\u003c/li\\u003e\\n\\u003cli\\u003eOkhuysen, Gerardo A., and Beth A. Bechky. 2009. \\u0026quot;Coordination in organizations: An integrative perspective.\\u0026quot; \\u003cem\\u003eThe Academy of Management Annals\\u003c/em\\u003e 3 (1): 463-502. https://doi.org/10.1080/19416520903047533.\\u003c/li\\u003e\\n\\u003cli\\u003eOrlikowski, Wanda J. 2002. \\u0026quot;Knowing in Practice: Enacting a Collective Capability in Distributed Organizing.\\u0026quot; \\u003cem\\u003eOrganization science (Providence, R.I.)\\u003c/em\\u003e 13 (3): 249-273. https://doi.org/10.1287/orsc.13.3.249.2776.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2006. \\u0026quot;Material knowing: the scaffolding of human knowledgeability.\\u0026quot; \\u003cem\\u003eEuropean Journal of Information Systems\\u003c/em\\u003e 15 (5): 460-466. https://doi.org/10.1057/palgrave.ejis.3000639. https://doi.org/10.1057/palgrave.ejis.3000639.\\u003c/li\\u003e\\n\\u003cli\\u003eOrlikowski, Wanda J., and Susan V. Scott. 2008. \\u0026quot;Sociomateriality: Challenging the Separation of Technology, Work and Organization.\\u0026quot; \\u003cem\\u003eAcademy of Management Annals\\u003c/em\\u003e 2 (1): 433-474. https://doi.org/10.5465/19416520802211644. https://doi.org/10.5465/19416520802211644.\\u003c/li\\u003e\\n\\u003cli\\u003ePearsall, Matthew J., and Vijaya Venkataramani. 2015. \\u0026quot;Overcoming asymmetric goals in teams: The interactive roles of team learning orientation and team identification.\\u0026quot; \\u003cem\\u003eJournal of Applied Psychology\\u003c/em\\u003e 100 (3): 735-748. https://doi.org/10.1037/a0038315.\\u003c/li\\u003e\\n\\u003cli\\u003ePeine, Alexander, Ingo Rollwagen, and Louis Neven. 2014. \\u0026quot;The rise of the \\u0026ldquo;innosumer\\u0026rdquo;\\u0026mdash;Rethinking older technology users.\\u0026quot; \\u003cem\\u003eTechnological Forecasting and Social Change\\u003c/em\\u003e 82: 199-214. https://doi.org/https://doi.org/10.1016/j.techfore.2013.06.013. https://www.sciencedirect.com/science/article/pii/S004016251300139X.\\u003c/li\\u003e\\n\\u003cli\\u003ePipek, Volkmar, and Helge Kahler. 2006. \\u0026quot;Supporting Collaborative Tailoring.\\u0026quot; In \\u003cem\\u003eEnd User Development\\u003c/em\\u003e, edited by Henry Lieberman, Fabio Patern\\u0026ograve; and Volker Wulf, 315-345. Dordrecht: Springer Netherlands.\\u003c/li\\u003e\\n\\u003cli\\u003eRagu-Nathan, T. S., Monideepa Tarafdar, Bhanu S. Ragu-Nathan, and Qiang Tu. 2008. \\u0026quot;The Consequences of Technostress for End Users in Organizations: Conceptual Development and Empirical Validation.\\u0026quot; \\u003cem\\u003eInformation Systems Research\\u003c/em\\u003e 19 (4): 417-433. https://doi.org/10.1287/isre.1070.0165. https://doi.org/10.1287/isre.1070.0165.\\u003c/li\\u003e\\n\\u003cli\\u003eRaith, Florian, Ingo Richter, and Robert Lindermeier. 2017. \\u0026quot;How Project-management-tools are used in Agile Practice.\\u0026quot; the 21st International Database Engineering \\u0026amp; Applications Symposium, Bristol, United Kingdom.\\u003c/li\\u003e\\n\\u003cli\\u003eRichter, Alexander, and Kai Riemer. 2013. \\u0026quot;Malleable end-user software.\\u0026quot; \\u003cem\\u003eBusiness \\u0026amp; Information Systems Engineering\\u003c/em\\u003e 5: 195-197. https://doi.org/https://doi.org/10.1007/s12599-013-0260-x.\\u003c/li\\u003e\\n\\u003cli\\u003eSchmidt, Kjeld, and Carla Simonee. 1996. \\u0026quot;Coordination mechanisms: Towards a conceptual foundation of CSCW systems design.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 5 (2): 155-200. https://doi.org/10.1007/BF00133655. https://doi.org/10.1007/BF00133655.\\u003c/li\\u003e\\n\\u003cli\\u003eSchmitz, Kurt W, James TC Teng, and Kimberly J Webb. 2016. \\u0026quot;Capturing the Complexity of Malleable IT Use.\\u0026quot; \\u003cem\\u003eMis Quarterly\\u003c/em\\u003e 40 (3): 663-686. https://doi.org/https://doi.org/10.25300/MISQ/2016/40.3.07.\\u003c/li\\u003e\\n\\u003cli\\u003eShaikh, Maha, and Ola Henfridsson. 2017. \\u0026quot;Governing open source software through coordination processes.\\u0026quot; \\u003cem\\u003eInformation and Organization\\u003c/em\\u003e 27 (2): 116-135. https://doi.org/https://doi.org/10.1016/j.infoandorg.2017.04.001. https://www.sciencedirect.com/science/article/pii/S1471772716301816.\\u003c/li\\u003e\\n\\u003cli\\u003eShao, Zhen, and Xixi Li. 2022. \\u0026quot;The influences of three task characteristics on innovative use of malleable IT: An extension of adaptive structuration theory for individuals.\\u0026quot; \\u003cem\\u003eInformation \\u0026amp; Management\\u003c/em\\u003e 59 (3): 103597. https://doi.org/https://doi.org/10.1016/j.im.2022.103597. https://www.sciencedirect.com/science/article/pii/S037872062200009X.\\u003c/li\\u003e\\n\\u003cli\\u003eSimandan, Dragos. 2019. \\u0026quot;Revisiting positionality and the thesis of situated knowledge.\\u0026quot; \\u003cem\\u003eDialogues in Human Geography\\u003c/em\\u003e 9 (2): 129-149. https://doi.org/10.1177/2043820619850013. https://journals.sagepub.com/doi/abs/10.1177/2043820619850013.\\u003c/li\\u003e\\n\\u003cli\\u003eSlagter, R., M. Biemans, and H. ter Hofte. 2001. \\u0026quot;Evolution in use of groupware: facilitating tailoring to the extreme.\\u0026quot; Proceedings Seventh International Workshop on Groupware. CRIWG 2001.\\u003c/li\\u003e\\n\\u003cli\\u003eSommerville, I. 2008. \\u0026quot;Construction by Configuration: Challenges for Software Engineering Research and Practice.\\u0026quot; 19th Australian Conference on Software Engineering (aswec 2008).\\u003c/li\\u003e\\n\\u003cli\\u003eSpradley, James P. 1979. \\u003cem\\u003eThe ethnographic interview\\u003c/em\\u003e.\\u003cem\\u003eThe development research sequence.\\u003c/em\\u003e Belmont, CA: Wadsworth Group - Thomson Learning.\\u003c/li\\u003e\\n\\u003cli\\u003e--. 2011. \\u003cem\\u003eParticipant observation\\u003c/em\\u003e. Australia: Wadsworth, Thomson Learning.\\u003c/li\\u003e\\n\\u003cli\\u003eTen\\u0026oacute;rio, Nelson, Danieli Pinto, and Pernille Bj\\u0026oslash;rn. 2018. \\u0026quot;Accountability in Brazilian Governmental Software Project: How Chat Technology Enables Social Translucence in Bug Report Activities.\\u0026quot; \\u003cem\\u003eComputer Supported Cooperative Work (CSCW)\\u003c/em\\u003e 27 (3): 715-740. https://doi.org/10.1007/s10606-018-9326-0. https://doi.org/10.1007/s10606-018-9326-0.\\u003c/li\\u003e\\n\\u003cli\\u003eThomas, D. M., and R. P. Bostrom. 2010. \\u0026quot;Team leader strategies for enabling collaboration technology adaptation: team technology knowledge to improve globally distributed systems development work.\\u0026quot; \\u003cem\\u003eEuropean Journal of Information Systems\\u003c/em\\u003e 19 (2): 223-237. https://doi.org/10.1057/ejis.2010.14. https://doi.org/10.1057/ejis.2010.14.\\u003c/li\\u003e\\n\\u003cli\\u003eWeinert, Christoph, Christian Maier, Sven Laumer, and Tim Weitzel. 2020. \\u0026quot;IS Reappraisal and Technology Adaptation Behaviors: A Longitudinal Study During an IS Implementation.\\u0026quot; \\u003cem\\u003eSIGMIS Database\\u003c/em\\u003e 51 (4): 11\\u0026ndash;39. https://doi.org/10.1145/3433148.3433151. https://doi.org/10.1145/3433148.3433151.\\u003c/li\\u003e\\n\\u003cli\\u003eWiegel, Valeri, Abby King, Hajar Mozaffar, Kathrin Cresswell, Robin Williams, and Aziz Sheik. 2019. \\u0026quot;A systematic analysis of the optimization of computerized physician order entry and clinical decision support systems: A qualitative study in English hospitals.\\u0026quot; \\u003cem\\u003eHealth Informatics Journal\\u003c/em\\u003e 26 (2): 1118-1132. https://doi.org/10.1177/1460458219868650. https://doi.org/10.1177/1460458219868650.\\u003c/li\\u003e\\n\\u003cli\\u003eWittgenstein, Ludwig. 1954/2009. \\u003cem\\u003ePhilosophical investigations\\u003c/em\\u003e. Wiley-Blackwell.\\u003c/li\\u003e\\n\\u003cli\\u003eWulf, Volker. 1999. \\u0026quot;\\u0026ldquo;Let\\u0026apos;s see your search-tool!\\u0026rdquo;\\u0026mdash;collaborative use of tailored artifacts in groupware.\\u0026quot; Proceedings of the 1999 ACM International Conference on Supporting Group Work, Phoenix, Arizona, USA. https://doi.org/10.1145/320297.320303.\\u003c/li\\u003e\\n\\u003cli\\u003eWulf, Volker, Oliver Stiemerling, and Andreas Pfeifer. 1999. \\u0026quot;Tailoring groupware for different scopes of validity.\\u0026quot; \\u003cem\\u003eBehaviour \\u0026amp; Information Technology\\u003c/em\\u003e 18 (3): 199-212. https://doi.org/10.1080/014492999119084. https://doi.org/10.1080/014492999119084.\\u003c/li\\u003e\\n\\u003cli\\u003eZhang, Yibin Fabricius. 2024. \\u0026quot;Too little or too much transparency? Influencing accountability in project management through the practices of using digital technologies.\\u0026quot; \\u003cem\\u003eInternational Journal of Project Management\\u003c/em\\u003e 42 (6): 102636. https://doi.org/https://doi.org/10.1016/j.ijproman.2024.102636. https://www.sciencedirect.com/science/article/pii/S0263786324000784.\\u003c/li\\u003e\\n\\u003c/ol\\u003e\"}],\"fulltextSource\":\"\",\"fullText\":\"\",\"funders\":[],\"hasAdminPriorityOnWorkflow\":false,\"hasManuscriptDocX\":true,\"hasOptedInToPreprint\":true,\"hasPassedJournalQc\":\"\",\"hasAnyPriority\":false,\"hideJournal\":false,\"highlight\":\"\",\"institution\":\"\",\"isAcceptedByJournal\":false,\"isAuthorSuppliedPdf\":false,\"isDeskRejected\":\"\",\"isHiddenFromSearch\":false,\"isInQc\":false,\"isInWorkflow\":false,\"isPdf\":false,\"isPdfUpToDate\":true,\"isWithdrawnOrRetracted\":false,\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"computer-supported-cooperative-work-cscw\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":false,\"externalIdentity\":\"cosu\",\"sideBox\":\"Learn more about [Computer Supported Cooperative Work (CSCW)](http://link.springer.com/journal/10606)\",\"snPcode\":\"10606\",\"submissionUrl\":\"https://submission.nature.com/new-submission/10606/3\",\"title\":\"Computer Supported Cooperative Work (CSCW)\",\"twitterHandle\":\"\",\"acdcEnabled\":true,\"dfaEnabled\":true,\"editorialSystem\":\"em\",\"reportingPortfolio\":\"Springer Hybrid\",\"inReviewEnabled\":true,\"inReviewRevisionsEnabled\":false},\"keywords\":\"Malleable technology, groupware, technology configuration, coordination, situated knowledge, ethnography\",\"lastPublishedDoi\":\"10.21203/rs.3.rs-7489297/v1\",\"lastPublishedDoiUrl\":\"https://doi.org/10.21203/rs.3.rs-7489297/v1\",\"license\":{\"name\":\"CC BY 4.0\",\"url\":\"https://creativecommons.org/licenses/by/4.0/\"},\"manuscriptAbstract\":\"\\u003cp\\u003eThe introduction of malleable technologies offers new opportunities to continuously adapt technical systems to the dynamics of evolving teamwork. These open-ended technologies enable users to co-define system capabilities through configurations. However, while configurations of malleable technologies are central to achieving the promised task-technology fit, whether team members accomplish in coordinating such technology configurations to suit the collective team remains underexplored in the current literature. Drawing on a nine-month qualitative field study at a Scandinavian IT company, this study investigates the process of malleable technology configurations in teams (specifically, digital project management tools). Using the theory of situated knowledge, we show that the team coordination of technology configurations is hindered by three emerging understandings within teams\\u0026mdash;assumed symmetry, assumed intentionality, and assumed adequacy. These divergent, yet simultaneously valid knowledge claims emerge from the sociomaterial interplay between malleable technologies and differently positioned team members and constrain their ability to engage in configurations meaningful to the collective team. By unpacking the process of configurations in teams, our study explains why malleable technologies do not always lead to the intended positive outcome of continued technological support but can instead entail time-consuming challenges in ensuring team usability.\\u003c/p\\u003e\",\"manuscriptTitle\":\"When Coordination Goes Wrong: The Challenge of Configuring Malleable Technologies in Teams\",\"msid\":\"\",\"msnumber\":\"\",\"nonDraftVersions\":[{\"code\":1,\"date\":\"2025-10-29 14:50:05\",\"doi\":\"10.21203/rs.3.rs-7489297/v1\",\"editorialEvents\":[{\"type\":\"communityComments\",\"content\":0},{\"type\":\"decision\",\"content\":\"Revision requested\",\"date\":\"2026-02-10T18:51:12+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"editorInvitedReview\",\"content\":\"\",\"date\":\"2026-01-14T20:51:27+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"editorInvitedReview\",\"content\":\"\",\"date\":\"2026-01-05T14:01:33+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"editorInvitedReview\",\"content\":\"\",\"date\":\"2025-12-16T21:48:59+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"reviewerAgreed\",\"content\":\"84384310058119875474123257721485675173\",\"date\":\"2025-11-11T10:33:54+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"reviewerAgreed\",\"content\":\"108488057484729315234399939696262955499\",\"date\":\"2025-11-11T09:06:30+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"reviewerAgreed\",\"content\":\"35693916349522676039517143315660396158\",\"date\":\"2025-10-17T10:29:09+00:00\",\"index\":\"hide\",\"fulltext\":\"\"},{\"type\":\"reviewersInvited\",\"content\":\"\",\"date\":\"2025-10-15T12:48:21+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"editorAssigned\",\"content\":\"\",\"date\":\"2025-10-02T09:37:45+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"checksComplete\",\"content\":\"\",\"date\":\"2025-09-09T11:37:21+00:00\",\"index\":\"\",\"fulltext\":\"\"},{\"type\":\"submitted\",\"content\":\"Computer Supported Cooperative Work (CSCW)\",\"date\":\"2025-08-29T13:55:41+00:00\",\"index\":\"\",\"fulltext\":\"\"}],\"status\":\"published\",\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"computer-supported-cooperative-work-cscw\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":false,\"externalIdentity\":\"cosu\",\"sideBox\":\"Learn more about [Computer Supported Cooperative Work (CSCW)](http://link.springer.com/journal/10606)\",\"snPcode\":\"10606\",\"submissionUrl\":\"https://submission.nature.com/new-submission/10606/3\",\"title\":\"Computer Supported Cooperative Work (CSCW)\",\"twitterHandle\":\"\",\"acdcEnabled\":true,\"dfaEnabled\":true,\"editorialSystem\":\"em\",\"reportingPortfolio\":\"Springer Hybrid\",\"inReviewEnabled\":true,\"inReviewRevisionsEnabled\":false}}],\"origin\":\"\",\"ownerIdentity\":\"40e06b5a-c90b-4379-bbbe-9e4dd7fc2fb5\",\"owner\":[],\"postedDate\":\"October 29th, 2025\",\"published\":true,\"recentEditorialEvents\":[],\"rejectedJournal\":[],\"revision\":\"\",\"amendment\":\"\",\"status\":\"under-review\",\"subjectAreas\":[],\"tags\":[],\"updatedAt\":\"2026-05-12T08:23:57+00:00\",\"versionOfRecord\":[],\"versionCreatedAt\":\"2025-10-29 14:50:05\",\"video\":\"\",\"vorDoi\":\"\",\"vorDoiUrl\":\"\",\"workflowStages\":[]},\"version\":\"v1\",\"identity\":\"rs-7489297\",\"journalConfig\":\"researchsquare\"},\"__N_SSP\":true},\"page\":\"/article/[identity]/[[...version]]\",\"query\":{\"redirect\":\"/article/rs-7489297\",\"identity\":\"rs-7489297\",\"version\":[\"v1\"]},\"buildId\":\"8U1c8b4HqxoKbykW_rLl7\",\"isFallback\":false,\"isExperimentalCompile\":false,\"dynamicIds\":[84888],\"gssp\":true,\"scriptLoader\":[]}","source_license":"CC-BY-4.0","license_restricted":false}