1 Introduction

Gieryn (1983) coined the term boundary work to describe the protection of professional autonomy. In his description of boundary work, Gieryn argued that scientists construct a boundary between the production of scientific knowledge and the way in which non-scientists consume that knowledge, with the goal of having immunity from blame for the way non-scientists use the knowledge (Gieryn 1983). The professionals protect their right to determine and perform the work as they see fit. This means that each individual professional will protect their individual professional autonomy. When each individual professional protects their autonomy, regardless of the context, there may be an overuse of individual professional autonomy to the detriment of team autonomy.

Team autonomy has been defined as the autonomy to monitor and manage work processes (self-managing units), designing the performing unit and its context (self-designing units), or setting overall direction (self-governing units) (Hackman 1986). That the team is allowed to set the overall direction is rare when the team is part of an organization. Therefore, a distinction between the overall direction (outcome) and the result of the teamwork (output) is made to clarify how much autonomy the team may be given (Gemünden 2015). This means that the common purpose of the team is defined as the outcome, and the performance goals defined by the team and for which they hold themselves accountable are the output (Katzenbach and Smith 1993). The team collaborate to define the goals and their approach, and they work interdependently to achieve them.

This collaboration can be studied through the lens of boundary work, because later studies on boundary work have expanded the term to cover the areas of collaborative boundary work, such as that between doctors and nurses in an intensive care unit (ICU) (Liberati 2017), and of configurational boundary work, such as in creating a joint organization for non-invasive surgery to build a bridge and collaboration between radiologists and surgeons (Mørk et al. 2012). We draw on Langley et al.’s (2019) definition of boundary work as the “purposeful, individual and collective effort to influence the social, symbolic, material and temporal boundaries, demarcations and distinctions affecting groups, occupations and organisations”. Langley et al. (2019) categorized research on boundary work according to three categories: competitive, collaborative, and configurational. Competitive boundaries are drawn between and around one person or a group of people, collaborative boundary work is enacted to reduce the impact of boundaries, while configurational boundary work is a reconfiguration of the boundaries, usually to support collaborative boundary work.

Instead of seeing individual autonomy as a personality trait (Moe et al. 2019), we propose taking the perspective that the use of individual autonomy by professionals is expected and is the natural way of working. By seeing individual autonomy as the natural thing to do, we can study why individual autonomy is not downplayed when the situation calls for it. Therefore, boundary work is useful as a lens through which to study the use and overuse of individual autonomy to the detriment of team autonomy. The use of individual autonomy is the best way of working when the complexity is low, and the problem is technically simple (Boonstra and Reezigt 2019). When the complexity is higher and/or the predictability is low, the use of individual autonomy can become a problem because the situation calls for collaboration. Boonstra and Reezigt (2019) described four project types and ways of working based on the predictability and complexity of the content and the internal and external context. When predictability is high, and the complexity is low, plan-driven working is possible. When predictability and complexity are both low, short-term sprints and longer-term flexibility are useful. When complexity and predictability are high, extensive stakeholder analyses can be performed. When the complexity is high and the predictability is low, scenarios and prototypes are developed. We can see that a low level of predictability increases the need for higher team autonomy to enable adaptation to the changes in context and/or content.

Software development projects can be seen as a special kind of project with lower predictability because the content and context are less predictable than what is possible in analogue projects. The content can vary more, because software development does not depend on the laws of nature (Dybå and Dingsøyr 2015), such as physical objects or materials. Moreover, the need for standardization of the product is lessened, which means that each developer might create their own way of writing the code (as long as it is accepted in the coding language). Repetition is a way of increasing predictability in projects (Davies and Brady 2000), but in software development repetition often uses copy-and-paste approaches, whereas in construction, for instance, houses may look exactly the same, but each individual house needs to be built. The internal context can vary because of the team, in that it is a loosely coupled production system (Langfred 2000), and because interdisciplinary teams often require leaders, domain experts, technology experts, test experts, design experts, and so on to collaborate to create useful solutions (Edmondson and Nembhard 2009). The external context contributes to low predictability in several ways: the internet has caused a major increase in speed in the development of new software frameworks, which means that there is a heightened need for learning new technology continuously (Nagaraj 2019) and for involving the team in external environments to innovate (Lyytinen et al. 2016) and to create output that leads to an outcome that is a good fit for both the customer and the company’s business model (Teece and Linden 2017).

Given all the above, software development projects are rarely, if ever, highly predictable and low in complexity. Due to this, the team must collaborate to utilize and develop their team autonomy, but in many cases, there is a problem with an overuse of individual autonomy (Moe et al. 2009). To study the area between the use of individual autonomy and team autonomy, our research investigates if the team members have an intention to collaborate and if this intention is enacted in collaboration where the team members work together to find the solution to their challenges. These intentions can be seen via the lens of boundary work. We find that this lens contributes to a richer understanding of influences on team autonomy.

The research question is, therefore: How does choice of boundary work in software development teams influence the team autonomy?

To answer this question, we make use of the boundary work categories of Langley et al. (2019). Through an action research project, we pinpoint the low predictability of software development and engage experienced consultants working in teams to reflect on how they do boundary work. The contribution of this paper is its demonstration of how the perspective of collaborative boundary work can help us see intentions to collaborate and intentions not to, which widens the view on collaboration.

