Introduction

My name is Juan, and I’m an Engineering Manager at Spotify. I’ll address the scaling of our organization, in particular, transitioning from smaller teams to having hundreds of developers today.

Our model is not typical and is instead based on rapid innovation. This helps us stay competitive in our landscape. Our model reduces the bottlenecks for the decision making, and allows everyone on a small team to make the decisions to drive our network forward.

Full-Stack Autonomous Teams (Squads)

The model starts with a small unit that is full stack and autonomous. It has all the needed components to run: a product developer, an iOS developer, and Android developer, QA, an Agile Coach, and a product owner. As a full-stack team, there’s little need to depend on other teams for development, and they’re given the latitude to innovate in their space.

The squad room comfortably fits 12. By keeping the team relatively small, it’s possible to iterate and innovate quickly, and they’re able to have discussions regarding the feature they’re working on. A product of this environment is that the team has a collective responsibility on their tasks. If a search feature on iOS does not work, the fault is felt with the team as a whole, and not solely on the iOS developer.

Squads have their own leadership group, and that is comprised of the Product Owner, Chapter Leader, Agile Coach. The acronym we use for this group is the POCLAC. The leadership style is not a “top-down” approach, offering directives to the group, but rather, it’s assessment based. They assess staffing and performance in relation to the tasks to be accomplished.

Chapter Lead

A person who oversees one to five squads is called a “chapter lead”. I am a chapter lead. A chapter lead someone squad members can talk to if there are issues; someone they can talk to about salary and growth opportunities. It’s important to note that a chapter lead is not a manager of the team, but is a manager of a domain that spans across teams.

As chapter lead, it’s possible to get great visibility on issues. For example, if a team is lacking, or needs support, you can talk to people to resolve those issues. It also allows for better cooperation. Suppose I need another iOS developer to help with a feature on a particular squad, I can shift the iOS to another squad, and they’ll retain the same chapter lead. This allows the ability to build a good long-term relationship between the chapter lead and the individual contributor.

In developing for Chromecast, I worked with other partners. We took contributors from different teams and kept an open discussion with different chapter leads. This allowed us to pick people from a team, ship the Chromecast app, then bring the people back to their original teams.

Tribe

Different squads that work on something in common is called a tribe. I work in the partners’ tribe. The squads in this tribe work on TV, car integrations, and the Spotify connect feature. The ideal size of a tribe is around 40 people, which is the minimum amount needed to justify this structure. Any more than 150 would be too big. The purpose of a tribe is to allow people to know one another, share knowledge, and to show demos. We do not want to reinvent the wheel.

The tribe also has a leadership structure that comprises of Tech, Product, and Design, TPD for short. The product lead here corresponds to a product owner in a squad - this is the same for designers.

Guild

Another structure, a Guild, exists to ensure that all of the squads’ efforts are in alignment with company-wide decisions. Because a squad is capable of pushing code to the app, there may be some conflicts. Some questions for the guild include whether they’re supporting iOS 7, what the minimal acceptance level is for unit tests are, or how we should use assertions in our code base.

There are guilds for many things at Spotify. Some are technical, like iOS and Android, but there are also guilds for photography, for example. Guilds meet regularly, and attendance in those meetings are optional.

Alliance

Coordination between tribes requires an alliance. Roles at the alliance level includes VP of Ingenuity, and the VP of Design for example. At the moment, there are four or five alliances.

How We Hire

Spotify is a big organization, and we hire about 100 people a month. There is a mobile interview committee who meets on a semi-regular basis. They are responsible for our first interview, which is an online code challenge they designed. They get together to discuss new problems, solutions, and make improvements to the challenge.

The mobile hiring panel makes further decisions after the online coding challenge. The panel is formed by engineering managers and HR. Each candidate goes through four interviews. Based on that feedback from those interviews, the hiring manager decides whether or not to hire the candidate.

Diversity is very important for us and our product. It’s important to have a diverse group to help create a product that is used by diverse people.

As an example, during my first week at Spotify, I was in a meeting and they were discussing why people subscribe to Spotify Premium. Many people in the meeting never thought of the offline functionality as the reason. This is because they personally never needed it, as they are from countries with great internet. Other countries, like in Latin America, do not have great 4G, and the offline capability is essentially required to use Spotify.

Another example is that when we launched a feature called Moment, diversity was important because we needed to make sure that the life moments in the feature were culture, gender, and age diverse.

Our interview process

HR initiates a conversation about your experience and asks you which team you want to join. Then, there is an online challenge with two engineers (the one I previously noted). If you pass, you fly to Stockholm for a full day of interviews. The interviews are broken down to include:

• Culture: career and team fitting
• Problem-solving: analytic ability
• Show and tell: sharing what you’ve built
• A Team lunch

A final decision to hire is based on the interviews above.

Onboarding

As part of onboarding, we have a boot camp that is run by people operations. Here, you get to practice working on a squad on features. You learn the tech setup and the release cycle. Projects that are worked on in boot camp can end up being real projects shipped to production.

Change is Constant

Changes are constant in our model. We had a reorganization last year, and people were given the choice as to which team they wanted to work on. One of the teams I was in started with three, but eventually had to be divided because it grew to 45. The structure we created looks chaotic, but it is done well and is capable of solving problems by having a fluid and dynamic environment.

What Does not Work Well?

Big projects are difficult, particularly projects that require the whole company to work together. For example, we recently launched a video feature; this required video support, new protocols, new UI, and backend changes. This was a task that involved at least 1,000 people.

With big projects, we have resorted to traditional waterfall techniques, which results in reinventing the wheel. For example, because squads are autonomous we ran into the issue of writing two communication protocols for Bluetooth and writing two ways of evaluating metadata.

Q & A

Q: How does this model across different locations?

• Juan: Some of the tribes spawn in more than one location, but squads do not.