Designing for Digital—Lessons from Spotify

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.

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]

A FOCUS ON AUTONOMY

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.

BALANCING AUTONOMY WITH ALIGNMENT

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.

SHARING KNOWLEDGE ACROSS TEAMS

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]

ARCHITECTING A FOUNDATION

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.

WHAT’S A BIG COMPANY TO DO?

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

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.