2 Theory

In this section, we explain the concept of boundary work, after which we present different perspectives on team autonomy and how these are connected to software development.

2.1 Boundary work

The concept of boundary work is a way of seeing the boundaries between people as they are enacted, and change based on the actions people take (Langley et al. 2019). This is different both from the concept of boundary spanning (Ancona and Caldwell 1992), according to which people span a boundary, for example, to get more resources for a team where the boundary is seen as fixed, and from the concept of boundary objects, where objects such as maps are used to communicate between people from different disciplines (Star and Griesemer 1989).

Langley et al. (2019) conducted a thorough review of the extant literature and categorized boundary work as competitive, collaborative, or configurational. Competitive boundary work distinguishes between “them” and “us”, such as between engineers and technicians on who decides what to produce (Bechky 2003), and it involves boundaries being drawn to create an advantage over others. The term competitive illustrates the self-oriented nature of such boundary work. It can be initiated for different reasons, which include the existence of external triggers such as new technologies, direct challenges, or regulatory changes (Langley et al. 2019), and it can be used to acquire resources, and to reproduce power and social position. Competitive boundary work is divided into three types: defending, contesting, and creating boundaries. Defending a boundary is boundary work that keeps others out of already defined boundaries, contesting means engaging in competition to attain a certain position or power, and creating involves defining a new boundary.

Collaborative boundary work involves blurring boundaries to achieve something together, such as when nurses and doctors diagnose a patient together in an ICU (Liberati 2017). Collaborative boundary work happens when the boundaries are made permeable, allowing individuals to learn from each other. The boundaries can be made permeable by downplaying them, by embodying, or by negotiation (Langley et al. 2019). Kellogg et al. (2006) described the collaborative activities of negotiations as trading zones. They demonstrated how actors in post-bureaucratic conditions coordinate across boundaries when the boundaries are fluid, emergent, and ambiguous, as well as how the employees typically work on several projects in parallel, increasing the need for information from all the projects they are working on (Kellogg et al. 2006). Their research showed how the use of an extranet, calendars, and other coordination mechanisms improve the projects. An example of the possibilities in embodying formal roles of boundary spanning in technology production has been studied in a project for design and implementation of an organization’s intranet (Levina and Vaast 2005). The authors showed that officially appointed boundary spanners may not always engage in actual boundary spanning, and that some agents who are not appointed may in practice work as boundary spanners. Embodiment can lead to skilful coping and has a social dimension in doing things together (Coeckelbergh 2019).

Downplaying is when, for instance, boundaries are ignored on purpose, or assigned to the background (Langley et al. 2019). When solving complex problems in cross-functional teams, practices such as cocreating a scaffold to integrate the different knowledge areas can be conducted, with the result that boundaries are transcended rather than traversed (Majchrzak et al. 2012). The behavior we expect to see in the teams is that of setting temporary boundaries (Flood 2010) and seeking to create alignment through, for example, provisional settlement (Girard and Stark 2002). When the team together defines ambitions for the next step that it will take, thereby creating alignment, a provisional settlement can be reached (Girard and Stark 2002). It is provisional in that the involved parties must agree that the settlement is for a defined period rather than for the whole project. By attending to each other in the improvisation of daily work, the boundaries can also be downplayed (Torrance and Schumann 2019).

Configurational boundary work involves organizing or rearranging the sets of boundaries to influence others’ behavior; examples are the creation of a boundary organization to support collaboration between two fields of interest, such as radiologists and surgeons (Mørk et al. 2012), or the creation of a boundary organization for technology transfer between research and commercial use (Guston 1999). Configurational boundary work is divided into three subcategories: arranging boundaries, buffering boundaries, and coalescing boundaries. In this context, arranging means to organize in a new way, such as by creating a temporary team to work together. Buffering can be accomplished by creating boundaries that allow those involved to be a part of something new while still being allowed to stay within their preferred boundaries. Coalescing involves performing actions to break down the boundaries, such as those between two functional units.

To sum up, competitive and collaborative boundary work are two ways of acting on existing boundaries, while configurational boundary work changes where the boundaries are drawn. Configurational boundary work is often done by someone external to the group, for example, to facilitate collaboration or to separate people who are in conflict (Langley et al. 2019). See Fig. 1.

Fig. 1
figure 1

The three categories of boundary work

Full size image

To study the actors’ intentions, these three “C”s constitute a simple yet communicative framework. They cover working individually and working together, and as such they fit with the problem studied in this paper.

2.2 Team autonomy

Team autonomy can be seen from an organizational perspective, from a team perspective, and from an individual perspective. When studying team autonomy from an organizational perspective, team autonomy can be defined as decoupling from the rest of the organization (Clark and Wheelwright 1992). This type of autonomous team is better at handling technological novelty and radical innovation than are teams with more connection to the operational organization (Patanakul et al. 2012). However, managers may intervene and withdraw team autonomy when a problem occurs, or because managers are experiencing a loss of authority (Gerwin and Moffat 1997).

