Spotify Squad Models feat. Kevin Goldsmith, Former VPE of Spotify
Tonight's Fireside chat is hosted by Interna. This is the first of a series where we asked today's leaders to acknowledge what they have learned and how to innovate on product, strategy, and technology. The interview will be conducted by David Subar. David is the founder and managing partner of Interna, a consultancy that enables technology companies to ship better products faster, to achieve product market fit more quickly, and to deploy capital more efficiently.
Interna has worked with companies ranging in size from small six-member start-ups, to the Walt Disney Company, and helped Pluto on its way to a $320 million sale to Paramount and Lynda.com on the path to its $1.5 billion-sale to LinkedIn. Prior to founding Interna, David was CTO and CPO of a number of companies including Zest Finance, Break Media, and Interthinx. He currently serves on the board of directors of the LA CTO Forum.
Our special guest for tonight is Kevin Goldsmith. Kevin has been a developer, software architect, technology manager, and senior technology executive for over 28 years. He's the Chief Technology Officer at Anaconda, overseeing innovation for Anaconda's current open source and commercial offerings, and developing new solutions to bring data science practitioners together with innovators, vendors, and thought leaders in the industry. Formerly, Kevin was the Chief Technology Officer at Onfido, Chief Technology Officer at Avvo, the Vice President of Engineering, Consumer at Spotify, and Director of Engineering at Adobe Systems, and Development Lead at Microsoft.
If you have questions for tonight's guest, direct message or tweet at David, directly on Twitter @dsubar, that's @-D-S-U-B-A-R or you can follow the link on his Clubhouse profile. Additionally, in the final part of tonight's interview, you may raise your hand and ask your questions directly onstage. Questions will be answered in the order they are received. Now, for the interview.
Great. Hello, Kevin, and thank you for doing this with us, glad to have you here.
Yes, I’m delighted to be here.
Thank you, thanks. Just for everyone in the audience, I got to know Kevin through an interesting argument we had. I was giving a presentation to the Seattle CTO Club, and talking about various methodologies of how product managers and engineers might work together. I talked about the Spotify model, which, for those of you are not familiar with it, is a way that companies have been following Spotify in the way that they've developed teams and software for releases. People are copying the model almost word-for-word. I pointed out an article where someone from Spotify said the model itself doesn't work. Kevin raised his hand and said, "David--"
I’m going to paraphrase, Kevin's a much nicer person than I am. He said, "David, you don't understand, that's actually not correct." We got into a conversation, an offline conversation. I thought what Kevin had to say was very insightful and had a unique perspective for reasons that'll become immediately obvious and was right in a lot of ways that I wasn't. That's our conversation tonight. Let me just kick it off with what is an obvious question is, Kevin, why do you know so much more about this than I do?
[laughs] I worked there for three years. I joined Spotify a few months after the original white paper on how the company organized themselves was published. I was there for three years as we grew from a couple a few hundred developers up to about 800 or so by the time I left. I saw how that system that Spotify created scaled and worked. I feel very protective of it, but I also feel very strongly just because I saw it work very well.
Great. Just before we get into what the Spotify method really is, some of the stuff you and I talked about, let's talk about what people are following as a method for developing products about the squads and tribes and those components. Just walk us through what the outside implementation is just for a moment, and then we can talk about what it really is.
Absolutely. The interesting thing about the Spotify model is people condense it down to a few of the keywords, squads, tribes, guilds, chapters. These are essentially ways to organize software development teams. It is, at heart, a matrix-model organization where that means essentially that someone working in a team reports to someone who may or may not be in that team. For example, although web developers report to someone who manages the web developers, that person may be in their team or they may be in a completely different team, that is what defines a chapter.
A squad is a group that maybe works on a set of features. For example, in Spotify the search that you have in the product, that's managed by what used to be called, I don't know if the name has changed since I left, but the BFS, breadth-first search squad. They write all the search code.
That has people who are front-end developers, back-end developers, and mobile developers and they collectively own that feature. A group of those teams, those squads are grouped together in what's called a tribe. That would be, for example, when I joined, I was the tribe lead of the music player tribe. We owned a lot of the features in the product. As we grew, we created a new thing called alliances which were collections of tribes, and I became an alliance lead. That's what people think of a very simplest version of the Spotify model.
Great, thank you. This has become one of the popular models for technology companies to emulate in organizing developers, product managers, into alignment with features and users. People would copy it one for one, and then there was this other paper that came out. There were two videos, maybe papers, that came out of Spotify that described it, and then there was this other paper that came out that said-- What did it say?
Are you talking about the squad goals one?
No, I’m talking about the one that said, "Hey, this actually doesn't work. Spotify doesn't actually use it." I think I just what the paper said.
Yes, that's the failed squad goals one. I would say, if you think of agile software development, there's lots of people telling you how great agile software development is, and then there's people who have either tried agile and it didn't work for whatever reason, sometimes there's lots of reasons why you might try and it didn't work as well as you hoped. Spotify really doesn't talk about the Spotify model anymore, partially because Spotify never cared whether you used it or not.
There's been more than one blog post of companies that said either, "We tried it, it doesn't work at all, this is all a lie." Or the article you're talking about came from someone that was a contract product manager at the company for like five months, wrote a blog post saying, "This entire thing is a lie." Basically did a hit piece on it and has gotten tremendous amounts of traction. A lot of people have heard how great it is, they love hearing that it doesn't work at all. That's the, I think, article you're talking about.
It's disappointing when somebody can write something like that that is a personal attack on something where they weren't successful and just declared that it failed and gets a lot of notice for it. It happens. There's plenty of articles about lots of things that are like that.
I’m going to make the following argument is, for a lot of people, the Spotify model didn't work, doesn't work. I’m going to argue that there's two reasons. One is because they didn't actually follow the Spotify model as outlined in the document. Second is they shouldn't have started using the Spotify model in the first place. I’m going back to the conversation Kevin you and I had about misunderstanding what was the driver of the Spotify model. Maybe that hit piece was correct because people didn't understand what the Spotify model really was. He was critiquing something he shouldn't have been critiquing is what I'm arguing.
He actually did work at Spotify.
No, I get that.
I think the thing is I wrote a blog post that has been a popular saying, "You should not do the Spotify model." I wrote it while I still worked at Spotify. The main reason I wrote it was, as I said, a minute ago, Spotify never cared if you did Spotify model. Spotify wasn't a consultancy, Spotify wasn't selling you software development organizational models. We talked about it for two reasons. One, we talked about it because it worked really well, and we wanted to share knowledge. The other reason we talked about it was we were employer branding. We were trying to tell people like, "Hey, look at this cool thing we're doing."
A lot of companies post about how things work at the company because they're trying to find people who are interested in working that way. Spotify, we never talked about this because we were encouraging other companies to do it. That's an important thing. A lot of what made this Spotify model work was the Spotify culture. That's what I said in my post, because I kept talking to companies that would try and copy it. We wrote one white paper, that was like four pages long, that described it, which is not enough if you're going to go and do this in your own company. The companies tried and it didn't work because they didn't understand it, we didn't give them enough information.
Their culture was very different than Spotify's. Later, the reason we made the two videos was because we were a little tired of people telling us, "You keep saying how great this is, you're obviously lying because nothing works that well." Part of the intent with the videos was to talk about the things that didn't work as well at Spotify. We wanted to be very open and transparent about it because we knew other companies were trying it, and we were trying to give them a little bit more insight. It's interesting, in the time when I was at Spotify, I was there for a few years, companies kept trying to adopt it and kept failing, and it was cause they didn't have the right culture to support that.
In the time since I've left, more companies have actually found success with it. I think part of it is because there's a lot of people that have left Spotify, that are training or are working with companies now and more information's out. Also, I think people learned to take the ideas and not necessarily the specifics and apply that in their own company. ING, for example, is a company that took the Spotify model, changed it for their culture and applied it on a massive scale. As far as I know, last time I talked to people there, it's been working great for them.
What I thought it was really interesting when you and I talked about was the fundamental thing that I think that you're touching on now, but I think you'd mentioned some of this when we do our one-on-one. The fundamental thing that people are missing about the development of the Spotify model, about the attributes that were picked and how. Do you know what I'm referring to, and can you talk about that for a little--
Yes. One of the things that's made Spotify as successful as it has been: Daniel Ek very, very early on understood that, in the end, there was only going to be two, maybe three streaming music companies. One of them was going to be either Amazon or Apple. There was maybe room for one startup. For that reason, he and Martin, the founders, really took a blitz scaling approach. Now, if you can imagine, you know you need to grow as quickly as possible, you know that you're already in a very crowded space, you need to out-innovate everyone.
Building in a very traditional top-down hierarchical way is probably not going to work well for you, and especially if you're coming really out of a Swedish culture, which has a strong belief in equality and autonomy, that model is not great for that culture. They took a very agile first, very made sure that as we scale, we don't lose speed. The initial thing was very more traditional organized, they had some problem, they were starting to slow down.
They made a decision to make a pretty radical change, which is what developed that first version of that cross-functional matrix model, which then brought in an idea of continuously looking to improve and update and change as needed, which then helped them grow the model very, very significantly and grow and do well as grow as the company grew. That was an important innovation. One of the reasons why they started with us very early, because they wanted to make sure as they grew the teams, that they didn't have that slowing down that you get when you're just building really deep hierarchies.
Each of these teams are relatively independent or completely independent.
The true model is they're 100% autonomous. Me, as a leader of an organization, I worked incredibly hard to make sure that the teams had no hard dependencies between each other.
Got it. Now, I'm developing some code to do something, let's say it's trying to come up with a good example, I wanted to split a particular widget on the iPhone. Now, you're in a different team.