Close Cookie Notice

Welcome to the MIT CISR website!

This site uses cookies. Review our Privacy Statement.

Red briefing graphic
Research Briefing

Designing for Digital—Lessons from Spotify

This briefing examines what established companies can learn from Spotify as they attempt to reorganize around empowered teams.
By Abayomi Baiyere, Jeanne W. Ross, and Ina M. Sebastian

To remain competitive, established companies are increasingly recognizing the need to develop digital offerings. Digital offerings, however, are dependent on software. Unlike traditional products and services, software-based offerings constantly evolve in response to both customer demands and new opportunities to address customer needs. To support digital offerings, companies must adopt new organizing principles—specifically, empowered teams that own digital components. This briefing examines what established companies can learn from Spotify as they attempt to reorganize around empowered teams.

Access More Research!

Any visitor to the website can read many MIT CISR Research Briefings in the webpage. But site users who have signed up on the site and are logged in can download all available briefings, plus get access to additional content. Even more content is available to members of MIT CISR member organizations.

To compete in the digital economy, MIT CISR research has found that, like digital start-ups, established companies must both rapidly create digital offerings and continuously introduce new features and services that enhance the value proposition.[foot]For a definition and description of digital offerings, see J.W. Ross, C.M Beath, and I.M. Sebastian, “Digitized ≠ Digital,” MIT Sloan CISR Research Briefing, Vol. XVII., No. 10, October 2017.[/foot] Companies with many thousands of employees cannot hope to pivot to new market opportunities as rapidly as companies that are just starting up. But big companies can—and must—learn how to innovate quickly.

MIT CISR has studied how digital music provider Spotify continues to rapidly innovate as it grows. To be sure, as a company with three thousand employees, Spotify’s growth does not rival that of the biggest digital companies, such as Amazon, Google, Facebook, and Salesforce. But Spotify has been unusually public about its organizational design and management practices—practices that are consistent with those described by the largest digital companies. And Spotify finds it must constantly adapt to new and unforeseen competitors—a threat faced by many established companies.

We want teams to go and explore new techniques, new technologies, or try out new tools so that we get some innovation. We allow every team the freedom of taking the tools that they believe are the best for them.


MIT CISR research has found that the need to rapidly and persistently create digital offerings will require companies’ digital product development units to more closely model the design and culture of start-ups. This briefing summarizes what we believe established companies can learn from Spotify’s product organization, which makes up approximately half of the company. The briefing is based on public information and a recent MIT CISR interview with Anders Ivarsson, an organizational coach at Spotify, who is quoted throughout.[foot]MIT CISR interviewed Anders Ivarsson in September 2017.[/foot]


To facilitate speed, companies must design themselves to minimize the obstacles to getting work done.[foot]K. Dery, and I.M. Sebastian, “Building Business Value with Employee Experience,” MIT Sloan CISR Research Briefing, Vol. XVII, No. 6, June 2017.[/foot] This requires empowering and supporting problem solvers. Like many other companies, Spotify has created small agile teams—also known as squads—that are responsible for rapid development and delivery of new offerings and capabilities. Spotify emphasizes the need to make squads autonomous so they can be creative about what they deliver and how they deliver it.

At Spotify, rapid innovation depends on squads learning quickly what does and doesn’t work. Thus, a key principle at Spotify is to encourage experimentation and learning. Importantly, when experiments fail, leaders do not assume responsibility for dictating how to fix things. Instead of dictates, Spotify relies heavily on coaching—in particular, agile coaching. Agile coaches are team development experts who work across squads to facilitate team dynamics and get the squads working together on new objectives.

Squads exercise autonomy in both their work practices and their deliverables.[foot]Katja Lotz, “Self-Organising the Company Re-Org at Spotify,” recorded January 21, 2016 at News UK in London, UK, video, 18:11.[/foot] For example, more than a year ago, management floated the idea of squad leaders who would enjoy elevated status and salary relative to the other squad members. No squad was required to name a leader, and only three of the company’s approximately thirty squads chose to do so. The three that chose a leader subsequently dropped the role.

On the other hand, management introduced the role of road manager to coordinate a couple of large projects. The road manager handled logistical details, much like managers of bands ensure that gigs go smoothly. Squads picked up on the value of that role, and most have implemented it. Fundamental to team autonomy is the premise that the people working on a product or service are best equipped to make decisions about it.

To accelerate learning and innovation, squads regularly re- lease new digital features and offerings. The squads get rapid feedback from key constituent response to the new features and can swiftly map out next steps. Spotify’s squads deliver rapid innovation because they are designed specifically for speed rather than efficiency.