From the team perspective, we can study what the team is allowed to do. Langfred (2005) used a level of autonomy relating to how to carry out tasks, according to which the tasks to do were defined outside the team. Chen et al. (2015) widened the definition to include the authority and freedom to take decisions necessary to fulfil the team’s mission. To increase innovation, it is an advantage that the mission is defined as an outcome—the effect the teamwork should have—rather than as an output—what the team should create (Gemünden 2015).

The third perspective, which is that of the individual member level, studies how team performance suffers when individual autonomy is too high, such as when there is high task interdependence (Langfred 2005), even though the people using individual autonomy believe it to be the most efficient way of working (Moe et al. 2009). However, team autonomy is not necessarily about giving up individual autonomy. Jønsson and Jeppesen (2013) found that a higher degree of experienced team autonomy is connected to a higher degree of individual experienced autonomy, especially in loosely coupled production systems like software development (Langfred 2000). Moreover, equality in the use of individual autonomy in the team supports innovation (Hoegl and Parboteeah 2006), while collaboration helps the team handle the complexity and uncertainty of the situation (Sharp and Robinson 2010).

In new product development, the levels of individual versus team autonomy cannot be determined at the outset (Gerwin and Moffat 1997), which puts the responsibility of understanding when to utilize what type of autonomy on the people involved. Choosing the right way of working is hard because, when conducting a project or developing a new product, some of the task has high predictability and some of it has low predictability (Boonstra and Reezigt 2019; Lenfle and Loch 2010). This implies that it is important for the involved parties to understand the level of predictability of particular tasks. However, humans have a tendency to see simple cause and effect connections that can be solved in a linear way rather than to see more complex non-linear systems (Norman and Stappers 2015). This means that despite the importance of working in accordance with the demands of the content and context, it is not what humans are best at. This may lead to less collaborative boundary work than needed in the actual project, and thereby an overuse of individual autonomy. The overuse of individual autonomy is a recurrent problem for transitioning to agile practices (Moe et al. 2009, 2019). The team will benefit from creating a situation where there is a possibility for all team members to influence the decisions taken in the team (Hoegl and Parboteeah 2006). To create opportunities for such decision-making, there should be some sort of collaborative boundary work present. For example, there should be a process for creating a provisional settlement (Girard and Stark 2002).

It has been argued that a higher complexity must be handled by a sufficient level of autonomy (Trist 1981; Trist and Bamforth 1951; Van Eijnatten and Van Der Zwaan 1998). The team understands the problem they are working to solve better than outsiders can understand it (Achterbergh and Vriens 2019). The levels of complexity and predictability are influenced by content, internal context, and external context (Boonstra and Reezigt 2019), and the tasks in a project or product development vary in their level of complexity and predictability (Lenfle and Loch 2010). This means that someone in the team must understand when to work in a certain way.

Team autonomy is important when the predictability is low, in both low complexity and high complexity settings. The low complexity way of working in software development is called agile. The agile movement has attempted to transform projects from the plan-driven project types with high predictability and low complexity in Boonstra and Reezigt (2019) project diagnosis model, to a way of working in a context with low predictability and low complexity. This is expressed in the agile manifesto that was published online under the title “Responding to change over following a plan” (Beck et al. 2001). In this way, agile software development adapts to the low predictability of the context and content by embracing change in requirements (Highsmith and Cockburn 2001). This is accomplished both through frequent revisions of the backlog (list of issues to address) and by the possibility of introducing new backlog issues during the project (Highsmith and Cockburn 2001). The flexibility of the backlog combined with frequent deliveries is shown to increase the success of a project (Jørgensen 2016). Agile teams are defined as self-organized teams in that they have the autonomy to decide the activities and to coordinate interdependence and problem solving to accomplish tasks (Moe et al. 2008). Team autonomy has been a key element of agile development, so much so that the term autonomous team is often now used instead of agile team (Dybå and Dingsøyr 2015). The transformation from plan-driven projects to agile projects has been difficult for some, with reasons for this difficulty being both outside the team, such as in a control-oriented management (Hoda and Noble 2017; Spiegler et al. 2019), and inside the team, such as in how the team works and in the overuse of individual autonomy (Moe et al. 2019).

When the complexity is high and predictability low, the work is conducted with the use of prototyping and probing (Boonstra and Reezigt 2019). In software development, inspired by lean start-up (Ries 2011), this is often called hypothesis-driven development (Khanna et al. 2018) and is a way of working that an increasing number of software teams are aspiring to adopt (Bland and Osterwalder 2019). Collaborative boundary work supports team autonomy, see Fig. 2.

Fig. 2
figure 2

Examples of autonomy and the processes of individual and collective boundary work

Full size image

In summary, the right amount of team autonomy is important for a team to innovate and to achieve a high team performance. Individual autonomy is also important, but it can become a problem if it is overused. When taking the perspective of boundary work, the individual professional autonomy is the default, so to get individuals to collaborate it is necessary that there is an understanding of why collaborating is necessary in the actual case. A way of making collaboration possible might involve understanding the level of predictability and complexity as well as the best way of working according to the setting. We will now consider how boundary work is performed in various software development teams, some of which are defined as projects and some as product teams.

3 Methodology

3.1 The setting

