1 Teams

For an impression of the continuous actuality of teams/autonomous teams, see, e.g., Trist and Bamforth 1951, Herbst 1962, Hackman and Oldham 1980, Womack, Jones and Roos 1990, Karasek 1998, Lee and Edmondsson 2017, or consult journals such as “Team Performance Management “(https://www.emerald.com/insight/publication/issn/1352-7592).

The idea of “teams” and the idea of “autonomy” challenge the hierarchy concept. Obviously, the idea of autonomy presupposes that organizational judgment and decision-making must be somewhat distributed, and not entirely at the top. The team concept in itself is also a break with hierarchy, since the direct line of control through managers and supervisors comes to a halt at the team door. From there onwards, to some degree, it will be the team, not individual-focused supervisors, who take responsibility for planning, organizing, and carrying out the tasks.

At its start, organization theory held no space for teams. Organizations were conceived as consisting of leaders, structures for instruction and coordination, and individuals. The “taken-for granted” classical or typical outlook of the rationally designed organization was always the hierarchy, with its structures, tasks, division of labor and supervision, prescribed by Weber (1978), Fayol (1949) and Taylor (1911). Without the hierarchical features, how can there be organization?

1.1 Autonomous teams

Team-like features such as individuals’ need to belong to a group, work performance’s reliance on social issues and social coherence among coworkers were observed and brought into the theory of organization and management by the Hawthorne studies (Mayo 2003/1933) and the so-called “human relations” school that developed afterwards (Maslow 1954, Hackman and Oldham 1980), but the idea of developing work organizations based on teams was developed by the creators of the sociotechnical theory (Trist and Bamforth 1951; Herbst 1976; Trist 1981).Footnote 2 A core aspect of this theory was the concept of (semi)-autonomous teams, or initially, “the composite work group” (Herbst 1962). These teams/groups were expected to be managed through controlling the input and output, while the internal activity was the responsibility of team members. The internal activity was a relatively whole task. The group members typically had some discretion over decisions about work organization, methods and schedules. A major argument was that organizing work in groups allowed space for local discretion, learning and development through sharing responsibility for work, instead of fragmenting and assigning it to individuals. Thus, team organization was assumed to increase the quality of work by increasing motivation and work satisfaction and contribute to better organizational performance. Work itself was intended to create the necessary team coherence. This is well captured in the team design concept “responsible autonomy,” defined as:

  • “[Team’s] acceptance of responsibility for an entire cycle of operations

  • Recognition of the interdependence of one man or group on another for effective progress of the cycle

  • Self-regulation by the whole team and its constituent groups “(Trist et al. 2013:21)

Nowadays, especially in software development, autonomous teams is a common term. Autonomous teams are described as teams given freedom by management (Takeuchi and Nonaka 1986) and composed of people with a variety of skills to effectively tackle the variety in their environment (Morgan 2006). Guzzo and Dickson (1996) describe an autonomous team as “employees that typically perform highly related or interdependent jobs, who are identified and identifiable as a social unit in an organization, and who are given significant authority and responsibility for many aspects of their work, such as planning, scheduling and assigning tasks to members, and making decisions with economic consequence.”

Although organizational theory was not able to “see” team organization for many decades, it was probably there. Now, team organization is a ubiquitous recipe. In today’s organizations, teams can be both temporary and permanent elements in an organization. Some teams are specialized by job function, while others are more interdisciplinary, perhaps with a focus on a specific task. The theory of teams first addressed mining and industrial production but has since been used in relation to service provision and in knowledge-work organizations. Team organization is also used at levels in an organization other than the purely operational ones, such as management teams.

1.2 Autonomous teams of knowledge workers

In contrast to routine work such as classic manufacturing, where the conversion processes are linear, sequential and reasonably predetermined, the non-routine work systems of knowledge workers involve a much higher degree of ambiguity and nonlinearity in the conversion processes (Pava 1983; Claussen et al. 2019). Inputs and outputs vary, the workflow is not unidirectional and transformations are difficult to specify.

In contrast with the autonomous team model of routine manufacturing, the team model of knowledge work highlights that members are too specialized to replace one another entirely and too individualized to have an interest in it. However, team development also takes effort, training and time for teams of knowledge workers. The prevailing theories agree that autonomous teams do not appear and start functioning “just like that.” They need enabling structures, direction, support, coaching and a certain duration (Hackman 1989, 2002). Members have to know who is on the team and who is not. According to Van Amelsvoort and Benders (1996), it takes years to develop a team with the ability to work together without managers, solving conflicts between team members and producing consensual decision-making.

The concept of “agile teams,” well known from software development, also presupposes a certain level of autonomy for work teams. To a certain degree, the work process itself demands it when solving complex software related problems: “Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection” (Schwaber and Sutherland 2020:4Footnote 3). According to Stray et al. (2018), the following are important barriers to agile (autonomous) team performance in software development:

  • Not having clear and common goals, creating ambiguity about direction.

  • Lack of trust within the team and/or between the team and managers.

  • (Too many) dependencies on others: manifold needs for agreements, synchronizations and joint deliverables with too many stakeholders, all requiring constant alignment and coordination.

  • Lack of organizational support.

  • Norm diversity: people not subscribing to the same rules and values about work (Stray et al. 2018:3).

In knowledge work, autonomous teams cannot be created just by tearing down organizational hierarchies or instituting one-person-one-vote decision-making processes. Hackman (1989, 2002), van Amelsvoort and Benders (1996) and others have discussed recipes for team development that require effort, time and training. The question is whether such resources are available to typical agile software development teams. Learned from the empirical field, agile teams are rarely “fixed teams” but rather temporary, volatile and part time:

  • People come and go: the crew of an autonomous agile team is not constant over time.

  • Individual members have less stable and permanent employment relations—they move around. Quite a few team members may be “temps”: in it for a while (Garsten 1999).

  • Agile teams often span company borders, with members belonging to different companies and not necessarily located in the same space.

  • Team members are part-time members who also work in other positions, perhaps in other teams; frequently, members of agile teams have dual assignments or more. They often are not 100% allocated to one team but spread their work efforts across several setups. Hence, they have mixed and varying obligations and commitments.

All this implies that an autonomous team’s social fabric in an agile setting is of a loosely interwoven kind, different from that of the classical team recipes, such as that suggested by Hackman (1989, 2002).

2 Autonomy

The previous discussion of the role of teams and teams in organizations could hardly be done without getting into the concept of autonomy, precisely because it is difficult, if not impossible, to imagine a team organization that in no sense implies autonomy. It is nevertheless necessary to emphasize the concept of autonomy itself, both because in so many contexts it is only assumed without being clear on its content, and because the scope of autonomy and its effects is so intimately connected with what kind of work processes it takes place within. Therefore, before we turn to digital transformation, which potentially reshapes work processes significantly, we need a clear understanding of the concept of autonomy in team and organizational contexts.

Autonomy is relational: the autonomy of one actor (A) will always meet the autonomy of other actors who are in a relationship with the actor (actors B and C). If A is granted increased autonomy, it could mean that B and C’s autonomy will be restricted. To the extent that a team is to act autonomously, the organization around it must relinquish some of its governing authority, and the team’s individuals must be submissive and conform to what the team as a unit chooses to do. The autonomy aspect produces a challenge when the horizon widens. The freedom of individual teams cannot be created simply by tearing down organizational hierarchies or ignoring individuals. To function autonomously, a team needs to develop and learn. However, putting engineers, designers and sales and business representatives together in cross-functional teams, encouraging them to cooperate and expecting them to work properly integrated does not necessarily mean they succeed. Possible barriers are communication problems caused by transdisciplinarity (Bernstein 2015; Ravn 2004), interaction problems caused by different working practices and goals (Mikalsen et al. 2018), social loafing (Liden et al. 2004) and group thinking (Janis 1972). Additionally, as we argued above, not all teams have the time, space and resources to develop as teams.

Autonomy can be understood as limited and instrumental, but also far-reaching and overarching. In organization and management theory, understandings of autonomy seem to regard “influence on the task at hand” more than overall organizational strategy or governance. For instance, Hackman and Oldham (1980) state that “autonomy refers to control over conducting the task.” In original sociotechnical theories like the ones referred to above, the concept of autonomy was also used as similarly instrumental, enabling better organizational performance. However, autonomy at work was also seen as a cornerstone in societal theory, as Gustavsen paraphrased Emery’s key insight, “…the core significance of autonomy in work, its anchoring in democracy, and the need to see workplace development as an issue on the level of society….” (Gustavsen 2017:118). One way to examine autonomy is to relate it to participation. Abrahamsson (1977) used the concepts of “political participation” and “sociotechnical participation” to distinguish between overarching strategic influence and instrumental autonomy at work. Political participation means involvement in high-level goal setting and long-term planning (1977:186). Sociotechnical participation means “involvement in the organization’s production”—it is about implementing decisions made at a higher level. Such involvement will include changes in the production organization, mode of operation and various job enhancements. The autonomy concepts in the team literature relate to sociotechnical participation. Nevertheless, in empirical cases in organizations, the distinction is blurrier. Political/strategic and sociotechnical participation blend into each other. Understanding how autonomy works in organizations requires us to examine structures of sociotechnical participation around tasks and how they relate to overall decision-making.

3 Team contexts

A team’s work and autonomy are influenced by its environments. There is the corporate level: the organization(s) to which the teams belong that hold the management prerogative over the team. By its ways of structuring, among others, the organization directly affects team autonomy. There are also the wider institutional and cultural environments that affect teams indirectly.

3.1 The close environment: the host organization

Attention must be paid not just to the autonomous teams themselves, but also to the status and the developments in the organizational landscapes embedding them. Such contexts directly influence a team’s work and the quality of its performance (Doolen et al. 2003). Lee and Edmondson use the term “self-managing organizations” to denote organizations that seek to “radically decentralize authority in a formal and systematic way throughout the organization” (2017:50). In a team-based organization design, this means to design for team autonomy. How this is to be done will depend on what kind of work system it is.

Additionally, all teams must operate in the context of an environment. The type of environment for an autonomous team will vary a lot, and it may change over time. The environment will have a number of qualities and offer several types of relationships. Many of these relationships affect a team’s autonomy by producing dependencies between team and environment or disruptions in relation to the team’s internal processes. The immediate environment is typically a host organization, but this may come in many variations. The team is structurally coupled to its host organization through a setup of instructions, tasks, regulations, communication structures and other factors, but dependencies on and influences from the environment can go far beyond this. They can be about normative expectations of various kinds, epistemological assumptions or mechanisms of power, and the source of such is not limited to the host organization. The more variety and influence from the environment the team is exposed to, the more demanding it will be to maintain its autonomy.

3.2 The wider environment: culture and political economy

Both manufacturing and software teams have their respective industry features. Some teams may share traits across the globe, but they are also shaped by the situations surrounding them: not just the markets, products or technologies, but also culture and political economy.

Culture is about meaning: the values and the basic assumptions in society. People’s world view is “their picture of the way things, in sheer actuality are, their concept of nature, of self, of society” (Geertz 1957:421). According to Hofstede’s major studies of national cultures across the globe, these differences can be summarized according to six cultural dimensions, including “power distance,”Footnote 4 “uncertainty avoidance”Footnote 5 and “individualism”Footnote 6 (1984, 2010). Aside from the debates about inaccuracies and essentialism Hofstede has been criticized for (McSweeney 2002; Baskerville-Morley 2005), it is a language that establishes that there are cultural differences between people and places and that these differences affect how people make sense of the world and how they act.

We take political economy to denote the institutional setup of a country, state or region in terms of (market) economy, structure of political governance and the type of rule of law (Weingast and Wittman 2008). These differ; e.g., Hall and Soskice (2001) identify two distinct types of market economies – liberal, such as the US, the UK or Australia, and coordinated, such as Germany, Japan and the Nordic countries. These two types differ in several aspects regarding how the economy is politically/institutionally conditioned, which again shapes the room for an organization (and thus, for autonomous teams) to maneuver.

The wider environment, here illustrated by the concepts of culture and political economy, also affects teams’ ability to manage themselves. National cultures and institutional regulations of work differ across China, the US and Europe (Smite et al. 2021a, b). The opportunities and hindrances facing a team are also a product of leeway and degrees of freedom offered by cultural norms and institutional regulations.

4 Protecting a team against disturbance

Various measures have been tried to shield teams’ internal work processes so that they do not constantly alternate between performing their actual work and dealing with various forms of external disturbances. A team needs to control the disturbances it is exposed to. In principle, this can be done in two ways, as de Sitter has shown (in Achterbergh and Vriens 2010): by decreasing the level and number of disturbances or by increasing the ability to cope with them. The latter factor is the team’s ability for operational regulation (op.cit). The team’s performance of its primary work is weakened if its exposure to disturbance is too high and operational regulation ability too low. Ability for operational regulation is a sum of resources such as competence, authority, and ability to make judgments and budget time. Any organizational structure requires that the operational regulation is in accordance with the primary processes and the level of disturbance. In autonomous teams, the potential for regulation must be sufficient where and when it is needed. However, equally important are measures taken to decrease the need for teams to handle dependencies and disturbances—in de Sitter’s terms, to “reduce disturbance probabilities by a reduction of impending variety” (de Sitter et al. 1997:509). Various measures have been introduced to reduce the negative effects on a team’s workflow that can be caused by outside interference. In the following, we will refer to such measures as various forms of buffers.

4.1 Safeguarding team autonomy: the buffer

Autonomous teams need to be protected from disturbances. If all kinds of re-instructions, changes in customers’ specifications, software updates and project sequence changes are imposed on teams on a level beyond the team’s regulation ability, then team autonomy ceases to be a productive design. This insight was developed in the early days of team organization and is well reflected, for instance, in Cherns’ “principles of sociotechnical design” (1976, 1987), such as “minimal critical specification of the work” ascribed to the team, variance control by the team (not external to it) and sufficient power and authority to maintain control of the work. However, teams also need boundaries, and there must be restrictions on what types of interference from the outside are allowed, such as conflicting views by external stakeholders, reallocation of resources and other changes that go across the team’s authority. The tasks that can be defined as belonging to an area spanned by a boundary should be the responsibility of the team in charge within that boundary.

A condition that is easily overlooked in connection with disruptions to a work process in an autonomous team has to do with timing. When something happens is, of course, crucial. If the team is disturbed all the time or at unfavorable times, it is detrimental to the flow and progress of the work. Having the opportunity to time-control the environment’s interactions with the team is an important autonomy factor.

Summing up, the realization of autonomous teams is conditional on them having a certain “protection” against turbulence from the outside. We call this the team buffer and offer the following definition:

“Team buffer” refers to structures, procedures, methods, processes, technologies and time management measures that are implemented in connection with the team’s work processes and used as a protective barrier against disruptive fluctuations.

In production organizations, buffer inventories are intermediate stores positioned before and/or after an operational unit, used to ensure that production in that unit can proceed without interruption. This form of buffering is material and visible and makes it easy to understand how buffering protects the inner workflow of a unit from disturbances. However, in studying various setups of autonomous teams across time and types of work (such as software development and similar types of knowledge work), one can also identify other kinds of buffers that allow for a safe zone and thus enable the performance of autonomous teams. Next, we present different buffers that have played and are still playing important roles in relation to teams in different contexts.

4.2 Type #1: Material inventory buffer

In the early days of team organization, for example, in mining and manufacturing, team tasks were about manual work, such as “longwall” or “shortwall” mining in the UK (Trist and Bamforth 1951) or car assembly in Sweden (Sandberg 1995). In both cases, teams organized work themselves as they wished, as long as the overall tasks were completed. In manual production, there was a significant flow of material compounds, both as input (rock in the mining case, auto parts in the car plant case) and as output (coal loaded on wagons, fully or partially assembled cars). These flows crossed the team boundary. If the team itself did not have good control of the boundary conditions, then the autonomy in its internal processes was disturbed—for example, if they were forced to accept a strong input before they are ready to receive it, or if there were a screaming demand for the team’s output pace that may have forced them to shift their internal production plans. In the cases mentioned, boundary control was established with the aid of buffer inventories. Once the mining or car team had finished a workload, it was put on the team’s output inventory. In this way, the buffer inventory created slack in the relationship between one team and the team upstream of it (the team next in the sequence).

4.3 Type #2: Role and guideline buffer

In the early days of agile software development, the most adopted method was Scrum (Dybå and Dingsøyr 2008), which focuses on agile project management. In 2021, Scrum is still the most popular agile approach. The name “Scrum” was inspired by an article characterizing new product development teams in Japan by Takeuchi and Nonaka (1986), in which “self- organizing project teams” was one of six key characteristics. Rising and Janoff (2000) describe Scrum as a development process for small teams, which includes a series of short development phases or iterations (“sprints”). The team is given significant authority and responsibility for planning, scheduling, assigning tasks to members and making decisions: “The team is accorded full authority to do whatever it decides is necessary to achieve the goal” (Schwaber 2001). During the sprint (usually 2–4 weeks) the Scrum guidelines describe that no one is allowed to disturb the team, and interactions with the outside only happen when there is a need to clarify issues related to the work and the team’s tasks.

Before the sprint, a joint planning session is conducted during which the team and customer representative (also known as the product owner) identify the product backlog (what is to be completed during the sprint). The purpose is to make sure the team and customer agree on what is most important, and that the team has enough information to work independently during the following sprint. If there is a need for larger changes in the backlog during a sprint (e.g., by a stakeholder or customer), the sprint is to be stopped and replanned.

In addition to controlling when the team is allowed be disturbed through guidelines, a dedicated role (the Scrum master) has the task of limiting external disturbance. The Scrum master is to protect the team from external requests during the sprint and remove impediments that hinder the team from doing the work.

4.4 Type #3: Architectural and process buffer

Limiting disturbances via guidelines and a dedicated role (e.g., the Scrum master) help protect a single independent team. New challenges arise when agile methods are used in a large-scale context. The reason for why it is more challenging to maintain the buffer when scaling is that teams in large-scale projects need to reach agreement on many decisions with external experts, managers, stakeholders and other teams (Moe et al. 2019). Further, quality concerns and the need for frequent releases require agile teams in large-scale projects to be aligned with the rest of the teams and the organization (Moe et al 2016). A team breakdown in terms of quality, functionality or timeliness will immediately affect other teams. Therefore there is a need to balancing organizational control and team autonomy (Moe et al 2021). However, the need for aligning the work and coordinating externally increases the frequency of interactions, which is likely to cause a disturbance (Stray et al. 2022). Working by sprints and making sure all teams have the same rhythm (starting and stopping at the same time) helps maintain a buffer, but since teams are dependent on each other (i.e., need other teams to do work for them or help them), such mechanisms are not enough. Another form of buffer is needed in such situations, and it is created using software architecture criteria and procedures for when and how different teams can intervene in each other’s work processes.

One solution to maintain the buffer is creating a technical interface between teams and letting teams have control over their own code and services. That means if a team needs to access a service from another team, the service is accessed through a defined interface. When a team changes its software code, the change does not have any effect on other teams as long as the interface is the same. This strategy is often named API-centric architecture. The term API is an acronym for “Application Programming Interface”.

Even though relying on defined APIs reduces the need for disturbing or interrupting another team, in large complex systems with many dependencies, teams still need other teams to support them to reduce waiting time. If a team needs to wait to sprint (2–3 weeks) for every change done by others, then the system becomes very slow. To support a team requesting another team to do something for them without disturbing other teams much, they can create a so-called pull request (PR) (Stray et al. 2021). In the PR process, a contributor in one team creates a PR (to/for another team) after making code changes (in the domain of the other team), and then a reviewer in the team responsible for the code inspects the suggested changes to see whether they can be merged into the project. PRs are handled by a tool, and the reviewer decides when they want to review the request. In practice, teams regularly allocate time for such work that fits with their own rhythm. If needed, the reviewer interacts with the contributor and others in discussion threads associated with the PR (Maddila et al. 2020). The PR approach does not necessarily reduce the number of disturbances, but enables a team to control when they happen.

5 Digital transformation

In the previous section, buffer mechanisms for manufacturing teams, agile teams and large-scale projects and programs were described. The question is, then, how are buffers maintained in digital transformations, which is an even more complex context?

Driven by the necessity to maintain competitive advantage, organizations face the need to enable their businesses digitally and increase organizational flexibility (Moe and Mikalsen 2020). When organizations use digital technologies, such as cloud computing, the Internet of Things and platforms to improve business outcomes, it is often referred to as digital transformation (Vial 2019).

An example of a digital transformation took place at Netflix, where a digital content platform allowed the company to transition from being a provider of rental movies to a streaming service, and later to a company that also produces content. This example illustrates that a digital transformation implies a change in a firm’s product strategy, revenue logic, distribution model (channels that a firm uses for marketing and selling its products to end users) and how the system will be installed and implemented. For such complex transformations to succeed, a company needs to be able to sense these changes and respond appropriately.

5.1 Digital transformation defined

Digital transformation is defined as “a process where digital technologies create disruptions triggering strategic responses from organizations that seek to alter their value creation paths while managing the structural changes and organizational barriers that affect the positive and negative outcomes of this process” (Vial 2019:118). Contemporary processes of digital transformation go deep and potentially disrupt everything on the job or individual, organizational, inter-organizational/ecosystem and societal levels. The challenges are not the same on the various levels; neither are the remedies or coping mechanisms, but all levels must be addressed, studied, analyzed and understood if we are to develop new knowledge that allows us to deal with digital transformation—even at the level of disruption—for the benefit of people, organizations, the economy and society.

In digital transformation, digital technology is central in redefining companies’ value propositions, which causes the emergence of a new organizational identity. Digitalization, in contrast, involves the use of digital technology to support an existing value proposition, implying that the existing identity of an organization is reinforced (Wessel et al. 2021). Therefore, in digital transformation, agile methods are more strategically significant and need to be adapted to fit more complex organizational environments (Khan et al. 2016). This complexity comes from increased interfacing between complementary roles on development teams, between agile teams and between agile teams and other organizational units (Dikert et al. 2016). Further, rapidly changing markets and technology developments drive organizations to adopt agile ways of working in and outside software development units (Mikalsen et al. 2018). Such transformations imply that agile methods are also applied to organizational units such as markets, sales and operations (Barroca et al. 2019).

5.2 Type #4: Transdisciplinarity buffer

None of the buffers for autonomous teams introduced so far seem to adequately meet the needs created by digital transformation, which of course exposes teams to other types of disruption. Digital transformation hits barriers such as hierarchical leadership (Chanias et al. 2019), poor alignment of organizational units (Sebastian et al. 2020), conflicts between existing and new business strategies (Yeow et al. 2018) and resistance from employees (Vial 2019). Such barriers and frictions cause interruptions, as development, operations and business teams constantly need to be involved in the complex alignment activities to succeed in the transformation. Guidelines, roles, processes and architecture are not enough to protect a team against disturbance.

Therefore, one particular requisite for organizational digital transformation is creating semi-independent, cross-functional teams with personnel from both business- and software- development and operations that use agile methods to improve the value of the digital products being developed (Vial 2019). The inner workflow of a unit is then protected from disturbances by extending the unit and making sure that a wider part of the organization is represented within it. Instead of the need to align between business units, the alignment process is handled within the team as key roles and team members with authority related to the transformation are represented in the team. The buffer is created by moving variance from outside to the inside of the team. Such autonomous teams with a high degree of diversity imply a significant increase in interdependencies between team members. This buffer is created by moving away from complex organizations with simple jobs to simple organizations with complex jobs (de Sitter et al. 1997).

A case study by Mikalsen et al. (2018) describes how such teams – consisting of business representatives from business development, IT developers, testers and user experience (UX) designers from IT development—achieve a continuous business planning process, development and maintenance.

6 This special issue

This special issue is intended to present research on the autonomy of teams in companies in digital transformation. We will now describe the five research papers included in the issue and how they relate to the concept of buffers.

First, Abdallah and Salameh’s (this volume) article “An architecture governance approach for Agile development by tailoring the Spotify model,” covers a longitudinal case study over 21 months that included 225 observed ceremonies and 14 semi-structured interviews. Findings indicate that the proper software architecture enables several teams to work together to release a product without disturbing each other (architectural buffer). Such an architecture can be formed top–down or bottom-up. The authors found that their case, a multinational fintech organization, had challenges in aligning architectural decisions across autonomous teams. Therefore, they introduced an architectural governance approach through an intervention-embedded case study. The approach gave benefits such as a decentralized architectural decision-making process and improved architectural knowledge sharing among the teams, which positively affected the team autonomy.

Second, Wulff and Finnestrand’s article (this volume), “It’s like taking a ball for a walk: On boundary work in software development,” explains how the absence of collaborative boundary work can lead to an individualized zone in software teams. Drawing on data collected through action research methods, the paper investigates teamwork in software development in a medium-sized Norwegian IT consultancy company. Even though teams might have different types of buffers (e.g., guidelines, roles, process and architectural buffers), the teams in the study experienced challenges when dealing with expectations of fixed project boundaries (missing buffer type 1: material) in processes that often required flexibility to meet clients’ actual needs. Wulff and Finnestrand explore the importance of the level of autonomy where teams have to adjust boundaries as a project is running, but also how collaborative boundary work within teams allows for effective alignment of ambitions and goals. In the absence of such alignment processes, team members more often operate in what the authors call an individualized zone of boundary work. Working largely on the basis of assumptions of what is needed, such individualization not only increases the probability of misunderstandings, but also places a larger burden of responsibility on the individual developer.

Third, in so-called BizDevOps teams (a use of the type #4 transdisciplinarity buffer), there are many different roles present, and such teams with a high degree of diversity imply a significant increase in interdependencies between team members. Wong and van Gils (this volume), in their study, “Initiated and received task interdependence and distributed team performance: the mediating roles of different forms of role clarity,” surveyed 191 participants working in distributed agile teams within three companies in Norway. The authors show that high initiated task interdependence is associated with higher role clarity for others, while received task interdependence is associated with higher role clarity for oneself, and that both subsequently result in higher team performance in distributed agile teams. Their study suggests that, while connecting team members, discussing initiated and received interdependence separately may promote clarity of the team members’ roles in different ways. Finding the right balance between these types of interdependence can help agile team members become clearer about their own roles and those of others on their team, ultimately leading to a better-performing distributed agile team. Many companies have announced work-from-anywhere policies (Smite et al. 2021a, b), allowing employees to choose how often they prefer to be in the office or at home, and increasing numbers of teams are working virtually and coordinating through digital tools; thus, research by Wong and van Gils plays an important role for those organizations working on a digital transformation.

Fourth, Hagen, Tolstad and Bygdås, in their article, “Magic through many minor measures: How introducing a flowline production mode in six steps enables journalist team autonomy in local news organizations,” studied digital transformation in a newspaper organization. The authors investigated how the organization aligned its production and publishing processes to readers’ online news consumption by introducing a flowline production mode to enable team autonomy. They found that the organization created new organizational structures and a transdisciplinarity buffer, and that the involvement of autonomous teams was vital to the digital transformation. The organization involved everyone in the change process, which created awareness of the enablers and barriers for change. The organization also used tools to motivate and enable change. The new organizational structures facilitated the team’s learning process to be integrated in the learning of the organization. The organization then transitioned from a controlled process to one in which employees in autonomous teams were given responsibility and ownership for their work. Further, they were allocated decision-making authority, allowing them to design their everyday work activities. All these steps and measures were found to facilitate the digital transformation.

Finally, in Thun, Bakås and Storholmen’s paper (this volume), “Development and implementation processes of digitalization in engineer-to-order manufacturing: enablers and barriers,” they analyze the development and implementation process of digital technology in a manufacturing organization through a sociotechnical systems design lens. Through semi-structured interviews, the authors identified four enablers of the digitalization processes: shared trust, shared visual understanding, shared user perspective and shared learning. Likewise, they identified four barriers to effective digitization: lack of trust in the systems, lack of understanding of benefits, unclear perspectives on the economics and difficulties with managing scope. Their findings and takeaways emphasize the importance of stakeholders’ understanding and management of the key enablers and barriers for a successful digitalization process in manufacturing. The paper also demonstrates how identified organizational enablers can be helpful tools to address expected barriers to digitalization. This work is not an explicit study of teams, but of an organization containing a whole set of manufacturing teams being made the subject of digitalization. It exemplifies the type 4 buffer well in its identification of factors (trust, shared perception, perspective and learning) that enable the organization and its teams to work transdisciplinary, and not the least by exploiting transdisciplinarity to bring resilience and perseverance into the digitalization process.

The last article is also suitable to bring together the themes of this special issue: firstly, by addressing how all kinds of work processes will have to be transformed through digitalization, permeating also previously un-digitized organizational space, and secondly, by bringing the topic of digital transformation back to the starting point of autonomous teams in the history of organization theory: manual, industrial work. It helps us to remember that digital transformation is of concern for far more than the purely digital spaces.