I was in San Francisco in December for a conference. While I was there, I ended up connecting with a couple different companies who have been inspired by Henrik Kniberg’s whitepaper on Scaling Agile at Spotify, and who have been trying to implement some of those ideas in their own companies.
I think Henrik’s paper does an excellent job on describing the what and how, but it seems that the “why”, and some of the critical ideas can get lost when others read it.
If you haven’t read Henrik’s white paper, I’d suggest that you read that before reading the rest of the blog post. I will do a quick recap here though.
Spotify’s engineering and product organization (now over 600 people) is split into several large groups called Tribes. Each Tribe is responsible for a set of related features or engineering functions. For example, our largest tribe is the Infrastructure and Operations Tribe, whose name is pretty self-explanatory. I am the Tribe Lead of the Music Player Tribe. We handle importing audio from our label and distribution partners, storing and streaming the music, search, collection and playlists, artist pages, music metadata and the music knowledge graph that supports things like the above, but also ads, discover, radio and the like.
While the whole company works on the same product, Spotify, each tribe is set up so that it can work as independently as possible. As you will see below, a critical aspect of our organizational model is to give autonomy at every level. This helps remove decision-making bottlenecks and unnecessary dependencies, which improves velocity.
Each tribe is composed of squads. A squad is a team that is responsible for a single feature or component. For example, there is a squad that is responsible for search, a squad responsible for the AB test infrastructure, etc. As each tribe is set up to be as autonomous as possible, each squad is also set up to be autonomous. In the context of a feature development team, this means that each team is a full-stack team. A full-stack team is responsible for both backend implementation as well as the user interface implementation, on all platforms.
A typical feature squad would have web service engineers, iOS, Android, web and desktop engineers as well as testers, an agile coach, a product owner and UX designer. With this staffing, the squad has everything they need to implement anything related to their feature. They don’t have to wait on another team to implement the pieces they need. They also have autonomy and local decision-making ability, so there are few impediments on their speed of execution.
To this point with Tribes and Squads described only, Spotify may seem like a traditional, hierarchical engineering organization, but this is where the similarity ends. Unlike a traditional organization, a squad does not have a single engineering leader whom everyone on the team reports to. In fact there is not a single leader for the squad. The Product Owner and UX Designer work with the engineers and testers collectively to make decisions about their features.
Spotify is not a “no manager” culture though. We feel strongly that managers have a role in supporting the people who work for them. Managers have an important role to play as technical and career mentors and organizational communication conduits. Rather than have management hierarchies follow organizational ones (creating a de facto command-and-control structure), we instead have first level managers responsible for technical functional areas across multiple squads.
We call these reporting and functional groupings “chapters.” Again, as an example, reporting to me, the tribe lead, are Chapter Leads. In my tribe, there are currently three backend (services) development chapters, two front-end development chapters (including all the UI developers), a core library chapter, and a test chapter. These seven Chapters span eight different squads. Almost every chapter lead has reports in 2 squads, and a few of them have reports in three squads. Almost all chapter leads work within a squad in some capacity as well, either as developer or technical lead, and not necessarily within a squad that has members of their chapter.
This chapters/squads matrix organization is critical to our organizational agility. It allows the squads and the tribe to be more fluid. We can spin up a new squad to take advantage of an opportunity or handle an issue without worry about changing reporting structures. If a squad completes its goals and has no reason to exist anymore, we can dissolve it without punishing a manager. This is a very important difference to a traditional hierarchy, because it gives us a lot of flexibility and helps us avoid the old political issues around empire building and resource contention.
In addition to our Tribes, Squads and Chapters, we also have virtual organizations called Guilds. Guilds are cross-tribe organizations centered on different technical or interest areas and their membership is voluntary. The guilds serve as ways to promote cross-tribe collaboration and communication, especially around things like best practices. For example, we have guilds for Web Development, Agile Practices, Leadership, Test Automation, etc. The guilds foster developer-to-developer communication, which is one of the ways that we keep all these autonomous teams from all going off in completely different directions.
From Henrik’s paper, this diagram illustrates the organizational structure I discuss above:
I’d like to give some more background around why we have implemented this organizational model at Spotify; elaborate on our goals for implementing it, and discuss the aspects of our culture, which have been critical to its success. It is really great that other companies have been inspired by the way we work, but I think if you implement only parts of the model or try to impose it on a very different corporate culture; you will have a difficult time achieving the same level of success with it that we have had.
If you are considering using the Spotify organizational model within your company, there are a few things that will be critical to your success:
Our organization model assumes that engineering is doing development with agile methodologies. Our goals for autonomy mean that we do not prescribe any particular development framework our squads must subscribe to. However, all of squads use agile development methodologies. While we do our best to minimize dependencies between squads and tribes, there will always be some since we are all working on the same product. Any individual squad choosing to build using a traditional waterfall or other non-agile process would not be able to keep up with the rapidly changing teams around them. If they tried to impose some sort of process on other teams so that they could follow a longer-term development plan, they would start slowing down the rest of the organization.
A critical requirement in making our organization model work well is that the entire company works with and understands agile practices and processes. While our legal team isn’t doing scrum or kanban, they are used to working with engineering teams that use agile processes. Having the entire corporation understand and agree with agile means that no line of business area becomes an impediment to the speed of implementation. Think of this in terms of Amdahl’s law, applied to a development organization. If your development teams are working quickly in parallel, but marketing or legal is not supportive of an agile approach, they will become a bottleneck that will slow down the overall speed of the company.
Similarly, implementing this with just one team as a test in a larger engineering organization will be prone to issues. A traditional engineering organization is not usually set up for autonomy. Adding a single autonomous team within that web of dependencies is likely to hamper and frustrate the team and skew the results of the experiment.
While I’ve mentioned autonomy in several places already, I cannot understate its criticality. Each squad must be empowered to make their own decisions, not only on features, but also on development model, infrastructure, and implementation. Every decision that has to be approved outside the team means a delay that slows development. Each dictated implementation or infrastructure decision means that a technology that doesn’t fit to the way the team works or something new that must be learned before the team can build. This is a challenge to coordination, but in practice it isn’t as bad as it might seem. Best practices and technologies do spread from team to team through avenues like guilds. Teams adopt these practices and technologies on their own schedule or pioneer new ways of working if it makes it easier for them to deliver value to our customers and then spread their learnings to the other teams.
Trying to layer the tribe and squads model over a traditional reporting hierarchy would be very problematic. While we have many long-lived squads at Spotify, we are constantly creating and disbanding squads as new needs arise or missions are fulfilled. Squad membership will also ebb and flow as required by the needs of a squad’s mission. Traditional hierarchical organizations are self-perpetuating and restructuring them is very disruptive both to the management chains as well as the individual team members. You would gain some of the benefits of the Spotify model by building full-stack teams in a traditional organizational hierarchy, but you would lose a lot of the overall speed benefits that we leverage with our matrix organization.
In conclusion, if you are looking to improve the speed of your development and are inspired by Spotify’s organizational model, there are a few things that you need to understand. Our model works because it is layered on top of our corporate culture. Our culture values autonomy, agile processes, democratic teams, and servant leadership, amongst other things. You can certainly take some of the ideas from the way we work and apply them in your organization, but without the cultural underpinnings you may not get the same returns.
Some other references worth checking out are Henrik Kniberg’s keynote at the Paris Scrum Gathering and my keynote at the { develop: BBC } conference.
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
Thoughts on emulating Spotify’s matrix organization in other… http://t.co/KDsNIQxdto via @instapaper
Great insights from a good friend.
RT @kstewart: Thoughts on emulating Spotify’s matrix organization in other… http://t.co/KDsNIQxdto via @instapaper
Great insights from a…
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
RT @kstewart: Thoughts on emulating Spotify’s matrix organization in other… http://t.co/KDsNIQxdto via @instapaper
Great insights from a…
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
RT @KevinGoldsmith: Thoughts on emulating Spotify’s matrix organization in other companies: http://t.co/fZNuDiuBv7
Is there a “guild coordinator/leader”? I’m wondering how you convince folks who have a full plate of work commitment for their own chapter/tribe to break out of that occasionally to encourage cross-tribe collaboration. Thanks.
Cross-Tribe or even cross-squad efforts can be challenging. The way that we handle this is by making sure that the larger priorities for the company are widely communicated. This way the squads have the info they need to make good prioritization decisions. For the things that are lower priority, that sometimes requires a bit of negotiation between teams. Plus, you know, karma. We may not agree on priorities, but we generally try to do right by each other…
You write that you are constantly creating and disbanding squads as new needs arise or missions are fulfilled. Do I have to think of new squads forming every few months or what is the shortest a squad is staying together? Coaches often stress the point that it takes time for a team to form and thus the squad should not be taken apart too often. What is your take on that?
This depends a bit on the missions of the squads as well as the tribe culture and mission. My tribe has many of the feature teams, which means that the squads in my tribe are long lived since their missions don’t have an end point.
We’ve created one squad and dissolved one in the last year, but that squad was dissolved because the Echo Nest joined the company and they had people already doing the mission of that squad. So the tribe could use the members’ skill sets to better advantage elsewhere. The new squad was solving a problem that another squad really had two missions, so we wanted to get more focus on each of them. One of the squads also decided themselves to split into two because they felt that they were too large to be effective, but now they are recombining because they are in a new stage of development on their feature.
We’ve also created temporary squads to solve specific technical problems or address a one-off need. Those squads will sit together and work like any other team, but with no plans to continue after their mission is finished. When they are done, they go back to their normal teams.
In other tribes, they tend to have a lot more shorter-term missions so squads will spin up or spin down. Squads also will tend to recombine based on the evolution of their mission or as they take on new challenges.
The effectiveness of a long-term team versus shorter term teams is one that we discuss often. I’m a firm believer in the effectiveness of a group of people that have worked together for a long time; and that has been proven out as well at Spotify when we’ve investigated it. Because tribes get us around the Dunbar number problem a bit, squads changing isn’t the same thing as bringing in a bunch of new people. People end up working with each other in multiple squads. That said, we are trying to figure out how to maximize the benefits of longer term teams while still having the flexibility that we value. There are a bunch of experiments going on around this right now.
Thanks for this article
How do you manage priorities and budget ?
If two tribes need more people, and no more people “exist” in your company, how do you deal with this ?
Thanks
Good question. This is one are where we are continuing to experiment on the best ways to achieve alignment across teams and have a shared understanding of priorities without compromising autonomy. Today, when a tribe is short people for a project, we will usually ask the other tribes to borrow some people temporarily. This isn’t usually a problem, and in fact is fairly common practice. The karma effect works well here. I am usually inclined to help out other tribes if I can because I can count on them to help my tribe out. In fact, one way to get a lower priority project done by another team is to loan them the people to make it happen. We do this too.
We also do this on the smaller scale from squad to squad with our tribes as needed.
An important part here is that usually this also involves selling a project to a developer since they obviously will get a say. Most are happy to do this from time to time to get exposure to things other teams are working on or to help out.
Hey Kevin,
would you be able to post some more details on each role, or overall process, for example, what is the tribe leader responsibility, and how things get initiated, who drives the overall development, ideas, and etc.
Also very important, how do you document the work, since it is vary progressive development.
Additionally, have you implemented any Quality Assurance processes, and how do they affect the agility of the squads?
I know it’s a lot, but any feedback would be highly appreciated 🙂
Thanks,
Alex
Alex, that is a pretty big ask. There are lots of presentations and the white paper I refer to that should answer many of your questions.
One thing I will say is that we document our work, but it works differently in different teams, we tend to let each team do what makes sense for their process. Good ideas tend to get adopted by multiple teams and eventually they become the way everyone works, but it isn’t something we force.
We have several quality roles (although quality is everyone’s responsibility at some level). We have QA who are focused on manual testing, QE who are focused on building test infrastructure, and TA who build large-scale test automation. This is in addition to our test-driven development practices.
I have been working with quality roles in agile teams for 15 years, anyone who says that agile and testers are incompatible is just wrong.
Hey Kevin, I find the Spotify org structure very interesting, but all I have ever seen written about it is how well it works and I am wondering can you think of the challenges you have had to work through because Spotify is structured the way it is and how have you done this? I also was wondering what were the key drivers of the change toward this structure?
Thanks for your question Danielle, in my talks, I usually try and include some of the stuff that we’ve had to work through to support our model.
There has been one thing that has been especially challenging due to our structure which is handling large cross-squad and cross-tribe projects. If you are set up to have lots of autonomous teams, what happens when you need to work on a project that requires lots of those teams to work together? This has been difficult, and when these projects happen we try to learn the lessons from past exercises to get better with our next attempt.
We are just completing a major project that involved a third of the tech organization (press event is on Wednesday!) and that has been our most successful large project thus far. After the retro, I may write a blog post or talk about it.
Another challenge has been how we continue to scale the existing model. It isn’t so much a problem of the number of squads, but more how to grow without adding more levels of management. In a servant leader culture, you need to be able to support your reports, which means you can’t have too many of them. How to do that without adding extra unnecessary levels of hierarchy is something we’ve been focusing on a lot lately. I will likely discuss this in some of my talks later this year.
In general, the best part of what we do is that we don’t get too pedantic about the way we do things. We are continually adapting and changing our own model to suit the issues and problems we encounter. If there are any lessons from our model that other organizations should pay attention to they are: model your organization to your culture, focus on constantly improving, and be free to change and experiment (and consequently to make some mistakes).
One of the reasons you don’t hear a lot about the problems with the Spotify organizational model is that it is constantly adapting to fix its own deficiencies. It is another reason why any particular talk or blog post you read is more of a view of a moment in time instead of the way things have always been or will be.
Hi Kevin, this post is very interesting, and shed some more light on Spotify.
I have a question regarding test automation infrastructures, used by QA & Dev engineers – From your experience, in a model similar to Spotify, of autonomous squads, is it better to have a dedicated squad developing these infrastructure, or is it better to let each squad develop its own infrastructure?
Thanks!
We used to have each team developing their own (or leveraging existing ones). Over time we found this wasn’t very productive because it was hard for teams to run each other’s validation for shared trees like the client products. It also made it harder for people to help out other teams. So we consolidated this effort and there is a squad that is responsible for it now.
thank you for sharing your experiance.
A big company wants to change “only” in some Business Parts to agil organization. This parts needs as you write in one answer a real change and also a alowness not to use / be in the process…. How are you handling the “process” – salary , bonus, and the personal targets and so on? (welcome to big company not yet there where Spotify is but dreaming of it )??
Awesome!
Given that all structures have their compromises you’ve probably just about hit the sweet spot with this as far as balancing agility and consistency across teams. But I have a question about what the structure looks like above tribes?
From the very top there are usually big picture questions about how product X (or the company as a whole) is doing against some form of plan. Conveniently ignoring the problems with top-down plans, the questions: “are we doing ok?” “are the products making best use of company-wide budgets?” “are we fulfilling our strategic vision” are at least understandable. Usually the CEO asks these things of the CTO in order to summarise a holistic picture. The old-school way would probably be to have Tribe Managers, or worse, programme managers of managers of tribes.
The CxO is then faced with either having lots of direct reports and having a decent shot at knowing what’s going on (by consolidating a lower level technical picture themselves) or having fewer direct reports who will inevitably be less in touch with reality on the ground.
Are you able to say anything about how the bigger picture view gets wrapped up and managed? This works in reverse too of course – every developer likes to feel that their work contributes to that big picture and the more layers you have the more confusion is sowed in the communication.
We of course have CxO roles and they have product vision and set goals for the company.
The main difference in an autonomous bottom-up model and a command-and-control top-down model is that the amount of detail that gets specified at the senior levels. The goal of senior management (including myself) is to set the large-scale goals, give the context and coach/challenge the organization of necessary. The team needs this information (it gets enhanced as it goes to the tribe by the next level of product/tech management) to make good decisions aligned with the company objectives. However, the teams are still driving their missions towards these objectives and not the other way around.
We are always 100% successful on actually living the vision, but we are always striving for this.
This was great! It answered a bunch of the questions I had about the model. We followed something similar a little while ago, and switched to a model where the reporting structure follows the squad structure. Now, we’re running into many of the problems you mentioned with that model, and we’re thinking of switching back to a less hierarchical structure.
I’m still confused on something, though.
How does growth and performance management work when the chapter lead isn’t necessarily involved in their chapter members’ day-to-day work? How does a chapter lead decide on compensation increases for their chapter members, help them pick up on skills they might be missing, or understand when a chapter member is underperforming and needs help? Do they rely on feedback from the other members of the squad?
I’m sure I’m missing the differences between a chapter lead and a traditional “X manager”, but I’d love to hear what those are.
Yes, the chapter lead talks to the other members of the squad. There is also an informal group that has evolved called the POCLAC (Product Owner, Chapter Lead(s), Agile Coach) for many squads that meets regularly and issues and good things will come up in that meeting so that the CLs know if there is anything they can do.
The main different between a CL and normal people manager in a more traditional organizational model is the the CL is focused solely on the personal and professional development of the people that work for them and not on team deliverables (since they are not a team manager in the traditional sense).
What do you think of rotating squads after a period of time to take on new missions and having other squads pickup their old mission?
Thanks for this article, really great!
A few questions, I would be happy for some feedback.
How many direct reports do you have as a tribe leader and which roles are reporting directly to you?
Does the tribe lead focus on personal/professional developemnt of the people (as a Chapter lead) or also on team deliveries/functionalities?
How many people are in a chapter/a squad. just average?
Thanks
@Karim:
You’d lose the institutional memory and expertise on the systems in that case and there would be a big ramp up. You’d also run the risk that the squad picking up the “old mission” would feel like they were getting some other team’s cast-offs while that team moves on to new and more fun things.
That said, we have done exactly that quite a few times. Some times it has worked well, when the squad taking over the other’s mission is passionate about that mission. Some times not quite as well, when the squad moving on to new things didn’t want to give up their work. In general, we try not to do it very often. It is an exception rather than a rule.
@AlexP
When I was a tribe lead (I am now an alliance lead which means I have tribe leads reporting to me), I started out with eight direct reports, I think. Five chapter leads, and three agile coaches. As the tribe grew, I eventually had around twelve direct reports. By the time the tribe grew to be over 80 people, I started having Chapter Leads reporting to other Chapter Leads because I couldn’t support them all reporting to me any more. It was also a good way to grow my senior chapter leads and prepare them for more senior management roles.
The Tribe Lead is responsible for both the professional development of the Chapter Leads and the Individual Contributors in their tribe as well as making sure that the tribe is delivering and that the individual teams are effective. The Tribe Lead is the first level of full-time management, the first level of “Directly Responsible Individual” in the organization. That doesn’t mean that the tribe lead is telling teams what to do. It means that the Tribe Lead is supporting the teams, coaching them, but also taking the responsibility to make sure that the teams are delivering against company and tribe priorities.
Chapters might range from 3 people up to 14. For a very large chapter, the Chapter Lead will end up becoming a full-time manager in order to support all the people. It is more common in some tribes rather than others. In my tribe, most of my Chapter Leads wanted to remain contributing members of squads, so we kept the sizes of Chapters on the smaller side which also resulted in me having more Chapter Leads in the tribe.
A squad size is based around a traditional agile team size. So usually between six and twelve people. There are smaller squads and larger. Full-stack feature teams usually are on the larger side or squads focused on a particularly large mission. Usually if a squad gets too large, it becomes a victim to it’s own mass and then usually the squad will split into two to be more effective.
Hi Kevin, thank you for the insight. I have one more question. How do you handle branching/merging and code ownership. Do you have code areas that are being modified by several chapters ? In this case, how do you make sure they are aligned ?
And in case each piece of code has a chapter who owns it, how to you make sure that chapter members from different squads do not end up breaking each others functionality ?
Thanks
Each client shares a single tree. We used to have feature teams own their own branches, but that lead to merge hell for each release, so we switched to having the squads share a tree for each client. For services, we build micro-services, so those codebases are relatively small.
We don’t dictate a code style, but with everyone working in the same code base and having things like guilds helping to spread best practices, people tend to converge on a common way of working. As well, we are pretty serious about code reviews, and that will catch any problems that may come up usually.
If we consider this like any other shared code base, be a good guest, be a good host, and leave things better than how you find them, it works pretty well. We have fairly decent test automation, but that is certainly something we are continuing to focus on.
Where does quality control and release regressions fit into this model?
I would imagine that different Tribes and Squads are empowered to make changes to core libraries. Who ensures that their changes are not breaking some critical process that the group does not have visibility into?
Who runs a final regression, ensures unit test coverages, ensures compliance with critical regulations and agreements (for example privacy and preventing one team from storing user information and setting up the company for a lawsuit?)
Each team is responsible for it’s own quality on it’s features. We have an additional team that is looking across the product on each platform making sure that the holistic quality is good and that nothing gets caught between the cracks of the features.
We have a lot of test automation that runs, additionally we have a pretty strong code review culture. A breaking core change is usually caught pretty quickly given that it will have implications all over the product.
The final regression is done by all the teams working together after we branch for each release. Teach team is responsible for it’s own unit test coverage and quality metrics. If a team gets a bit behind in this area, it would normally be caught either by the Chapter Leads or by the Tribe Lead. Compliance issues like Security and Privacy requirements are done by training and best practice sharing, all teams are responsible for their own systems / features.
Hi Kevin
a couple of other inquiries about the spotify model based on the videos and white paper I would like to ask about :
1. The Client app squads what are their role and how do they differ from the client/FE developers in the squads themselves? That is especially if we are developing native apps and all squads need to touch the same app
2. in an organization where the are multiple channels serving multiple products it becomes complex to readily understand responsibilities. Channel representatives (digital for example would be a channel) act as POs but they still have to discuss with Bus Owners on what is coming through from a roadmap perspective. Also what BO bring in might touch multiple squads and thus this becomes complicated from prioritizing and deliviring. One thing that caught my attention was the Open source model mentioned that could be a potential resolution to interdependencies. The one question I am not sure and hoping to get your feedback is how to assign incoming BO requests to the squads?
1) The client app teams handled the app framework, all the “in between” bits that weren’t owned by the feature squads. We no longer have these squads anymore. The feature teams took on those bits themselves and are now completely responsible for delivering the clients with some build and test infrastructure support from the client infrastructure teams. All the feature squads work in the same shared client codebase.
2) We don’t have Business Owner roles. There are of course stakeholders in other parts of the organization that make requests to the tribe or the squads. It is up to each squad to prioritize these requests with the context that they have around the business needs and larger scale priorities.
Thanks Kevin, what are your thoughts on creating a seperate squad for the client side and having the feature teams only run with server side code. The challange is that with fullstack there is the argument that some user stories are going to be Client only and that could impact the teams velocities as only the client developers would be busy (in the case devs are specialized).
In practice, that isn’t really a problem in full-stack teams. The team will try to balance client-side work with server side work, so even if there are some client-side only stories, there will be other that will require some server work that the team can work on, or some server-only side stories. The benefit of full-stack teams is that you don’t end up with hard dependencies between teams which create synchronization bottlenecks which affect the velocities as teams have to negotiate priorities. Also, in practice, while some devs are more specialized, many of the client devs can do some server work and the server devs can do some client work as well…
Thank you so much for this post. It’s very very helpful. I have some questions, it would be great if you can answer them. Thanks in advance!
– Do you have one agile coach per squad or agile coaches have they own squads and are shared between the other squads? Same question applies to UX/UI people and testers.
– Which are the tribe leader’s responsabilities? What are his/her main skills? Is he/she part of any squad besides doing management stuff?
– Who does the tribe leaders report to?
– Who are the CTO’s reports?
– Do you have career paths? If yes, can you provide an example pls?
This post was written before we created new structures to support the growth in the organizations, Alliances and Missions. I explain these in this talk: http://www.infoq.com/presentations/spotify-culture
– We hire more senior coaches usually, and they will support multiple squads. Different numbers in different tribes. I tend to think that a senior coach can handle 3 squads, but beyond that they get spread a bit thin.
– The Tribe Lead is responsible for the tribe, both individual growth, team health, delivery and (ultimately) technical choices. The Tribe Lead supports the tribe, servant-leadership style, but they are expected to bring their expertise and experience to help the tribe make good decisions (instead of make decisions for them). They also make sure that the tribe has the right information to make good decisions, and they will represent the tribe in other forums.
– Tribe Leads report to Alliance Leads if there are multiple tribes supporting a single mission or directly to the CTO if they are the only tribe in a mission.
– The CTO’s reports are Mission Leads.
– for information on our Career Paths: http://blog.kevingoldsmith.com/2016/03/15/building-a-technical-career-path-at-spotify/, https://labs.spotify.com/2016/02/15/spotify-technology-career-steps/, https://labs.spotify.com/2016/02/22/things-we-learned-creating-technology-career-steps/
Thanks a lot for your answer, this information is really helpful and inspiring!
I read about the steps framework (very interesting!) and I also watch the infoQ video. I have a few more questions:
– You say you have a Chief Architect whose mission is to ask the difficult questions and so on. He is one for the whole tribe(s)? Does he belong to a chapter (are there other architects in the squads?)? Who does he report to?
– Do you have one UX per squad or they are a pool shared by the squads?
– I understand that every tribe has an IT lead, a PO lead and an UX lead. Does the three of them reports to the CTO?
The Chief Architect reports to the CTO, so he is not in a chapter. We have one UX per feature squad, we don’t share them between teams. The tech lead for a tribe reports to a Mission Lead who reports to the CTO (I am a Mission Lead now). The PO and UX report to our head of design and Chief Product Officer.
Hi again Kevin. Thanks for all the answers, I have one more. Do you have a team lead or tech lead in every squad? If yes, what are her/his responsibilities?
Thanks!
I have two questions.
1) How do you deal with business as usual (BAU) once a project is done? Is the squad reduced in size, or do you have a dedicated BAU team?
2) How are marketers put aware of new features being deployed? Since there are multiple release trains, releasing at any appropriate moment, how do they figure on what to communicate towards the web?
1) If a squad dissolves because their mission is complete, part of the definition of done is that any systems that were created have to have new owners before the squad disbands.
2) Marketing gets the updates of what is in flight and what is currently being tested, but they used to be a bit reactionary to things because they weren’t brought into the process early enough. That is improving and there is a stronger marketing/product development bond now.
Many thanks for your replies.
Talking about Spotify’s approach, a colleague commented that this extreme-agile approach only works in the US. Companies that tried this out in Europe failed. Is this also your opinion?
Well, Spotify developed this approach and is mostly based in Sweden. So, it is really a European model. ING, Skyscanner and several others have modeled their organizations on this as well. I actually don’t know if any US based companies have successfully implemented this model.