[We are] over investing both in systems and in people because we believe this is faster. We might not have the optimal resource allocation or there might be double work happening in the company. We’re fine with that monetary investment because we believe the speed it gives us is worth much more to the company.



As Spotify has grown, it has worked to make sure that autonomy doesn’t lead to chaos. The company has long assembled squads into tribes, so that major offerings can be divided into components. Each squad in a tribe fully owns one or more components. This arrangement coordinates activities around major offerings and capabilities, but it does not ensure alignment across tribes.

The central mechanism for ensuring alignment across tribes is Spotify’s concept of mission. Missions are statements of the key strategic objectives of tribes (and ultimately individual squads). For example, the mission of a music delivery tribe is “providing fast and reliable access to all the world’s music.” The mission of an infrastructure tribe is “enabling high product development speed while maintaining a highly available service.”[foot]Anders Ivarsson and Henrik Kniberg (2016), “Scaling Agile with Tribes, Squads, Chapters & Guilds,” recorded February 6, 2013 at JFokus Developers Conference in Stockholm, Sweden, video, 47:37.[/foot]

Missions are guided by—and to some extent help establish— the company’s big “bets.” While missions define tribes’ objectives, bets define strategic objectives for the whole company. For example, a bet could be, “We believe we can increase retention or we can reach X users or more artists by [doing] this.”

“Company ‘bets’ is the name for our top company priorities. We call them the top ten things, or the top five things we do as a company. We call each of them a bet, because we actually don’t know what the downfall will be... We start with, what are all the data we have around this? What insights are we drawing from this data? Based on those insights what are our beliefs about the world? Based on those beliefs, what is the bet that we’re making?”

Spotify's missions and bets are established through both bottom-up and top-down processes, then articulated as goals to be achieved within a given time frame and mapped to clearly defined metrics.

“Sometimes the idea comes from the leadership team itself, like here is where the industry is going or here is a problem in our metrics or something we need to fix on a strategic level or a market launch we need to do. More often it’s bottom up... Anyone can pitch new company bets and then get support from some different functions in the company that help them really flesh it out.”

As market conditions change and the company identifies new opportunities, bets and missions also change. Such changes can require that squads and tribes be reformulated. In order to consistently address market demands, change is a constant at Spotify.


Missions and bets help coordinate individual team efforts, but they don’t ensure synchronization of daily activities. Accordingly, Spotify has introduced mechanisms for sharing knowledge both within and across tribes.

At Spotify, every squad member is assigned to a chapter, with a chapter lead who serves, in effect, as a line manager. Chapters are often organized around a single competency, such as graphic design or backend development. Chapter members meet to discuss issues and ideas specific to their roles. This facilitates learning across squads and leads to more coherent technical decisions. Chapters also allow for team flexibility because individuals can move to a new squad without changing chapters and thus managers.

Guilds bring together people who share similar interests across different tribes and sections of the organization. Guilds stage internal “unconferences” to share the latest discoveries in their domain and to formulate best practices. In this way, guilds help members develop specialized skills.

Agile coaches also play an important role in sharing knowledge. Because they work with multiple squads in a tribe, they can recommend practices that other squads have implement- ed. Formal and informal knowledge sharing mechanisms have evolved, such as post mortems following failures so that teams can learn from one another’s failed experiments.[foot]Jimmy Janlén, “Agile Culture @ Spotify,” recorded June 11, 2015 at Agile Auckland Meetup, video, 37:54.[/foot]


Spotify’s desktop client was once a monolith. This design was viable when the company’s product was simple, but as the company added offerings and features and product teams multiplied, the monolithic structure—like legacy systems in established companies—was limiting speed and increasing risk. It also limited team autonomy because new code could only be put into production when all teams had stable code and all interactions could be tested.[foot]Henrik Kniberg, Agile Answers #13, published December 16, 2016, video, 10:21[/foot]

Spotify addressed this issue by defining standards for a modular architecture that relied on API-enabled services.[foot]Henrik Kniberg, “Spotify engineering culture (part 1),” on the Spotify Labs website, March 27, 2014.[/foot]

“On the back end specifically, we are heavily leaning on microservices, which means that every team owns a few services rather than, you know, ten or twenty teams all work[ing] on one big service. This allows [the teams] a lot more freedom and autonomy and enables them to move a lot faster.”

