Spotify | Tribe Engineering Model

ou may have heard of the most common Product Lifecycle framework, or model used these days – Agile and various flavors like Scrum, Kanban, and others. The goal of Agile as a model was to bring in a method to contain the complexities in the development lifecycle, in turn enhancing the throughput of the entire effort.

Over the years, I have worked with teams following Waterfall and later teams that adapted to Agile. Often, organizations try to declare a 'one size fits all approach and have little flexibility given to the groups to decide which model to choose. This strategy backfires when the product or project requirements aren't aligned with the teams' goals.

Spotify, over the years, has innovated upon its processes and developed what's called a 'Tribe Engineering Model.' The teams here have greater flexibility to choose which methodology they should follow based on the requirements in front of them.

What is the Tribe Model?

The model consists of units like Squads, Tribes, Chapter, Guild, Trio, and Alliance. The model is not entirely new in itself, but itfeels like an iterative innovation guided by the organization's needs.

Squads are cross-functional autonomous teams of 6-12 individuals focusing on a particular feature set.

Tribes - This unit is built when multiple squads collaborate on the same feature.

Chapter – It's a community of technology specialists belonging to a tribe that ensures the tech standards and best practices are ingrained in the effort throughout.

Guild - This is a community of folks passionate about any particular topic. Members here can come from multiple tribes as well.

Trio - This unit is a combination of three people- Tribe Lead, Design Lead, and Product Lead; the aim is to maintain synergy in goals while working on a feature.

Alliance - At times, the product requirement may call for deeper collaboration, requiring multiple tribes to collaborate. Alliance is a combination of Tribe Trios who collaborate and guide their tribes on bigger product goals.  

Unlike in Scrum, there aren't many other practices followed; Squads may have sprint planning and retrospectives and have greater flexibility to figure out the path to success.

What are the benefits of this model?

Spotify wanted to move faster, build superior products and features, and earn minimum technical or organizational debt in the process.

• Outcome-driven approach – There are minimum processes to be followed; instead, the squads are aligned towards ensuring success in individual team deliverables and working towards a standard product success goal.
• Boundless Autonomy – Moving away from enforcing compliance, Squads have greater autonomy to figure out the best possible solution. Squads also get to decide whether a particular product or feature needs to be developed or not! This means there's an environment of trust at each level in the organization and, more importantly, among the team members.
• Superior Customer Experience – The model ensures the teams work on products or features that customers are obsessive about. This calls for greater experimentation and filtering of the features and products. But, the final product is bound to take customer experience to greater heights.

A lot of teams and companies over the years have made various unsuccessful attempts at copying this model. The model may look very simple, but it has to be built upon the unique culture that Spotify has fostered for all these years. For the model to work, a major cultural re-engineering may be required to build greater trust and autonomy at each level, more importantly among the team members.

Please provide your feedback on my articles at heyy@devanggaur.com.Your feedback will be invaluable towards improving the content.

Image credits - Google Images