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.
Thanks again.
[1] https://en.wikipedia.org/wiki/Bus_factor
[2] https://www.groovehq.com/