1. S E L B S T S I C H E R Z U M E R F O L G
borisgloger consulting GmbH
The Spotify Model
Challenges of a Transformation
Agile Austria, 25.06.2019
Christoph Schmiedinger
@cschmiedinger
2. S E L B S T S I C H E R Z U M E R F O L G
The Rise of the Spotify Model
3
https://youtu.be/TaV-d7eKWFc
Spotify-model-at-telekom
commerzbank-takes-spotify-as-a-role-model
3. S E L B S T S I C H E R Z U M E R F O L G
The Object of Interest
4
„Scaling Agile @ Spotify“ von H. Kniberg und A. Ivarsson (https://bit.ly/2PneB7L)
2012
5. S E L B S T S I C H E R Z U M E R F O L G
Spotify after 2012
6
Growing to over 4,000
employees
First lessons from the
existing structure
First operational
profit achieved in
Q4/2018
Alliance
Several tribes with common
objective (e.g. consumers)
Alliance Leadership
1 Tech Head
1 Product Head
1 Design Head
Tribe Leadership
1 Tech Lead
1 Product Lead
1 Design Lead
6. S E L B S T S I C H E R Z U M E R F O L G
Is all of this really new?
7
Business Unit Design Pattern
Solar Hydro Wind Nuclear
Board/CEO
Business
Unit Manager
Sales
R&D
Assembly
QA
Operations
7. S E L B S T S I C H E R Z U M E R F O L G
Is all of this really new?
8
Business Process Engineering
(using an insurance example)
Auto
Household
Life
Business
Processes
Process
Owner
IT Developer Actuary
Marketing
Specialist
Coaches
Customer
Center of
Excellence
8. S E L B S T S I C H E R Z U M E R F O L G
The Challenges of Implementation
9
1 The organizational cross-section of Tribes
2 The role of the Product Owners
3 Arranging the Chapter and its Leads
4 Establishing Support units
9. S E L B S T S I C H E R Z U M E R F O L G
Cross-functional Teams under one Reporting Line
10
1
11. S E L B S T S I C H E R Z U M E R F O L G
The Leadership Trio as a Way Out?
12
1
12. S E L B S T S I C H E R Z U M E R F O L G
The Product Owner Role
13
Larger gap in strategic work
and management span
“more difficult“ to advance on
the career ladder
Management
responsibility
approx. 50 – 100 people
max. 9 people
2
13. S E L B S T S I C H E R Z U M E R F O L G
Possible Solutions
14
Scaled Product Owner Role Chief Product Owner Role
2
14. S E L B S T S I C H E R Z U M E R F O L G
The Mysterious Chapter Lead – the Theory
16
Chapter Lead = Disciplinary Management?
3
https://thenextweb.com/business
https://www.cec-managers.org/scandinavian-leadership
15. S E L B S T S I C H E R Z U M E R F O L G
The Mysterious Chapter Lead – the Reality
17
same same but different
3
16. S E L B S T S I C H E R Z U M E R F O L G
The logical progression?
18
Autonomy Purpose
Mastery
Optimal framework condition for
working on solutions
One roll ensures “autonomy”. It
accommodates the employee need
for self-determination in order to
encourage.
One roll ensures “purpose”. It
accommodates the employee
desire to work on something that is
important to them.
One roll ensures “mastery”.
It accommodates the
employee wish to
continuously improve their
competencies and
abilities.
Scrum
Master
Product
Owner
Chapter
Lead
Implementing
“true” 360° feedback
processes
collective salary
determination processes
3
17. S E L B S T S I C H E R Z U M E R F O L G
Operational collaboration in the Squads?
19
Yes ✓ No
Factors to consider:
Chapter size
Necessity of strategy work
Necessity and effort for setting standards
Example UX Design Chapter:
• Continued team member development
• Drafting brand presence
• Developing and maintaining the style guide
3
19. S E L B S T S I C H E R Z U M E R F O L G
A Huge Breakthrough
21
20. S E L B S T S I C H E R Z U M E R F O L G
The Challenges during Implementation
22
1 The organizational cross-section of the Tribes
2 The role of the Product Owners
3 Arranging the Chapter and its Leads
4 Setting up the Support Units
Vortrag: 45min + 10min Q&A
Hello and welcome to my talk here at Agile Austria 2019. My name is Christoph Schmiedinger and I work for borisgloger consulting, a consulting company focusing on all the areas dealing with Agile. Including everything from supporting and enabling agile teams up to complete organizational agile transformations. Today, I am going to talk about Spotify, which has been a role model for many digital agile transformations that are currently being undertaken. First of all, I want to do a little check. Who of you is aware of the Spotify model and knows at least a little bit about it? Oh, almost all of you. That’s quite good because my talk won’t cover the details of the model itself – as you can imagine that would be also quite boring. Therefore, I will spend only one slide about it, I promise . The rest of the talk I will spend mainly on highlighting a few of the challenges that always arise during such an adoption of the Spotify model. I can report on first hand as I had the opportunity to support three transformations that dealt with it. And I will also dive a little into the Spotify universe and take a look at what Spotify has actually done since 2012 and where they are at today. So without further ado, let‘s jump into this topic.
The Spotify Model has made big waves in the past few years. It is the symbol of an agile organization, a hip and innovative company culture. Within a short time, the organizational structure at Spotify from 2012 became the standard for restructuring companies. The ING Banking Group had an essential role in the propagation of the Spotify Model: An established company whose roots reach back to the 1900s took on a complete transformation and with it unleashed a huge trend. From this point, it was no longer a model that only worked for start-ups. Other corporations followed. Today, big names like Commerzbank, Deutsche Telekom and REWE are among those companies using the Spotify model.
An impressive and bold step – but the devil is often in the details. We have seen how companies too quickly adopt this model without considering how it fits to their company simply because it is fashionable to do so. The often never ask the question whether or not this model is even suitable for their company and its associated business model. Because of the pressure put on these companies, essential aspects of the approach are misunderstood, ignored and ultimately implemented incorrectly.
The Spotify Model has made big waves in the past few years. It is the symbol of an agile organization, a hip and innovative company culture. Within a short time, the organizational structure at Spotify from 2012 became the standard for restructuring companies. The ING Banking Group had an essential role in the propagation of the Spotify Model: An established company whose roots reach back to the 1900s took on a complete transformation and with it unleashed a huge trend. From this point, it was no longer a model that only worked for start-ups. Other corporations followed. Today, big names like Commerzbank, Deutsche Telekom and REWE are among those companies using the Spotify model.
An impressive and bold step – but the devil is often in the details. We have seen how companies too quickly adopt this model without considering how it fits to their company simply because it is fashionable to do so. The often never ask the question whether or not this model is even suitable for their company and its associated business model. Because of the pressure put on these companies, essential aspects of the approach are misunderstood, ignored and ultimately implemented incorrectly.
Here is a quick refresher on what everyone was after, which was published in a whitepaper in 2012 by Hendrik Kniberg and Anders Ivarsson. An organizational structure consisting of Tribes, which essentially combine several teams together to work on a topic, for example a product or a part of the product. Thus, the Tribe is a comprehensive unit that is managed by a Tribe Lead. Cross-functional teams, called Squads, work in these Tribes. Each Squad has a Product Owner who is responsible for the content line of approach of the individual Squads. To guarantee continued development also in the functional units, there are so-called Chapters. Here, team colleagues with the same skills are collected within a Tribe (for example, all database developers). This Chapter are managed by Chapter Leads, who also work in one of the Squads. The third possibility for association are the so-called Guilds. These are voluntary cross-Tribe communities which are dedicated a singular topic, such as testing automation.
But what is the actual background of Spotify in the year 2012? Let‘s take a look behind the scene of this model. Stockholm, 2012 – around 600 employees, many of them IT experts, are working for the (back then) still young startup Spotify, which was founded in 2006. To be able to handle strong growth and gain market share before the overpowering competition (such as Google and Apple), they needed an organization that guaranteed the ability to deliver quickly. Also, there was and still is a very open company culture. The hierarchy in the organizational structure is not actually practiced as it shown on paper. And the company overall was very young, headed by Daniel Ek, founder and CEO, who was 29 years old at the time.
Even Spotify themselves talk about a newly designed matrix organization. Compared to classical structures, it is weighted towards delivery, placing the focus on a customer-focused value stream and the specialized functional professionalism is ensured in the background through the matrix allocation to Chapters. Even with the cross-functional work on products and services, the delivery-oriented structure of each Team setup is given priority (the Squads), since most of the time the work is done here.
Spotify also made it very clear in their publication that they deviate from their own rules in many areas of their organization because the mission to be accomplished is more important than the principles of structure. Behind this idea is also the principle that agility is delivering to the customer in the best possible way, independent of rules and dogma.
Even then, though, the authors included a disclaimer that warned against simply copying the model without reflection.
I often wonder why we are still interested today in the Spotify model from 2012, despite it being from 7 years ago. Since 2012, much has been learned at Spotify, which has influenced the adapted organizational structure. My hypothesis: Later publications are simply not as well know, although they do exist! Two presentations from 2015 and 2016, as well as two articles from 2015 and 2018, outline a good overview of the developments since 2012. Spotify has scaled to over 4000 employees from the 600 back then, thus they have grown nearly sevenfold since the initial take on their model.
From these first lessons from the old structure, two essential changes to the to the 2012 model have occurred: The implementation of Leadership Trios at the Tribe level and the introduction of so-called Alliances. Introducing Alliances was the answer to the increasing demand for vertical alignment, i.e. between the Tribes, due to Spotify‘s strong growth. Thus, at least two related Tribes were combined into the next larger unit, an Alliance. Also, Alliances and Tribes were divided into business and support missions based on the type of customer they served (internal or external). Typically, business missions are assigned according to customer segments to ensure optimal service with the help of several products.
Another big lesson learned was that the focus of the Tribe Leads was very one-sided because they originated either from the technology or the business specialization. Thus, Tribe Leadership Trios were established, which consisted of three people from the product/business, technology and design areas (Tech Lead, Product Lead and Design Lead). These employees also manage the associated specialized Chapters. At the Alliance level, there are also Heads for each Lead (Tech Head, Product Head and Design Head).
A little side fact: Spotify achieved its first operating profit in the history of the company in the fourth quarter of 2018. This means that the company was in a strong growth phase in the previous years and used the initial modeled structure specifically for this goal. Established companies should take this fact into consideration before copying this model.
The question that always comes up for me when accompanying these transformations is whether all of this is really so new? The answer is also no. There are essentially two significant influences from the 90s that could have been the inspiration for this model.
The first idea is the Strategic Business Unit for decentralizing decision-making in larger companies. With this, a large part of the central functions for creating and selling a product or service is bundled into one unit under one manager (ideally with profit/loss responsibility). This is supposed to ensure that all employees, regardless of their function, focus on the common goal of their business unit success. However, this idea of decentralization was not carried out within the business unit causing the internal structure to still be primarily function-oriented, once again leading to the danger of small silos being created within the business unit.
Another approach from the 90s originated in Business Process Reengineering, which postulated, among other things, the idea of putting the operational structure (and thus the processes) in the foreground because these are what create value for the customer. The BPM expert Michael Hammer wrote in 1997 that the permanent organization should consist of centers of expertise, each with its own coach who focuses on the professional expertise within the company. In addition, the employees should be gathered into autonomous and independent process teams to create value for the customer under the guidance of a Process Owner. Other than the differences in terminology (Center of Expertise vs. Chapter, Coach vs. Chapter Lead, Process Owner vs. Product Owner), we see many similarities to the Spotify approach.
Now that we have taken a look behind the scenes at the history, I would like to now talk about the challenges of the recent transformations. In particular, I noticed that a large part of these challenges were due to inadequately examining Spotify‘s advancements, especially since there were indications of inadequacies with their model. For this presentation, I am going to focus on four challenges:
-) the organizational cross-section of Tribes, especially the allocation of cross-functional employees and the tendency to build very large Tribes
-) the role of the Product Owner, which is experiencing a new appreciation while at the same time overwhelming many people in this role
-) the design of the Chapter and their Leads, especially considering the many questions regarding disciplinary leadership and cooperation within the Squad
-) and the setup of support units and how their work model functions
In my view, one of the core ideas of the model is the combination of technology and subject matter experts for a particular product or (sub-)process into a single organizational unit and thus under one manager. At the same time, it is also one of the biggest challenges and many companies do not consistently model this to the end of the future design.
Far too often, people cringe at the implications of one manager for many different experts. Yet this design is what makes the model so appealing because it ensures alignment towards a common goal for all experts. It also represents a major challenge for the future manager, the Tribe lead. Similar to a Product Owner, but more strategic, this manager must have and use subject matter, economic and technical skills in order to adequately manage this area.
Often these managers come from a business background and must learn how include the technology people.
Another challenge is the size of the Tribes. Professional literature often refers to Dunbar‘s number, which is the number of people in a collective that still know each other and feel they belong together. This number, defined to be around 150 people, is gladly used as a design criteria for organizational units, such as a Tribe. Spotify defined the maximum size of a Tribe to be around 100 people.
In practice, however, this size already presents companies with a challenge if we look at it from a management perspective. If we talk about small Squads, with a total of 100 people we are dealing with at least 12 Squads and Product Owners (in the case of a 1-to-1 ratio between Product Owner and Squad). Based on the various skills that are usually needed for developing and selling a service or product, there is usually at least 10 Chapter Leads for such a large Tribe.
Even if you allocate the Business Chapter to the Tribe Lead, we still wind up with around 4 – 7 Chapters. If all of these are reporting to the Tribe Lead, the number of direct reports quickly adds up to more than 20. Even if you aren‘t a fan of strict hierarchies, it must be clear that such a large number of direct reports will not have a positive effect on the management within the company. A modern management style requires a large investment of time per employee (for example, through one-on-one coaching).
Possible solutions for easing the Tribe Leads high level of responsibility and the associated high number of direct reports is expanding the Tribe leadership with technology and/or design managers, like in the newer model adaptation at Spotify. At some of the companies we have supported, we established Technology Leads to support their Tribe Lead, who is responsible for the product.
Whether Design Leads are also needed, like at Spotify, should be determined on an individual basis. But as we saw on the previous slide, even this constellation is a large burden on the management span of the Tribe Leads. So we cannot avoid also making changes to the Product Owner role in order to achieve an acceptable direct management span.
Another issue that companies are confronted with eventually is the configuration of the Product Owner. Since there is no additional level between Product Owner and Tribe Lead, Product Owners must work very strategically in large Tribes with more than 5 or 6 Squads. This is because a Tribe Lead can no longer handle this task in such large setups. One of my customers, for example, had a Tribe with 15 Squads and 12 Product Owners. Obviously the Tribe Lead can only assume an overview and high flight level approach towards the content-related work.
This is equivalent to the common concept of a mature agile setup, where Product Owners work very strategically. In practice, nevertheless, we often see Product Owners overwhelmed and unable to perform this strategic work. We also see that there is difficulty in climbing up the career ladder since there is a significant difference between leading a team as Product Owner or are a Tribe Lead for an entire Business Unit.
One possibility is to use one Product Owner for several teams, as it is prescribed in the scaling framework LeSS. However, this requires very independent teams with business knowledge in order to, for instance, be able to write User Stories themselves and coordinate with the users and customers. The Spotify model uses multi-functional Squads consisting of technology and subject matter experts, so this should be easier to achieve.
Another possibility is working with the Chief Product Owner roles by taking over the strategic work for large products comprised of more than 3 Squads. This allows the alignment work and communication with the stakeholders to be bundled. This is another possibility to better scale the entire construct without adding a formal hierarchical intermediate level.
It minimizes the management span of the Tribe Leads because only the Chief Product Owner reports content to the Tribe Lead.
There is one big uncertainty in the Spotify model, which is the function of the Chapters and the associated role of the Chapter Leads. What exactly does the Chapter do and how much are they involved in ensuring the alignment? Is the Chapter Lead the disciplinary manager and are they really working with the team? What happens if a second Chapter member is working in the same team? Do we really still have a hierarchy-free room?
In Spotify‘s case, in fact, the Chapter Lead was the actual disciplinary leader having all the responsibilities associated with this, such as continued development of their colleagues, setting performance expectations and salaries, and much more. The Chapter Lead also continues to be a part of the operational work in a Squad in order to keep in touch with reality. Nonetheless, companies who implement the model today are culturally much different that Spotify in 2012. Back then, Spotify was a start-up, not to mention a Scandinavian one, who are known for not strictly defining or adhering to hierarchy, as these two articles reported.
There is one big uncertainty in the Spotify model, which is the function of the Chapters and the associated role of the Chapter Leads. What exactly does the Chapter do and how much are they involved in ensuring the alignment? Is the Chapter Lead the disciplinary manager and are they really working with the team? What happens if a second Chapter member is working in the same team? Do we really still have a hierarchy-free room?
In Spotify‘s case, in fact, the Chapter Lead was the actual disciplinary leader having all the responsibilities associated with this, such as continued development of their colleagues, setting performance expectations and salaries, and much more. The Chapter Lead also continues to be a part of the operational work in a Squad in order to keep in touch with reality.
Nonetheless, companies who implement the model today are culturally much different that Spotify in 2012. Back then, Spotify was a start-up, not to mention a Scandinavian one, who are known for not strictly defining or adhering to hierarchy, as these two articles reported.
So much for theory – but how does it look in actual practice and reality. In many companies that are inspired by this approach, I have seen the Chapter Lead installed as a new manager. However, they still have the well-known management tasks such as feedback, performance and appraisal management, so it is basically a classical manager being installed with a new name.
We also see a sort of paradox in practice. There is a frequent urge to condemn hierarchical leadership but, at the same time, miss it when it is no longer being used.
I recommend to companies that they pursue a hierarchy-free organization as much as possible. Individual employees should be managed according to the management model from Daniel H. Pink. Through the three roles of Product Owner, Agile Coach and Chapter Lead, the areas of purpose, autonomy and mastery are managed, but completely without a formal hierarchy. All three roles manage laterally and have a common goal, namely to create the best working environment for the employees so that they can continuously develop themselves and work efficiently towards the company goals. The final disciplinary authority in this case can still be the Tribe Lead, although they will not have regular contact to all employees.
More importantly, there must be a mature 360° feedback process in place, including a collective salary determination process, in order to bring this hierarchy-free setup to life. A large part of the day-to-day management tasks should be dealt with within the three roles collective such that the Tribe Lead is only a disciplinary fallback on paper. The biggest challenge when setting up this model is the fact that it is dealing with big changes to delicate and sensitive topics (above all the changes to feedback and salary determination processes). So companies shy away from consequently implementing these changes.
When working with a Chapter, I emphasize that it strongly depends on the intensity of the alignment, the strategy work and establishing standards within the Chapter and areas of interest. If less alignment is needed (less than 20% of normal working time) and the primary focus is on the professional development of the colleagues, it is quite acceptable for the colleague to continue working in a team. However, we must keep in mind that our colleague‘s focus will suffer because they are again in a classical dual-function position, which can have (prioritization) conflicts. If, in addition to the professional development aspect of the employee, there is a greater need for alignment, including working out comprehensive strategies and associated standards, the Chapter Lead should place their focus on that and let go of the operational work.
A common example of the second case is the UX Design Chapter. In the UX Design Chapter, the Lead is responsible for the professional development of Chapter members, as well as for creating and developing the styles guides and brand identities.
The challenge in many organization when assigning Chapter Leads is that former managers perhaps want to, but are no longer capable of, filling a collaborative role. Because they have spent years focusing on coordination and strategic activities, they simply do not have the expertise for operational work. The important thing is, even if Chapter Leads are no longer working in operations, there can be no ivory tower of management created, and instead that the focus remains on the true issues affecting the Chapter members.
We have spoken a lot about product development departments, the Business Units. What about the Support units we sketched in on the right-hand side? We believe, ultimately, that in order to successfully scale, the entire company needs to be agile.
We want to emphasize that this doesn‘t mean everyone should and must work with Scrum. More importantly, every employee – regardless which department they work in – should understand the Agile values and principles so they are able to relate to the product development teams and why they work the way they do. It is also a good idea if a Pairing or Mob use agile tools like Task Boards or visualization to improve their own work processes in the support units.
In the end, evidence remains that redesigning the organizational structure represents a decisive turning point for the existing organization. Even if only a small area of the company is converted, typically there will still be at least 50 employees affected. There us also typically a huge impact of such change in the company undertaking it because typically a significant portion of the workforce is involved.
That‘s why it is so important to allow enough time for such a large step. To allow yourself enough time to plan and examine what should actually be achieved with this change. We can also say from our experience in supporting many transformations that the company must expect a short-term drop in productivity. Many new teams and constellations must be set up and adapted to before they can get into a production mode again.
Accompanied by a structured agile change process (for example, by using a Transition Team) and providing transparent communication, this significant transformation can be successfully mastered.