The Journal of Systems & Software 200 (2023) 111649

Contents lists available at ScienceDirect

The Journal of Systems & Software

journal homepage: www.elsevier.com/locate/jss

In practice

Decentralized decision-making and scaled autonomy at Spotify✩

∗
Darja Šmite a , , Nils Brede Moe b , Marcin Floryan c , Javier Gonzalez-Huerta a ,
Michael Dorner a , Aivars Sablis d
a
Blekinge Institute of Technology Karlskrona, Sweden
b
SINTEF Trondheim, Norway
c
Spotify Stockholm, Sweden
d
SAF Tehnika JSC Riga, Latvia

article info a b s t r a c t

Article history: While modern software companies strive to increase team autonomy to enable them to successfully
Received 5 April 2022 operate the piece of software they develop and deploy, efficient ways to orchestrate the work of
Received in revised form 13 December 2022 multiple autonomous teams working in parallel are still poorly understood. In this paper, we report
Accepted 13 February 2023
how team autonomy is maintained at Spotify at scale, based on team retrospectives, interviews
Available online 15 February 2023
with team managers and archival analysis of corporate databases and work procedures. In particular,
Keywords: we describe how managerial authority is decentralized through various workgroups with collective
Scaling agile authority, what compromises are made to team autonomy to ensure alignment and which team-related
Scaled autonomy factors can further hinder autonomy. Our findings show that scaled autonomy at Spotify does not
Enabling constraints mean anarchy, or unlimited permissiveness. Instead, squads are expected to take responsibility for
Coordination their work and coordinate, communicate and align their actions with others, and comply with a few
Large-scale software development enabling constraints. Further, squads take many decisions independently without management control
The Spotify model
or due to collective efforts that bypass formal boundary structures. Mechanisms and strategies that
enable self-organization at Spotify are related to effective sharing of the codebase, achieving alignment,
networking and knowledge sharing, and are described to guide other companies in their efforts to scale
autonomy.
© 2023 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license
(http://creativecommons.org/licenses/by/4.0/).

1. Introduction management and subordinates (Lee and Edmondson, 2017). How-

ever, a common understanding of how complex interdependent
As the size, complexity, and diversity of today’s software con- work can be accomplished effectively at scale in the absence of
tinues to grow, and the pace of change increases, software com- managerial authority remains scarce (Lee and Edmondson, 2017).
panies seek new ways to orchestrate their activities efficiently. Attempts to decentralize decision-making result in the need
One of the trends that helps to deal with these challenges is to practically support autonomy on the operational level, which
de-bureaucratization, which marks the journey towards creating in software companies means that more autonomy is given to
complex jobs within simple organizations instead of simple jobs teams. How much autonomy shall be given under which cir-
within complex organizations (de Sitter et al., 1997). As a result, cumstances is still an open debate (Moe et al., 2021). Traditional
organizational decentralization has in the recent decade gained agilists claim that team autonomy means that teams should be
mainstream consideration (Hackman, 1986; Lee and Edmondson, allowed to decide how to best accomplish their work (Sutherland
2017; Olsson and Bosch, 2016). The steps taken by the com- and Schwaber, 2013). To achieve this, teams need to take up
panies to organize less hierarchically range from a situational responsibility and be accountable, monitor their performance,
delegation of authority to the radical company-wide formally rec- manage and improve ways of working, and actively search for
ognized elimination of authority-over relationship between the missing knowledge, or in other words, self-manage (Hackman,
1986). Many argue that teams shall have a broader authority
than just the control over their own process. In practice, teams
✩ Editor: Marcos Kalinowski.
need a mandate over planning their work, assuring work qual-
∗ Corresponding author.
ity, recruiting and dismissing members, or even suggesting new
E-mail addresses: [email protected] (D. Šmite), [email protected]
(N.B. Moe), [email protected] (M. Floryan), [email protected]
product ideas (Hackman, 1986) and making decisions with eco-
(J. Gonzalez-Huerta), [email protected] (M. Dorner), nomic consequences (Guzzo and Dickson, 1996). Research into
[email protected] (A. Sablis). team autonomy suggests that members of autonomous teams

https://doi.org/10.1016/j.jss.2023.111649
0164-1212/© 2023 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

are happier, more innovative, more engaged, more motivated,

more productive, more accurate and able to solve more complex
tasks than manager-led teams (Janz et al., 1997a; Cohen and
Bailey, 1997; Langfred, 2007; Bernstein et al., 2016). Autonomy
improves the quality of work life (Kalliamvakou, 2017); purpose-
driven, responsible individuals do not want to be managed or
controlled (Rey et al., 2019). Yet, enabling the autonomous work
of multiple teams working in parallel (autonomy at scale) is a
challenge due to coordination complexity (Bernstein et al., 2016)
and having too many dependencies between teams (Moe et al.,
2021), and is sometimes referred to as a matter of managerial
art and science (Mankins and Garton, 2017). The notion of ‘‘the
boundaries of needed coordination and alignment’’ (Rey et al.,
2019) are said to be those absolutely necessary. However, con-
strained autonomy is not well researched. Besides, self-centered
autonomy can suffer from the association with ambiguity, inef-
ficiencies, organizational chaos (Mankins and Garton, 2017) or
simply opportunistic behavior. Therefore, some researchers as-
sociate autonomy with the freedom to make decisions and the
responsibility over the completion of work (Janz et al., 1997b).
Yet, the practical advice for how to distribute decision-making
in a large organization and enable autonomy at scale are still
missing. Fig. 1. Network of backend microservice dependencies. Every node is a service,
every edge is a direct call obtained from the service catalog and service discovery
In this article, we describe organizational decentralization at
data.
Spotify, the new generation agile company with iconic ways of
working that promote team autonomy and employee empow-
erment and attempt to understand the mechanisms that enable
team autonomy at scale.

2. Background: Spotify squads

Spotify, the world-leading provider of music streaming ser-

vices, evolved its own ways of working, which became iconic
for many new-generation agile organizations. The culture of en-
gagement and teamwork is emphasized in the organizational
structures of Spotify and the unique terminology used to describe
them (squads, tribes, missions). Squads are engineering teams at
Spotify, which were initially set up to feel like mini start-ups,
be highly cross-functional and self-organized (Smite et al., 2019)
and be able to prototype, test, code, deploy, operate, and A/B
test features and services independently of each other. A squad Fig. 2. Task dependencies between squads. Every node is a squad, every edge
would typically employ a mixture of backend engineers, web represents one or multiple GitHub pull requests connecting the squad authoring
engineers, and data scientists to ensure the ability to develop a pull request with a squad that owns the repository.
and deliver end-to-end functionality. However, there are also
specialized squads with only backend engineers or only web en-
gineers. Spotify is a purpose-driven organization (Rey et al., 2019) The majority are interrelated, often with services owned by other
with missions (business areas) as organizational units that unite squads (see the center of the graph). Cross-squad work coor-
several tribes (departments) working in a particular functional dination may be resolved by requesting the owner squad to
area. Missions are formed to be independent and, if possible, make the changes in their microservices (or other type of code),
co-located, to ease the coordination and decision-making. or by suggesting the changes in a pull request. Fig. 2 shows
In the spring of 2020, Spotify employed ∼500 squads in six the network of such cross-squad pull requests accounting 435
missions (business areas) divided into ∼50 tribes (departments) author-reviewer combinations. In one year (2019), each squad,
developing and maintaining thousands of services, mobile fea- on average (mean) interacted with 26 other squads, which shows
tures and data pipelines. As the company and its product portfolio that squads perform highly interdependent work and contribute
grew in size and complexity, maintaining autonomy became in- to many repositories owned by others.
creasingly difficult. Some organizational structures have been To know how Spotify enables squad autonomy on a large
abandoned (such as chapters Mankins and Garton, 2017), some and continuously increasing scale and what challenges they face,
we looked at how work execution is organized. We asked six
have decreased in popularity (such as guilds Smite et al., 2019;
squads responsible for deploying features or services about their
Šmite et al., 2020), and some new structures have been intro-
perception of autonomy, executed authority and its constraints,
duced (such as missions). Yet, no organizational restructuring
mechanisms enabling the work execution and barriers to their
alone can alleviate the need for cross-squad collaboration and
autonomy.
coordination. In the following two examples, we illustrate the
scale of cross-squad coordination. Fig. 1 shows the number of 3. Details of the research study
technical dependencies in a network of backend microservices.
A squad working with the backend may own one or more mi- To understand team autonomy at scale, we conducted an
croservices. Few are isolated (see the periphery of the graph). exploratory single-case study (Runeson et al., 2012) at Spotify,
2
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

Table 1
Profile of the studied squads.
Squads Location Short Members Key reflections on own autonomy
description (based on direct squad member quotes from the retrospectives)
Total New hires Consultants
Alpha Sweden Well-performing 7 2 2 ‘‘. . . We are a part of designing our future – what and how we build. It’s not
someone else, WE are defining it’’.
Beta Sweden Challenged, 7 2 3 ‘‘There is a lack of skills, confidence or competence, also resources, to do
recently something’’; ‘‘We have a this-has-always-worked syndrome’’; ‘‘There is no one
redesigned single person who owns the process and drives it, but it has become better in
the last two months’’; ‘‘I agree. Don’t you think it has to do with [Squad
Manager] who joined us?’’
Gamma Sweden Well-performing, 6 3 – ‘‘Vision and mission for the squad is defined by ourselves. We sit together and
somewhat decided what we want to do. People want us to own more stuff, but it’ up to
unstable us to keep the scope’’.
Delta Sweden Challenged, 8 2 – ‘‘Difficult for a team to be autonomous, a lot of politics go around – manager
recently often helps with that’’; "We can’t do everything ourselves. Architecture does
redesigned not support that. Autonomy ends at the boundary of our turf’’.
Epsilon USA Well-performing, 8 3 – ‘‘We can only be as good as are the parts we depend on. [We need to] keep
recently track of the health of dependencies’’.
established
Zeta USA Newly 5 1 – ‘‘To truly be autonomous we need to remove all dependencies, which is an
established idealistic idea. If we were a small company, we would be able to have control
of the tech stack, do more work, own more work, make decisions about our
work ourselves. Dependencies hinder the ability to control our own destiny’’.

based on qualitative and quantitative data from various sources, themes based on the levels of authority suggested by Hackman
including: (1986) and the decision-making authority being squads and man-
agers (Hackman, 1986; Lee and Edmondson, 2017). For example,
• Squad retrospectives conducted with squad members, the following squads’ member statements were assigned three
• Interviews with squad managers, codes [Squad-made decision], [Squad’s task execution] and [How
• Social network analysis survey, to implement features/ services] – ‘‘I like that we can control
• Archival analysis, and decide how we plan our sprints. We have a lot of control’’
• Process and organizational descriptions from the internal and ‘‘What and how we build – it’s not someone else, we are
blog. defining it ourselves’’. During the analysis, however, we decided
to extend the primary themes that were based on the binary
The objective of our research was to understand the degree of
view of authority decentralization suggested by Hackman (1986)
squad autonomy in a large-scale environment, barriers to squad
and followed by Lee and Edmondson (2017). Instead of squad-
autonomy, and mechanisms that help enable autonomy at scale.
made vs management-made decisions, we also coded decisions
Analysis of the perception of squad autonomy, executed au-
made by the management in consultation with the squads, by the
thority and its constraints, and barriers to squad autonomy is
management based on squads’ recommendations or input, by the
based on the data gathered through interviews and retrospec-
squads in consultation with the management, and, finally, what is
tives. In May, October and December 2019, we ran retrospectives
more important, we identify the area of collective responsibility,
with six squads (here called Alpha, Beta, Gamma, Delta, Ep-
which is one key extension of the current literature. For example,
silon and Zeta, see Table 1) and interviewed their engineering
the following quotations were coded as [Collective responsibility],
managers (managers of five out of six squads). Squads were [Squad’s task execution], [Constrained choice of technology], and
selected by convenience sampling with a prerequisite to have [Hindering factor]: ‘‘A single authority that says what we should
challenged or recently formed squads (Alpha, Gamma and Zeta) use – it’s anti autonomy. We should be able to make such decisions
and well-performing squads (Beta, Delta and Epsilon). Squads inside the squad’’, and ‘‘We need to standardize across squads. Stan-
were recruited through the call for volunteers. dardization makes us more autonomous, because the policy applies
Retrospectives followed a structured 2,5-hours long agenda. to everyone – it is therefore both adds and hinders autonomy’’.
We asked participants to individually report and later discuss en- Next, codes from different squads were compared to deter-
ablers and hindrances to the squads’ autonomy in a DAKI format mine whether levels of authority were perceived by all squads
(Drop-Add-Keep-Improve) (Caroli and Caetano, 2020) and dis- similarly or depended on some squad characteristics or the con-
cussed the squads’ dependencies (coordination with experts and text. For example, a squad working on less prioritized tasks
other squads, meeting fora for work coordination). Researchers affected its ability to recruit members, in other words, to design
took detailed close-to-transcript notes (later verified with the its organizational context, as evidenced in the following quotation
participants) and recorded the drawings. Interviews with squad ‘‘Hard to advertise this squad, hard to prioritize, so candidates came
managers focused on gathering general information about the top down’’ in contrast to another squad’s experience: ‘‘We are
squads and the work they are assigned to do, as well as dis- not in control of the headcounts. I am fine with that. But we are
cussing squad performance and factors affecting the squads’ abil- in control of the competences we need’’. The result of these steps
ity to execute their work. Detailed notes were taken during these of qualitative analysis was used to draft our understanding of
interviews for further analysis. authority distribution at Spotify, which was then combined with
The qualitative analysis started by identifying the level of the process and organizational descriptions from the internal
squad authority and the distribution of managerial authority. blog and verified with the representatives from the company
Two first authors performed thematic coding of the detailed management to derive the designed distribution of authority
notes from team retrospectives and interviews with the four core (Fig. 3).
3
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

Fig. 3. Level of decentralization of authority by decision area.

Finally, we performed thematic coding of factors that hinder findings across the company and beyond the squads included in
and enable squad autonomy based on squad retrospectives and the qualitative analysis. We start by illustrating the complexity of
identified barriers related to the squad characteristics and contex- the work environment and cross-squad dependencies at Spotify
tual factors that emerged in the comparative analysis of the levels in an image of backend services (Fig. 1) containing direct calls
of authority across squads. Barriers to autonomy are discussed in extracted from the service catalog and service discovery data,
Section 5 and summarized in Fig. 5, while the enabling factors illustrating interdependencies and indirectly showing the level
combined with the process and organizational descriptions were of work coupling on a company level. Next, we drew a network
used to derive Spotify’s practices to foster autonomy at scale, of task dependencies for squads based on the data extracted
which are discussed in Section 6. from the GitHub Enterprise (see Fig. 2). We used all 87,606 pull
To capture squad interactions (see Fig. 6), we asked partici- requests (PRs) from 2019, from which we excluded all squad-
pants of the retrospectives to report important work connections, internally reviewed pull requests (44,36%), as we are interested
as many as they determined necessary, in a ‘‘free-recall’’ for- in the cross-squad collaboration. In the network, we visualized
mat. This was operated as a web-based survey distributed to all unique author-reviewer combinations as the edges (total of 5659)
participants after the retrospective. Respondents recorded each and squads as the nodes (total of 435). This was done to show
work connection as a separate entry in the personal Google sheet, that the studied squads’ coordination needs are not unique. The
including the contact’s name, the content of each connection abovementioned data sources were provided by the company
with an ability to select knowledge received, knowledge trans- representatives. We have, therefore, not extracted them system-
ferred, work-related information received, work-related infor- atically or in connection to the studied squads. Next, using data
mation transferred, administrative information received and/or from the employee database, we visualized the proportion of
administrative information transferred. Further, for each iden- managers in the company to all employees in the engineering
tified contact, the participants also provided an answer on the departments from 2018-01 to 2021-09 (see Fig. 4) to support
frequency of coordination with the selected contact using the 5- the claim that managerial overhead in Spotify is relatively low
point Likert scale (from Rarely to Sometimes to Every day). Our despite the organizational growth. Finally, we drew another net-
survey partially replicated a questionnaire conducted by Manteli work illustrating mutual help and information exchange based
et al. (2014). We followed a ‘‘realist’’ approach and relied on on the data extracted from the Q&A system built as a corporate
perceived individual networks, which are believed to correspond StackOverflow instance for the period between 2018-11-26 (the
to the actual boundaries of social groups (Lee and Edmondson, start of its use) and 2019-12-11, in which we connected question
2017), and used to identify social networks before (Šmite et al., authors, respondents and commentators. In total, we have pro-
2017; Manteli et al., 2014). To construct the networks, we first cessed 2428 questions, 3112 responses and 3684 comments from
completed the list of recalled contacts from all respondents and 929 users (see Fig. 7). Here we show the company-wide use of one
clarified these with company representatives to verify the names, strategy we recommend as a mechanism supporting autonomy at
roles in the company, and location. We visualize four squad scale.
networks, omitting two squads (Epsilon and Zeta) because of low The quantitative materials are used to understand the internal
response rate. In the four squads, 21 of the 28 squad members validity of our results and the representativeness of what we find
returned the survey (75% response rate, ranging from 60% for in the studied squads in the context of the entire company. In
Alpha to 88% for Gamma). Social networks were then visualized other words, through the qualitative analysis we understand the
using the Fruchterman–Reingold layout algorithm (Lee and Ed- level of autonomy that squads have and squad experiences with
mondson, 2017) based on the squad members, their contacts that cross-squad alignment and collaboration, and through the quanti-
they recalled and reported connections. tative analysis we understand how representative these needs for
The quantitative analysis focused on illustrating our findings alignment and collaboration and mechanisms that support scaled
and demonstrating the internal validity or applicability of the autonomy are.
4
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

4.2. What can Spotify squads decide?

When asked to reflect on the squad autonomy, everyone

agreed that squads, in principle, are granted significant author-
ity, even though not all squads felt equally autonomous. The
well-performing squads perceived exploiting higher levels of
autonomy, while the challenged squads were said to be less
autonomous leading to increased management involvement. An
engineer from Gamma explained that to be independent squads
ought to prove their accountability: ‘‘As long as you can show
that you are creating value for the company, the company will
believe in you. People around you will know that what you are
Fig. 4. Proportion of employees with the managerial role in the engineers doing [. . . ] is something useful. So, they will let you keep doing it’’.
departments. Besides, squad autonomy also depended on the position of the
squad, and its work in the organization, i.e., how much the squad
is dependent on others and how much others depend on the
4. Results – Decentralization of authority squad in terms of technical dependencies and competencies. In
the following, we describe what type of decisions Spotify squads
can take independently, and where their autonomy needs to be
We start by describing the level of autonomy and managerial constrained.
authority based on the squad testimonies, followed by an outline
of the planned distribution of managerial authority that combines Executing squad’s tasks Decisions regarding work execution at
the squad insights with the managers’ testimonies and process Spotify are fully decentralized and management does not directly
interfere with squad-internal decisions on how to implement
and organizational descriptions (Fig. 3).
a feature or a service. To a large extent, squads independently
decide how to code a feature or service, with few exceptions such
4.1. What do Spotify managers decide? as where squad autonomy is sacrificed because squads do not
work in isolation, and some decisions must be taken collectively.
The key reasons to constrain squad independence are twofold –
Autonomy and self-management are paramount for Spotify
necessity to align on the choices of technology and programming
and are associated with empowerment, one of the core values
languages and the necessity to coordinate task dependencies.
that is believed to be the foundation of fast-paced product de- Autonomous squads should, in theory, be able to choose the
velopment and innovation and signs of humanistic, participatory technology best suited for solving their tasks. However, in prac-
management (Lee and Edmondson, 2017; Rey et al., 2019). Squads tice, there is a need to align the use of programming languages,
are given a great deal of authority to take squad-related decisions, technologies, frameworks, processes, and infrastructure to avoid
which are only in certain circumstances and areas constrained by maintainability problems and increase the ability to collaborate
the management (see the level of decentralization of authority and help each other (read about TechRadar, Spotify’s collective
at Spotify by design in Fig. 3). The high level of decentralization effort to align technical decisions in the next section).
can also be evidenced in the low proportion of the employees Squads’ freedom is also constrained by the technical depen-
with managerial roles in the engineering departments, which dencies with other squads, which we have found surprisingly
remains rather stable despite the company growth (see data for many, despite the company’s attempts to decouple the architec-
2018–2021 in Fig. 4). ture by design (microservice architecture principles) and by ac-
tion (code ownership principles and continuous re-engineering).
Designing the organizational context high-level decisions re- The number of cross-squad and even cross-tribe pull requests
lated to organizational design and redesign at Spotify are largely especially in mobile client development (see Figs. 2 and 3) is
centralized. Senior management decides how the organization huge, and these technical dependencies have been acknowledged
should be structured and plans organizational growth. In its turn, as the major challenge by all studied squads. As an engineer
tribe management plans and leads the recruitment efforts, espe- from Delta stated: ‘‘We can’t do everything ourselves; architecture
cially when hiring (and dismissing) managers. does not support that. Autonomy ends at the boundary of our
turf’’, while someone from Zeta noted: ‘‘Dependencies hinder the
Setting overall direction: Strategic decisions regarding the long-
ability to control our own destiny’’. Changes in others’ code are
term vision, directions and key priorities at Spotify are set by unavoidable, especially on the client-side where there is no good
the senior leadership. Further, all Spotify missions and tribes equivalent to the backend microservice architecture. We learned
perform quarterly planning — these decisions are taken by the that some squads are significantly affected by these uncontrolled
tribe leadership in consultation with the individual squads. In dependencies, as one engineer from Beta explained: ‘‘We write
addition, the senior leadership reviews new initiatives quarterly directly to others’ databases, and others write to ours. Interfaces to
and sets priorities for strategic work, called company bets. For other teams are unspecified. We are stuck in a way, which prevents
example, when Spotify entered the Japanese market, it required us from being independent’’ (read about the ways to coordinate
significant changes to the core software functions such as the technical dependencies in the next section).
search functions and metadata fields, as well as demanding new Monitoring and managing process and progress: Decisions re-
functions such as having karaoke mode. Company strategic ini- lated to the process management at Spotify are largely decen-
tiatives usually involve squads from different tribes and even tralized and decisions on how to perform the actual work in
missions, and thus require resource allocation outside of the a particular squad are driven by the squad. Planning decisions,
scope of the squads- or even tribe-focused planning. Such plan- progress monitoring and quality assurance tasks are also all re-
ning usually starts by approaching squads and including them in sponsibilities of the individual squads. In our study, we found
design discussions and working groups. that well-performing squads at Spotify actively followed their
5
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

progress by gathering and analyzing squad-related performance large freedom to contribute and innovate within the business area
data, which helped to continuously improve their internal pro- they belong to. However, we learned that high performing squads
cesses. As a member of Alpha explained, ‘‘The [performance] data desire to contribute more broadly and be even more autonomous
is our reference point. We know that work with a lot of depen- when it comes to cross-company contributions. As someone from
dencies takes 2,5 times longer, so what can we do about that? squad Alpha explained, ‘‘We are defined by the mission of what we
It gives us a lot more freedom – Let’s try this thing; No, it did do and that sometimes limits us to do more. We could innovate in
not really help, so let’s try something different’’. Although not all different places and do more, but we are limited’’.
squads have such advanced progress data monitoring habits, all
squads mentioned having retrospectives and experimenting with
ways of working, except for one challenged squad, Beta, that felt 4.3. Where are Spotify squads obliged to compromise, align or coor-
they did not succeed with improvements, as the squad members dinate?
described ‘‘being focused on something too much, and not seeing
problems around’’, ‘‘not questioning things’’, and having the so-
called ‘‘this-has-always-worked syndrome’’. Admittedly, failing to Autonomy at Spotify is clearly not understood as anarchy.
manage own processes might considerably hinder teams ability The studied squads acknowledge that the scaled autonomy starts
to self-manage (Hackman, 1986). As explained by the members with the end-to-end responsibility for their work, which requires
from Delta — the squad started out with a clear scope but further support in the form of formal rules guiding collective
over time received more diverse tasks into their backlog; to action. Collective efforts concern the formation of various work-
optimize productivity, each engineer became responsible for their groups and squad-to-squad interactions that occur naturally, on a
own tasks, which decreased teamwork. As a member of Delta need basis. In what follows, we describe several formalized work
explained: ‘‘Because we are doing so many different things at the groups and efforts, as well as principles and actions that Spotify
same time, it is impossible to replace each other’’. Eventually, in engineers follow to self-organize.
the absence of reflection and corrective action, the squad had
too many diverse tasks with urgent priority. Because members Executing squad’s tasks To support the alignment of the choice
focused on their own tasks and thus individual goals, joint goals of technologies used by the squads, Spotify established a central
became blurry, and the squad performance suffered. committee of very senior engineers who own the list of ac-
cepted technologies called TechRadar, and a well-defined process
Designing the organizational context: Many squads have sub-
for proposing technologies and trying them out. Anyone can
stantial authority over the recruitment of new squad members.
and is encouraged to suggest new technologies that might be
Any squad can signal the need for more people, which is con-
of interest for the company. In our study, we found that not
sidered by tribe leadership. The following recruitment process
everyone agrees with the restrictions that TechRadar implies.
is typically led by the squad together with their engineering
manager, who also has the authority to remove squad members Some members we talked to strongly object to the limitations
if seen necessary. However, not all squads are equally successful of professional freedom, calling this practice an ‘‘anti-autonomy’’.
in getting new members. Members of Delta explained that some Yet, many understand the importance of enabling constraints,
squads, like theirs, demand very specific competences, which e.g., limiting the use of unpopular or unsupported technologies.
are hard to advertise. There might also be differences in how In a way, limitations to someone’s autonomy might enable others’
prioritized and visible the work done in some squads is, which autonomy. They help to be more resilient and avoid being stuck
affects member recruitment. with the code written in a language that nobody knows, when the
original developers leave or move, and to improve evolvability of
Setting overall direction: Squad-related strategic decisions in-
the products, allowing squads to help each other and contribute
clude choosing the squad’s scope of work, prioritizing work in
to the majority areas of the codebase.
the backlog, and taking decisions regarding the future of the
features and services that a squad owns, which might require Work coordination across squads and joint decision-making
taking decisions with economic consequences (Guzzo and Dick- is also the consequence of selected code ownership principles
son, 1996). The key sources of work tasks for squads include followed at Spotify — being allowed to change code owned
market feedback and product development ideas regarding their by other squads (weak code ownership principles, i.e., taking
area of responsibility. For example, there is a squad in Spotify, responsibility for your code, letting others change it, and keeping
which owns ‘‘Spotify experience in the car’’ and together with an eye on those changes Fowler, 2006). When the squad’s work
their product manager plans the features and services to be impacts other squads, engineers are expected to consult the oth-
developed or improved. Squads do not independently determine ers either informally or through formalized action. Large changes
their own direction but certainly have a big influence on their are documented in the form of so-called Requests-For-Comment
goals and scope. Work planning for the squad is performed in (RFC) which are sent to a wider audience for feedback, to ensure
sprint planning meetings and is the sole responsibility of the that there is an agreement about the emerging changes and de-
squad, except for the cases when squads are assigned to strategic pendencies. Smaller changes are handled through the GitHub pull
initiatives, i.e., company bets. Among the squads we studied, requests (PRs). The pull requests are typically reviewed by the
some reported having a very clear scope with full control over it, owning squad, which is responsible for coordinating the changes
as one explained: ‘‘We sit together and decide what we want to do’’. and keeping an eye on the technical health of their code reposito-
Yet, some squads admitted that their goals are ‘‘too fluffy’’, which ries. In some cases, changes are reviewed by members of a third
is the consequence of not managing their processes well. The
squad, not authoring the change or owning the repositories, if
studied squads explained that internal consensus and clarity in
changes are critical or interdisciplinary.
what the squad owns and commits doing is important to ensure
their accountability. Finally, although squads do not decide which Monitoring and managing process and progress: Spotify culture
projects or product areas they work on, they have relatively and ways of working are embedded in the organizational de-
6
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

sign. Our previous research at Spotify illuminates the workgroups the various forms of organizational authority decentralization
called guilds that collectively monitor domain- or technology- and support. We use the results of quantitative analysis of the
related practices and discuss the needed improvements (Smite squad self-reported social networks and information sharing net-
et al., 2019; Šmite et al., 2020). For example, processes of quality works from internal systems to further illustrate and support our
assurance are discussed in the quality guild, while web guild and recommendations.
C++ guild are concerned with the questions related to practices
of programming in a particular language or technology, many 5.1. Barriers to Squad autonomy
of which also maintain active support channels to help those
with questions. A template for squad retrospectives developed Here, we present the factors that were pointed out as bar-
by the agile guild is an example of a concrete outcome of col- riers to squad autonomy, which we mapped to the levels of
lective efforts. Beside the guilds, there are other collective efforts authority (Hackman, 1986) (see a summary in Fig. 5).
that emerge on a need basis, such as ‘‘Friday-feels’’ circles that Our results demonstrate that despite the efforts to decen-
bring together managers, or book clubs where interested partic- tralize the organization by design, squads’ autonomy might be
ipants discuss insights and applicability of ideas from literature. limited by factors beyond managerial control. For example, the
The outcomes of these groups often provide recommendations for squad immaturity (lack of knowledge redundancy, lack of compe-
improving various work processes. For example, the No-meeting- tence) negatively impacts autonomy. This is consonant with the
Wednesday initiative, which emerged in response to numerous related work that associates autonomy not only with the free-
complaints and discussions during the COVID-19 pandemic time dom to make decisions, but also with the responsibility over the
of working from home. New processes and practices are usually completion of work (Janz et al., 1997b) and work that links team
piloted by the dedicated workgroups and recommended for a independence with the self-sufficiency in skills (Kalliamvakou,
broader use if found valuable. The results of pilot studies are 2017). Autonomy and responsibility are also found to be a source
spread in the company through various means, internal blog posts of stress (Grant and Parker, 2009). In our study, we found auton-
and presentations at various group meetings being the most com- omy to cause pressure related to the necessity to coordinate the
mon ones. Whether the suggested new practices will be followed work and manage mutual dependencies.
Another large group of barriers to squad autonomy is rooted
by the squads largely depends on the level of social integration,
in injured teamwork and failure to self-manage (too broad scope,
curiosity, and awareness of the individual squad members of the
unclear goals, missing process improvements, lack of process for
collective initiatives.
getting things done, poor onboarding).
Designing the organizational context: As a typical post- Some context factors (lack of control over recruitment, team
bureaucratic organization (Burns and Stalker, 1961), Spotify pro- instability) can also negatively affect squad autonomy.
motes network structures of control, authority, and communica- While previous factors were related to the squads internal
tion, as evidenced in the presence of collective control mecha- doing, another group of factors that hindered autonomy at scale
nisms. Various workgroups and groups of interest, such as com- relates to technical, human and task dependencies. Barriers here
munities of practice called guilds (Smite et al., 2019) or the contain architectural and legacy constraints, technical debt, the
management support group called ‘‘Friday feels’’ emerge and self- need to compromise with old systems and clients, and undoc-
manage primarily by collective efforts. When groups are formally umented tribal knowledge. Evidently, despite the architectural
recognized, they often are mandated to make certain decisions or decoupling (microservices) which has been previously found to
recommendations to the leadership. enable independence (Kalliamvakou, 2017; Jamshidi et al., 2018),
When it comes to solving squad-centered experience or exper- we found that the implementation of code ownership also mat-
tise gaps, it is not uncommon to mutually agree on a solution with ters. We learned that weak ownership principles lead to squads
another squad, i.e., borrowing and lending members (the practice depending on others and the success of cross-squad collaboration
called ‘‘embedding’’, usually associated with member mobility for depends on the social integration of individual squad members in
three months). These decisions are often initiated by individual the organizational network, which has been also pointed out in
engineers who want to increase their competence or squads who other studies related to large-scale software development (Šmite
need resources approved by engineering managers. et al., 2017). Finally, work on interactive parts of the system used
by others (referred to as increased visibility) means that squads
Setting overall direction: Although Spotify workgroups described receive many questions and requests for code review, limiting
in our work are not mandated to make strategic decisions or set- their autonomy. Interestingly, while mandatory code reviews in
ting overall direction, they are encouraged to voice their opinion related studies are found to be related to increased coordination,
and bring to light the operational evidence as input to strate- they are also related to aligning the team internal practices with
gic work. Examples of collective efforts that reached strategic those of other teams’ (Kalliamvakou, 2017).
level include the inclusion of Rust, an emerging programming Finally, we learned that the lack of squad autonomy does not
language, into the TechRadar as a result of curiosity-based ex- only affect the squad concerned; when working at scale it also
periments, and subsequent hands-on experiments (PoCs) in the affects other squads as a chain reaction, which we refer to as
C++ guild, and a bottoms-up initiative to set-up support for the chain of autonomy. This is especially evident when squads
build systems for web components that led to the creation of a are hindered by task dependencies with many incoming requests
dedicated team that rolled this initiative out for all of Spotify. for code reviews or code changes. When coupled with the lack
of experience or competence, squads are likely to be congested
5. Discussion (when arrival of tasks exceeds the ability to close them), and this
is found to also cause the congestion in the whole network (Can-
In this paper, we presented the perceptions of squad authority tor et al., 2016). The concepts of the chain of autonomy and
and the levels of organizational decentralization by design. In this network congestion indirectly substantiate Bungay’s argument
section, we discuss first discuss the factors that hinder squad that increased alignment increases the autonomy an organization
autonomy based on the analysis of the squad testimonies, their can grant (Bungay, 2011). Our research further shows that when
characteristics and contextual factors that affected the ability of teams’ capabilities or goals are not aligned (as often the case in a
the squads to exploit the designed levels of authority. We then growing organization), it is hard to rely on the designed level of
present the strategies for enabling autonomy at scale based on autonomy.
7
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

it takes 4–5 days before they are done. [...] It’s too slow and we are
delaying it because... I don’t know why’’. Many agree that this could
be addressed by establishing better ‘‘contracts’’ between squads
specifying mutual expectations and responsibilities, or just better
processes for getting the pull requests done (e.g., dedicating time
every morning to unblocking others). To optimize the depen-
dencies, squads may also self-manage the code ownership. For
example, Beta and Gamma negotiated and changed the owner-
ship of the code repositories they depended on to increase squad
autonomy. As a member from Gamma explained, ‘‘We took over
[Beta’s] work because they were not able to help us to do that. We
now own a part of their problem. We are more autonomous, though
we also have more work’’.

5.2.2. Strategies for achieving alignment

Autonomy and self-management are found to predispose com-
panies to reduced coordination across teams (Ingvaldsen and
Rolfsen, 2012). This is why, large-scale development efforts re-
Fig. 5. Barriers to Squad Autonomy.
quire alignment towards the clear vision or goal for a team and
awareness of how the team’s work fits in it (Kalliamvakou, 2017).
Traditionally, this is achieved by enforcing more control and pro-
viding detailed instructions, which is proven to be a failing strat-
5.2. Strategies for autonomy at scale
egy in rapidly changing contexts. Instead, autonomy is increased
by increasing the alignment through limiting the direction and
In this section, we outline the mechanisms that help Spotify
supporting mutual adjustment (Bungay, 2011). Management ef-
address many of the aforementioned challenges and to orches-
forts that support alignment, called ‘‘directed opportunism’’, such
trate the interdependent work of hundreds of autonomous squads
as guidelines towards commonality, are also found to be the key
while keeping organizational control to a minimum.
to success in scaling agility in Atlassian (Kalliamvakou, 2017).
Similarly, many other companies use Objectives and Key Results
5.2.1. Strategies for sharing the codebase
(OKRs), a framework for large-scale agile environments that at-
Like in related studies that suggest that large-scale collabo-
tempts to involve employees in setting common goals across the
ration requires practices that are more typical for open-source
organization. OKRs have been found to aid knowledge shar-
software projects such as reduced communication, independent
ing and improved transparency between teams, however, the
work, and self-organization enabled through GitHub (Ingvaldsen
practice takes years to implement and is not always well re-
and Rolfsen, 2012), we also found code maintenance in GitHub
ceived (Stray et al., 2002). In the following, we describe the
as an important coordination mechanism. In the following, we
practices that support alignment at Spotify.
present two practices that were found essential to enable effec-
tive collaboration on the codebase with increased autonomy. Collective review of important changes: One inherent problem
with scale is that it is nearly impossible to continuously follow
Formalized code ownership To ensure that squads can have
what is being changed where. Spotify’s answer to this is collective
end-to-end responsibility for the developed functionality and
review of important changes. When the squad’s work impacts
minimize the handovers, Spotify engineers are allowed to change
other squads, engineers are expected to consult the others either
code owned by other squads, following weak code ownership
informally or through so-called Requests-For-Comment (RFC) to
principles (Fowler, 2006) (as opposed to collective code ownership
ensure that there is an agreement about the emerging changes
which is equivalent to no ownership or strong code ownership,
and dependencies. The RFC document is typically prepared and
which often challenges the end-to-end responsibility allocation
shared with the rest of the company or the concerned tribe, open
on a functional level). We found that formalizing code ownership
for comments and improvement suggestions for a given period.
in general is a prerequisite for the well-functioning of the cross-
Similar effects in Atlassian are achieved by organizing regular
squad collaboration at scale. When a piece of code has an owner,
demos of teams’ work in progress, which admittedly increase the
there is a clear point of contact for those with questions and a
needs for coordination to arrange events (Kalliamvakou, 2017).
clear quality guard when changes emerge. The absence of code
owners hinders squads, as a member of Gamma explained, ‘‘Some Formation of parallel structures mandated to make decisions:
systems are not owned by anyone. If you need something from As a typical post-bureaucratic organization (Burns and Stalker,
them it’s impossible to get any help’’. Code changes are typically 1961), Spotify promotes network structures of control, author-
reviewed by the owning squad, which is responsible for coordi- ity, and communication, as essential mechanisms for collective
nating the changes and keeping an eye on the technical health of action. These are, for example, numerous workgroups, such as the
their code repositories. In some rare cases changes are reviewed Technology Architecture Group that owns TechRadar and guilds,
by members of a third squad, not authoring the change or owning which emerge on the need basis by self-organization or as a
the repositories, if changes are critical or interdisciplinary. response to a managerial directive and involve members from dif-
ferent squads, tribes, and sometimes even locations. The formally
Self-managing code ownership: Unfortunately, it is not uncom-
recognized groups are mandated to make decisions and might
mon that weak code ownership leads to slow pull request han-
have a budget. Similar groups for making collective product-
dling and bottlenecks and slows the squads’ progress down. As a
related decisions called communities of practice have also been
member of Alpha explained: ‘‘We are waiting for others to review
found in Ericsson (Paasivaara and Lassenius, 2014; Moe et al.,
our stuff. In the team we are quite quick to review [internal PRs]
2021).
because we can talk physically, but other teams can be quite slow be-
cause they have their focus. You have to poke them a lot sometimes’’; Constrained choice of technologies: Implementing changes in
and another member admitted ‘‘If someone puts a PR in our stack, other’s repositories can be troublesome if they are written in
8
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

a unique or rare programming language or using old unsup- illustrate with the social networks of the four studied squads (see
ported frameworks, as it might limit squads’ ability to implement Fig. 6).
changes independently. Clearly, with scale the number of used
technologies increases, while the awareness of what is imple- Horizontal communication patterns: Spotify squads are highly
mented using which technology decreases. To eliminate such collaborative and social, reaching out to other squads, experts,
situations, squads discuss what technologies shall be accepted, workgroup members, etc. This is evidenced in the way task in-
the list of which (called TechRadar) is maintained by the Tech- terdependencies are handled (Fig. 2), and the way information
nology Architecture Group. The different tools, apps, and infras- is shared (Fig. 6). In fact, an individual squad with experienced
tructures recommended for each engineering task are available in members might have tens of contacts outside the squad main-
the developers’ Marketplace called Backstage.1 tained on a regular basis (see examples of external networks of
Alignment of practices through tutorials and templates Beta and Delta in Fig. 6).
(Golden Paths): The wide variety of technologies and tools com- The spontaneous interactions of the engineers vary. They in-
bined with the large number of developers and development clude acquiring the knowledge missing internally in the squad,
locations makes it not only difficult to get onboarded as a new providing support to others, and dealing with task interdepen-
hire, but also for experienced engineers to produce consistent dencies. The communication typically bypasses the managerial
outcomes, especially when contributing to tasks outside of one’s
hierarchy, also known as ‘‘going role to role’’ in Zappos and other
comfort zone. To tackle these challenges, Spotify developed so-
participative organizations (Bernstein et al., 2016). However, the
called Golden Paths – tutorials to introduce engineers to tech-
nologies or best practices and templates that guide them on ability to communicate horizontally highly depends on the indi-
how to create a concrete type of services. Golden Paths are vidual squad member’s social integration and contact network, in
similar to coding guidelines and tutorials used in many other the absence of which the members might turn to their manager
organizations (Kalliamvakou, 2017). The development of Golden for help. However, in principle, mature and newly established
Paths is organized in the different workgroups, such as guilds squads as well as senior and junior employees at Spotify, as in
dedicated to a particular technology (Web and Backend), while Zappos (Lee and Edmondson, 2017), enjoy autonomy.
the resulting documentation is maintained by a dedicated tribe.
Social integration: The studied squads discussed the importance
of maintaining a good contact network and knowing who knows
5.2.3. Strategies for networking
what, as being well integrated into the company’s network helps
While some argue that achieving agility in large-scale projects
to coordinate the work efficiently. A member of Delta explained
requires blending in plan-driven approaches and increasing coor-
dination and management efforts (Dingsøyr et al., 2018; Petersen that getting their PRs done requires a buy-in and priority from
and Wohlin, 2010), some studies show that planned coordination others. These depended on the negotiator’s social connections,
through forums like Scrum-of-Scrums is inefficient (Paasivaara and the ability to influence others. As someone from a relatively
et al., 2012). This has been one reason for an increased interest new squad, Zeta, explained: ‘‘You have to use your network or
in mutual adjustment as the core coordination mechanisms that find people who have been longer in Spotify, [they] have a larger
enables alignment of teams’ efforts and heavily relies on the network. [. . . ] [Otherwise], sometimes we need to post to a squad’s
social networks of individuals and teams (Šmite et al., 2017; Slack channel: ‘‘Hey channel, can anybody help me out here?’’.’’
Moe et al., 2021). In the following, we describe the networking
Squads that perceive being successful in negotiations often have
practices that support autonomy at Spotify at scale, which we also
pioneer engineers who know nearly everyone (like Beta and Delta
in Fig. 6). Being aware of the organizational network, who knows
1 Open-sourced tool released by Spotify https://backstage.io/. what and who does what is important not only when working

Fig. 6. Squad external networks of contact.

9
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

on interdependent existing products, but also when coordinating

work on new products. As evidenced in the challenge faced by
Zeta who are both new in the company and working on devel-
oping a new piece of software: ‘‘Since we are building something
new, it’s unclear who we need to talk to’’.
Embedding: The practice of temporary mobility called embed-
ding, the social integration with other squads for some time,
is a practice encouraged at Spotify that helps grow social net-
works and foster inter-squad communication. Embedding has
many positive effects, outweighing the pain of the temporary
loss of a squad member. As someone from Delta explained, ‘‘You
can pair with an engineer who knows something you don’t. This
would help in doing pull requests and get an easier buy-in from
another team. People could embed with us as well, to have people
who could help us’’. Embedding has become popular also because
it contributes to personal growth. A similar practice of moving Fig. 7. Information sharing network. Every dot is an author of a StackOverflow
around different teams to acquire first-hand knowledge of how entry tagged with #Backend, every edge connects questions with answers and
others are working is also reported at Atlassian (Kalliamvakou, comments.

2017). Culture of mutual help: The culture of open collaboration and

contribution beyond organizational boundaries is emphasized in
Personal interaction: Despite Spotify being an international com-
Spotify’s Band Manifesto2 – ‘‘we’re all in this together’’. The suc-
pany with extensive experience with distributed work and ex- cess of the multi-squad development at scale highly depends
cellent technological infrastructure, we learned that effective on mutual help, which indirectly diminishes the autonomy (in-
interaction still highly depends on the ability to communicate dependence) of a particular squad. As an engineer stated, ‘‘The
face-to-face. Co-location was mentioned frequently when dis- number of dependencies is not a problem as long as no one becomes
cussing how squads negotiate with other squads. As one from a bottleneck’’. One way for a squad to become a bottleneck for oth-
Alpha noted, ‘‘Other teams can be quite slow because they have ers and for the company is to constantly prioritize their own tasks
their focus. You have to poke them a lot, sometimes through Slack, from the backlog. In fact, previous research has linked individual
sometimes I can go and say – Hey!’’ and another member added, autonomy with being less accessible for support (Drach-Zahavy,
‘‘It helps if you can explain what you are doing and why it is 2004), which evidently can be the case on a group level. This
done like this’’. Such communication across offices becomes more is challenging because squads depend on community help, on
challenging. As someone from Alpha explained, ‘‘Sometimes we squads solving pull requests for others, and more experienced
only see them in Slack, we don’t really know them. If we knew them Spotifiers responding to queries and providing expert opinions
or met them in person, the way we would talk would be different. about solutions to complex problems. Squads and individuals
have a reputation of being responsive or not. This is related not
Problems would be solved much faster’’. Members who travel to
only to availability for a conversation but also to personal activity
other Spotify offices also acknowledged the positive effect of
in solving pull requests promptly and responding to queries re-
visits on cross-site communication.
ceived through open and focused information exchange channels
Office spaces that facilitate socialization and networking: Spo- such as Slack3 and a corporate StackOverflow4 .
tify has invested a lot of resources and attention to provide Tools for information exchange: Our analysis suggests that tools
engineers with numerous opportunities to socialize in the office. like Slack and StackOverflow are excellent facilitators of collab-
These include comfortable large dining areas and coffee corners, oration even in the absence of personal contact. For example,
open spaces for seminars, video- and board-gaming spaces and junior backend developers, who do not know who the experts are,
even billiards and pubs. Being introduced to a friend of a friend or often turn to the backend guild’s Slack channel, which resembles
getting to know people who are interested in the same activities a ‘‘support line’’ with hundreds of users and tens of members
in such companies as Spotify is thus a common happening. monitoring the channel, ready to provide answers (Smite et al.,
2019). Similarly, the corporate StackOverflow accumulates an-
swers to a wide variety of questions from technical questions to
5.2.4. Strategies for information exchange legal frameworks (e.g., GDPR) or even personal experiences (see
In contrast to teams working on isolated tasks or stand-alone an example in Fig. 7). In slightly more than a year of its exis-
components, teams working on creating a joint system in parallel tence 2428 questions, 3112 responses and 3684 comments were
with many other teams are accompanied by the feeling of being a exchanged between the total of 929 users. Our analysis shows
piece of a system. As we discussed above, such systems are prone that half of the questions posted in StackOverflow are answered
to congestion, which occurs when teams are tasked to deliver within thirty minutes and 59% of the accepted answers come
more than they can (Cantor et al., 2016). Evidently congestion from members of other tribes, which engineers with the question
is often caused by barriers to autonomy, the lack of competence might not even know personally. Thus, those not knowing who
or many task dependencies, which may negatively affect the
whole company. One known congestion-avoidance mechanism 2 The Band Manifesto, https://www.spotifyjobs.com/the-band-manifesto/.
for teams in plan-driven organizations is to ask management 3 Slack at Spotify is one of the key communication tools used by individuals,

to limit their requests. But what happens in the contexts with squads and groups. It is also used to share knowledge, facilitate Q&A, and store
an archive for everyone to use.
increased level of autonomy? At Spotify, squads often help each 4 Spotify’s instance of StackOverflow. At Spotify this is a relatively new tool,
other and increase awareness and visibility into their work that in use since 2018, as a platform where users can post questions and seek advice,
indirectly supports alignment (Kalliamvakou, 2017). answer others’ questions, comment and vote on posts.

10
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

knows what can reach out to basically everyone subscribed to a 2010), most squads can handle most of their mutual dependen-
channel. More importantly, we found that 1/3 of the questions cies and interactions. In fact, no scaled agile practice, up-front
in StackOverflow are answered by the authors themselves. This planning, or supervision can yield similar results as also admitted
is because engineers take the initiative to help others and post by prior research (Bungay, 2011; Kalliamvakou, 2017; Paasivaara
tips and tricks to ease the work of peers. Those who donate and Lassenius, 2014; Moe et al., 2021).
knowledge also receive points in the user reputation score in The company’s main challenge is to continue ensuring team
StackOverflow, which adds an element of gamification. autonomy while growing. This is because being autonomous re-
quires being socially integrated into the company, which takes
Demos: When squads build something good and potentially use-
time. As the Spotifiers from Alpha referred to a phenomenon
ful for others, it should be shared. Sharing at Spotify is done
called the chain of autonomy: ‘‘If other teams are less autonomous,
in many ways. Squads make demos, tribes circulate the latest
we, being a part of the same system, become less autonomous. If we
developments in regular ‘‘Show & Tell’’ and ‘‘All Hands’’ sessions,
want to do something and another team is blocked because they are
there are a lot of ‘‘Lunch & Learn’’ sessions, where engineers and
not as autonomous as we are, there is a chain reaction’’. Because of
squads share interesting findings, many engineers at Spotify write
blog posts about new tools and libraries they’ve developed, and, these chain reactions, suboptimal solutions made by less mature
of course, post the news on Slack. squads working in isolation that result in the accumulation of
All these activities can be overwhelming and disturbing, as a technical debt might limit the future work of related squads.
member of a challenged squad Beta describes, ‘‘. . . activities outside As another from Alpha observed: ‘‘What affects us today is not
of development, going presenting at tribe meetings, contacting peo- our quality, but others’ quality’’. This also means that maintaining
ple – takes away the development focus and time. The expectation autonomy for a continuously growing organization will be a
is that developers are not just developers, but ambassadors for the constant challenge.
team’’. Yet, many squads acknowledge that maintaining their Several interesting directions for future research emerge from
reputation is important as it creates the prerequisite for a higher our findings. First, we recommend looking into the conditions of
degree of authority. granted autonomy for immature and challenged teams and the
ways of coaching teams to be autonomous. Second, it is reason-
6. Conclusions able to look at the team formation principles to maximize the
ability of a team to be autonomous (e.g., having a healthy mixture
Many researchers and practitioners have been skeptical about of seniority at the company present in the team). Third, future re-
the applicability of autonomous teams in large-scale and complex search may investigate the relationships between organizational
projects. This is one reason why large-scale agile projects often size and the very ability to employ autonomous teams, as well
combine agile and traditional methods to avoid chaos (Dingsøyr as the possible thresholds when autonomy becomes technically
et al., 2018; Bernstein et al., 2016), and in practice strive to unmanageable.
simplify jobs by creating complex organizational structures ex- Finally, one may wonder whether Spotify’s case is unique or
pressed in increased managerial overhead (Petersen and Wohlin, useful for others. The interest in autonomy and self-management
2010). However, uncertainty and frequent changes, that often emerge in many different contexts, not only within modern IT
accompany software development, make increased bureaucrati- companies published in software engineering research, but also
zation and control inefficient (Bungay, 2011). Decentralization in other industries published as research on the organizational
and de-bureaucratization instead suggest that the focus shall psychology and management (Lee and Edmondson, 2017; Bern-
be rather put on dealing with complex jobs within simple or- stein et al., 2016). The strategies we describe that help Spotify
ganizations (de Sitter et al., 1997). Our study is one example address autonomy at scale are per se not new. Although some
of a large decentralized organization developing software. Our strategies, such as embedding, might have not been that well
results demonstrate that Spotify can empower its squads with documented and the special focus on the large scale might make
a large degree of autonomy even at scale. Further, the com- the collection of practices less common. In our study, we refer
pany managed to keep a low number of employees with man- to other more traditional environments (Ericsson) and modern
agerial roles despite organizational growth. What helps Spotify companies such as (Atlassian, Zappos), which also report similar
succeed? We found that the key is the ability of squads to self- approaches. This means that our findings could be useful in large
organize – collaborate on the shared codebase, coordinate and industrial contexts with a high level of adaptability and fast-
align their efforts, share information and resources, and make changing environment, and even open-source projects, as pointed
informed decisions together. To facilitate squads with autonomy out by related research (Bernstein et al., 2016).
and ability to self-organize, the company promotes greater com-
mitment and accountability, cultivates network structures and CRediT authorship contribution statement
supports formation of collective fora that bypass organizational
boundaries (i.e., typical mechanisms of a post-bureaucratic orga- Darja Šmite: Conceptualization, Methodology, Investigation,
nization Burns and Stalker, 1961), while enabling just-necessary Data curation, Formal analysis, Writing – original draft. Nils
enabling constraints, which help balancing adaptability and reli- Brede Moe: Conceptualization, Methodology, Investigation, Writ-
ability (Bernstein et al., 2016). ing — review & editing. Marcin Floryan: Conceptualization, Re-
Of course, the Spotify journey is not problem-free. Our results sources, Validation, Writing – review & editing. Javier Gonzalez-
demonstrate that despite the efforts to decentralize the orga- Huerta: Data Curation, Formal analysis, Writing – review & edit-
nization by design, squads’ autonomy might be constrained by ing. Michael Dorner: Data Curation, Formal analysis, Visualiza-
factors beyond the managerial control. In our study, not all squads tion, Writing – review & editing. Aivars Sablis: Data curation,
were equally autonomous or accountable, some squads helped Formal analysis, Visualization, Writing – review & editing.
others more and faster while some admitted being a bottleneck,
some were better in informing about the changes while others Declaration of competing interest
prioritized their internal workload, some were better at handling
and continuously removing technical interdependencies while The authors declare that they have no known competing finan-
others were too inexperienced to navigate themselves in the cial interests or personal relationships that could have appeared
complex system evolution. Yet, as previously suggested (Elbanna, to influence the work reported in this paper.
11
D. Šmite, N.B. Moe, M. Floryan et al. The Journal of Systems & Software 200 (2023) 111649

Data availability Paasivaara, M., Lassenius, C., Heikkila, V.T., 2012. Inter-team coordination in
large-scale globally distributed scrum: Do scrum-of-scrums really work? In:
Proceedings of the ACM-IEEE International Symposium on Empirical Software
The data that has been used is confidential. Engineering and Measurement. IEEE, New York, pp. 235–238, 2012.
Petersen, K., Wohlin, C., 2010. The effect of moving from a plan-driven to an
Acknowledgments incremental software development approach with agile practices. Empir.
Softw. Eng. 15, 654–693, 2010.
Rey, C., Pitta, N., Ramonas, D., Sotok, P., 2019. Agile purpose: Overcoming
We sincerely thank the Spotify squads for volunteering their bureaucracy. In: Purpose-Driven Organizations. Palgrave Macmillan, Cham,
time to participate in our study. This research is co-funded by pp. 75–86.
Runeson, P., Host, M., Rainer, A., Regnell, B., 2012. Case Study Research in
the Swedish Knowledge Foundation within the ScaleWise project Software Engineering: Guidelines and Examples. John Wiley & Sons.
(KK-Hög grant 2019/0087) and the SHADE project (KK-Hög grant de Sitter, U., Den Hertog, J.F., Dankbaarl, B., 1997. From complex organizations
2017/0176), and by the Research Council of Norway through the with simple jobs to simple organizations with complex jobs. Hum. Relat. 50
10xTeams project (grant 309344). (5), 497–534.
Šmite, D., Moe, N.B., Floryan, M., Levinta, G., 2020. Spotify guilds: When the
value increases engagement, engagement increases the vlue. Commun. ACM
References 63 (3), 56–61.
Smite, D., Moe, N.B., Levinta, G., Floryan, M., 2019. Spotify guilds: How to succeed
with knowledge sharing in large-scale agile organizatons. IEEE Softw. 36 (2),
Bernstein, E., Bunch, J., Canner, N., Lee, M., 2016. Beyond the holacracy hype.
51–57.
Harv. Bus. Rev. 94 (7/8), 38–49. Šmite, D., Moe, N.B., Šāblis, A., Wohlin, C., 2017. Software teams and their knowl-
Bungay, S., 2011. The Art of Action: How Leaders Close the Gaps Between Plans, edge networks in large-scale software developent. J. Inf. Softw. Technol. 86,
Actions, and Results. Nicholas Brealey Publishing. 71–86.
Burns, T., Stalker, G.M., 1961. The Management of Innovation. Tavistock, London. Stray, V., Gundelsby, J.H., Ulfsnes, R., Moe, N.B., 2002. How agile teams make
Cantor, M., MacIsaac, B., Mannan, R., 2016. Steering software development objectives and key results (OKRs) work. In: Proceedings of the International
workflow: Lessons from the internet. IEEE Softw. 33 (5), 96–102. Conference on Software and System Processes and International Conference
Caroli, P., Caetano, T., 2020. Fun retrospectives: activities and ideas for mak- on Global Software Engineering. pp. 104–109.
ing agile retrospectives more engaging. Available online: https://www. Sutherland, J., Schwaber, K., 2013. The scrum guide. In: The Definitive Guide to
funretrospectives.com/daki-drop-add-keep-improve/. Scrum: The Rules of the Game. Scrum. Org, p. 268.
Cohen, S.G., Bailey, D.E., 1997. What makes teams work: Group effectiveness Darja Smite is a Professor of Software Engineering at Blekinge Institute of
research from the shop floor to the executive suite. J. Manage. 23 (3), Technology, Sweden and a part-time research scientist at SINTEF in Norway.
239–290. She leads research efforts on global software development and more recently
Dingsøyr, T., Moe, N.B., Fægri, T.E., Seim, E.A., 2018. Exploring software develop- remote working from home. Her research interests include large-scale agile
ment at the very large-scale: a revelatory case study and research agenda software development and software process improvement. Šmite received a
for agile method adaptation. Empir. Softw. Eng. 23 (1), 490–520. Ph.D. in computer science from the University of Latvia. She has led a number
Drach-Zahavy, A., 2004. Exploring team support: The role of team’s design, of nationally funded research projects related to the effects of offshoring and
values, and leader’s support. Group Dyn.: Theory Res. Pract. 8 (4), 235–252. scaling for the Swedish software industry, with partners such as Ericsson,
Elbanna, A., 2010. Rethinking IS project boundaries in practice: A multiple- Spotify, Telenor, ABB, DXC, Emerson Process Management, and Boss Media.
projects perspectve. J. Strateg. Inf. Syst. 19 (1), 39–51.
Fowler, M., 2006. Code ownership. https://martinfowler.com/bliki/ Nils Brede Moe is a chief scientist at SINTEF im Norway. He works with
CodeOwnership.html. software process improvement, intellectual capital, innovation, autonomous
Grant, A.M., Parker, S.K., 2009. Redesigning work design theories: the rise of teams, agile and global software development, and digital transformation. He has
relational and proactive perspectives. Acad. Manage. Ann. 3 (1), 317–375. led several nationally funded software engineering research projects covering
Guzzo, R.A., Dickson, M.W., 1996. Teams in organizations: Recent research on organizational, sociotechnical, and global/distributed aspects. Moe received a
performance and effectiveness. Annu. Rev. Psychol.. dr.philos. in computer science from the Norwegian University of Science and
Hackman, J.R., 1986. The psychology of self-management in organizations. In: Technology, and holds an adjunct position at the Blekinge Institute of Technology
Pallack, M.S., Perloff, R.O. (Eds.), Psychology and Work: Productivity, Change, in Sweden.
and Employment. American Psychological Association, Washington, DC.
Ingvaldsen, J.A., Rolfsen, M., 2012. Autonomous work groups and the challenge Marcin Floryan is the Technology Operations Lead at Spotify. He is a passionate
of inter-group coordination. Hum. Relat. 65, 861–881, 2012. technology leader focused on creating an environment where people can do
Jamshidi, P., Pahl, C., Mendonça, N.C., Lewis, J., Tilkov, S., 2018. Microservices: their best work together. Floryan is interested in complex adaptive systems,
The journey so far and challenges ahead. IEEE Softw. 35 (3), 24–35. agile software development, leadership, and organizational development. Floryan
Janz, B.D., Colquitt, J.A., Noe, R.A., 1997a. Knowledge worker team effectiveness: received an M.Sc. in biomedical engineering from the Warsaw University of
The role of autonomy, interdependence, team development, and contextual Technology, Poland.
support variables. Pers. Psychol. 50 (4), 877–904.
Janz, B.D., Wetherbe, J.C., Davis, G.B., Noe, R.A., 1997b. Reengineering the systems Javier Gonzalez Huerta is an associate professor in Software Engineering at
development process: The link between autonomous teams and business the Blekinge Institute of Technology, in Sweden, working on making companies
process outcomes. J. Manage. Inf. Syst. 14 (1), 41–68. more effective when managing their software assets aiming at helping them
Kalliamvakou, E., 2017. Collaboration Via Aligned Autonomy for Commercial to avoid asset degradation and Technical Debt. Gonzalez-Huerta received his
Software Teams (Doctoral dissertation). Ph.D. in Computer Science from the Universitat Politècnica de Valencia (UPV) in
Langfred, C.W., 2007. The downside of self-management: A longitudinal study 2014, after working in the industry for more than 10 years. His research focuses
of the effects tf conflict on trust, autonomy, and task interdependence in on Asset Management, Asset Degradation, and Technical Debt. Gonzalez-Huerta
self-managing teams. Acad. Manage. J. 50 (4), 885–900. has been doing applied research together with industrial partners like Ericsson,
Lee, M.Y., Edmondson, A.C., 2017. Self-managing organizations: Exploring the Spotify, Fortnox, and Swedbank for the last five years.
limits of less-hierarchical organizing. Res. Organ. Behav. 37, 35–58.
Mankins, M., Garton, E., 2017. How Spotify Balances Employee Autonomy and Michael Dorner is researcher and doctoral candidate at Blekinge Institute of
Accountability. Harvard Business Review. Technology, Sweden. His primary research is to measure, leverage, and improve
Manteli, C., Van Den Hooff, B., Van Vliet, H., 2014. The effect of governance on the continuous exchange and flow of information within communication net-
global software development: an empirical research in transactive memory works in software engineering and to understand the communication networks’
systms. Inf. Softw. Technol. 56 (10), 1309–1321. capabilities to cache, transport, deliver, and diffuse information on time. Before
Moe, N.B., Šmite, D., Paasivaara, M., Lassenis, C., 2021. Finding the sweet spot academia, he was data scientist and software engineer at Siemens.
for organizational control and team autonomy in large-scale agile software
developent. J. Empir. Softw. Eng. 26 (5), 101. http://dx.doi.org/10.1007/ Aivars Sablis is a Project Manager in SAF Tehnika JSC, Latvia and a Ph.D.
s10664-021-09967-3. student in Software Engineering at Blekinge Institute of Technology. His research
Olsson, H.H., Bosch, J., 2016. No more bosses? In: International Conference on interests include knowledge management and team coordination in large-scale
Product-Focused Software Process Improvement. Springer, Cham, pp. 86–101. agile software development. He has participated in nationally funded research
Paasivaara, M., Lassenius, C., 2014. Communities of practice in a large distributed projects related to global software development and project management in
agile software development organization - case ericsson. Inf. Softw. Technol. large-scale distributed software development projects, with partners such as
56, 1556–1577, 2014. Ericsson, ABB, Telia, and Spotify.

12