In 2009, a small group of employees at Spotify decided that in order to build the engineering culture they wanted, they would need to do things differently than most companies. They were expanding quickly and needed to find ways to ensure the company’s growth wouldn’t keep their engineering team from moving fast. Five years later they’ve begun talking about what makes agile at Spotify so unique.
According to Henrik Kniberg, one of Spotify’s agile coaches, many of the engineers went to agile conferences, read books on the subject, and spoke with engineers at companies like Twitter, Netflix and Google. Then they set off to experiment with all the new ideas they had gathered.
“Most parts of our structure weren’t designed up front. We evolved by doing lots of experimenting and having a change-friendly culture,” Kniberg said in a recent interview with Highfive. We spoke with him to understand Spotify’s alternative approach to agile and how it has made them so successful.
Organize for autonomy
About five years ago, Spotify decided to break their engineering team into eight-person autonomous squads. Each team worked towards a common company mission, but had the autonomy to work on a chosen project.
Allowing teams to choose what they worked on was difficult to manage at first, but Spotify learned how to make it work. The company created an internal motto “Be autonomous, but don’t suboptimize.” As Kniberg writes, building products at Spotify should be like being a part of a jazz band; although each musicians is autonomous and plays a different instrument, they should all listen to each other and focus on the whole song.
Spotify has been able to afford a high level of autonomy by establishing loose boundaries like squad missions. For example, one team’s mission may be “To make Spotify the best place to discover music,” while another may be “To make internal a/b testing as easy as possible for other teams at Spotify.” This aligns the team around a common goal. In addition team leaders create product strategies and short term goals that are discussed every quarter. The result is a creative environment and a reliable product — an ideal almost every tech company strives for.
Alignment affords autonomy
Kniberg recently made a short video outlining how he and his team think about the tradeoff between alignment and autonomy. In the video he explained that Spotify strives to offer a high degree of autonomy without suffering from a lack of alignment. “We’re trying hard to be aligned and autonomous and we keep experimenting with ways of doing that. The stronger alignment we have, the more autonomy we can afford to grant.”
He explains the relationship between alignment and autonomy by drawing a grid. On one end of the spectrum you have low alignment and low autonomy: “No high level purpose. Just shut up and follow orders,” as Kniberg says.
“Many leaders are good at telling employees what problem needs to be solved, but also tell them how to solve it.” These companies find themselves in the upper left quadrant. “Low alignment and high autonomy means teams do whatever they want. Leaders are helpless and the product becomes a frankenstein.” Companies with this management style find themselves in the bottom right quadrant of Kniberg’s grid.
At the top right quadrant of Kniberg’s grid is the company that Spotify strives to be. He explains that high alignment and high autonomy means that leaders focus on what problem to solve and let the teams figure out how to solve it. The result is happier employees and more creative ways of solving a problem.
Autonomy leads to cross-pollination
In addition to enjoying a boost in creative output and employee satisfaction, Spotify’s autonomous work environment results in a diversity of agile practices and tools in use. The company’s leadership team doesn’t enforce which agile practice to use and team leads don’t tell employees what tools they must use. Instead Spotify gives employees the freedom to choose what will make them most productive.
For example, teams can use Kanban, estimate stories, or practice whatever development process they want. Similarly, an engineer can choose to use whatever code editor she pleases. When enough teams begin using the same tool, like Git, that becomes the path of least resistance and other squads naturally choose it. Squads start supporting that tool and it becomes a de facto standard. This freedom gives the company a balance between consistency and flexibility.
Apply open source methodologies to internal products
One of the most unique methods that Spotify has implemented actually originates from a common open source practice. In situations where one squad needs to access the code base of another team, a squad will first ask for the change. But in the likely event that the other team (let’s call them squad B) is too busy, the team asking for a change (squad A) is free to change the code. After making changes Squad B can submit the code to Squad A for a code review.
This culture of peer code review improves quality and spreads knowledge. But more importantly it enables each squad to move as fast as possible.
Spotify’s relentless pursuit of agility has driven them to break many of the traditional rules of scrum and create an entirely new agile practice. They’ve allowed decisions to happen locally which enables a team of more than 1,000 people to move a lot like the 100 person startup they were five years ago. And keeping squads autonomous has minimized the amount of hand-offs, which allows the product to scale without getting bogged down by dependencies and coordination. The result is one of the best engineering cultures in technology and an incredible product.