Our Analysts' Insights

Our current research into continuous localization has revealed more companies adopting the “Spotify Model” to organize their development teams – and in some cases all business functions. Since Spotify has been in the news quite a bit over the last few weeks, we thought localization teams should be on the lookout for the model to be coming their way.

Quick Overview of the Spotify Model for Development Teams
 

Basically, the Spotify model allows groups of developers to organize themselves into very small teams – known as squads – that focus on putting their own code into production with no centralized control. Squad members are also members of “chapters” that represent competency areas such as quality assurance or web development. Squads are grouped into “tribes,” which function as light matrix organizations. There are also “guilds” that are company-wide communities of interest where people gather to share knowledge related to a specific area.


Source: Henrik Kniberg at engineering.atspotify.com

If all of this sounds like a form of controlled chaos, those who practice it confirm that it is. One of the company’s engineers explains the model here in his own words. We interviewed Spotify recently, and they confirmed that they’re still using this model based on hundreds of squads.

Why do engineers like this model? They can release more frequently through self-service and fewer – if any – hand-offs. Much less planning discipline is required – if a team misses today’s release train, they simply jump on the next one. Feature toggles hide unfinished features, but still allow developers and testers to uncover integration problems and avoid code branches. In sum, the model allows teams to experiment and learn much faster than traditional Agile set-ups.

While all of this controlled chaos may be great for creative engineers through removing processes that get in their way, that’s not necessarily the view from the localization team. The Spotify model has a big impact on localization because development teams are constantly morphing – even more than usual under Agile or continuous integration/continuous deployment (CI/CD) models. Therefore, it’s very difficult to trace code back to the people who developed it – obviously a nightmare if the code is not extremely close to 100% globalization-compliant at all times, regardless of new developers joining and old ones leaving.
 

Prepare to Integrate Under the Spotify Model with Your Eyes Open
 

Similar to Agile and CI/CD, each company will implement the Spotify model based on its own organizational culture. That being said, here are a few areas that we recommend that localization teams be ready to handle:

• Spotify developers never intended for companies to adopt their model. Enough said. Implementers beware.
   
• The model increases the urgency for engineers to take all responsibility for global-ready code. This requirement is a non-starter. Without it, there is no hope for any flavor of continuous localization to be successful.
   
• The context conundrum doesn’t go away. If anything, it becomes more of a challenge to balance a) alignment with engineering velocity with b) the quality of the global customer experience. At the end of the day, the localization team must align what it delivers to business requirements. No easy answers here.
   
• Localization must pivot from project- to program-based roles. Doing so allows you to integrate more tightly with product design, product management, and engineering and to be more proactive. This is essential because, under the Spotify model, no one really owns anything anymore over time within engineering. Ergo, you can’t go back and ask someone about a string. This requires that localization be involved and vocal throughout the code development and delivery process at the program, not the project, level.

A mindset that views continuous localization as simply an avenue for automating parts of various workflows to increase velocity is no longer enough. It’s about integrating as deeply as possible with the processes and technology of the teams that design, create, and deliver code. Our current research also shows that continuous localization isn’t just for software strings anymore. If you’re interested in more details of the results of this research, contact rebecca@csa-research.com.