Spotify has developed an engineering culture that has attracted a lot of attention: The Spotify Model. Many development teams that grew and wanted to implement a process tried to emulate it, but few managed to implement it. Today, Spotify is no longer using - or trying to use - this seemingly great structure. This begs the question: why?
By the end of this article, you'll know the elements of a successful product team that can help your company thrive.
Even though Spotify no longer uses squad groups, this method can benefit other flexible product teams.
A brief digression into the Spotify squad framework
Spotify was launched in 2008 with the concept of a Scrum team for its development approach. However, their radical growth showed that the traditional Scrum method was not always the most flexible option
The team decided to tailor Scrum, its methods and terminology to Spotify. They implemented the Spotify Squad Framework (Part 1, Part 2). Spotify Squads are cross-functional, autonomous teams with a maximum of eight people. They are solely responsible for all products created. This includes: Ideation, design, testing, deployment, optimization. Each squad unit has a unique mission, short-term goals, and multiple long-term goals that contribute to the overall mission of the company.
In Spotify's case, the company's mission is to unleash the potential of human creativity. Engineer squads make local decisions, which means they can drive projects or launch them independently without relying on approval from the top. Spotify built teams based on trust, relying on smart people to make smart decisions. With the goal of building an autonomous workforce. Spotify puts community over hierarchy, believing that a community strong enough could make the right decisions without needing the approval of high-minded executives. Spotify also believes that by building a self-contained community of squads, tribes, chapters and guilds, it can build a product team that has the potential to "make better products".
What are Spotify Squads, Tribes, Chapters, and Guilds?
Spotify has taken engineering culture to the next level - and given it new names. There are a few terms you need to understand to understand the whole structure of a product team, agile software development and product roadmap. Spotify squads are cross-functional, self-directed teams of up to eight people with cross-functional responsibility for ideation, design, testing, deployment and optimization. The main idea behind Spotify Squads was to enable individual teams to develop and deliver more frequently. In addition to Spotify Squads, there were also Tribes (groups of Squads), Chapters (areas of responsibility within departments, within Tribes), and Guilds (light communities of people with common interests between departments and Tribes)
Squads
A product ecosystem can consist of any number of squad units, as long as they are united by a common product mission. Spotify squads work together to find solutions. Certain squad units own certain processes or systems - they try to enable each other to use those systems or processes so that other Spotify squads can execute their mission. Spotify squads tend to focus on product quality and delivery.
Tribes
Tribes are squad groups. Tribes can include any number of squad units and typically group together for a specific purpose. This can be product area, location, a holistic view of the problem, and more.
Chapters
Chapters form areas of expertise across all units, within Tribes. For example, five squads might each have one person who specializes in application development. These five people form a chapter across departments. Each chapter has a leader who acts as a formal supervisor. This structure allows employees to move from one team to another and work on different initiatives without losing their manager and leader.
Guilds
Guilds form a community of people with common interests in Tribes and Squads. Guilds can have multiple people from the same Squad. They are necessary to create a culture and engage employees beyond their roles. People can come and go as they please. Guilds can team up in areas of professional development like Python or Google Analytics. Or they can focus on personal interests like yoga or soccer.
This is why the Spotify approach is failing in your business
One reason is this: you are not Spotify. Spotify is a Swedish, fast-growing, well-funded startup (now a listed company) with hundreds of developers developing a specific B2C product: An audio player on all kinds of devices. Also the high autonomy of the framework. However, without a responsible and collaborative process, this leads to a lot of wasted time and knowledge not being shared.
You can, however, use the lessons learned from the Spotify Squads platform to implement some of your elements in your own organization. To apply a similar methodology to your own team, remember that you need to change the leadership style and structure of the team, so make sure your entire team supports the new structure and make a certain number of recommendations. For product development, agile software development and product roadmap, Spotify methodologies are partially useful. Spotify's standalone product groups have ensured smooth product releases. They tend to make mistakes faster than anyone else and learn from them. Spotify also changed the architecture of its product to make releases and product management more independent. This meant that certain squad groups were responsible for certain functions or certain areas of SaaS product management, rather than all squads being responsible for the entire SaaS application. The product management units were divided into three main areas:
- Client Function
- Infrastructure
- Client application
Independent releases provide a "limited burst radius," meaning that if a product deployment fails, it is limited to its immediate radius and does not cause the entire product to crash. Spotify Squads' approach to product development was based on lean startup principles. They identify a problem through research, formulate a description to summarize the solution, and hypothesize (or hypothesize more than one) about the impact of this update or new product feature. Once all of this is done, product teams create prototypes for user testing. One way to incorporate this technique into your product development and product management team is to conduct doortests and collect relevant contextual feedback from users.
Important lessons from the failure of Spotify Squads for product management
The Spotify Squads framework has been the subject of criticism over the years, many of which came from former employees. It was criticized for solving the wrong problems, being too autonomous because of its assumption of human emotional intelligence skills, and shifting responsibility for results. The absence of engineering managers disrupted communication with PM. An important lesson learned from the structure of Spotify squads is that some level of hierarchy is required - managers exist for a reason. This structure allowed product owners to lead design and SaaS engineering teams without engineering managers. When disagreements arose within product development, the product manager had to negotiate with all the engineers on the team. If the engineers could not reach consensus, the product manager had to approach as many engineering managers as there were engineering specialists on the team. Of course, they had leaders; however, these roles had little or no responsibility for job outcomes; instead, they were responsible for career growth and professional skill development. This led to product managers talking to a group of engineers instead of a single technical supervisor or DevOps engineer, resulting in wasted time, a lot of back and forth, and perhaps too much autonomy.
Cross-team collaboration and autonomy are hard to combine
Spotify strives for a high level of autonomy and consistency in product management. Leaders, for example, present problems, explain why they are problems, and ask teams to find, create, and release solutions. However, many of these problems required collaboration between departments. This wasn't always possible because other squads with much-needed processes or tools didn't have enough bandwidth to collaborate. If I were to do anything differently, I would say that we shouldn't focus so much on autonomy. Every time you have a new team, they have to reinvent the wheel of how it's going to work. Maybe, just maybe, we should have "minimum viable agility." This led to product teams using agile software development and SaaS to develop their own tools and solutions. Despite the current code peer review process, a lot of time was wasted and knowledge was not shared. Everything was not working as quickly as they had hoped.
Collaboration requires skill and practice
Sure, Spotify has hired smart people; product managers, engineers and data managers. They strive to be a vital company with growth mindset, agile principles and the right people. However, smart people are not necessarily experienced people. The structure of Spotify's engineering team required certain skills that talent doesn't always bring, and collaboration was one of them. People lacked a common language to effectively discuss process problems, education to solve them, and experience to measure performance. Finally, great-sounding titles don't always lead to the right decisions and can create additional barriers. If your title structure is not written for your employees, it can be difficult for people to understand what is what.
Role and Functions of Chief Product Officers (CPOs)
As companies manage the growing demands of digital transformation and product-driven growth, the role of the CPO - as facilitator of this transition - is more important than ever. CPOs coming from B2B digital companies like SaaS typically focus product management on product growth. They already have an established, strong culture and products designed for digital. Chief Product Officers in traditional industries such as Manufacturing, Manufacturing and Media lead the digital transformation of their companies. For them, it's not the product that counts, but a smart product roadmap, agile software development and cultural change. And when it comes to digital transformation, it's all about the ability to transform a business with a very strong vision.
What makes a CPO successful? Product management focuses on the customer journey. That means measuring success based on user engagement, customer satisfaction and product adoption. When it comes to business metrics, CPOs think of revenue, time-to-revenue and incremental sales. But what sets a successful CPO apart are his or her real soft skills. And the most successful CPOs sit at the top management table, they have a very strong vision and they are very good at communicating that vision. They know what they need to build, and they do it right.
The faster the growth, the more stress
When a company grows quickly, it is under stress. Structure can improve the situation, but only if it is properly designed for growth. A good structure provides the foundation on which your organization can grow. A bad structure can make things worse. Structural decisions are business critical. They can build or destroy a business. If the success of your business depends on effective growth, you must get it right. Define your organizational structure because there are many ways to organize your product development or product roadmap. There are two approaches worth considering:
- The Triad Model. Each function (engineering, product, and design) has its own reporting structure and organization. They work together at eye level.
- The CEO model. Each organization is led by a General Manager who is responsible for all functions within his organization. This is also known as the "single threaded owner" model.
Both models work equally well for scaling your organization. However, if you can't identify the structure, it can hinder your growth. In many B2B companies, the different functions often clash.
Organize cross-functional designs, implement and design products
It is common for agile software development to organize along functional lines. For example, front-end and back-end teams. This may seem natural, because that's how engineers often think about their work. And engineers tend to build their identity around being front-end engineers or back-end engineers. So they expect front-end tasks and back-end tasks. While this approach is possible, it has many drawbacks.
These are:
- Increased dependency between teams, leading to poor performance.
- Increased organizational complexity (which gets worse as the organization grows)
- Increased need for communication
Every team should be able to add value to the business without involving other teams. Therefore, by default, you should organize teams cross-functionally and only manage them functionally if it seems inefficient. In most cases, pretend that design and product are part of the same team. Add a designer and a product manager to each team.
One of the most common sources of failure in fast-growing organizations is ineffective and lacking ownership in the leadership structures. A strong product owner who actively manages the product roadmap and involves all the necessary stakeholders such as sales, developers and design can go a long way. In fact, I would say that this is one of the problems we encounter most often.
In extreme growth situations, poor alignment can lead to organizational failure. If you double the size of the company in six months and it takes six months to adapt, you lose ground. That's why smart leaders invest in effective employee onboarding and do structural work to facilitate onboarding. An example of structural work that helps alignment is defining roles and a clear product roadmap. Who is responsible for technical leadership? Who is responsible for B2B project management? Identifying those things is important because you're hiring for those skills and everyone needs to understand how they fit into the rapidly growing organization you're building. That kind of structure is absolutely essential.
When you define roles, I recommend that you define them dynamically and you need to communicate that everything written is flexible and can change over time. If these written roles were immutable, it would hinder organizational flexibility and change. This is problematic for a fast-growing B2B company.