The setting is a Norwegian employee-owned IT consultancy with 160 employees. The company has offices in Bergen, Oslo, and Trondheim. The leader group consists of seven people: the CEO, the leaders of each local office, the leader of technology and sales, and the insider action researcher. The Oslo and Trondheim offices have five departments, each of which is led by a department manager, while there are two department managers in Bergen. The Trondheim and Oslo offices are approximately the same size, with about 70 employees each, while the Bergen office employs 21 people. The consultants consist of software developers and architects, test leaders, user experience experts, graphical designers, and team leaders/project managers. The organization model is most similar to an adhocracy where the leaders have little position power (Mintzberg 1979) and teams are assembled for new clients or products. In the salary model, consultancy work is valued, which ensures that senior personnel see a career path as a consultant. Some teams have worked for the same client for a long time, although with some changes in team members. Changes in a team might be initiated because of the needs of another team, to gather a new team, or because the consultants want to try something new.

In a software development team, the typical disciplines involved are software development, testing, user experience design, graphical design, and business development. The team might have a leader who is part-time or full-time. When the leader is full-time, they often contribute in one of the other disciplines as well; for instance, the team leader might also contribute to testing. Software developers might be full-stack developers, meaning that they can code everything from the database up to the user interface, or they might concentrate on the user interface (front-end development) or the logic and integration (back-end development). Testing can be divided into the roles of test manager and tester. The test manager designs the tests and works with the developers to build quality into the software, while the tester performs both functional tests and technical tests. Nowadays, the functional tests are often automatized, either by the technical tester or by developers.

In the design of the solution, it is important to create something that the user wants and can use with ease. The roles involved in the design are the user experience (UX) designer or UX architect, and the graphical designer or art director. The business developer is often a domain expert responsible for creating a profitable solution. Other domain experts can be part of the team to bridge the gap to users in the organization. When the solution is put into production, the role of operations handles the hardware. The role of automatizing software is often called DevOps to signify that it bridges development and operations. To be able to deliver frequently, it is important that the delivery process is automatized.

The clients are mostly organizations within the banking/finance sector and public sector. Typically, they are large organizations that need more capacity than they are able to employ themselves, or they are organizations that have outsourced IT development to consultancy teams. The main part of the work is done for clients, either as consultants participating in a customer team, or as a whole team with 1–2 representatives from the client. The team size can vary from 2 to 23 people, but normally the team consists of 4–8 team members. They can be located at the client offices or at the consultancy. The work consists of creating and maintaining mission-critical software, and the consultancy is renowned for its strength in creating secure applications. In addition, there is a focus on delivering solutions with a good user experience. The consultancy has a strategic initiative to provide more innovative solutions to its clients and, to this end, it has immersed itself in the literature on systemic thinking.

3.2 Research design

To study how a software development team conducts boundary work in high uncertainty settings, we chose an action research (AR) design due to its focus on increasing the systemic understanding of the people in an organization. AR is useful when the research question is directed towards studying the development of reflection among the involved parties and the resulting behavior. This can be done by initiating and studying a series of actions over time in a team or an organization (Coughlan and Coghlan 2002). AR is a research approach where both insiders and outsiders take action and create knowledge or theories about that action (Coghlan and Brannick 2014). The actions are usually performed in an iterative cycle based on gathering data that is being fed back to those concerned as a basis for further action (Coughlan and Coghlan 2002). Unlike a positivist framework where the idea is not to affect the research object, or an interpretative perspective where the influence is acknowledged but not sought after, the motivation for AR is to create change in the organization directed towards having a positive impact through partnership (Bradbury 2015; Finnestrand 2011).

The insider action researcher (Coghlan 2019; Greenwood and Levin 2007) in this study is a long-term employee of the organization, now employed as a Chief Process and Innovation Officer and PhD candidate to help the teams and consultants find better work processes, a role that Coughlan and Coghlan (2002) have described as a change agent. The position does not involve personnel responsibility, something that has been an important prerequisite to create a safe arena for open and critical reflection throughout the research period. To be an insider in the organization has its advantages because it enables a better pre-understanding of both explicit and tacit knowledge (Coghlan 2019), of the context and the common discourses in the field (Coghlan and Brannick 2014), and of the development of solutions that are a good fit for the organization (Williander and Styhre 2006). However, the working assumptions, research process, and interpretations of the findings have constantly been challenged in discussions with the co-author, who is an experienced action researcher and is an outsider to the organization. This collaboration has helped the insider action researcher to step back and reflect on the action (Coghlan and Brannick 2014).

The issue to be researched can originate in the business (Coughlan and Coghlan 2002), but, because it also has to be worthy of research, it can also originate in earlier research (McKay and Marshall 2001). The action researcher must be able to join the two. In this case, the steering group, consisting of the CEO, a project manager and both the insider and the outsider action researchers, acknowledged that the initial research question regarding boundaries in teamwork was one that the organization needed to work on, or what Bradbury (2015) called an objective for the AR project. The issues in the organization revolved around teamwork: how the team could be more innovative and how the team members could collaborate more. These questions were already defined as pressing issues in the organization prior to the AR project. The AR project created a momentum for the company to reflect on these questions, to identify and test new work forms that the AR prepared for the company, and to take ownership of the solutions (Schein 1990).

3.3 Data collection and analysis

