Working with Squads 🪖
Real-life experience and lessons learned from applying the famous Spotify model.
Today’s piece is from Nicola, and explores a well-known topic in organizational design: the Spotify Model!
Nicola has extensive first-hand experience with it, and today he shares the lessons he has learned throughout the years, including benefits, challenges, and plenty of practical advice.
As a team or department leader, one of the most gratifying experiences is watching your team grow. What starts as leading a handful of people can, almost imperceptibly, evolve into managing multiple expanding teams. But with growth comes a unique set of challenges.
Over the past decade, I've navigated this journey firsthand. From restructuring teams and implementing new processes to balancing innovation with maintenance, I've experienced the full spectrum of scaling pains. Eventually, I found myself at the helm of an entire department, proud of our established culture and processes that consistently delivered high performance and great products.
However, success breeds its own challenges. As our existing products required more maintenance, we faced a common dilemma: how to balance upkeep with innovation.
The natural inclination is to prioritize maintaining what works, but this approach comes with two significant downsides:
🏃♂️ Innovation — in the fast-paced world of tech, staying current and responsive to market changes is crucial.
🎨 Motivation — high-performing, product-oriented teams often lose motivation when innovation takes a backseat to maintenance.
About a year ago, I found myself at this exact crossroads.
We had a great team, both culture and performance-wise, with successful products used by thousands of customers, but we were spending most of our time on maintenance, leaving little room for new features or products.
I knew it was time to shake things up.
I'd always been intrigued by the Spotify Squad model, and at the beginning of 2024, I decided to implement it with my teams. The results were impressive, and I'm excited to share our experience with you.
In this article, we'll explore:
🎵 The Spotify Squad model — how it works and what are the main blocks.
⚖️ Benefit and challenges — the pros and cons of this approach.
🚀 Getting started with Squads — the essential requirements.
🔧 How to work with team Squads — implementing the model effectively.
Let's dive in!
🎵 The Spotify Model
Team squads are a concept made popular by Spotify due to its innovative approach to agile development.
This approach was first detailed in two videos published on the Spotify Engineering Blog in 2014 (part 1, part 2).
I still remember being amazed by many aspects of this culture when I watched them. However, even though I drew much inspiration from their cultural practices, I never had the chance to experiment with the model firsthand.
The idea was to create mini-teams, each with the autonomy to manage their own projects as if they were a self-contained startup.
1) Squads 🎽
A Squad is the basic unit in this model, similar to a small startup team.
Each squad has the following characteristics:
👥 Optimal-sized — typically, squads consist of less than 8 people, a size that supports effective collaboration, without turning into an unmanageable mess.
🎯 Focused — each squad operates with a clear, focused mission, aligning their efforts to specific company goals or product areas.
🤝 Cross-functional — squads are made of members from various disciplines like engineering, design, product management, and QA, enabling them to operate independently.
🚀 Autonomous — squads have the autonomy to decide how they work, which technologies to use, and how to best achieve their goals.
👑 Accountable — each squad owns the results of their work, fostering a sense of responsibility and accountability among its members.
⏱ Fast — the small size and self-sufficiency of squads allow for quick decision-making and rapid execution of tasks.
Over the years, Spotify's number of squads has consistently grown, leading to the introduction of more forms of structure. While these sub-structures were irrelevant to my experiment, I will briefly describe them for the sake of completeness.
2) Tribes 👥
A Tribe is a collection of squads working in related areas, often within the same business domain or feature set.
The primary role of a tribe is to provide support and facilitate collaboration among its squads.
Tribes help maintain alignment across squads so that they do not drift into conflicting directions even though each operates independently.
A tribe is led by a Tribe Lead, who focuses on providing the best environment for squads to succeed, rather than managing the specifics of projects.
3) Chapters 📙
Within tribes, individuals from different squads who perform similar roles (such as backend developers or product managers) are grouped into Chapters.
A chapter is a way to organize competency areas across squads.
Each chapter has a leader, usually an experienced individual in the specific field, who is responsible for the growth and development of the members, even though they work in different squads.
4) Guilds 🪄
Guilds are interest groups anyone in the company can join, regardless of their tribe or squad affiliation.
Guilds span the whole company and are organized around topics like testing, user experience, or data science: