The Anatomy of a Successful Team Squad
What I Learned from My Recent Experiment with the Spotify Squad Model
After a decade of leading teams at the same company and having the good fortune to work with great people who make even huge projects run smoothly, you might think I’m just coasting on the successes of past years.
However, if you know me, you know that I love to experiment, especially with processes.
That's why one of my goals for 2024 was to experiment with a “new” work approach, particularly the one adopted by Spotify some years ago: the Squads Model.
This wasn't just about experimentation; it was a necessity.
The more you develop, the more you have to maintain. Over the years, the workload within my teams has significantly increased, taking up space that could be used for new developments and sometimes making it difficult to focus on new features for the products we manage.
For this reason, after discussing it with my department leadership team, we decided to try applying the Squad Model to our team, which has a more traditional—though still very flat—structure.
In this article, I will share my recent learnings about the Spotify model and some tips from our direct experience implementing it.
This is what we will cover:
🎵 The Spotify Squad Model
How it’s structured and how it works
What are the potential benefits
What challenges it brings
🔧 How to work with Team Squads
What you require to work with Squad Model
Some suggestions coming directly from my experience
🎙️ Introducing Cliff Hazell (Ex-Spotify)
Let's be honest: one successful experiment doesn’t make me a great scientist.
For this reason, and to gain the perspective of someone who experienced the original Spotify Model firsthand, I contacted my friend Cliff Hazell, who worked at Spotify from 2014 to 2018 and was directly involved with this model.
Cliff was so kind to answer some questions, which you’ll find throughout this article, to reinforce certain concepts.
Nicola: Can you briefly introduce yourself and describe the role you had at Spotify?
Cliff: I’m Cliff, and my background is in Product and Business Management, previously Head of Product and General Manager at two Internet Providers in South Africa.
At Spotify, I leaded a team of 4 organizational coaches working across a 600-person organization responsible for the payments stack, customer operations, and the premium business.
I also worked in Data and Infrastructure for 2 years, supporting the early stages of migration to Google Cloud Platform, and scaling the area from 80 to 250 across 3 countries.
Cliff also writes a blog sharing many insights from his experience at Spotify.
🎵 The Spotify Model
Team squads are a concept popularized by Spotify due to their 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.
Squads
A Squad is the basic unit in this model, similar to a small startup team.
Nicola: How would you describe the Team Squads concept in one sentence to someone unfamiliar with it?
Cliff: Squads were mission-led, cross-functional teams with a single common goal. The idea was to reduce dependency and provide as much autonomy and freedom to move as fast as possible.
Each squad usually has the following characteristics:
👥 Optimal Size: typically, squads consist of less than 8 people, a size that supports agility and effective collaboration without becoming unmanageable.
🎯 Focused Mission: each squad operates with a clear, focused mission, aligning their efforts to specific company goals or product areas.
🤝 Cross-Functional Team: squads are composed of members from various disciplines like development, design, product management, and QA, enabling them to operate independently.
🔄 Agile Practices: squads typically employ Agile methodologies such as Scrum or Kanban to manage their work, ensuring flexibility and continuous improvement.
🚀 Autonomy: squads have the autonomy to decide how they work, which technologies to use, and how to achieve their objectives best.
🏆 Performance Ownership: each squad owns the results of their work, fostering a sense of responsibility and accountability among its members.
⏱ Fast Execution: The small size and self-sufficiency of squads allow for quick decision-making and rapid execution of tasks.
Nicola: How autonomous were the squads in terms of decision-making and project direction?
Cliff: This varied widely across areas of the organization. In general, most squads have more influence over decisions within their mission than over what mission was funded. Although there were mechanisms for raising missions and ideas so that they got funded, there were definitely cases where a partner company or senior executive had a very clear direction already set. In most cases, people would know this when they signed up to work on it, though.
Over the years, Spotify's number of squads has consistently grown, leading to the introduction of more forms of structure. While these substructures were irrelevant to my experiment, I will briefly describe them for the sake of completeness.
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.
Chapters
Within tribes, individuals from different squads who perform similar roles (such as backend developers, testers, or product managers) are grouped into Chapters.
A chapter is a way to organize the competency areas across the 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.
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 web development, user experience, or data science.
They are informal communities for sharing knowledge, tools, and practices and initiating wider discussions about these topics.
Not Only Team Structure…
While the team structure was probably the most fascinating part of the model, successful implementation required much more:
🌟 Leadership Commitment
Empowerment: leaders granted teams the authority to make decisions and showed confidence in their capabilities.
Transparency: they maintained open channels of communication to align squad activities with organizational goals.
Support for Autonomy: they encouraged teams to take ownership of projects, fostering a sense of responsibility.
🔄 Cultural Adaptation
Encouragement of Experimentation: they created an environment where trial and error were seen as part of the learning process.
View on Failure: they cultivated an attitude that viewed failures as opportunities for growth and learning.
Open Communication: they promoted regular feedback loops within and between squads to enhance processes and solve issues promptly.
💡 Professional and Personal Growth
Knowledge Sharing: they spread knowledge and skills throughout the organization to enhance collective abilities.
Skill Improvement: they ensured that individual growth aligned with the evolving needs of the organization.
🔧 Technical Changes:
Decoupled Releases: they implemented independent release capabilities for each squad, allowing for faster and more frequent updates without waiting for a full-scale release.
Modular Architecture: they developed a system where components were loosely coupled, enhancing the ability to make changes in one area without impacting others.
Continuous Integration/Continuous Deployment (CI/CD): they adopted CI/CD practices to ensure seamless and reliable code integration and deployment, supporting the agility of squad operations.
Benefits and Challenges of the Spotify Model
The Spotify model has been extensively discussed, including some significant criticisms from former employees.
Based on my research, conversations with individuals who have firsthand experience with this model, and my recent experience, here's a summarized comparison of the benefits and challenges.
Benefits
🚀 Enhanced Autonomy: the model empowers squads with decision-making authority and ownership, boosting their sense of responsibility.
⚡ Increased Agility: it supports agile methodologies, enabling squads to adapt quickly and efficiently to changes.
🐝 Cross-Pollination: people from different backgrounds and functions share knowledge and approaches, leading to natural people development.
🌟 Focused Innovation: squads focus on specific missions, encouraging deeper innovation without organizational constraints.
🗣️ Soft-Skills Growth: being organized in small teams encourages individuals to develop their interpersonal skills.
Nicola: What do you consider the most significant advantages of working within the Team Squads model?
Cliff: When a team has both the information and the authority required to make good decisions, it’s powerful. The pace and energy are so strong.
Challenges
🔄 Over-Reliance on Autonomy: excessive autonomy can lead to a lack of cohesion and misalignment with organizational goals.
🛡️ Dependence on Strong Leadership: the model requires leaders who can effectively guide and coach squads without micromanaging them.
🚫 Cultural Fit: the model is highly dependent on a supportive company culture and may not align well with every organization.
🏋️ Resource Intensity: managing autonomous, cross-functional teams effectively requires significant resources, especially at scale.
🛠️ Difficulties in Implementation: although the model sounds promising, the lack of defined rules can make it challenging to implement, particularly for traditional companies.
🔍 Mixed Results: while some organizations benefit from the model, others experience varied outcomes, affecting productivity and efficiency.
Nicola: Were there any notable challenges or drawbacks that your squad faced?
Cliff: More a function of the matrix structure, but many felt it often added overhead that wasn’t worth it. You may often feel like you have multiple managers and aren’t sure where to take direction from. Usually, this was caused by misaligned leadership, which is a super common problem in many organizations. When you have aligned leads, though, many of those problems disappear.
High autonomy can lead to teams thinking they don’t need to collaborate as much with other teams. This limits the size of the goals you can accomplish to what’s possible within a single team. Creating useful alignment across many teams was challenging, where they may have felt that aligning meant giving up their freedoms.
🔧 How to Work with Team Squads
As I mentioned, I recently tried to apply the Squad Model to a real scenario in my department, and I have to say the experiment was very successful.
So, what do you need to start experimenting with the Squad Model?
Minimum Requirements
Before even starting to think about team structure, I believe your wider team or department must meet some minimum requirements:
📚 Culture: they must be used to making decisions, support autonomy, and be ready to adapt to change. They should also be open to taking on responsibilities and be accountable for them.
🛡️ Leadership: leaders or managers within your team should be empowering, open to new ideas, and be able to avoid any micromanagement.
💻 Technical Environment: the model to be applied requires a flexible technical infrastructure that can support decoupled services and independent team deployments. This should also include features like robust test coverage, feature flags, canary releases, etc.
Don’t go All-In
Even if you meet all the previous requirements, I suggest you avoid introducing and forcing this model all at once. While the squad approach sounds intriguing, in my opinion, it is not suitable for everything.
That doesn’t mean it can’t coexist with a more traditional structure, and based on my recent experimentation, I believe the hybrid model could be a great approach.
So, while maintaining your traditional team structure and work processes, you can create squads on demand to develop certain features of your product or to improve specific areas.
All you have to do is:
🎯 Choose a suitable project: identify a project that can benefit from a focused, cross-functional team.
Nicola: Based on your experience, are there particular types of projects or organizational cultures that are more suited to this model than others?
Cliff: I think this model only makes sense when you want to use the expertise and skills of your people. If you just want them to do as they're told, then you're wasting your time. However, when you want thinking to be done at all levels of your organization, it’s worth taking the time to set out appropriate boundaries and collaboration mechanisms for teams to work within and across each other's domains.
👥 Choose the right people: select adaptable, collaborative individuals with the right competencies for the project.
Nicola: What personal skills or attributes do you think are essential for someone to succeed in a Team Squads environment?
Cliff: Empathy and people skills. Quite simply, it’s rare that we can accomplish our goals alone. We need to work with others to make big things possible. Most engineering orgs overweight 'technical' and underweight people and collaboration skills. I often refer to these as the differentiating skills, because they’re the lever for a powerful step change.
Give the Squad a Mission
One important concept of the Squad Model is that every Squad Team has a mission.
While in Spotify, this was mainly related to areas of their application, a Squad mission can be related to anything.
Things like:
“Implement this feature”
“Improve this system metric to reach X”
“Own this part of the application to improve customer retention by X”
These are just simple examples, but in my opinion, they are all suitable for forming a squad.
From a leadership perspective, the most important thing is to clarify the mission.
The Squad Set Their Own Rules
One important concept of the Squad Model is that every Squad Team sets its own rules and work processes.
While every squad will work in a different way and with their own rules, it’s also important to document these rules for two main reasons:
📝 Future squads will be able to get inspired by what other squads did.
🔄 The squad itself will be able to use this documentation to retrospect once a project is completed.
Make the Squad Part of your Traditional Work Process
If you choose the hybrid model, find a way to involve the team squad in your traditional process.
👤 Nominate a Squad Leader: while the original model does not have formal squad leaders, opting instead for product owners, in our experiment, we decided to nominate one. The squad leader (a title that could perhaps be refined) does not make decisions; they serve as the point of reference for external stakeholders.
📢 Pitch the Progress: a practice I found very beneficial is to have the squad team, or just the squad leader, provide updates during alignment meetings. My department holds bi-weekly meetings where the squad team regularly presented their progress.
🔗 Consider Dependencies: in a hybrid model, it might happen that the squad team can’t cover everything. Not every organization has enough people to build a fully independent squad. Although this slightly deviates from the traditional squad approach, I believe having some small external dependencies is acceptable.
📋 Involve in Planning: another beneficial practice is to involve the squad team in your planning process.
Be Aware of This
Especially when you start experimenting with this model:
🙌 Let people do their job: trust the squad to manage their tasks without micromanagement.
🚫 Avoid external influence: especially in a hybrid model, where part of your team will work more traditionally, try to minimize interference from outside the squad to maintain focus and autonomy.
🛑 Be prepared to fail: accept that failures are part of the learning process and necessary for ultimate success.
👁️🗨️ Transparency: this is essential in general, but even more so with the squad model. Squad teams must have all the information necessary to operate at their best. (read this from Cliff)
🏁 Conclusion
While the early results were promising, it's probably too early to say if the squad model will become a permanent part of our work processes. However, what I can say is that this experimentation has already yielded some valuable insights, and the people involved in our first squad were enthusiastic.
To conclude, I will leave you with a very important point from Cliff, which is my mantra:
Take inspiration from others, but don’t copy. What works for others will unlikely work for you.
Nicola: What advice would you give to other companies considering implementing a similar model?
Cliff: Make sure you explain your current situation and problems clearly.
Then explain how the changes you’re proposing will make that happen.
Too often I see changes proposed because 'Google does it', as if we have the same problems or context as them.
Be careful of assuming that what others do makes sense for you, because it rarely does. And adding change work to an overloaded team will only slow them down.
📢 Weekly Shoutouts
Underrated daily-job software engineering skills by
Perceived Difficulty is a Productivity Killer by
My Mentee Went From Junior to Senior Engineer in less than 2 years by
Conquering Imposter Syndrome by
✌️ That’s all folks
That's all for today! As always, I would love to hear from my readers (and if you've made it this far, you're one of the bravest). Please don't hesitate to connect with me on LinkedIn or Twitter and send a message. I always respond to everyone!
I'm always wondering: did Spotify ever used this model?
https://www.jeremiahlee.com/posts/failed-squad-goals/
I believe it is a good idea suggesting this model to the leadership at our company, hopefully you will write another article about later results as you experiment with the Squad Model