The data gathering was performed in cycles that built on each other, and it involved both the insider action researcher and the participants from the organization (Coughlan and Coghlan 2002). In total, the three cycles lasted from April 2019 to June 2020. Throughout this process, the insider action researcher wrote a diary on what was done and what happened during the project (Zuber‐Skerritt and Fletcher 2007). The description of the cycles is based on the diary and documents from the meetings. The structure of the presentation of the three cycles follows the AR cycle as described by Coughlan and Coghlan (2002).

3.3.1 First cycle

In the first cycle, the data were gathered by the participants in the organization. The first step was to establish whether the work the teams did was plan-driven or subject to change. Data was gathered over a 1-month period. To initiate reflection on whether their work consisted of clearly defined work that was performed as intended or whether there were changes during the project, each consultant in the company was asked to register on a form all negotiations and suggestions for change they made in a 1-month period regarding team, time, money, process, output (task), feedback, outcome, and impact (transition). The list was an elaborated version of the logic model, in that input was divided into team, time, and money (Knowlton and Phillips 2013). This inquiry involved 11 consultants from 9 teams (out of 17) who handed in the completed forms. The responses were anonymized at the level of team member, but not for the team. These data showed clearly that changes were experienced in all elements but that not all teams experienced all types of change. The most common were changes to time, team, money, and output.

During the data-gathering period, the insider action researcher received comments and questions on the internal chat channel, both from people filling out the form and from people explaining why they could not fill it out. However, because the insider action researcher was present in the company on a daily basis, many participants chose to engage with these questions at the lunch table or by the coffee machine, thereby including the AR work in their daily conversations.

To build a dynamic capability for change into an organization, it is important to engage the people in the organization in reflections on action (Coghlan and Shani 2008). The data feedback was given in conversations with the involved teams. In addition, the middle managers were invited to reflect on the topic in a meeting halfway through the data gathering. Based on the discussion in this meeting, it became clear that the middle managers were unsure about how they could take this further. Towards the end of this data-gathering period, the middle managers, therefore, suggested that, to engage in dialogue with the team members, the insider action researchers could give a lecture on the research topic and useful literature. To involve the middle managers is important, because middle managers can have access to all the “hidden rooms” where informal conversations occur (Coghlan and Brannick 2014). It is also important to involve middle managers to ensure that they do not become the “missing link” of the work (Holmemo and Ingvaldsen 2016), because they are the people needed to ensure the organizational improvements are implemented and sustained (Huy 2002). Their participation is also useful for further developing their leadership qualities (Zuber‐Skerritt and Perry 2002).

As suggested by Coughlan and Coghlan (2002), the data analysis was to some extent carried out in collaboration with the participants, where each team and the middle managers were invited to interpret the empirical data together with the insider action researcher. The participants were particularly encouraged to reflect upon what changes in input meant for their work practice. The middle managers were also encouraged to initiate dialogue with employees about how they worked in their teams. The insights from these dialogues were reported back in a meeting with the researcher and the other middle managers. These discussions were followed up by the insider action researcher who presented theories on autonomy and task interdependencies based on, among others, Langfred (2005), to give the team leaders some theoretical tools or frameworks for further work.

3.3.2 Second cycle

In the second cycle, the findings and the subsequent reflections were presented by the team leaders and the insider action researcher to all the consultants in the company. Presentations to each of the ten departments, as well as one to the Bergen office, were carried out in department meetings over a period of 2 months. By choosing to do this in department meetings, our aim was to get to the theory in use rather than to the espoused theory (Argyris and Schon 1974), because the team leaders could build their stories on each other and because we believed they saw department meetings as safe environments.

First, the findings and the impact of the findings on the team’s required autonomy were presented, and then the participants reflected on their ways of working in the teams. The insider action researcher was actively involved in the reflections and took linear notes of the comments by writing down shortened statements and recording the most salient quotes and the full sentences as they were remembered at the time (Piolat et al. 2005). The middle managers followed up this work in their monthly dialogue with the individual consultants, and both individual and team actions were planned accordingly.

The insider action researcher had at this point been introduced to the concept of boundary work and found the three categories of boundary work presented by Langley et al. (2019) useful when categorizing the observation notes. The stories of how the consultants worked, or tried to work, seemed to fit well with the concept of boundary work, and the data were, therefore, categorized into the three main categories: competitive, collaborative, and configurational. The different quotes were coded and sorted under each of the three headings. This analysis process showed that most of the boundary work done by the teams could be categorized as either competitive or collaborative.

In the second coding phase, the quotes were coded into the different kinds of boundary work within the three subcategories of each category. When writing the first version of the chapter on findings and analysis, a text explaining each quote was written in connection with each quote. The next step was to bring the most explanatory quotes into the article. Quotes that were too similar in content were removed. The quotes were shared with all the involved parties, each of which was encouraged to give feedback regarding possible incorrect quotes. In addition, the quotes included in this article were presented in a one-to-one conversation with the people quoted, and they were approved by them. The final findings focusing on the presence of an individualized zone are a result of this analysis process.

3.3.3 Third cycle

In the third cycle, the sorted categories of types of boundary work among the consultants, and the final findings focusing on how consultants’ handling of boundary work create an individualized zone, were fed back to the participants in an internal newsletter and in an open internal meeting where everyone was invited to join in. Approximately, 20 consultants and middle managers participated. This was done over a period of 6 months.

In AR, the theory emerges through the data and the use of the data in practice (Eden and Huxham 1996). The advantage of the AR approach—as opposed to doing conventional research that relies on, for example, interviews—lies in the cyclical data gathering and evaluation in practice, which facilitate a deeper understanding of the issues and how they can be solved. The development in dynamic capability can be seen in the actions that have been taken by teams and middle managers after the AR project, as some teams have been helped by middle managers to increase the collaborative boundary work. For instance, more teams now define team goals that are revised periodically using a framework known as Objectives and Key Results (OKR) (Doerr 2018).

The insider action researcher functions as a change agent (Coughlan and Coghlan 2002) with the power that comes with such a position in the organization. Therefore, it has been important to reflect critically on the participants’ ability to share information that may put them in a vulnerable situation with the change agent. As mentioned, this organization is predominantly an adhocracy, and, as such, the professionals, rather than the leaders, are the heroes (Mintzberg 1979). Furthermore, the insider action researcher has no personnel responsibilities. Nevertheless, that the insider action researcher has been working as a leader in the company for many years might have led to employees putting on their best behavior and bringing espoused theories to the table. Issues that are sensitive must be handled with sensitivity (Long et al. 2016), and, if stories about the work done were a foundation for salary talks, we would probably have had other replies. However, as we hope to demonstrate in the quotes presented below, although some individuals pointed to other people’s faults instead of their own, a good proportion also explained their own faults. It can be tempting for an insider to overestimate one’s own pre-understanding of the organization (Coghlan 2019), and the department managers should have been more involved both in the beginning and in the analysis of the material from the department meetings. This could have helped the quality of the relationship (Coghlan and Shani 2014) by making the terms we used in the project more aligned to the internal jargon. The reflections in the steering group meetings helped to keep the organization in the loop. No rewards were handed out in this work; rather, it was all seen as part of the daily work in the organization.

4 Findings and analysis

These findings are from the second and third cycles of the research, as these were the ones that had the closest relation to the subject of boundary work. Our research focus was on how the choice of boundary work in software development teams influences the team autonomy.

The main examples are from work in the banking and finance sector. The banking and finance sector experiences varying pace and predictability due to a turbulent market with high complexity (Lagarde 2018). At the same time, it is a highly regulated area with strict demands for secure software. This is a challenge for the software team, because software development with high security demands can be time-consuming work. When the product strategy changes often, it can lead to the need to reorganize what has already been made and to delete finished work. One of the consultants described his experience like this: “If they see an opportunity, that’s suddenly their focus. It is like taking a ball for a walk” (Developer). The need for a provisional settlement (Girard and Stark 2002) can be seen here as the need to keep the ball moving in the same direction long enough to ensure some software is produced and implemented.

As mentioned earlier, boundary work can be divided into three categories: competitive, collaborative, and configurational (Langley et al. 2019). Competitive boundary work involves boundaries being drawn to create an advantage over others; in collaborative boundary work, the involved parties downplay the boundaries between them to achieve something together; and configurational boundary work involves organizing or rearranging the sets of boundaries to influence others’ behavior and is often done by someone external to the team. We expected many examples of competitive boundary work, and so was also the case. Competitive boundary work by both the consultant and a client representative can be seen in this quote.

We all see problems and solutions through the basis of our knowledge and experience, and how you can give advice depends on what the opposite part enters the meeting with. The client has an employee who has been given the responsibility for cloud solutions, and according to him, anything can be solved in the cloud. He does not have any particular knowledge about the actual solution we are developing, but he was invited to a meeting as the client's technical expert. Our interpretations of the problem are far apart as we enter the meeting, and it is difficult to achieve sufficient understanding and alignment in the limited time frame of the meeting. The result is that we don’t really discuss the same problem, and it makes it very difficult to achieve a constructive and meaningful discussion. (Senior developer).

Here, the client has given a specific employee the responsibility for the cloud solutions and he is understood by the consultant as someone who believes anything can be solved in the cloud. The IT-solution the consultants refers to is a solution that has strong demands on security and was built before cloud solutions were in common use. The cloud expert and the consultants have differing views on the problem and solution space, and there is not enough time to address these issues. Alignment is then difficult to arrive at, and the differences in opinion continue.

Another way the client may show competitive boundary work is when the client decides what to do (Hoda and Noble 2017), as illustrated by this quote:

There are a lot of limits to our work. Time constraints and other constraints. When you ask the question “Why are we doing it like this?” you realize that it can be done differently. An example of when we don’t understand is when we are not allowed contact with the client. They [the client] don’t want to involve [the consultants]. (Test manager)

In this situation, the competitive boundary work performed by the client can be detrimental to the team autonomy. The possible effects of the client competitive boundary work can be seen in a case where the team used to have a product owner who decided himself what to make and told the team what to do. This caused the team to waste a lot of time on a product that the product owner wanted, but that the team was not so sure was the right thing to make. The teamwork improved considerably when a new product owner took a more learning-oriented approach that involved the team in deciding what to do:

Now we have finally reached the point where we can make what we should have made last year. Now we don’t have much time. We wouldn’t have needed to be under time pressure if we had made the right thing right away. We changed to the new product owner who sits together with us and contributes [which is good]. (Developer)

