Thanks for making it clear that you work at Spotify. Transparency is good start :-)
I just watched both videos. Thanks so much for doing these ! Or maybe thank Henrik when you see him, haha :-)
I have a lot of questions.
From what I understand, Spotify squads each focus on one area and each squad has very different members so it can stay autonomous. Is that right? What happens if sysadmin / developer / designer from squad X gets hit by a bus ? I'm actually talking about the bus factor [1] here, I hope you are all well :-)
How often do you change squads ? What about tribes ? The second video mentions "guild unconferences". What is that ? Can squads work remotely ?
How does code review work at Spotify ? For the last 2 weeks, we've been using pull requests on Github, which I've found to be a very good way of doing code review. Since the reviewer is the one to merge, eventually his/her name is on the commit too, which in my case makes me focus even more before hitting the "Merge" button. Merging creates an explicit merge commit, which makes reverting things easy if needed. And discussion in the comments allow for efficient, asynchronous discussion.
The video talks about how important trusting employees is to Spotify. That makes me wonder: do employees sign such things as non disclosure or non compete agreements ? what do you (or what does Spotify) think of such agreement ?
For the last few months, I've been reading the Groove blog [2]. Recently, Alex, Groove's CEO, talked about how much time he was spending talking to customers. How much do you (devs, sysadmins, marketers, designers, etc) communicate with users ?
How do gradual rollouts work ? Do you use a third party service for that ? Would love to learn more.
Hey! Thanks for the long question. I'll pass on your regards to Henrik :-)
> From what I understand, Spotify squads each focus on one area and each squad has very different members so it can stay autonomous. Is that right? What happens if sysadmin / developer / designer from squad X gets hit by a bus ? I'm actually talking about the bus factor [1] here, I hope you are all well :-)
It's not always easy of course. I think the notion of T/M-shaped people apply. E.g. if only one person in a squad can do iPhone development, better spend time training some of the other people to do it as well. It also creates collaboration opportunities, which are highly important to actually make a team work. Then of course there is a lot of fluidity between squads. If squad X needs design help but are out of a designer, squad Y might lend their assistance.
> How often do you change squads ? What about tribes ? The second video mentions "guild unconferences". What is that ? Can squads work remotely ?
It varies. Some people have been in the same squad for two years, others are in new ones every six months. And generally, you change squads and if a tribe move has to happen, that'll happen as part of that. Squads are generally co-located though, so not many squads are remote-composed. A guild unconference is simply an unconference (http://en.wikipedia.org/wiki/Unconference) on a certain area, e.g. Machine Learning, Web, Mobile, Backend etc. So all the people who are interested in that get together for a day and debate the future of that area.
> How does code review work at Spotify ? For the last 2 weeks, we've been using pull requests on Github, which I've found to be a very good way of doing code review. Since the reviewer is the one to merge, eventually his/her name is on the commit too, which in my case makes me focus even more before hitting the "Merge" button. Merging creates an explicit merge commit, which makes reverting things easy if needed. And discussion in the comments allow for efficient, asynchronous discussion.
We use GitHub as well. Roughly the same model.
> The video talks about how important trusting employees is to Spotify. That makes me wonder: do employees sign such things as non disclosure or non compete agreements ? what do you (or what does Spotify) think of such agreement ?
We think trust is highly important, and embodied in what we share internally and how open we generally are. Not sure I can comment on the legal aspects of that though.
> For the last few months, I've been reading the Groove blog [2]. Recently, Alex, Groove's CEO, talked about how much time he was spending talking to customers. How much do you (devs, sysadmins, marketers, designers, etc) communicate with users ?
Never enough :-) We do spend a lot of time with user research, both structured via our research team but also Starbucks testing, when a few devs go down to the local coffee shop and test features. Then we have community outreach teams that keep us honest and makes sure to push the customer voice inside the company. Also, a ton of engineers hang around on e.g. /r/reddit and asks questions. And when users blog about or voice their concerns, it does make the round on internal lists.
> How do gradual rollouts work ? Do you use a third party service for that ? Would love to learn more.
Mostly custom built, and it varies a bit between the backend and the front end. It's all the usual jazz though, deploying per machine or percentages of users or localized to markets etc.
How does accountability work at Spotify? It looks like your squads have a specific goal (and maybe a leader?) but when you get up to the tribe level it wasn't clear if one person is in charge of a tribe, or if a product, design and tech lead all share authority. If that is true, do you guys not suffer from the tyranny of structurelessness? How do you do strategic planning/coordination?
How do teams that are not engineering focused get stuff done? For instance a customer support team or marketing team - would it have its own engineers and engineering management?
Edit: finally, how long have you worked at Spotify with this culture?
Sorry for late answers here but thanks for asking questions!
> How does accountability work at Spotify? It looks like your squads have a specific goal (and maybe a leader?) but when you get up to the tribe level it wasn't clear if one person is in charge of a tribe, or if a product, design and tech lead all share authority. If that is true, do you guys not suffer from the tyranny of structurelessness? How do you do strategic planning/coordination?
Squads don't have leaders, but they do have product owners who ultimately owns the roadmap of the product owned by that squad. A tribe is lead by a trio of engineering, product and design. Responsibility for the various facets of the tribes output is divided between the three roles.
> How do teams that are not engineering focused get stuff done? For instance a customer support team or marketing team - would it have its own engineers and engineering management?
Yeah, the tech/product side of that have homes in tribes as well.
> Edit: finally, how long have you worked at Spotify with this culture?
I've been here 2.5 years. This structure has been in place for roughly three years, maybe a bit more.
I recently spoke to a recruiter at Skyscanner, and he mentioned that they have also adopted a similar model to Spotify. He called the model "Squads and tribes".
I work for Skyscanner, and can confirm this. It's a very effective model for managing a business this size, and IMHO fosters innovation within the business. Very basic description of the model as it is at Skyscanner:
Tribes - High level products (hotels, flights, car hire)
Chapters - "Departments"; areas of expertise (data acquisition, front end)
Squads - Autonomous project units (New features, development of an existing feature)
Guilds - Informal interest groups (Linux, Python, agile development)
Everyone is in a Tribe and a Chapter relating to their "department", and area of expertise; Squads are formed to work on projects, then disbanded once the project is finished; anyone can join and participate in Guilds, which serve as interest/support groups for technologies/strategies/methodologies.
Edit: Corrected my brainfart. Thanks ssabev! Can't believe I did it twice...
That's a good question. I think about it as a way to distinguish from e.g. departments, projects etc and set the connotation that these are different things. If you use them to mean a 1:1 mapping to e.g. projects, then it falls apart. The terms aren't important per se.
In other words – you can't make a race horse by painting a pig brown.
Cool to hear our model is getting adopted. A big difference here is that chapters at Spotify aren't departments, they are usually fairly small (5-10 people), and that squads are long lived, rather than project focused.
Never worked at Spotify but they seem very innovative (and they already let me rock out for eight hours everyday), so hey, nothing to bad say on my end.
Happy to answer questions.