What is the Spotify model?
Spotify is more than just a great music streaming service, they recently shared a series of videos that describe their engineering focused culture. When I first came across these videos a few years ago, they gave a glimpse of the Spotify culture and how they build great teams. Spotify instills in their team autonomy, the balance between process and innovation and trust. No matter what your team decides to do, the organization trusts that you can make the best decision for how your team operates. If one team loves Kanban but the other loves Scrum, use the methods that make sense for you. If one team wants to use Node.js and the other wants use Java, try them out and see what works for your team. Spotify’s entire premise is built on the idea that if you are a “build and run team”, than you should have the authority to make these decisions yourself. Honestly, I’m a sucker for team empowerment and I loved these videos when I first saw them and I shared them with everyone. If you haven’t seen these videos before (or if you haven’t watched them in awhile), the links are below. Concepts from them are referenced in the rest of the post.
Fast forward a year
The organization I work for decided to begin moving the entire Technology team towards agile methods and wanted to use Spotify as the foundational model. I thought this was a great idea; there is a lot of content about their model both written and in videos. The concepts in the Spotify model resonated with me and I saw it as a great primer for the team’s transformation. Armed with a team of coaches, we began sharing agile methods with the squads (or cross functional teams) and we started to have some successes. The first teams were already cross-functional (development, quality, business analysis) and both supported and built features for their system. They embraced team empowerment and started to learn more about agile methods and concepts. Our initial successes in the engineering teams gave us the confidence to look towards a complicated part of the organization, TechOps.
In the TechOps (or Infrastructure) part of our organization, the transition was much more difficult. These teams have a deeply held project mindset. Most of their work has a definitive start and stop date; they think like individuals, not a team. Spotify, and to a degree agile methods, were seen as checklists, and these teams would ask, “What do I need to do to be ‘agile’?” or “How does Spotify solve this problem?” The mindset and vocabulary were difficult for the TechOps teams. Their desire was to just copy the model rather than learning how to adapt it.
Strange things started to happen
By this time, most of the engineering teams had moved toward agile methods but the TechOps teams were beginning to have issues with the model. The language, customer focus and use of adaptive planning seemed strange to them. Because TechOps wasn’t inspired by Spotify they copied their concepts without embracing them.
The TechOps teams started to use the language of Spotify, squads, chapters and tribes but applied them to their existing team structure without regard to why the structure is important. Departments of 40+ people became squads but they were not cross-functional. Chapters were just the existing reporting relationships and the tribe was everyone in TechOps. The model they initially chose didn’t make a lot of sense and I knew they would struggle with it. I was at a tipping point, I knew this organization design didn’t make sense and they needed to figure out what made sense for their organization. If I continued to tell them what to do, they wouldn’t learn how to embrace change. As much as it hurt, I held my tongue and got the team to focus on a couple of basic ground rules.
- Focus on outcomes for your customer
- Have frequent feedback with the team
- Every couple of weeks take a step back and focus on continual improvement
Regardless of what they came up with, as long as they followed these rules, we would always improve from where they started. Even though they followed the ground rules, things eventually stalled.
What outcomes do you want from your team?
After a few months, the team was still going through the motions but hadn’t made progress in awhile. There was confusion around the purpose of Squads, Chapters and Tribes, what role everyone should play, and when to use Scrum or Kanban. They were spinning and needed some help. The problem was around the language other teams were using and not focusing on the outcomes the stakeholder wanted. They needed an intervention but I needed to get the stakeholder’s support first. She and I met for a brief conversation on how the team was doing. I asked her to forget about everything and answer this question, “What outcomes do you want from this team?”
The dogma can get in the way and distract us from important discussions. When the stakeholder was no longer burdened with the dogma, we were able to have a productive conversation about the team. After a few moments of talking about outcomes the team needed to accomplish, the stakeholder provided the following list:
- Focus on the major priorities
- Tell me what you’re delivering based on the priorities, not how it’s being delivered
- Collaborate with the team
Once we established the outcomes of the team, the stakeholder was able to come up with four goals that her department needed to accomplish in the next year. One of these goals was to improve employee productivity. We organized a small team (6-8 people) that were exclusively focused on this goal. Before we called this group a squad, we needed to verify that this model would work. If successful, then we would figure out how to amplify the experiment in other ways.
Help the team align to their goals
When forming a new team, I like to use an exercise that focuses the team on the goals they need to accomplish. Creating a charter is a helpful way to get alignment on the work, expectations, and any obstacles preventing success. Here are a few examples of questions I like to ask while facilitating a charter:
- What do you want to accomplish in the next 90 days?
- Who benefits from accomplishing this goal and how will they know?
- Who do you rely on to accomplish this goal?
- What other risks or dependencies will hinder you from accomplishing this goal?
In the chartering session, you should include the people that can answer the questions above as well as the people that will do the work to accomplish the team’s goal. If you need more than 10 people than your goal may be too broad. Tighten it and try to make the group smaller. At the end of chartering session your team should know in what areas they need to focus, any obstacles in front of them and if they have any dependencies. A few weeks after the charter you should have a retrospective as a touch base to understand how the team is doing. Remember, it’s not about getting it right; it’s about learning and adapting.
Remember it’s just a model
After a few weeks running this experiment with the team in TechOps, they liked the approach and we are now talking about how to start the next experiment focusing on another goal. We had a retrospective and we’ll use the lessoned learned from the initial experiment to figure out our next steps.
Models are a great starting point for figuring out new ideas to incorporate onto your team. Start slow, do your research, and learn why this model worked for a particular organization, at a particular moment in time. Once you are ready to try a small part of a model, come up with a hypothesis and figure out how to measure the experiment. After a few weeks running your experiment, use a retrospective to help measure your results. If the team is improving, amplify the experiment, if not dampen it. Remember, it’s just a model and you can’t copy it. The key is to adapt the model to fit your organization by using small experiments to figure out what works for you.