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:
- Empowered teams that encourage and enable constant delivery and learning through experiments
- Missions that provide distinct goals and objectives to those autonomous teams and align teams without introducing layers of hierarchy
- Formal knowledge sharing mechanisms that synchronize activities as the number of teams grows and expands the digital offerings portfolio
- Architectural standards that facilitate autonomy by ensuring that individual components are compatible