The modular, API-enabled architecture isolates the potential impacts of a failed experiment. Spotify refers to this approach as “limited blast radius.”[foot]Henrik Kniberg, “Spotify engineering culture (part 2),” on the Spotify Labs website, September 20, 2014.[/foot] For example, one squad’s experiment might inadvertently take out the album pictures from the music platform. The limited blast radius ensures that users can still play music and search. Because a modular architecture limits risk, it enables constant releases by individual squads and thus accelerates experimentation and learning.

Ultimately, Spotify’s modular, API-enabled architecture facilitates autonomy by providing a stable foundation for development of offerings and features.


Figure 1 summarizes the key design elements in Spotify’s approach to sustaining rapid innovation as it grows. As established companies introduce digital offerings, we believe that their product development organizations will require an environment that in some way embodies these four design elements:

  1. Empowered teams that encourage and enable constant delivery and learning through experiments
  2. Missions that provide distinct goals and objectives to those autonomous teams and align teams without introducing layers of hierarchy
  3. Formal knowledge sharing mechanisms that synchronize activities as the number of teams grows and expands the digital offerings portfolio
  4. Architectural standards that facilitate autonomy by ensuring that individual components are compatible

Figure 1: Key Design Elements for Digital Innovation

Based on MIT CISR's case study of Spotify in this briefing; J.W. Ross, I.M. Sebastian, and C.M. Beath, “BNY Mellon: Redesigning IT for Digital Transformation,” MIT Sloan CISR Working Paper No. 416, April 2017; and C.M. Beath, I.M. Sebastian, and J.W.Ross, “Northwestern Mutual’s Digital Transformation: Redesigning IT,” MIT Sloan CISR Working Paper No. 423, October 2017.

Leaders at Spotify note that the company is constantly evolving. No set of practices works exactly as planned and every solution exposes a new issue. Thus, the company must constantly redesign itself to address current issues and opportunities. As leaders at established companies attempt to become agile at scale, they too will encounter daily challenges. We expect they will find that persistently addressing those challenges yields a substantial payoff.

© 2017 MIT Sloan Center for Information Systems Research, Baiyere, Ross, and Sebastian. MIT CISR Research Briefings are published monthly to update the center's patrons and sponsors on current research projects.

About the Authors


Founded in 1974 and grounded in MIT's tradition of combining academic knowledge and practical purpose, MIT CISR helps executives meet the challenge of leading increasingly digital and data-driven organizations. We work directly with digital leaders, executives, and boards to develop our insights. Our consortium forms a global community that comprises more than seventy-five organizations.

MIT CISR Patrons
Axway, Inc.
Pegasystems Inc.
The Ogilvy Group
MIT CISR Sponsors
Alcon Vision
ANZ Banking Group (Australia)
Banco Bradesco S.A. (Brazil)
Banco do Brasil S.A.
Bank of Queensland (Australia)
Barclays (UK)
BlueScope Steel (Australia)
BNP Paribas (France)
Caterpillar, Inc.
Cemex (Mexico)
Cochlear Limited (Australia)
Commonwealth Superannuation Corp. (Australia)
Cuscal Limited (Australia)
CVS Health
Dawn Foods
DBS Bank Ltd. (Singapore)
Doosan Corporation (Korea)
Fidelity Investments
Fomento Economico Mexicano, S.A.B., de C.V.
Fortum (Finland)
Gilbane Building Co.
Johnson & Johnson (J&J)
Kaiser Permanente
King & Wood Mallesons (Australia)
Koç Holding (Turkey)
Nasdaq, Inc.
NN Insurance Eurasia NV
Nomura Holdings, Inc. (Japan)
Nomura Research Institute, Ltd. Systems Consulting Division (Japan)
Novo Nordisk A/S (Denmark)
OCP Group
Pacific Life Insurance Company
Posten Bring AS (Norway)
Principal Life Insurance Company
Ramsay Health Care (Australia)
Raytheon Technologies
Scentre Group Limited (Australia)
Schneider Electric Industries SAS (France)
Stockland (Australia)
Tabcorp Holdings (Australia)
Telstra Limited (Australia)
Terumo Corporation (Japan)
Tetra Pak (Sweden)
Truist Financial Corporation
UniSuper Management Pty Ltd (Australia)
Uniting (Australia)
Webster Bank, N.A.
Westpac Banking Corporation (Australia)
WestRock Company
Wolters Kluwer
Xenco Medical
Zoetis Services LLC

MIT CISR Associate Members

MIT CISR wishes to thank all of our associate members for their support and contributions.

Find Us
Center for Information Systems Research
Massachusetts Institute of Technology
Sloan School of Management
245 First Street, E94-15th Floor
Cambridge, MA 02142