However, collaborative boundary work is of particular interest here because this is the work that helps the team handle the complexity and uncertainty of the situation (Sharp and Robinson 2010). A good example of collective collaborative boundary work with a provisional settlement was presented by one of the senior developers who worked in a team for one of the largest clients:

The product owner [client representative on the team] is good at involving everyone in the team. We have whole-day workshops where we talk about our ambitions and what our goal is so that everyone has a mutual understanding. They [the workshops] happen now and then. In the daily work, the tasks are connected to the goals. (Senior developer)

However, another consultant working for the same client told a different story:

It varies from team to team. Our team does not have this [referring to team workshops for alignment and ambition clarification]. We have a TechLead acting on external influences that he discusses via a whiteboard. If you are not there when it happens, the team members may not be informed. Not because he consciously withholds information, but it sometimes just happens. That sometimes leads to things we have to redo. Misunderstandings. (Senior developer)

This second example shows that the work is individual in that there is no collective way of discussing what the team should do: the individual either participates in a discussion or does not. This lack of alignment at a team level can be seen in the case of the TechLead who involved whichever team member was near when he needed to talk. The TechLead invited some colleagues to participate in the exploration of what to do (Torrance and Schumann 2019), but not all of them and not in a way that the others experienced as structured. The team members worked on their own things, and this might have led to them producing code that was not needed, or to not fulfilling the project’s purpose. Consequently, they had to redo their work. The same frustrating situation is found in the earlier example of the product owner who enforced his right to decide what the team should do, and who did not include them in the learning process. Because of this, the product was delayed, and the team members were pressed on time. Some also believed that it was not possible for them to influence the decisions of what to make, as they had already been made: “We come in too late, it is already decided what to do. It is established, and then it is hard to challenge” (Developer).

Individual boundary work can be seen in the absence of collective collaborative boundary work. Here, consultants were not given an arena in which they could challenge the work done. Instead, they were left with the job of challenging the client by themselves, which can lead to difficult situations. As a developer explained, the reason for not initiating collaborative boundary work, even when the prerequisites have changed, was because it was too mentally and relationally demanding: “In the process, the original need has changed. And you don’t know why. To check [whether the prerequisites have changed] costs mentally. And it causes wear and tear to the relationship [with the client representative]” (Chief developer). Some consultants chose to attend meetings just to build relationships that would later allow them to participate in a decision.

Although collective collaborative boundary work was absent from some teams, some consultants made an effort to downplay boundaries by taking ownership of the client’s product and the goals they wanted to achieve.

My work involves testing, and, in my project, I follow up to check that it works for the client. I think: “If I was a user.” [...] The client notices when we think about them and are aware of them. It is easier to have a relationship with the client and suggest things when we see the solution as “our baby”. The clients’ openness to including us [is important]. (Test manager)

It is important for insider action researchers to reflect on whether they have found something that confirmed their assumptions or not, to make sure that they do not reinforce presumptions among the participants. As expected, competitive boundary work was seen both between client and consultants, and between team members. The effects of a lack of team alignment came as a surprise to the insider action researcher in this study, and it has also proven difficult to communicate with the organization until recently. The results from the three cycles continue to be a central discussion topic within the organization.

5 Discussion

Low predictability settings, like software development, must be handled by short-term flexibility (Boonstra and Reezigt 2019), such as using agile methods (Highsmith and Cockburn 2001), or hypothesis-driven development (Khanna et al. 2018). For teamwork to be possible, the team needs alignment on what to make in the next period (Girard and Stark 2002). In setting this alignment, the team exercise their team autonomy (Gemünden 2015). The alignment is a trading zone (Kellogg et al. 2006) where opinions can be shared and aligned and provide a foundation for the experts to execute their individual professional autonomy (Jønsson and Jeppesen 2013). The first cycle of the AR was interesting because the action researcher and the participants saw the need to establish that the projects worked on by the consultants had low predictability. This demonstrates how strong the expectations of predictability are, even in a context of producing one-off tailor-made software.

Our findings show that when the alignment is not made, the individuals choose strategies that are counterproductive. They may choose to close themselves off and work by themselves without regard for the team because they claim that getting involved demands too much mental capacity or relational work, or they may devote time and effort to initiating collaborative boundary work on their own. This is different from the professional protection of autonomy described by Gieryn (1983), where individuals do competitive boundary work to protect the professionalism of their work. In our case, the individual distances him/herself from what could be perceived as the right way of doing the work and adopts a position where he/she just gets the work done even though it might not produce the best solution. This strategy is counterproductive because it leads to work needing to be redone or scrapped. Whether engaging in individual collaborative boundary work should be seen as a waste or not, may be debatable. Participating in meetings to build relationships and authority may be necessary, but the impression we get is that team members use too much time downplaying the boundaries between, for instance, the product owner and themselves, because there is no collective arena where they can contribute with their knowledge and ideas. Levina and Vaast (2005) found that in some cases the boundary spanning was performed by someone not appointed to the role, and we found the same in that individuals take it upon themselves to perform collaborative boundary work.

