The “Spotify model” is an incredibly popular organizational methodology for managing work across teams. Personally it’s been present in some form in the last 4 places I’ve worked since 2014.
The Spotify model is a matrix organisational model that highly values team autonomy with servant leadership.
Now the critical thing is that you have to enable the team to be autonomous! You need to support the team members at their various levels of experience on how to be autonomous and effective. If you do this you will also get higher engagement in your culture and the actual work.
The Spotify Model
I’m going to assume you have heard about the model already. There are heaps of resources on google but I find that it’s critical to read the original whitepaper at https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf.
The core unit in the model is a “squad”. This is an autonomous, cross-discipline unit of 5-12 individuals that together own a product or product feature. There is no explicit leader of the unit. The product owner is responsible for prioritizing the work to be done by the team, but is not involved with how they do their work. The team must own their own processes. The process that the team uses to complete work should fit the team.
It’s interesting to note that the “model” was never intended to be a static model that could be transposed from Spotify on to your organization. In the original whitepaper it’s explicitly stated…
Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed.
Copying the model is a starting point, but you should have a process in place to adjust the process or model as your organization and the projects you work on change shape.
You also need to understand what your organization’s culture is. You will need to explicitly provide the support for the individual trust and autonomy that the model demands if it is to be successful.
In other words you should be trying to get your teams and culture to a place where you can invent your own “spotify model” internally!
Autonomy
Daniel H. Pink wrote the book on autonomy in the workplace with his book “Drive”. He provides a generic audit for measuring autonomy in your organization at https://www.danpink.com/audit/.
This audit can be augmented for a specific product development team by working through the following with the team on a whiteboard or in some kind of facilitated discussion. These topics are fundamental to providing a supportive environment for autonomy and trust. You might be surprised that the individuals in the team have different answers than you or each other.
- Do you have a clear mission?
- What are the constraints and principles for your product and team?
- Explain how you receive support, organizational or technical?
- Do you feel fully trusted to do your work?
The responses to these questions can highlight gaps in your explicit support for autonomy. You can fix these AND improve engagement at the same time.
1. A clear mission
In order for the team to know that they are making the right decisions everyone has to be on the same page on what the mission is. This needs to be unambiguous and repeated regularity. It should be clear how the stories or problems to be solved will adance the mission. Everyone that’s on the team should care about the mission.
The mission will change as the team gets customers, solves problems and learns new things, but don’t assume that this shift is implicitly understood by all the team at the same time. Be explicit. An example might be moving from a temporal mission - we are optimizing to get this feature done by April, to a product market fit mission - ok we got that done, now we need to iterate on the feature and improve.
2. Constraints and principles
It should be explicit what the constraints are for a team in your organization. These constraints should be written down and understood by all the team members. This doesn’t have to be crazy, just list the really important things and the things that have caused wasted time previously.
e.g. we have to use AWS, we have to support GAMP, we use these languages or tools at our organization to keep costs down, this client of ours values predictability over scope or quality. These are things that some team members might be exposed to and have an implicit understanding of but others may not. Again it’s better to be explicit.
3. Learning and support
It’s important that the team members have access to support for organizational issues or technical issues. Is there a person they can present questions to about the Spotify model at your organization?
If you’re using scrum or kanban, has the team received explicit training about how those methodologies work, what they emphasize? Do they understand how to measure the success of each methodology?
If you have pick’n’mixed parts of each methodology, has the team explicitly understood the tradeoffs from losing parts of the methodology? Are they changing the methodology to solve a specific problem?
Being able to change the methodology being used confidently is a great way for the team to improve their autonomy and improve throughput by having a process that fits the team and the work!
4. Trust
Trusting the team means when you have the first three items above dialled in, you can just let them off without checking in every day. This can be difficult for organizations more used to top down management or close supervision. You have to know that almost everyone you work with is going to do their absolute best to solve problems they understand and care about. If you have done that bit then you don’t need to worry about engagement.
Issues usually arise from miscommunication. A common issues are that the team didn’t understand the mission or the constraints. You really need to spend the time to ensure these are communicated and understood well. Get the team to play them back to you in a facilitated way to verify.
Another common issue is that the team didn’t have the competence to solve a problem but the culture in the org didn’t allow them to ask for help, or they didn’t know where to ask for help. To have a successful Spotify model you should make sure there is always help available and it’s encouraged to learn from others and to share knowledge across teams (This is what the chapters and guilds are for).
Trusting the team also means supporting them through perceived failures. Make sure they are focusing on the lessons that were learned.
There will always be something to work on here but it will be specific to your team so I won’t talk about it too much. Always be trying to improve trust in the team.
Consider trust between team members and between your team and the other teams or stakeholders too!
Feedback and Autonomy
Ensure there’s a feedback mechanism so the team knows that they are on the right track! Have the team members provide feedback to each other too. So for example if you use strict Kanban, add a regular retrospective type meeting in there!
