Abstract
Through a 2-year case study of a scaled agile transformation at a leading German automotive manufacturer, we examine how the role of IT architects changes during liminal stages of the transformation where the work setting in which they operate undergoes deep structure changes. Drawing on theories about roles as social positions and punctuated socio-technical change, we show how in the liminal stage of a scaled agile transformation, three deep structure changes are triggered: the introduction of new organizational structures, the re-definition of role expectations, and new software tool implementations. These changes introduce new role interdependency dynamics, namely, contested consensus expectations, increased conformity pressure, rising role conflicts, and adaptive role taking, which in turn prompt liminal role performance changes in terms of responsibility accumulation, communication intensification, technical competency increase, and intensified decision-making for architects. We contribute new insights about how deep structure changes that characterize the liminal stage of scaled agile transformations drive socio-technical role adaptations during the process of organizational transformation, which decrease rather than increase the stability of the work setting for architects.
Introduction
IT architects 1 have always been critical to the success of large organizations because they help aligning business strategy with technology execution (Shanks et al., 2018). But over recent years, the role of IT architects has arguably become even more critical (Bruls et al., 2010; Shanks et al., 2018), as the pressure has risen for large organizations to undergo organizational transformations in order to accelerate delivery and become more reactive to more volatile markets. In response, many firms are trying to find a way to introduce more agile ways of working 2 into their incumbent structures and functions (Caroll et al., 2020; Dikert et al., 2016; Rigby et al., 2018) and scaling them such that they remain able to manage cohesion and interdependencies across different teams and units (Limaj and Bernroider, 2022).
These so-called scaled agile transformations 3 are generally challenging for firms for many reasons, including resistance to change, role confusion, mindset, and staffing (Conboy and Caroll, 2019; Putta et al., 2018). But they are particularly challenging to IT architects: their role is the focal point of disruption through shifts in governance structures, redefined expectations, and new embeddings into fast-paced, cross-functional teams (Caroll et al., 2020; Mueller et al., 2025; Uludağ and Matthes, 2020). During scaled agile transformations, architects find themselves in a liminal stage in which they are literally “betwixt and in-between” (Ibarra and Obodaru, 2016; Söderlund and Borg, 2018) different work settings: they experience both an old and a new nature of their role (e.g. when new role definitions such as enterprise, solution, and system architects are introduced), an old and a new structure (e.g. when they have to learn how to operate in cross-functional, agile teams with distributed decision-making and continuous delivery structures), and an old, structured and a new, agile way of working (e.g. when they need to balance structured with participative decision-making and control with empowerment). Until a scaled agile transformation is complete, all these aspects of their work setting coexist.
This experience of IT architects is most pronounced during the early stages of a scaled agile transformation where the old situation is “unfreezed” and a “move” toward a new situation is started yet not completed (Cummings et al., 2015). In other words, in the early years of a scaled agile transformation, new structures, new roles, and new principles are being introduced and implemented while incumbent structures, roles, and principles still exist and apply. Thus, during early stages of a scaled agile transformation, architects experience intense pressure: they must retain strategic oversight of incumbent systems, structures, and processes and simultaneously find a way to integrate themselves into emerging fast-paced, cross-functional teams and re-form their professional identity (Mueller et al., 2025).
This is not an easy feat. Scaled agile transformations fundamentally alter organizational expectations and interdependencies of the social position IT architects occupy in the organization (Galletta and Heckmann, 1990; Zhu and Zhou, 2008). This means that going through a liminal stage where both structured and agile structures and ways of working co-exist creates pressure around role consensus, conformity, and adaptation, which are not merely operational issues but could shape strategic architects’ contributions.
Our goal is therefore to understand holistically how architects deal with the social and technical challenges they experience in the early, liminal stages of a scaled agile transformation. Traditional role theory highlights that they might encounter role stressors such as conflict, ambiguity, or identity strains (Moore, 2000; Tubre and Collins, 2000) and suggests that adaptive role taking would occur in a liminal transition (Biddle, 1986; Mueller et al., 2025), but it provides limited explanations about how and why roles evolve in response to their interdependencies with the broader sociotechnical environment of IT architects – the tasks, technologies, and structures that both constrain and enable role performance. This narrow focus risks portraying interdependence only as conflict and overlooks complementary and enabling dynamics (Bechky, 2006; Levina and Vaast, 2005).
We conducted an in-depth case study of CarCo, a leading German automotive manufacturer undergoing a company-wide scaled agile transformation on basis of the SAFe framework, to understand how the IT architect experienced the liminal transition in which their role evolved interdependently with changes to the sociotechnical work setting in which they operate. Our research question is: How do the nature and the work setting of architects change during the liminal stage of a scaled agile transformation?
We followed CarCo’s implementation of the SAFe framework as a new standard for managing IT and business initiatives for 2 years between 2023 and 2024. We traced how the role of the IT architects in the organization evolved from a traditional enterprise–domain–solution configuration (Josey, 2011) toward a new, more agile enterprise–solution–system configuration (Putta et al., 2018). The period of our study can be characterized as the liminal stage of CarCo’s scaled agile transformation, for two main reasons. First, this timeframe was set by the organization as a fixed period during which a total of eight transformation projects were to be carried out in which new roles, structures, tasks, and technologies were introduced within these projects whilst old roles, structures, tasks, and technologies co-existed outside of these projects. Second, even within these projects, the changes to roles, structures, tasks, and technologies were introduced incrementally. Thus, both cross-sectionally and temporally, the period between 2023 and 2024 was an “in-between, transitional phase” (Söderlund and Borg, 2018) where architects were conceivably “betwixt and between” (Ibarra and Obodaru, 2016) an old role identity that slowly dissipated while their new, emergent role was still being formed.
Within this empirical setting, we draw on role theory (Biddle, 1986) and theory on punctuated sociotechnical change (Lyytinen and Newman, 2008) to analyze how the social position and interdependencies of the architect role shifted as deep structure changes were progressively implemented. Our analysis shows that the implementation of the large-scale agile framework at CarCo triggered three main deep structural changes: (1) the establishment of new organizational structures, (2) the re-definition of architect roles, and (3) the implementation of new software tools. These deep structure changes in turn created new liminal role interdependency dynamics as architects interpreted and fulfilled multiple stakeholder demands and perspectives. These liminal role interdependency dynamics in turn prompted liminal performance outcomes that manifested for the architects as responsibility accumulation, technical competency increase, communication intensification, and decision-making intensification, which in turn re-shaped the architects’ new work environment within which they occupied their social position. The resulting work setting became provisional, dynamic, and markedly unstable, rather than becoming an end point or closure of the transformation let alone a stable work setting or role equilibrium. Our findings underscore that scaled agile transformations are neither purely enabling nor purely disruptive for architect roles; instead, they prompt an ongoing process involving complex re-balancing of the socio-technical role and interdependency dynamics that destabilize the social position of architects.
We proceed as follows: We first review relevant literature, particular research on the role of architects in scaled agile transformations, role theory, and the socio-technical theory frame. We then describe our procedures for data collection and analysis. Next, we present the empirical findings from our analysis and then propose a theoretical model for architect role changes in scaled agile transformations. Finally, we discuss theoretical and practical implications and conclude with limitations and directions for future research.
Background
The role of architects in scaled agile transformations
IT architects are system-level coordinators that oversee organizational structures and governance through which IT architecturally generates organizational benefits (Beese et al., 2023; Lange et al., 2016; Shanks et al., 2018). They are boundary spanners between IT and business strategy (Kotusev et al., 2023) and negotiate the competing logics by enacting projects and key strategic change initiatives (Ajer et al., 2021).
Historically, IT architects operated in plan-driven environments with centralized governance schemes through which they typically specialized in one of four different domains: business, data, application, or technology (Josey, 2011). Enterprise architects, for example, focus on the business domain, that is, on organizational strategy, capabilities, and processes. Domain architects manage application architectures, that is, IT system landscapes within specific domains (e.g. sales). Solution architects oversee data architectures entailing logical and physical data structures as well as technology architecture in terms of the software and hardware infrastructures required to support business needs (Foorthuis and Brinkkemper, 2007; van den Berg and van Steenbergen, 2006).
Yet, the domain responsibilities of and expectations toward IT architects have started to shift as organizations began to implement agile methods to become more responsive to shifting customer demands and market conditions (Beese et al., 2023; Bruls et al., 2010; Lange et al., 2016) and to become more flexible and adaptive in strategy design and execution (Mikalef et al., 2021).
Agile methods and mindsets were originally designed for small and individual teams (Conboy, 2009). Adopting them in large organizations therefore introduces challenges in terms of scaling, synchronization, and mindset (Conboy and Caroll, 2019; Dikert et al., 2016; Putta et al., 2021; Rigby et al., 2018). For example, large organizations (such as CarCo in our study) must balance their desire for increased flexibility and responsiveness through agility with a need for coordination and control because of their size (Caroll et al., 2020; Dikert et al., 2016; Limaj and Bernroider, 2022). Scaled agile transformations seek to achieve this balance. A number of industry frameworks exist to that end, in particular SAFe, the most widely used framework (Putta et al., 2018; Scaled Agile Inc., 2025), or Large Scale Scrum, Spotify, Nexus, or Scrum at Scale (Conboy and Caroll, 2019; Putta et al., 2021).
A scaled agile transformation brings forward many changes to the deep structure of an organization. For example, SAFe stipulates that work must be re-organized in cross-functional team networks labelled “agile release trains” (ARTs) that follow so-called “hardening, innovation, planning” iterations to develop “potential shippable increments” of typically 3-month lengths (Putta et al., 2018), which must be synchronized across multiple through regular joint planning events (Scaled Agile Inc., 2025). SAFe also stipulates additional or updated roles, such as ART engineer, system team, release management team, and portfolio management team (Putta et al., 2018; Scaled Agile Inc., 2025).
Thus, implementing large-scale agile frameworks such as SAFe profoundly redefines the role of architects in an organization. For example, adopting SAFe means that traditional architect distinctions – enterprise, domain, and solution architects mapped to business, application, and technology domains (Foorthuis and Brinkkemper, 2007; van den Berg and van Steenbergen, 2006) – give to way to a distinction between enterprise, solution, and system architects that operate across entirely redefined domains. Thus, architects are confronted with entirely new role expectations: Enterprise architects are no longer expected to focus on organizational strategy, capabilities, and processes alone but instead expected to extend their focus from business strategy to portfolio-level technology visions across all architecture domains. Domain architect roles largely disappear, while solution architects are now meant to coordinate multiple ARTs delivering shared solutions. Finally, system architects are now expected to ensure technical alignment within a single ART.
Comparison of traditional and scaled agile architect roles.
The deep structure changes summarized in Table 1 suggest that the transition from a traditional role of architects toward the similarly named yet substantively different position of being an architect within a scaled agile organization is not merely an operational concern, but central to transformation success (Rigby et al., 2018; van Wessel et al., 2022). This is particularly the case in the liminal stage of a scaled agile transformation. Because architects are situated at the intersection of strategic vision and technical execution and must balance long-term architectural guardrails with adaptive short-term delivery, they are particularly affected in the liminal stage where they are betwixt and between old and new ways of working. How architects navigate this liminal period and how they evolve their roles during that period remains insufficiently understood. To develop this understanding, we start by examining the available literature on role changes.
Role changes and evolving interdependencies during scaled agile transformations
Roles are socially constructed positions shaped by shared expectations, behavioural norms, and interdependencies (Galletta and Heckmann, 1990; Zhu and Zhou, 2008). Four aspects to roles are typically examined (Biddle, 1986): (1) consensus, the degree to which expectations for a role are shared; (2) conformity, the pressure to align behaviour with organizational norms; (3) role conflict, which emerges when a role is subject to incompatible demands; and (4) role taking, the process by which individuals interpret and enact the expectations of others, either accurately or by integrating multiple perspectives.
Scaled agile transformations challenge each of these four aspects: role expectations become contested, conformity pressures intensify, conflicts multiply, and architects almost inevitably engage in adaptive role taking during the liminal period of a scaled agile transformation (Mueller et al., 2025). But while prior research on agile role adaptation has shown how roles such as project managers or developers navigate tensions of old versus new identity (Maruping and Matook, 2020), and how both positive effects (e.g. increased motivation and efficacy) and negative effects (e.g. increased fatigue and role overload) can accrue from scaled agile transformations (Benlian, 2022; Mueller et al., 2025; Venkatesh et al., 2020), the role of architects has remained underexplored (Edison et al., 2021; Uludağ and Matthes, 2020).
Moreover, much of the available research on role changes has interpreted the notion of role interdependence quite narrowly as primarily interpersonal, equating it with stressors such as role conflict or ambiguity (e.g. Barki and Hartwick, 2001; Moore, 2000; Tubre and Collins, 2000). Other research has focused on interdependencies between roles as social positions, highlighting the importance of role complementarity (Bechky, 2006), coordination (Massey et al., 2003), and negotiation (Levina and Vaast, 2005). What has remained overlooked, however, is how roles interdepend not only with other social positions but also with the structures, tasks, and technologies 4 that constitute the sociotechnical work setting in which roles operate and which form part of the betwixt and in-between setting in which architects must operate during the initial, liminal period of a scaled agile transformation. Given that scaled agile transformations trigger deep structure changes to both social and technical elements of work (Bostrom et al., 2009; Lyytinen and Newman, 2008; Sarker et al., 2019), it is thus imperative to understand how all the deep structure changes to tasks, technologies, and structures alter the interdependencies of the social position of architects that is defined by norms and expectations. The research on sociotechnical system evolution (Bostrom and Heinen, 1977; Lyytinen and Newman, 2008) alerts us that changes in any sociotechnical component will ripple across the entire sociotechnical system, so effective adaptation of roles inevitably requires alignment between social and technical elements that shape the interdependencies of the role. This is thus the focus of our empirical analysis, as well as the reason to focus on the early, liminal period of a scaled agile transformation where these changes and their consequences will be most pronounced.
Method
Setting and design
We studied the case of CarCo, a large German automotive manufacturer renowned for its diverse vehicle line-up and substantial market share across numerous geographic regions. In response to intensifying market competition and the growing strategic significance of digitalization, CarCo’s IT management launched a scaled agile transformation using the SAFe framework to overhaul their IT and business project management by implementing SAFe guidelines, artifacts, and roles.
Before their scaled agile transformation, CarCo had three established architect roles consistent with the TOGAF framework (Josey, 2011), viz, they employed enterprise, domain, and solution architects. CarCo separated IT and business architect roles at the domain level, with IT architects focussing on the technical application landscape, and business architects aligning business capabilities and processes with the overall strategy of the business domain. As part of the scaled agile transformation, CarCo sought to transform the architect role according to the SAFe guidelines, which meant new roles had to be defined with new responsibilities, competences, and tasks.
We observed CarCo’s scaled agile transformation initiative from its decision to adopt SAFe in January 2023 through a total of eight 3-month project increments including three pilot projects across 2 years. During that timeframe, the scaled agile transformation initiative progressed as planned, meaning that at the end of 2024 CarCo reached a target of 20 teams operating according to SAFe. Since then, CarCo has been continuing with its operations according to the SAFe framework. They stopped measuring new ARTs as key progress indicators and simply consider this way of working their new “operating business.” Thus, the 2-year period of the scaled agile transformation we followed can be conceived as covering the “early to middle stages” of a typical organizational transformation, which is clearly the liminal period of such a transformation in which old structures and work settings are being “unfreezed” and a move is occurring toward new structures and settings, but these are not yet “refreezed” (Cummings et al., 2015) – which roughly occurred at CarCo from 2025 onwards. At the end of 2024, CarCo achieved an “evolutionary to effective level” of scaled agile maturity (Turetken et al., 2017): they successfully implemented new practices, such as evolutionary requirement elicitation, smaller and frequent releases, continuous delivery, release planning, regular reflection, and frequent face to face communication in self-organized teams; however, CarCo does not have intentional architecture or lean requirements at scale yet.
Case overview, research cycles, and data sources.
Data collection
We followed CarCo’s journey from the outset and began collecting data formally 6 months into the transformation. Our first data collection as part of our first research cycle, took place between June and July 2023. We focused on exploring CarCo’s scaled agile transformation as a whole. We selected key informants based on two criteria: being involved in strategic planning (strategic informants) or being engaged in daily operations of CarCo’s six initial transformation projects from January to July 2023 (operative informants). We conducted 25 semi-structured interviews with nine strategic and 16 operative participants. We supplemented this data with website reports and media coverage of similar initiatives in other large organizations. At this time, we realized in the interviews that the transition from traditional IT roles to agile roles was a key hindrance to the transformation at CarCo. Participants consistently emphasized that IT architects in particular were struggling the most to adapt, warranting our deeper investigation of this key role.
We engaged in a second research cycle between February and April 2024 after our initial exploratory open coding of the data. Because our goal at this stage was now theory development (Eisenhardt, 2021), we recruited additional informants through two theoretical sampling criteria: (1) Having profound architecture experience in one of CarCo’s incumbent architect roles being enterprise, domain, and solution architect from an IT- (focused on application, data, and technology architecture) or a business (focused on business architecture)-specific role or (2) taking over a new, agile architect role in the transition, such as enterprise, solution, or system architects, or supporting agile roles such as Architect Sync coordinators (a role label from SAFe). Our interview protocols were refined based on the emergent concepts and insights from our initial data collection.
In our third research cycle, the goal for our data collection was to corroborate our findings and the theoretical model we inductively developed during data analysis through member check-ins (Schwandt et al., 2007) with both company-internal and -external architecture experts. Our selection criteria for the company-internal experts were that the informants actively work as scaled agile architects at CarCo, while company-external experts had to have at least 3 years of experience in consulting organizations from different industries within their scaled agile transformation with a specific architect focus. In total, we conducted five interviews, three with CarCo’s architects and two with company-external agile consultants.
Across all three cycles, we completed 46 semi-structured interviews totalling 1.400 min with an average length of 30 min per interview, supplemented with secondary (e.g. SAFe practice reports and website documentation) and informal data sources (e.g. observations from project planning meetings we attended and data from internal skill databases).
Data analysis
Overview of data analysis.
Phases of our analytical process, inspired by Sahaym et al. (2023).
In the first analytical phase, our aim was discovery (Gregory and Henfridsson, 2021) to develop a pre-understanding of the case. We used open coding procedures (Strauss and Corbin, 1998) to analyze the 25 interviews conducted in the 1st research cycle. We broadly coded for benefits, challenges, expectations, and experiences of the scaled agile transformation. This allowed us to surface key issues and themes as experienced by multiple stakeholder groups involved in the initiative. It quickly became apparent to us that IT architects faced the most difficulties in adapting to the new ways of working that were being introduced, which in turn prompted us to direct more attention to the architect role in subsequent phases.
In our second analytical phase, we continued with open coding the 16 additional interviews we executed in the 2nd research cycle, which we had sampled because of their relevance to the identified challenges of architects. We then proceeded with selective coding all interviews, meaning that we honed in on how the informants at CarCo experienced the observed challenge “architect role change,” which became our core analytical category. For instance, the quote “so normally you have had 2-year decisions. Now I have to look in 3 months, in the interval, in the product interval, what decisions do I make?” (ID 36, System Architect, 2024) was coded as “the time for making an architectural decision decreased from 2 years to 3 months.” We recognized that the IT architects at CarCo differentiated between their work environment before and during the scaled agile transformation. This prompted us to adapt the interview guideline to understand what the prior state of CarCo’s architects was before the transformation, what the state looks like within the scaled agile transformation, and how the specific changes took place.
In the third analytical phase, we moved toward concept development (Eisenhardt, 2021). Our mode of reasoning switched to deduction to elaborate our early codes into abstract concepts (Azungah, 2018). We turned to role theory (Biddle, 1986) and the punctuated sociotechnical change model (Lyytinen and Newman, 2008) as sensitizing lenses to map 204 open and selective codes to (1) the role theory constructs consensus, conformity, and role conflict (Biddle, 1986), as well as the (2) sociotechnical systems elements structure, actors, technology, and task (Bostrom and Heinen, 1977; Sarker et al., 2019). In that process, we challenged our logical connections and interpretations by discussing within our research team all cases where the logical linkage from an open code to a theoretical element was not entirely clear to one of us. For instance, we felt that the code “the time for making an architectural decision decreased from 2 years to 3 months” could be attributed to both STS elements people and task, since a specific architect role executes a specific activity as a task. Discussions continued until we reached consensus (e.g. in this example, we decided to map the code to the STS element task since the meaning of the quote refers to the specific activity of taking a quick decision). Appendix B1 summarizes the outcomes from our deductive coding.
In our fourth analytical phase, our aim was theory building (Urquhart et al., 2010). Our aim was to theorize inductively how the architect role transitioned from the prior to the new agile socio-technical setting by examining the deep structure changes paired with the underlying mechanisms and outcomes explained the relationships between the concepts we had developed. We iterated between data and the conceptualizations we had developed in our second phase. For example, the quote “I think that’s also an issue, that the roles that we had here are mostly different to what SAFe suggests for us architects. But I can also see that for the other IT roles that they don’t completely match up” (ID40, Solution Architect, 2024) was coded as the 1st-order concept “traditional IT roles and SAFe roles cannot be completely matched”. Similar concepts were grouped into 2nd-order themes such as “re-definition of architect roles,” which we classified as the aggregate dimension “deep structure changes”. Appendix B2 summarizes our inductive coding.
By drawing inspiration from the punctuated sociotechnical change model (Lyytinen and Newman, 2008), we conceptualized four main episodes of change during the scaled agile transformation: (1) the implementation of a large-scale agile framework as a critical event triggering three deep structure changes as organizational decisions and adaptations that re-defined the architecture of roles and tasks, (2) the resulting activation of liminal role interdependency dynamics as the key mechanisms that prompted, (3) individual role changes manifesting as shifts in responsibilities, communication, competencies, and decision-making for the architects, leading to (4) new work system interdependencies manifesting as both benefits (e.g. enhanced alignment and knowledge integration) and costs (e.g. role confusion and underskilling). These four episodes provided the scaffolding for our emergent theoretical model of architect role change during CarCo’s scaled agile transformation.
In our fifth analytical phase, we moved toward theory elaboration (Fisher and Aguinis, 2017), by deductively mapping the consequences for the new work system from the previous phase onto the four main STS components, leveraging the punctuated sociotechnical change model to capture processual dynamics. This mapping traced how outcomes manifested at the interfaces between components: for example, knowledge integration emerged as a positive outcome bridging both the new agile, cross-functional teams and the supporting technology platforms used by architects to share their know-how and experiences. Similarly, enhanced alignment connected tasks and structure, while role confusion arose from misaligned tasks and actors, and underskilling from misaligned actors and technology. These mappings clarified how benefits and costs materialized across socio-technical subsystems, illustrating that CarCo’s scaled agile transformation neither uniformly enabled nor uniformly disrupted architect roles, but rather heightened the socio-technical instability while re-balancing the underlying dynamics across actors, tasks, structures, and technologies.
In the sixth analytical phase, we moved toward theory corroboration through reflection (Sætre and van de Ven, 2021) with a focus on plausibility rather than validity (Schwandt et al., 2007). We performed five additional interviews in which we sought qualitative corroboration through member-checking (Lincoln and Guba, 1985). Specifically, we assessed our emergent theoretical model across four dimensions: plausibility, resonance with lived experience, completeness, and transferability (Guba and Lincoln, 1989). We presented each interviewee with a visual representation of our theoretical model and posed open-ended questions for each dimension: for plausibility, we asked whether the depicted relationships and dynamics struck them as reasonable and recognizable; for completeness, we asked whether any relevant aspects of their experience appeared absent from the model. We interpreted responses as corroborating when interviewees affirmed the model’s core logic without introducing substantively contradictory experiences, and as prompting revision when interviewees identified gaps, imprecisions, or misrepresentations – as occurred, for example, with the relabelling of “improved collaboration” to “knowledge integration.” Across all five interviews, our model’s plausibility and completeness were affirmed, with interviewees characterizing it as “reasonable” and as capturing “all relevant aspects” of their experience.
5
While all interviewees corroborated the findings with their personal experiences, some architects felt the underskilling aspect could be emphasized more strongly, while others felt that benefits such as enhanced alignment and knowledge integration were more prevalent in our model than in their lived experience. Regarding transferability of our insights, the company-external architect experts asserted that they observed all aspects of the architect role changes and inherent changes to the STS in transformation initiatives of organizations across other industries. One of them stated: It actually always follows pretty much the same pattern in all the industries I’ve been in more or less. […]. I think you’ve summed up the pain points, the most important pain points really well. […] I co-wrote the SAFe Architecture training back in the day and […] and we should actually include actually address these points. (ID43, External Scaled Agile Architecture Expert, 2024)
Together, the feedback from our member checks corroborated the saturation of our emerging understanding, because in this final analytical phase “no apparent absurdities” (Sahaym et al., 2023) emerged anymore.
To assure the quality of our research procedures, we adhered to recognized principles for qualitative data analysis and theory development (Sarker et al., 2018). Whenever possible, we triangulated our interview data with CarCo’s press releases and experience reports from similar organizations from the official SAFe website. We also corroborated our findings with informal data sources such as company-internal job profile data. For example, we confirmed that the original enterprise architect role descriptions at CarCo listed 37 required skills, while the SAFe enterprise architect role description lists 50 required skills, a 35% increase. To mitigate interpretation bias, we transparently shared coded passages, labels, and drafts in our team across all stages of our analytical process. To minimize subjective bias during coding and theory development, both authors participated in all key stages of the analysis. Initially, both independently coded data and identify preliminary categories. We then engaged in several rounds of discussion to compare our coding, challenge our underlying assumptions, and explore alternative interpretations through suspicion and dialogical reasoning. Disagreements were openly discussed and resolved until we reached full agreement on all code labels, category assignments, and theoretical definitions. This iterative process continued for each subsequent stage of our data analysis and theory development, ensuring that coding and emerging concepts reflected a shared interpretive understanding grounded in the data. Our approach ensured that all coded data and conceptualizations were mutually agreed upon by both authors and remained traceable throughout. For example, our final theoretical model was the outcome of jointly iterating and debating over 25 different versions.
How the work setting of architects changed at CarCo during the liminal stage of their scaled agile transformation
Much like other automotive manufacturers, CarCo found itself spiralling into an ever-more challenging situation over recent years. With new technological advances, stiffening global competition amidst new entrants, and ever-changing customer requirements, CarCo decided that it needed to fundamentally revamp the way it organized IT and business projects in an attempt to increase product development speed, elevate customer satisfaction, and safeguard product quality. Its senior management decided to implement the SAFe framework and began its transformation initiative in January 2023 with three pilot projects to introduce SAFe guidelines, rituals, and roles such as product managers, system architects, and scrum masters. The projects were staffed with newly created agile roles from cross-functional business units that were assigned to IT and business specialists from units such as production or research & development. From mid-2023 onwards, CarCo then gradually introduced further cross-functional agile teams throughout more projects, reaching their target of 20 teams operating as per the SAFe standard by the end of 2024.
To summarize how this initiative disrupted the role of architects during this period of “unfreezing” the old work setting and “moving” toward a new setting, Figure 2 visualizes the main constituent elements of the work setting and characterizes the role experience of IT architects at CarCo before and during the liminal period of the scaled agile transformation we studied. Role and work setting of CarCo’s IT architects before and after the liminal period of the scaled agile transformation.
Consensus, conformity, and conflict in the IT architect role before and during the scaled agile transformation
In their incumbent work setting, CarCo’s architects experienced moderate consensus on role expectations, with most IT colleagues broadly agreeing on what architects essentially did in their daily activities. During the scaled agile transformation, however, these previously broadly agreed-upon expectations became contested and reduced, as entirely new and diverging interpretations emerged regarding what hierarchical management, agile teams, and cross-functional business specialists expected from architects. One architect explained: So, even if some managers disagreed before what architecture is, why it is important and what architects generally do, the introduction of SAFe really changed a lot. Now, also the other IT roles such as product managers or the developers have different understandings. And the business specialists, that also form a part of these ARTs, have again a different understanding. So it is all really confusing for us to be honest.(ID32, Enterprise Architect, 2024)
Similarly, prior to the transformation, architects exhibited functional conformity in their behaviour, meaning they broadly knew how to carry out their architectural activities even if specific practices varied across business units. Yet, the scaled agile transformation introduced a new, prescriptive “architect norm” espoused by SAFe framework that many architects struggled to adopt. Conformity was disrupted and architects had difficulty aligning their behaviour with the newly imposed agile norms. One architect described this liminal shift as follows: In the past, we knew how to handle things. And I think that most architects would agree on this. However, with this new understanding of what an architect should do according to SAFe, many of us struggle to understand this. And with our current know-how, it is difficult to keep up with what they expect from us in the PI plannings and all these other events. (ID27, Enterprise Architect, 2024)
Role conflicts were already common before the scaled agile transformation but were typically resolved pragmatically and informally within inter- and intra-business unit projects, so that the overall working system was never truly disrupted. The scaled agile transformation, however, created intensified, acute, and multi-directional role conflicts because architects were caught in a liminal state between their legacy responsibilities and new role expectations. Agile teams required hands-on architectural guidance, management demanded transformation success, and ongoing IT projects expected detailed planning and strategic oversight. This combination of competing demands amplified conflicts within the architects’ work. One architect explained: Some IT projects want a detailed business capability map from you, some agile teams want you to present a technical architecture vision in the PI planning, and the managers want to hear that the SAFe transformation works and makes us better. And between all this, we as architects try to satisfy everyone as good as we can. Someone always ends up complaining. (ID26, Enterprise Architect, 2024)
The work setting of IT architects before and during the scaled agile transformation
The visual summary in Figure 2 highlights that all sociotechnical elements of the work setting of IT architects changed during the scaled agile transformation. Regarding the structure aspect of the work setting of architects, originally, each business unit of CarCo had its own architects, namely, enterprise, domain, and solution architects, who operated using waterfall-like methods within temporary project structures. These architects collaborated in IT projects for both intra-business unit and inter-business units.
During the scaled agile transformation, CarCo requested its architects – in addition to their historic structural deployment – to operate in newly formed, cross-functional agile teams staffed by different business units, denoting that similar architect roles from different business units needed to collaborate in the same ARTs. One architect described the structure changes as follows: CarCo is a very large company. Complex and even more complex is the collaboration between different business units. […] All levels play a role in this SAFe transformation with new ARTs between the business units. And of course, they all have to move in the same direction, more or less in the same rhythm with architects coming from business unit A, business unit B, and so on. (ID26, Enterprise Architect, 2024)
Regarding the actor aspect of the work setting, originally, CarCo differentiated between enterprise, domain, and solution architects, and further classified the intermediary role of domain architects into business and IT architect levels. While business architects focused on defining and governing the business capabilities and processes of a specific domain, IT architects emphasized the diverse application landscape. Further, the different architects received a structured role-specific training program based on their specific architecture layer and inherent skills.
During the scaled agile transformation, CarCo shifted to enterprise, solution, and system architects in adherence to the SAFe guidelines. In turn, the enterprise and solution architects received new role definitions, the system architect role was completely new to CarCo, and the historical domain and business architect level roles were dissolved. Moreover, architects were required to undergo not only role-specific architect training, but also intensive deep-dives into the agile methodologies and inherent architect concepts based on the official SAFe for Architects® training courses. One architect described the changes as follows: So, I’m now also a certified SAFe architect, right? I did the training. I am certified. I passed the exam. All the buzzwords, although I couldn’t do much with them either, right? In general, this methodology, that’s a huge catalog. […]But of course a new person who’s just starting out can’t really understand when they hear words such as evolutionary architecture. They’re all words in the SAFe context, right? What does that really mean? Good question. (ID36, Enterprise Architect, 2024)
Regarding the technology aspect of the work setting, originally CarCo had standardized architecture software tools across all architect roles and all business units. However, each business unit established their own governance strategy and guidelines for the standardized architecture tool.
During the scaled agile transformation, CarCo implemented new project management tools and integrated them into the daily work of the agile teams. In turn, the architects were required to acquire new skills and knowledge to effectively operate and collaborate with these tools. Moreover, the heterogenous tool governance from business units in the original state closed in on the newly-formed value-based structures across different business units. For example, every ART would decide on how it used and governed both the standard architecture tools and the new project management tools. One architect illustrated the technological changes: What really hinders me in my architecture work is all this coordination, right? At every agile layer, I always have some other guidelines on how to use the tools. That makes it sometimes really confusing, but every ART can do it as it likes. (ID37, System Architect, 2024)
Finally, regarding the task aspect of the work setting, the tasks of architects were originally restricted to their specific enterprise, domain, and solution architect roles. For example – a domain architect “only” needed to execute domain-specific activities related to the business and IT landscape, but not activities that would concern how the technical interfaces and data platforms interact with each other. Further, the daily architecture work was mainly focused on the operations and communication activities with the respective stakeholders of the intra- and inter-business unit-specific IT projects. Since historically, projects at CarCo were plan-driven and followed waterfall-like principles, much of the work of architects was executed in lengthy pre-project phases to indicate new IT projects into the existent IT and business landscape of the business units and the entire enterprise.
During the scaled agile transformation, architects were asked to execute more technical tasks because of the new cross-architectural domain guidelines and the resulting blurring of the architectural layers. The architects were asked to establish alignments across enterprise, solutions, ARTs, and agile teams. Another crucial change resided in a drastically narrowed time window for decision-making based on the frequent cadence structures according to SAFe. One architect narrated the task changes as follows: In my opinion, now, the technical competence needs to be built up even further than before. […] Before, that was not like that. […] And also very important, now, which was not so deep before, which dependencies do I identify as an architect or can I identify? And can I accept them or do I have to eliminate them, right? So that’s a very important topic. (ID36, System Architect, 2024)
The three deep structure changes that triggered liminal role interdependency dynamics
CarCo’s strategic decision to adopt a large-scale agile framework triggered three deep structure changes
6
—the creation of new organizational structures, the re-definition of architect roles, and the implementation of novel software tools, which prompted a cascading process of change unfolding over four main episodes and which in sum re-configured the structures, actors, technologies, and tasks of IT architects’ work setting, thereby introducing new liminal role interdependency dynamics that produced changes to consensus, conformity, and conflict in the architects role. A strategic stakeholder captured the scope of this shift as follows: In many different aspects like the mindset, the way to work together, the decision processes and of course also the roles are completely different from what has been lived so far at [CarCo], how they are currently implemented. (ID10, Education Specialist, 2023)
The first fundamental change involved the creation of new organizational structures. Long-standing functional units were re-organized into cross-functional, agile teams operating across business divisions and oriented toward end-to-end value delivery. This move required dismantling embedded silos and moving away from a rigid engineering mindset, which was difficult for many to grasp. A strategic stakeholder noted the magnitude of this change, observing that CarCo’s classic, highly structured separation between business departments was replaced with cross-functional, interdisciplinary agile teams and ARTs functioning at multiple organizational levels. This new, value-driven structure initially proved difficult for many employees to fully understand due to its intangible nature: The biggest change for me in this SAFe transformation is our classic structure. We are a very structured company with a clear separation of business departments and functions. In SAFe we now talk about building these cross-functional, interdisciplinary agile teams and ARTs. And this happens on different levels of the company. We somehow need to become value-driven in this new structure. For many people, understanding that new structure is hard since it is not very tangible at first. (ID7, Project Leader, 2023)
To illustrate, Figure 3 visualizes the change of the organizational structure at CarCo. The overlapping horizontal and vertical delineation of departments and roles are meant to indicate how CarCo attempted to combine stability and control of their traditional hierarchy with the adaptability and speed of a horizontally aligned matrix structure that was meant to allow cross-functional agile teams to operate alongside established line functions while both structures were meant to be aligned via shared goals and integrated tools. In this new structure, architects were literally “in-between” vertical (department structures) and horizontal (project structures) delineations of tasks, goals, and responsibilities. CarCo’s change to its organizational structure.
The second fundamental change was the re-definition of architect roles. To align with SAFe, CarCo decided to eliminate their incumbent, company-specific business architect role at the domain level. They also introduced a new system architect role and re-interpreted the enterprise and solution architect roles with altered responsibilities, tasks, and required competencies. The reinterpretation of enterprise and solution architect roles was not merely semantical. At CarCo, the traditional enterprise architect role was tasked with establishing an IT architecture vision that fits to the business strategy, whereas the new enterprise architect role under the SAFe framework was now expected to establish a portfolio’s technology vision, strategy, and roadmap. A similar change occurred for solution architects. Their traditional focus at CarCo was on specializing in the technical aspects of a single system, but during the scaled agile transformation their role shifted to establishing a shared technical vision for solution trains developed by several ARTs. A former business architect who transitioned into a product manager role during the scaled agile transformation described the effect as follows: Well, I was surprised that the domain architect and also the business architect role do not exist in SAFe. So I become a product manager. To be honest, I then learned somewhere that the best way to influence the business architecture is by managing the product rather than through a downstream, shall I say, architecture analysis. (ID34, Product Manager, 2024)
The third change was the implementation of new software tools. As part of their transformation, CarCo acquired licences for new software tools meant to support iterative planning, enhanced transparency, and enabled real-time collaboration across teams during their projects. One architect involved in the rollout highlighted the significance of this software change: With SAFe, we have new project management tools [tool X] and [tool Z]. We are working with the development teams. As architects, we didn't have that before in our projects. The developers are way more used to this. But I can see the advantages of alignment and collaboration already. (ID37, System Architect, 2024)
The integration of the new agile project management software tools affected all architects at CarCo: Their enterprise architects were now required to update strategic roadmaps and align multiple ARTs through the tools, solution architects had to start using the new tools to manage work packages and dependencies across ARTs, and system architects became tasked with maintaining the ART-level and agile team backlogs in the new software tools.
Four liminal role interdependency dynamics prompted by the changes
The three fundamental changes detailed above produced reverberations that quickly cascaded into the daily practices of architects. As the new structures, roles, and tools were implemented, new role interdependency dynamics emerged that translated these systemic changes into individual experiences and outcomes that were salient to the liminal role experience of architects at CarCo.
The first observable dynamic was a shifting consensus baseline surrounding the architects’ role. Whereas expectations had been moderately aligned in their prior work setting, the introduction of SAFe principles during the liminal stage of the scaled agile transformation brought diverging interpretations of the architects’ role from management, agile roles, and business specialists to the fore. This resulted in reduced and contested consensus on what architecture work meant in practice: I think that with SAFe, it has become less clear what the people we work with expect from us and how they interpret architecture work. (ID27, Enterprise Architect, 2024)
Because architects could no longer rely on collectively shared role expectations to delimit the boundaries of their work, they were compelled to fill interpretive gaps by absorbing unassigned tasks and expanding their coordination efforts. This mechanism – active gap-filling triggered by contested consensus – constitutes the primary pathway through which diverging role interpretations translated into the responsibility accumulation architects subsequently experienced.
A second observable dynamic can be described as an increased conformity pressure. With the creation of new organizational structures and the redefinition of architectural roles, architects at CarCo were quickly expected to adopt the new, prescriptive SAFe norms and practices, irrespective of their relevance to daily work or the past norms they were accustomed to and that often were still salient in day-to-day work. In turn, in the liminal stage of the transformation, architects experienced a growing sense of being evaluated against abstract standards rather than situational needs: I feel that in every PI planning, management and the PMs [Product Managers] and the other roles there put more and more pressure on us [the architects] to deliver what SAFe suggests. Even if in practice, this is not needed. Just because some SAFe guidelines says that it should be this way. (ID40, Solution Architect, 2024)
Because SAFe’s prescriptive norms structurally required architects to participate in cadence-driven rituals and multi-team coordination events irrespective of situational needs, architects were systematically pulled into more frequent and cross-directional interactions than their prior roles demanded. This coercive enrolment into SAFe-defined communicative behaviours is the primary mechanism that explains how conformity pressure produced the communication intensification the architects came to experience.
A third observable dynamic were rising role conflicts. Continued historical demands from traditional IT projects started to compete with new expectations expressed by the newly formed agile teams and the new project management. These contradictory demands could not be satisfied simultaneously. This ultimately turned previously latent tensions into acute, multi-directional conflicts. One of the architects explained: How are the architects supposed to do well in their work when they are stuck between traditional IT projects and these new SAFe teams and ARTs? I tell my manager that, but no one did so far really answer that question to me. (ID37, System Architect, 2024)
Because architects remained simultaneously accountable to traditional IT project timelines and to the compressed planning cadences of newly formed agile teams, they could no longer sequence architectural decisions across extended time horizons as before. Thus, the simultaneity of these competing demands – rather than their mere coexistence – was the causal mechanism through which role conflict produced the decision-making intensification the architects came to experience.
Finally, a fourth observable liminal role interdependency dynamic was adaptation through role taking, in which architects engaged to cope with the tensions they increasingly experienced. By actively interpreting and switching between stakeholder perspectives, architects attempted to navigate conflicting expectations and maintain workability in their daily routines. In some cases, collective coping practices were developed to ease these shifts: How do we solve this? Good question. So what we did with the architects together was creating kind of translation maps, where we can see who expects what from you and where. There has been good feedback. Because with that, at least they know a bit better how to switch their heads in their daily work. (ID 38, Architect Sync Coordinator, 2024)
Thus, by assuming the perspectives of development teams who expected deeper technical engagement, architects rendered own competency gaps visible and actionable – making role taking not merely a coping strategy but instead a cognitive mechanism through which they translated the pressure to adapt into technical skill development.
Together, these four liminal role interdependency dynamics illustrate how the deep structure changes triggered by the adoption of the SAFe framework translated into role-level tensions and competing demands that characterized the liminal “betwixtness and in-betweenness” of architects and which mediated and amplified their day-to-day individual work challenges in their liminal work setting that was caught between the dissipating old work setting and the not-yet-rigidified new work setting.
Role performance outcomes the architects experienced
Through the three fundamental changes that the adoption of the SAFe framework triggered and the resulting new liminal role interdependency dynamics these changes produced, the architects at CarCo began noticing four salient changes to their role performance in their ongoing work:
First, the transition toward new organizing structures and the redefinition of architect roles led to a marked responsibility accumulation. Architects were now expected to exercise greater decision-making authority, assume heightened accountability, and coordinate more intensively with cross-functional agile teams. This role expansion created both upward and lateral pressures, as expectations increased from management and peers in newly formed agile roles. One architect described the intensification of responsibility as follows: This is a transformation from old architect roles to new roles with not only new but even more tasks, competences and above all responsibilities according to SAFe. We have more responsibilities as we need to coordinate with all the teams and the ARTs in some way and they also expect us to do so. (ID41, System Architect, 2024)
Second, the emergence of cadence-based events, such as project increment plannings, daily stand-ups, and retrospectives, combined with the adoption of new collaboration software tools, resulted in communication intensification. Architects had to engage in more frequent and complex information exchanges, often translating between technical and business perspectives. This required them to cultivate stronger communication skills, including an ability to align with business strategies and customer-focused perspectives. As one architect emphasized: I need a lot more communication skills with business departments. I need the topic of strategy derivation to an even greater extent, because these are business unit strategies and not IT strategies. […] I also need to understand the language of the business department and also need to know what a customer journey is and how I actually build and communicate it. This whole agile principle requires me to be a better communicator. (ID39, Enterprise Architect, 2024)
Third, the redefined architect roles demanded a significant technical competency increase. Whereas architects had previously maintained a system-level perspective focused on conceptual integration and high-level design, they were now increasingly expected to support development teams in hands-on technical decisions - ranging from automated workflow and software assembly pipelines to code-level reviews. This shift exposed a competency gap, especially for those who had been less engaged in daily development activities. One architect noted: The majority of architects at [CarCo] are really working with the capabilities, processes or the system landscape in general, I think. And I think now in SAFe, many of them need to make deeper technical decisions and tasks. The development teams at least expect them to do so. And this is difficult if you have no experience and this is new to you, right? (ID37, System Architect, 2024)
Fourth, the accelerated cadence of agile planning cycles compressed the time available for architectural decisions, creating decision-making intensification. Where architects once operated on multi-year planning horizons, they now faced 3-month (or shorter) intervals for critical product decisions during the newly implemented project increments. This temporal compression heightened both the frequency and the stakes of decisions, producing pressure and stress in the transition, at least for some architects: So normally, you have had two-year decisions. Now I have to look in 3 months, […] in the product interval, what decisions do I make? And that can be very difficult. (ID36, System Architect, 2024)
Collectively, these liminal role performance outcomes illustrate how the organizational-level deep structure changes created dynamics that cascaded into notable individual-level changes to the architects’ performance in their daily roles. The interplay of accumulated responsibilities, intensified communication, increased technical demands, and compressed decision-making cycles marked a profound shift. While these shifts were essential organizationally for enabling a transition toward more agile ways of working, they simultaneously introduced new tensions and frictions in the actual individual role performance of the architects during the transition period.
The destabilization of the work setting of IT architects
The individual-level role performance outcomes of the architects at CarCo during the liminal phase of the scale agile transformation cascaded upward through the interdependencies the architect roles shared with their broader work setting. These cascading consequences materialized through the accumulation of both benefits and costs to architects’ daily work, which in turn affected the balance and performance of the entire sociotechnical work setting in which the architects operated.
In terms of benefits, the architects experienced in their liminal work setting enhanced role alignment between the new organizational structures (e.g. the new cross-functional agile teams) and the new tasks that were expected from the architects (e.g. architectural planning and decision-making). The adoption of cross-functional, agile teams and cadence-driven rituals fostered closer collaboration between architects and agile teams, enabling decisions to be contextualized across value streams rather than isolated in functional silos. This reduced response delays and supported faster alignment between architectural intent and implementation. As one architect described: Typical architecture activities were very isolated, right? I received requests about something. I worked on them and was only able to support them somehow in that context. Now in SAFe, I first evaluate the whole thing in the context of the entire ART. And since I have the opportunity and the contacts for the other ARTs, I can also evaluate the whole thing at solution […] That’s the biggest difference for me and improves our coordination. (ID33, Product Manager, 2024)
A second benefit was better role coordination through improved knowledge integration. The adoption of the new digital collaboration tools enabled architects to document, share, and synthesize insights more effectively, fostering transparency and joint problem-solving across teams. This integration supported collective sensemaking between different architects and other roles (e.g. project managers and developers) and improved the quality of architectural decisions. The improved knowledge integration positioned architects as orchestrators and bridge-builders, connecting technical and business domains, as one architect summarized: I already see since [Tool X] is implemented in our architecture work, things have changed. It helps us to work together better with the product owners and the others [other agile roles]. The people document things in a structured way. […] So we can really share information, talk more and learn from each other. This is very helpful for me as an architect. (ID29, System Architect, 2024)
At the same time, architects also experienced costs in their liminal work setting during the scaled agile transformation. The most notable cost was substantial role confusion, emerging from misalignment between their tasks (new responsibilities and decision rights) and actors (architects with historically different role expectations). The shift from traditional role definitions to agile-oriented responsibilities created uncertainty about boundaries, priorities, and competencies. Interestingly, architects frequently reported feeling “lost” in translating theoretical SAFe role descriptions into daily practice – even though they also felt better aligned across other agile roles and teams. This tension became apparent within their informal peer exchange rituals and newly formed architect synchs. The ambiguity represented a persistent gap between role expectations and performance, straining team interactions and slowing adaptation, as one put it: The new architect role definitions and how they are really lived in the [CarCo] reality is still quite confusing to be honest. For many architects I know this change is not easy because the way we should work according to SAFe with all new responsibilities, competences and tasks is different. Right now, there is always a lot of confusion. And the theoretical SAFe trainings don’t really help for our daily work. (ID41, System Architect, 2024)
A second notable cost manifested in the form of role underskilling, caused by a gap between the expectation levelled at the architects and the technology they were increasingly and rapidly meant to use (new tools and technical demands). While architects underwent training in SAFe principles, deeper technical competencies that required during ongoing work – such as DevOps practices, system integration management, and real-time tool usage – were often lacking in the liminal stage of the scaled agile transformation. This mismatch left architects underprepared and struggling during this phase of the scaled agile transformation to meet the new expectations from management and development teams that emerged rapidly and early. In turn, the liminal experience of role underskilling amplified stress for the architects and slowed their technical decision-making speed, as one architect explained: Maybe you went to one or two SAFe events and training courses. The SAFe theory is always explained to you there. Somehow, I still didn’t understand what do we really have to do in the future. It was all very generic and not really related to what we actually do here. Honestly, I don’t feel prepared for what is expected of me there. (ID36, System Architect, 2024)
Taken together, these benefits and gaps illustrate how the trajectory of CarCo’s scaled agile transformation was uneven and literally “in-between.” While the emerging benefits of enhanced coordination and knowledge integration fostered the formation of new alignments across some work setting components, the experience of costs in terms of role confusion and underskilling introduced new problems in the work setting that contributed to a state of heightened socio-technical instability: with both benefits and costs accruing during the scaled agile transformation, the entire work setting was no longer stable and instead became a liminal “in-between” state that was in flux and required the architect to invest effort into re-balancing benefits and costs of their liminal role and actively negotiating further evolutions to their new roles and work setting interdependencies to eventually reach a new, stable state.
A theoretical model of architect role changes in scaled agile transformations
Figure 4 shows the theoretical model we developed to abstract the insights we gained in our empirical study.
7
Our model conceptualizes a scaled agile transformation and its impacts on the role of architects as a punctuated sociotechnical change process (Lyytinen and Newman, 2008) that is triggered by the decision to implement an agile framework, which prompts organizational-level deep structure changes that in turn generate liminal role interdependency dynamics that affect the liminal role performance of architects as individual-level outcomes. These individual-level outcomes in turn reconfigure the interdependencies of the architects role with the sociotechnical work setting in which they operate and thereby make this work setting less rather than more stable than previously, which implies that the next stage of the scaled agile transformation, from moving to refreezing (Cummings et al., 2015), is further complicated. Theoretical model.
The central thesis of our model is that liminal role interdependency dynamics triggered by deep structure changes invoked in an scaled agile transformation manifest in concrete liminal role performance outcomes for architects in their daily practices (in terms of responsibility accumulation, intensified communication demands, expanded technical competency shifts, and compressed decision-making cycles) that destabilize the sociotechnical work setting in which architects operate and which is interdependent with both role expectations and performance of architects.
Our model highlights the key role of role interdependency dynamics that function as liminal mechanisms that translate organizational-level change decisions into individual-level role performance outcomes. These outcomes fundamentally reshape how architects work and how they interact and make decisions within their broader sociotechnical work system. In doing so, they alter the alignment between role expectations and performance both in positive (improved role coordination and alignment) and negative ways (increased role confusion and underskilling) during the scaled agile transformation and which explain how the abstract notion of being “betwixt and in-between” manifests for architects. Scaled agile transformations thus at least temporarily destabilize – rather than stabilize – the work setting of architects; casting into doubt the narrative that scaled agile transformations unequivocally improve the working condition. Our model underscores the punctuated and uneven nature of architect role changes during scaled agile transformations. It illustrates how organizational pressures produce a critical event, reconfigure deep structures, activate role interdependency dynamics as mechanisms, and generate individual role performance outcomes that ultimately create a complex mix of benefits and gaps. This complexity not only complicates the remaining effort of the scaled transformation, but also challenges the “refreezing” metaphor of later-stage organizational change. Rather than locking in a new stable state as a new norm, organizations must first move the liminal work setting out of its destabilized place before they can “lock in” a new way of operating.
Discussion
Our study examines how a scaled agile transformation impacts and re-configures the role of IT architects during liminal stages of the transformation. Through our examination of role changes with a focus on their interdependencies to changes in the sociotechnical work setting of architects, we constructed a theoretical model that explains how deep structure decisions at the organizational level cascade into role interdependency dynamics that alter the role performance of architects in their daily work during the liminal period of a multi-year scaled agile transformation during which their work setting is destabilized in ambivalent – both positive and negative – ways.
Our findings extend prior research on scaled agile transformations (Caroll et al., 2020; Dikert et al., 2016; Edison et al., 2021) by unpacking the mechanisms through which socio-technical instability arises during liminal stages of a scaled agile transformation, which impacts and alters how architect roles are being reconfigured during scaled agile transformations. These findings provide three key contributions to different literatures, which we discuss, in turn.
Implications for research
Sociotechnical interdependence in role dynamics
Recent research has begun to treat roles as dynamic rather than static. Jahnke (2010), for example, shows how role structures in a sociotechnical community evolve from informal, trust-based configurations toward formal arrangements in which social mechanisms – rather than software architecture alone – come to govern knowledge management processes. Roshani (2025) maps the temporal evolution of actor roles across innovation ecosystems, identifying five dynamic role types – including core anchors and cross-network integrators – that adapt fluidly in response to technological shifts and collaborative opportunities. Zoppelletto et al. (2023) demonstrate that individual attitudes, leadership styles, and managerial approaches shape how roles change during digital transformation. While these studies collectively establish that roles are dynamic and context-sensitive, they primarily examine role evolution at the community, ecosystem, or managerial level. Our study now adds to these insights by examining the mechanisms through which deep sociotechnical structure changes produce specific role performance outcomes for practitioners caught in the liminal stage of an organizational transformation We examine roles as sociotechnical positions embedded within interdependent configurations of tasks, technologies, and structures. Our analysis of CarCo’s scaled agile transformation reveals that during the “unfreeze and move” stage, deep structure changes reconfigure not just interpersonal expectations but also the structural and material conditions underpinning both role performance and role expectations. Role expectations and performance thus emerge from distributed sociotechnical interdependencies, where the ability to fulfil expectations depends as much on the surrounding sociotechnical infrastructure as on individual agency – a mechanism not yet foregrounded in prior work on dynamic roles.
By emphasizing this interdependence in roles, our findings extend prior research that focused on identity (Stryker and Burke, 2000), stress (Tubre and Collins, 2000), or managerial leadership approaches during digital transformation (Zoppelletto et al., 2023), by showing that coordination mechanisms, digital tools, and modular structures can also redefine what counts as effective role enactment during periods in which not only roles and identities but also structural and material conditions of the work setting are unstable and in flux. Future theorizing on role performance could thus adopt our sociotechnical lens to examine how technology-mediated work systems restructure opportunities for consensus, conformity, and role taking within organizations.
Our insights also extend classical notions of role conflict and ambiguity (e.g. Barki and Hartwick, 2001; Moore, 2000). Rather than treating these as stressors that undermine role performance (Tubre and Collins, 2000; Venkatesh et al., 2020), our findings suggest that conflict also functions as a transitional signal of underlying sociotechnical, structural and material reconfiguration – an indicator of emerging interdependencies that need redesign and adjustment. At CarCo, many of the architects reported a pronounced sense of role confusion at the level of their professional identity, feeling torn between their traditional roles and the expectations of the new scaled agile architect role, even as they experienced improved alignment and integration with other agile roles and teams. To navigate this tension, architects actively engaged in informal meetings and peer exchanges – not only within the community of architects to collectively reflect on changing role expectations and mitigate confusion, but also across other agile roles and teams – to deepen mutual understanding and foster alignment. This proactive, collaborative approach indicates that the ongoing transition became an iterative sensemaking and co-creative design process, in which architects tried to reconcile fields of tension they experienced in the liminal period by jointly constructing new meanings and adaptive practices for their evolving roles. In the context of CarCo’s scaled agile transformation, lack of role clarity during the liminal stage of the transition became resolved less through from formal definitions and instead more through iterative sensemaking by the architects as part of their daily role performances.
Bridging role theory with sociotechnical theorizing
A second contribution of our study lies in bridging role theory and sociotechnical theorizing, two traditions that have evolved largely independently but address complementary questions about how individuals in their work systems adapt to change. Role theory traditionally explains how social positions are constituted through expectations, norms, and sanctions (Biddle, 1986), whereas sociotechnical theories typically explore how human actors and digital technologies co-produce effective work systems through joint optimization in liminal stages of transformation (Bostrom et al., 2009; Lyytinen and Newman, 2008; Sarker et al., 2019). We integrate both views to develop a theoretical account of how transformations in the technical subsystem of work (tools and tasks) reciprocally shape and are shaped by roles and structures in the social subsystem of work in the liminal “unfreeze and move” stages of a scaled agile transformation. We show that when CarCo introduced the SAFe framework, which prompted changes to their organizational structure and the implementation of new collaboration software, architects’ roles iteratively evolved through a cascading process of sociotechnical negotiation and change. The new tools redistributed relevant knowledge and decision rights, while the new organizational structures started to redefine accountability and authority rights. These shifts did not merely change task allocations but transformed both role expectations and performance and transformed how architects depended on, enabled, and constrained others in performing their own roles. This role adaptation process exemplifies what Lyytinen and Newman (2008) describe as deep structure change in a sociotechnical work system; however, our study adds a more nuanced and detailed account of how fragile and unstable the liminal dynamics, outcomes, and work setting implications of such a role adaptation process are.
One key implication of these insights is that roles can serve as mechanisms of sociotechnical alignment during liminal change periods such as those in the early-to mid-stages of an scaled agile transformation. Roles mediate between evolving technologies and enduring organizational logics, between the “old” and the “new” that coexist in liminal transition periods, and they pinpoint the concrete structural and material aspects of work settings where adaptation occurs or is needed Integrating role theory within a broader STS perspective therefore enables analysis of how scaled agile or digital transformations unfold not just through technological substitution (Zimmer et al., 2023) or cultural change (Wessel et al., 2021), but through iterative reconfiguration of the sociotechnical role and its link with social and technical elements of the work setting in which roles must operate and in which they undergo change. Future research can thus extend this line of thought, for example, by using multi-level and longitudinal research designs to trace how role configurations stabilize over time during or even after scaled agile and digital transformations. By situating roles within a broader sociotechnical perspective, IS scholars can more effectively capture the material, temporal, and structural nature of organizational adaptation.
Understanding IT roles during scaled agile transformations
Third, our study directly expands the growing stream of research on scaled agile transformations (e.g. Conboy and Caroll, 2019; Dikert et al., 2016; Limaj and Bernroider, 2022) with new insights about the reconfiguration of roles and their sociotechnical interdependencies while incumbent structures are unfreezed and altered. This liminal period is important because a scaled agile transformation is not a singular event of substitution from old to new but a lengthy process of adaptation and change where old and new structures, conditions, expectations, norms, and behaviours co-exist laterally and temporally (Wimelius et al., 2021). Existing research on scaled agile transformations has largely centred on process outcomes – such as improved flexibility, customer orientation, and delivery speed (Conboy and Caroll, 2019; Dikert et al., 2016) – or on challenges of scaled agile transformations on individual roles, such as their ability to cope (Mueller et al., 2025) or their job satisfaction (Venkatesh et al., 2020). However, while these studies have significantly advanced understanding of how scaled agile transformations unfold and what outcomes they create, they often treat roles as stable functional anchors rather than as evolving constructs and levers of change within unstable sociotechnical environments. Our findings shows that scaled agile transformation is not merely a shift in routines or governance but a profound process of realignment of sociotechnical systems that link people, technologies, and structures with their roles and which undergo a lengthy period of instability produced through deep structure changes, liminal dynamics and individual-level liminal outcomes that destabilize the work setting periodically and require ongoing renegotiation rather than a simple “refreezing” of a presumably stable structure.
While not our explicit focus, our research also draws attention to the stress that scaled agile transformations may evoke in different involved roles such as developers and project managers in scaled agile transformations (Benlian, 2022; Maruping and Matook, 2020; Mueller et al., 2025; Venkatesh et al., 2020). While prior work has shown how empowering leadership can buffer developer stress in complex projects (Windeler et al., 2017), architects have remain under-researched despite their strategic importance (Edison et al., 2021; Uludağ and Matthes, 2020). Our theoretical model offers a comprehensive framework to understand how architect roles evolve under scaled agile transformations, revealing both strategic contributions (e.g. role alignment and coordination) and vulnerabilities (role confusion and underskilling) that both introduce liminal destabilizing dynamics that likely create additional stress that is rooted in sociotechnical deep structure change processes (Lyytinen and Newman, 2008) rather than in behavioural or managerial cognition.
Implications for practice
While tentative and not statistically generalizable, the insights from our study also pinpoint two actionable insights for practitioners.
First, our study shows that the transition to cross-functional, agile teams with re-defined architect roles can create measurable costs in the form of role confusion and role underskilling where expectations for new competencies and responsibilities outpace architects’ preparedness and performance. These costs, if left unattended, risk exacerbating the instability in work setting that inevitably accompanies a scaled agile transformation process, which in might undermine scaled agile transformation progress. To counter this, organizations would benefit from initiating structured expectation-alignment formats early in the transformation process, such as role negotiation forums or similar workshop formats that bring together newly assigned or substantially altered roles within communities of practice where they can collectively clarify responsibilities, tasks, and mutual expectations to help navigate their evolving roles. Since these expectations are dynamic and shift with each iteration, these workshops should evolve into recurring “collaborative roadmap” events that allow participants to re-assess dependencies and negotiate trade-offs as the agile system matures.
Second, scaled agile transformations should directly address the expectable changes in role performance outcomes, namely the intensification of responsibilities, communication demands, and decision-making pace that architects experience during the transition. One practical measure could involve visualizing these interactions and decision processes through information flow diagrams, to help architects and other affected roles understand how individual events connect to broader coordination structures. Embedding senior architects as peer mentors and co-trainers further strengthens this approach, enabling the transfer of contextual knowledge and fostering sustainable support structures beyond initial training phases.
Limitations
Our study has several limitations. First, our data stems from a single case study of the scaled agile transformation of a European automotive manufacturer. While our setting provides rich empirical depth, its industry-specific context may limit the ability to generalize our findings. We attempted to mitigated this limitation by validating our theoretical model with external experts and by comparing emergent themes with secondary data providing insights into firms undergoing scaled agile transformations in other sectors (e.g. software, telecommunications, finance, and public sector), where similar patterns can be observed (Caroll et al., 2020; Dikert et al., 2016; Edison et al., 2021).
Second, our study covers the early to mid-stages of organizational transformation, within the timeframe where the changes were implemented and old structures disbanded but where a new, stable work setting had not yet been reached or formalized. While this focus allowed us to study the important “in-between” periods where old structures have dissolved but new ones are not yet established (Ibarra &and Obodaru, 2016; Söderlund and Borg, 2018) and where structural, material, social, and creative aspects of a long-term transformation are both salient and palpable, we cannot make statements about the long-term effects of the scaled agile transformation on the role of architects or the organization as a whole. We focused on the changes that manifest during the ambiguous, ambivalent and disoriented core phase of organizational change (Cummings et al., 2015) but further longitudinal research could trace how role and work setting interdependencies stabilize, evolve, and dissolve over time. Understanding the temporal dynamics of role reconfiguration would clarify whether new equilibria emerge or whether continuous technological evolution keeps roles in flux.
Third, while our chosen theoretical lenses (Biddle, 1986; Lyytinen and Newman, 2008) together offer a reasonably holistic lens for examining organizational change, alternative frameworks such as an institutional perspective (Hinings et al., 2018) or theories of identity rather than roles (Carter et al., 2020; Stryker and Burke, 2000) could have yielded different interpretations. However, we performed member check-ins (Schwandt et al., 2007) to test the plausibility and corroboration of our conceptualization with expert practitioners to lend credibility and corroboration to our interpretations.
Conclusion
We studied how IT architect roles evolve during the liminal stage of a scaled agile transformation. Through our analysis of the scaled agile transformation at CarCo, we show how deep structure changes create a cascading process of liminal role interdependency changes that creates new liminal role performance outcomes that destabilize the alignment between role expectations and performances within the evolving sociotechnical work setting in which IT architects operate. By theorizing these multi-level and temporal dynamics, our study provides a more nuanced understanding of how architect roles are re-configured in early-to-mid transformation stages of scaled agile transformations.
Supplemental material
Supplemental Material - Deep structure changes and the evolution of the IT architect role during scaled agile transformations
Supplemental Material for Deep structure changes and the evolution of the IT architect role during scaled agile transformations by Thomas Mayer and Jan Recker in Journal of Information Technology.
Footnotes
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article. The first author had a paid work relationship in a role unrelated to this study with CarCo at the time of the study.
Supplemental material
Supplemental material for this article is available online.
Notes
Author biographies
References
Supplementary Material
Please find the following supplemental material available below.
For Open Access articles published under a Creative Commons License, all supplemental material carries the same license as the article it is associated with.
For non-Open Access articles published, all supplemental material carries a non-exclusive license, and permission requests for re-use of supplemental material or any part of supplemental material shall be sent directly to the copyright owner as specified in the copyright notice associated with the article.