The overuse of individual autonomy, which has been described as a personality trait (Moe et al. 2019), is instead described here as a combination of a natural choice for professionals, and an effect of not involving team members in alignment. To understand how the choice of boundary work influences team autonomy, we have focused on the choice of alignment. When not invited to a collective team meeting to discuss the tasks and aims and to set a provisional alignment, the team members could choose either to do individual collaborative boundary work or to not engage. Our theoretical implication is to describe this as an individualized zone that occurs when no collective collaborative boundary work is done. It is individualized in that the consultants blame themselves for not having the capacity to engage in the necessary behavior. In the individualized zone, the burden of initiative is put on each actor’s shoulders, when it could be carried by a structure such as a provisional settlement. See Fig. 3.

Fig. 3
figure 3

The occurrence of situational individual autonomy

Full size image

Our findings indicate that individual professional autonomy makes it harder to carry out alignment in a team, because each individual is determined to assume the responsibility for their part of the work. Combined with the tendency of people to have too much faith in the predictability of the setting (Norman and Stappers 2015), conducting alignment processes in the team will be hard. In addition, the competitive boundary work where those in charge decide what the team should make also makes it harder for the team leader or team members to claim that the team should carry out an alignment process.

As mentioned above, developing team autonomy seems to be difficult (Moe et al. 2009). The practical implication of this is to acknowledge that professionals will protect their professional autonomy. In addition, the human tendency to believe in plan-driven processes, even when the predictability is low, do not create the best foundation for collective, collaborative boundary work. For the people responsible for making collaboration happen, it may be good to know that there is an untapped potential for collaboration. It seems that there are other types of work where collaborative boundary work will happen by itself. For instance, Liberati (2017) found collaborative boundary work in ICUs. This might be because an ICU is a setting where it is obvious to all involved that the predictability is low. We assume that it is harder to see the low predictability in software development, and, therefore, that it is harder to take the initiative to realize collaboration. Thus, helping the team to understand low predictability would be useful in software development.

We intended to open up a space for alternative explanations of the problem of using too much individual autonomy in teams (Moe et al. 2019). Ironically, the individual autonomy that can flourish in an individualized zone is seen as an individual’s problem. To demand that “thou shall work together”, but without creating the arena for it, can result in individuals feeling that they have shortcomings. On the other hand, invitations to workshops might not help to create collaboration because the team members firmly believe that they are most efficient when doing the work alone. Hopefully, by exploring the predictability and complexity of the project, and by finding the most suitable way to work in this setting, the overuse of individual autonomy can be reduced.

This AR has developed the organization in such a way that discussions about predictability are more prevalent. The participants in the research have increased their understanding of the importance of giving the teams the necessary autonomy, as well as for the team members to claim that autonomy. This AR project is one element in a bigger organizational development effort to increase the innovative potential of the teams and consultants. In addition, the trend in society towards using team alignment frameworks, such as OKR (Doerr 2018), have undoubtedly contributed. Therefore, it can be hard to attribute all that has happened to this one AR project. However, the ease with which some of the consultants now address the low predictability of the setting and the need for team alignment suggests that this work has contributed to an ongoing process of improvement. The discussions are not only internal, but also involve engaging with the clients and their understanding of the right way of working given the level of predictability. The fact that stories about configurational boundary work were almost entirely lacking has inspired us to provide workshops on team topologies first developed by Skelton and Pais (2019) for the teams and the team leaders. In this work, the focus has been on configuring different types of teams according to their different roles in the production (value-added team, enabling team, platform team, and complicated subsystem team).

6 Conclusion

In this paper, we have discussed how the choices of boundary work in software development teams influence team autonomy. We have shown that the choices made can reduce the team autonomy and increase the use of counterproductive individual autonomy. The choices of boundary work that are prominent in this paper are competitive and collaborative boundary work. Competitive boundary work is when individuals (and groups) protect their individual autonomy, while an example of collaborative boundary work is when an alignment is created. We argue that team autonomy is reduced when the team is not engaged in creating an alignment on what to make. In such teams, there is an overuse of individual autonomy.

To initiate or participate in collaborative boundary work, the actors around the team must understand that this is not a plan-driven project or product development, and they should give the team a mission and sufficient autonomy to perform. The team members must understand that they have been given a mission rather than a defined output/plan, they must understand the levels of predictability and complexity involved, and they should choose a way of working that is appropriate to these levels, which includes setting their ambitions for the next period of time. Fighting the human tendency to see linearity and simplicity where there is complexity adds to the task. And, of course, team members also need to perform well in their own discipline. This is clearly a daunting challenge, so it is not hard to understand why teams sometimes fail.

We have limited this article to the study of software development, but these findings are also useful for other types of projects and product development where there is a strong need for collaboration in teams. The levels of complexity and predictability of the context are mostly the same whether the frame of the work is defined as a project or as a product development area. There is a mission to accomplish in both types of team, and there is also a need for alignment. We believe, therefore, that the project diagnosis model of Boonstra and Reezigt (2019) is just as useful for product development as it is for other forms of project.

Digitalization of our societies continues to be important. Software companies play a vital role in supporting organizations in their digital reshaping. The findings of our research point to the importance of giving more thought and effort to the collaborative boundary work performed by teams, which would in turn enable companies to increase their level of innovation.