Spotify Squad Models feat. Kevin Goldsmith, Former VPE of Spotify

---

Transcript:

Alexander Agent:

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.

David Subar:

Great. Hello, Kevin, and thank you for doing this with us, glad to have you here.

Kevin Goldsmith:

Yes, I’m delighted to be here.

David:

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?

Kevin:

[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.

David:

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.

Kevin:

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.

David:

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?

Kevin:

Are you talking about the squad goals one?

David:

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.

Kevin:

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.

David:

Right.

Kevin:

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.

David:

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.

Kevin:

He actually did work at Spotify.

David:

No, I get that.

Kevin:

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.

David:

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--

Kevin:

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.

David:

Each of these teams are relatively independent or completely independent.

Kevin:

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.

David:

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.

Kevin:

Yes.

David:

How do we prevent your team from duplicating the code I'm doing, to be inefficient to code development and completely autonomous?

Kevin:

You don't care. It is not a model designed for efficiency in any way, shape, or form. The Spotify model is not an efficient way to build software development organizations because the requirements of autonomy mean if we're not creating strict dependencies between our two teams we may, and we may absolutely duplicate effort and that's expected. You don't go out of your way to make that happen, but you certainly would rather have it happen than have me wait on you to do something. That is by design.

David:

Got it. Right. You and I, and maybe five other teams might be developing the same thing, and that's okay.

Kevin:

That's absolutely okay. The thing we're going to look for, the thing me as a Tribe lead and an Alliance lead or the architect, what we're looking for is we don't want two different teams. We're trying to make sure that the two teams have enough distance between them that you are not building your own search for the product. If my team is a search team, no one else should be building search in the product.

That's the level we looked at it. If it means that I have this spinner widget to select something, and you build a completely different spinner widget, that's fine, that's okay. In fact, actually I would say, if you look at Spotify, 2013, 2014, up until 2015 where we actually really did a big effort to consolidate some more controls toward the same, you could tell-- We would show the organizational underwear in the product because the same control would work different in different parts of the same window because there's two different teams writing it. That was okay. We were okay with that.

David:

What forced that consolidation to say, "These two spinner widgets have the same purpose, but they're different, and we don't want to do that anymore"? What forced that, and how did that change the model?

Kevin:

Honestly, a big part of it was Rochelle King who was the head of UX, she'd come from Netflix, she's actually back at Netflix now. She joined a little bit before I did. There was a point where it was pretty obnoxious to look at the app and see, if you knew what the squads were, you could definitely tell different teams were writing the app looking at one window. There was an effort to figure out how to make design consistent without interfering with team autonomy. That was a big thing that her and her team figured out a way without forcing everyone to subscribe to a team that would build the controls for them to allow the teams to move forward, but doing it in a more consistent way.

There was, I forget which version it was, or the date around it, but it's like the 2014, 2015 timeframe where we, piece-by-piece, basically completely converted the app to a consistent set of design metaphors. For the controls that were nearly identical, we actually said, "Okay, there's no reason to have two of these now, now that these are done." We did do that process. From that point forward, if I needed control, I'm not going to ask somebody else to do it, we'll just make it, and that was expected.

David:

What about things that couldn't have been different, like security or authentication, how was that handled? Feel free to answer that question, and also say the question's not relevant because it's dependent on what your culture is. For this model, where you wanted autonomy, let's talk about that. Then I want to get meta about it and think about how do you think about the models.

Kevin:

Authentication was owned by a squad, so a single team owned authentication. That was really fine. Most parts of the app didn't really need to do a separate authentication. You only authenticate once, and then you're authenticated. Security was actually interesting because when I joined, we had security-minded people, but we didn't really have a security team. That grew while I was there, but they acted very much as consultants, as opposed to a team that owned security. Teams were expected to build secure code. They had access to a group of experts that could help them and help them do that, would occasionally go and poke around and make sure we weren't doing silly things, but that was how we did it. Again, maintaining squad autonomy was paramount.

David:

Can we just pause for one second, let's do a room reset. Actually, Alexander, I am going to let you do that, if you could.

Alexander:

Sure. The first thing, for those of you who are just now joining us, we're doing a Technology and Product Manager Fireside chat. Tonight's Fireside chat is hosted by Interna, and it's the first of a series where we ask today's leaders in Product and Technology what they've learned, how to innovate on Product, Strategy, and Technology. The interview's conducted by David Subar, and our special guest today is Kevin Goldsmith. I'll go ahead and let both of you do the more casual introduction of yourselves.

David:

You can start.

Kevin:

Okay. Hi, I'm Kevin Goldsmith. I am the Chief Technology Officer at Anaconda, today. I have been a CTO for the last five years at different companies in Seattle and in the UK. Prior to that, I was the VP of engineering at Spotify from 2013 to 2016. I was also, a Director at Adobe. I was there for nine years. I was at Microsoft for eight years, and various other startups and other companies over the years.

David:

Thank you, Kevin. I've gotten to know Kevin recently, but I will say that he's also being somewhat modest. He's a super-smart guy who knows a lot about, not just about technology, but about how technology is developed and how teams-- Very insightful thinker and also not shy. Those are the two-- No, that's great. That's not a criticism. You and I engaged because you taught me something. I'm super happy about that.

I am David Subar. I am the managing partner and founder at Interna. I've been CTO and Chief Product Officer of a number of companies as well, but been at Interna for eight years where we help Technology companies think about how to develop product more effectively, have lean-startup model type thing, how to build fast, ship fast, get product-market fit, get feedback on the product and do it again and again. I'm also on the board of directors of the LA CTO Forum. Let's go back to the part of the conversation we're having.

Alexander:

Before we jump in, David, I just want to say, if anyone has a question for tonight, feel free to direct message or tweet at David directly on Twitter. His handle is @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, anyone can raise their hand and ask your question directly on stage. Questions will be answered in the order they are received. That's all, just real quick, just wanted to throw that out there for anyone who--

David:

I think Kevin might've also had contact information that he wanted to share if people wanting to reach out to him later, too. Alexander, if you can quickly share that.

Alexander:

You can reach Kevin on Twitter @kevingoldsmith, as it's spelled K-E-V-I-N G-O-L-D-S-M-I-T-H or at his website, kevingoldsmith.com, which I believe that information is in his bio as well.

David:

Great. We were talking about authentication and different services that were, by necessity, forced to be shared by other groups-- actually, I'm going to dig into this a little bit more before we get more meta about it. I've seen this problem in a lot of companies where you have shared services, things that are horizontal, that other people have to build on top of.

Kevin, the point that you made before about don't constrain me by time, having to wait on your service that you have to build, which is why, in the Spotify model, things were as independent as possible, but was there any particular fix for things that had to be horizontal that everybody had to integrate with? Was there any particular fix at Spotify about how to make that not overly constraining?

Kevin:

Yes. We did occasionally have things like that. I actually wrote about this and we put this in the video as well because that was one of the things that I wanted. Henrik Kniberg, who was also one of the authors of the original white paper did the videos in 2015. I helped him a little bit around it. One of the things I wanted to talk about was that worked horribly. That was not great at Spotify. We were not organized to do large-scale cross-team projects. That was not the way the model was designed. It was designed to do a lot of innovation in parallel, not to do large-scale multi-team, big deliverable efforts.

We did do them, we got better at them because we were very, very good as an organization at learning. We did some very, very poorly, and spent a lot of time trying to understand why they didn't work. One of the things I did at Spotify was, I was the Engineering lead for something we called Spotify Now, which none of and once you happen to watch the press event in 2015 in the spring of 2015 because that didn't work very well. The project worked fairly well.

That involved several hundred people all working together, but at that point, we made the mistakes enough times that we found a way to keep the group moving forward without trying to control too much the deliverables of any individual team. That was about the best way we had to make it work on these big projects, but we were really not well-organized for that kind of thing.

For example, one of the things that happened while I was there, another thing, we had to move to Trustees, a different version of Linux because the version that we were using was basically end-of-lifed. That meant changing several thousand servers to the new operating system. That took us, I believe, about eight months. It took us about eight months because every squad had to decide when they wanted to do it, and no one could make them do it together because that's not what we did. That gives you that kind of sense. We were able to do these big projects, we were never good at them because that's not how we were structured.

David:

I'm going to go meta now. You had touched on a little earlier today and when we talked about what was important here is not the Spotify model, it's creating a model that represents the attributes of the company, the needs of the company. We talked about a little bit at Spotify. How would you think about that, or is there a way to think about that generically for a company of starting from first principles and what attributes we want to get to doing a model behind it. You were at Microsoft, I don't know if you were at Microsoft they still had pumps, I think we talked about this a little bit.

Kevin:

Yes.

David:

That was a model that worked when you were shipping silver disk, maybe not so well as online. Adobe, I don't know what they used, and maybe neither of examples were they even as thoughtful about what the process should be. How would you think about understanding the attributes before you define the model?

Kevin:

I think the critical thing and the thing Spotify did exceptionally well was it understood its own culture and it was very careful and thoughtful about its culture. That went everywhere from hiring to promotion to career advancement and to the way we organized the teams. When I advise startups today, I talk to them a lot about understanding the culture they have and understanding the culture they're trying to build, and starting from that first. Understand your values, your culture comes from the values, your everything else should come from your culture.

Because of that strong cultural set of values that Spotify had, they built a software development model that supported those values, that reinforced those values, but then also made sense for the business that they're trying to develop. That's an important part. When people think about the Spotify model, and even when people say things like, "The Spotify model is a lie," or, "That's not the way it worked," and they worked at Spotify, and I'm not saying the author of that one articles is that, a lot of times different squads work differently. Different tribes work differently, different alliances work differently. Each part of our organization was constantly experimenting on how to work better.

That was really the core idea of that. To me, that's actually what Spotify did exceptionally well. It wasn't the specific structures of Squads or Chapters or Guilds or Tribes or any of that stuff, it was that each of our units of organization was a little laboratory where we were just constantly trying to figure out the best way to do things, which meant that my tribe worked differently than the tribe literally on the next floor. They did things differently. They did things in their own way.

When they did things and worked really well, we would steal their ideas. When we did something good, they'd steal our ideas. That's how the model just was continually evolving. It was in a state of constant change. Anyone of those white papers or videos was really just marking a moment in time for one part of the organization. That was the critical idea of Spotify, to me, was really this real effort around constant innovation and constant experimentation about how we could do things better.

David:

I think all that's interesting. Let me dig in on the, how did you steal? That implies that there was some way of transferring knowledge among the teams, among the squads. How did that work?

Kevin:

This actually comes back to one of the things that we did at Spotify which was this notion of guilds. Spotify didn't invent organizations across team boundaries. Companies in the '50s that had social clubs or softball teams. A softball team was a guild. Spotify was very understanding of the fact that because these teams were so autonomous, they really became silos that have very little contact with each other. That's not necessarily a great thing for an organization because you want best practices to emerge.

That's where the guilds, which were essentially cross-company groups that were voluntary participation, but for example, all the mobile developers were in a guild, all the back end developers were in a guild, all the agile coaches were in a guild. What that meant was those were opportunities for good ideas to percolate across the organization. That helped break through those silos. There were more work guilds, there were more fun guilds. People were actually pretty serious about being in the guild of people that did a similar job as them, and good ideas would come that way.

Another thing is that we never thought we'd solved it all. We, as being part of the senior tech leadership of the company, we were constantly going out and visiting other companies, other companies would come and visit us-- just to see what they were doing and to see if they were doing anything interesting, or if they had a different take on something. We were very happy to share ideas and learn from other companies because we knew that we take those ideas, bring them in, and do our version of them to help us work better. That was another aspect where we were constantly looking, not just within the company, but also outside the company to see who is doing interesting things.

David:

Got it. Thank you, Kevin. Alexander, would you like to do a reset?

Alexander:

Sure. For those of you who are just now joining us or joining us in the past few minutes, we're doing a Fireside chat tonight. Tonight's Fireside chat is hosted by Interna, and is the first of a series where we ask today's leaders in product and technology what they've learned and how to innovate on Product, Strategy, and Technology. The interview is conducted by David Subar, and our special guest tonight is Kevin Goldsmith.

I'll give them both a chance to introduce themselves a little bit more fully, but before that, I want to quickly say, if you have a question for tonight's guest, feel free to direct message or tweet at David directly on Twitter @dsubar, that's @-D-S-U-B-A-R or follow the link on his Clubhouse profile. Additionally, in the final part of tonight's interview, we will be accepting raised hands to ask your questions directly on stage, and questions will be answered at that point in the order they are received.

If you're interested in contacting David, again on Twitter @dsubar, @-D-S-U-B-A-R, or on LinkedIn David Subar or on the Interna website, interna.com/contact. If you're interested in reaching out to Kevin after tonight, feel free to reach out on Twitter @kevingoldsmith K-E-V-I-N-G-O-L-D-S-M-I-T-H or at his website kevingoldsmith.com. I'll go ahead and let you both introduce yourselves. Kevin, if you want to go first, and then, David, if you want to follow up and then continue.

David:

Actually, let me try to introduce Kevin.

Alexander:

That sounds good. Perfect.

David:

I think I got it down. Kevin has been involved in technology for more than 28 years or approximately 28 years. He's been a developer, an architect, an engineering manager, a CTO, general Technology executive. He's seen a lot of different things. He's been in a number of companies, some of which are big brands that you know. We're talking today about Spotify where he was a VP. He was also at Microsoft earlier in his career and at Adobe where he was a director. He's been CTO of a number of places and a legal marketplace-- Kevin, if I screw up the pronunciation, please let me know.

Kevin:

Yes. Thank you.

David:

He's CTO now at Anaconda. He previously had been a CTO at Onfido. Kevin comes to us with a ton of experience and a ton to learn from him. We met when I gave a presentation recently at the Seattle CTO club. I was talking about organization between CTOs, CPOs and CEOs and conversations they should have. We got engaged in talking about the Spotify model. Kevin disabused me of some notions that I had about it. That's how we got to get to know each other and spend some time together. I, myself, had been CTO and Chief Product Officer of a number of companies.

I'm currently managing director at Interna, which is a consultancy where we help technology companies run the lean startup model. How do you build quickly, release quickly, get feedback, do it again and again? We've done work with everything from small startups to the Walt Disney Company, and the Disney Television Group, helped a bit on envisioning how Disney+ work; with Lynda.com, helping them scale to get them sold to LinkedIn for $1.5 billion; and a bunch of other companies too. Kevin and I come to this both very interested and engaged about how do you develop Product effectively? How do you solve problems? That's what we started talking about.

We're talking tonight about the Spotify model. What it is and what it isn't, and things to be learned from it. I invite people, if they'd like to ask questions, they can go ahead and tweet at me @dsubar or raise their hands now. If not, I'll keep asking Kevin my questions and we'll do that. Feel free if you want to ask questions directly to raise your hand. Kevin, you've seen a lot of different companies. I'm not familiar with the size of Anaconda and some of these other companies but some were clearly start-ups, some were very large-- I remember when you and I talked, you were talking about Microsoft taking up all of Redmond now, which was not a thing when I was there. There was a lot of open, green space. Clearly.

Now it's all Bill land everywhere except Bill's not there himself. What do you think the takeaways are from a company like Microsoft that pivoted when the internet came out in ways that were surprising for a large company to do that are attributes that other companies that are smaller than Microsoft, because almost everyone is, could easily take with them?

Kevin:

The things Microsoft did well that smaller companies could learn from?

David:

Microsoft or other large companies. Adobe is a large company as well. Spotify, you know?

Kevin:

Yes. The interesting thing was-- and actually, my old boss from Microsoft is in the room-- when I was at Microsoft, I have to say, I really did not like working in Microsoft. Which is a funny thing to say, given that I worked there for eight years. At the time, I thought, honestly, I thought that the company was just organized very, very silly and didn't make sense at all. What I later realized was-- No, it's hard to point at a company that was-- at the time when I was there... I was there '94 to 2000 and then I came back for two years, 2002 to 2004.

Microsoft is, by far, the most successful software company in existence at that time. It was doing a lot of things very, very well. It just was I was not a good fit for the Microsoft culture. I was just not the right person. It really took me a while to really understand, "Oh no. Microsoft was living its culture. It was just that I was the wrong person for that company." The way that company worked, especially when I was there-- When I was there, you still needed to do the Bill G reviews. It was a very top-down, very industrial model company.

Because of that, Bill decided it's time we get serious about the internet and boom, we got serious about the internet. He wrote the memo, everybody's stuff changed. Because it was a 50,000-person company, it didn't change the next day, but it changed pretty quickly. I think the things that I would learn or the things that I think made sense now, looking back at my time there, was, hey, they knew their culture, they built stuff. It comes back to the same thing I just said about Spotify.

Microsoft has actually understood who they wanted to be, how they wanted to work. I think the one thing they didn't do as well as a Spotify was they weren't articulate about it. They were very much like a lot of big companies where they would talk about collaboration and all these big fun HR words but, in the actuality, it was super competitive environment and proudly so. I think that was part of my problems. There was a lot of dissonance between what the company would say but actually how things were.

Adobe is a very different company than Microsoft. I think it had a little bit of that problem. What the company says and what the company does, but at the same time, I think people there understood-- It lived its values in its own way. It was not nearly as top-down. There was a lot more autonomy. There was a lot more support for internal innovation, but that was who that company was. The company knew who it was and it knew how it worked. If you were there and you worked in that way-- I was much more compatible with the Adobe culture than I was with the Microsoft one, so I was very successful.

It didn't take me nearly as long as it did with Microsoft to really understand, "Oh. I see how we are. I see how this makes sense for me." Again, it knew who it was. Spotify knows who it is. It's changed, by the way. Spotify today is very, very different than Spotify when I was there. I left the company five years ago. If it was the same as it is, I think several thousand-- When I left, it was about 3,000 people. Today, I think it's over 10,000. I don't know for certain.

It's a very different company because one of the things that Spotify was really good at was changing and growing and figuring out what it needed to be for the size it was, which means that I don't know if I would be happy if I went back to Spotify today, but I know that now. If I look at other companies like Netflix. Netflix is amazing because Netflix knows who it is. Netflix is very upfront. You read the culture deck, if that doesn't make you excited, you would never go work there. They're very happy for you not to.

Amazon, same way. Amazon, we are who we are. This is what we care about. I don't know if they still make people build their own desks. I don't think they do, but that kind of mentality said, "No, this is who we are. If you come here, this is who you need to want to be." I think that's a really important thing for any size of company. I think if you want to make a company that's going to grow well, having that understanding of who you are is really important.

The companies that I've seen really struggle are companies where either the founder-- the start-ups, where I advise or mentor leaders at-- the start-ups that really struggle are start-ups who think they want to be somebody they're not actually or don't know who they want to be. They create all this cognitive dissonance within the company, within their employees, investors don't understand what they're trying to give, trying to do and especially if they're selling-- You look at the problems that Uber had. There's a litany of companies that have had these struggles because who they said they were and who they were, were two different things.

David:

Got it. Thanks. I think I find that to be true as well with the companies that I advise is, "Say who you are. Don't say you're someone different," because it's exactly that same thing. I agree with that. Let's go back a little bit to Conway's law and rearchitecting software development processes and org structures. Here's the thesis of the question is that org structures are like software architectures and you rearchitect them when the problem's changed. You've seen some of these architectures, some of these org designs change. What were clues to you to think of?

If we establish that you need to have an org design that follows your company values and your company goals, and then let's argue that you're successful at doing that and there's some independence and maybe these different teams learn from each other, then you have the Bill G internet moment when everything has to switch. Sometimes it has come down, right? Bill G writes a memo, everyone salutes and says, "Yes, sir. Because you're Bill Gates." Oftentimes it doesn't happen quite so clearly as that. What are signals that you've thought about looking for to change the software development practices or do org design model within technology groups?

Kevin:

There's two different moments there. One is that, "Oh no. Something's changed. We need to figure out how to address this new opportunity, this new challenge, whatever." That is actually a little bit of an easier situation than, I think, what the normal situation is which is, over time, you build org debt, you build management debt in the same way, you build technical debt. That one's a little bit hard because you have to recognize it and then you have to do something about it.

Talking about the first case first. The, "Oh no. This just happened. We have to adjust." I would say if you're designing your organization to anticipate those kind of events, then you build an organization that is really resilient to, "Let's throw everything up in the air and reorganize around this new opportunity."

Actually, it's not a bad way to start out as a start-up as you're trying to find your product-market fit, and you need to be super nimble, and you don't have a ton of people, you got to be able to do that kind of thing. Hopefully, you don't have those, "Oh no, the internet's here," moments. When that happens, you're going to just do whatever you need to do to make that work. To your point, Bill G was Bill G. If some random at Microsoft were to say, "Oh no. The internet's coming," nothing would've happened. Nobody would've cared. You needed Bill to say it.

The other thing I actually think is a little bit more interesting, and it's only because it's so hard to recognize. Over time, just stuff isn't working quite as well as it used to and you're not really sure why not. Like, "Ah, just take it." I don't know. Stuff's moving slower or we can't get stuff out without bugs or we're just releasing the wrong things. Customers aren't happy with the things we're releasing. You look for 85 different ways because organizational structure was never the problem and now it is.

It's really hard to recognize because, generally, people tend to have a lot invested in the organizational structure, especially if you're a leader there. The last thing you want to do is have somebody mess with this thing that you've built. One of the things I thought we did really well at Spotify-- I still do-- is one of the little lessons I learned there is we would have a quarterly offsite of the senior tech leadership, all the VPs, and directors, and the CTO.

The first question we'd say is, "Is stuff working? Do we need to change it?" There was no fealty to that Spotify model whatsoever. If it stopped working, we were ready to move on. That is how, we think, we created things like alliances. We realized we've now scaled horizontally as far as we can. We spent six months trying to think of a way to scale without adding a new vertical layer before we just gave up and said, "All right. We've tried everything else. This is the obvious thing. We didn't want to do it, but we're going to do that."

Again, we were constantly looking at things and saying, "Is it working?" If it's not, we made sure we would change it. That's the thing I bring now to every organization that I'm part of is that revisiting, "Are things working. Do we need to change things? What should we be doing differently today?" Just trying to teach the leaders in my organization that they shouldn't get too precious about this stuff. They should be really thinking about the company needs as opposed to their own professional, "How many people do I manage?" things.

David:

Thank you. Thanks a lot. Let's do a reset and invite people to raise their hand. We have a few minutes left. Let Alexander do a room reset and invite people to raise their hand if they have questions. Go ahead, Alexander.

Alexander:

Hi, everyone. Tonight's fireside chat is hosted by Interna. It's the first of a series where we ask today's leaders in Product and Technology what they have learned and how to innovate on Product, Strategy, and Technology. The interview is conducted by David Subar and our special guest tonight is Kevin Goldsmith. If you have any questions for tonight's guest, direct message or tweet at David directly on Twitter. His handle is @dsubar. That's @D-S-U-B-A-R or you can follow the link on his Clubhouse profile.

Additionally, you may raise your hand and ask the question directly on stage. Questions will be answered in the order they are received, but we are welcoming hands raised, so feel free to raise your hand. To contact Kevin after tonight's Fireside chat, feel free to reach out to him on Twitter @KevinGoldsmith. That's @K-E-V-I-N-G-O-L-D-S-M-I-T-H or on his website, kevingoldsmith.com. His information should be in his bio. With David, you can contact David after tonight on Twitter @dsubar or on LinkedIn as David Subar or the Interna website, interna.com/contact.

David:

Excellent. There's a hand raised. I'm going to let this person up. Garett. Garett, you should be on stage. Go ahead.

Garett:

Appreciate it, David, Alexander, and Kevin. Kevin, I had a question for you. As an early-stage founder, I'm curious if you have any advice to scaling and growing the team vertically in any things particularly on the cultural side that you might recommend either avoiding or attacking.

Kevin:

Are you a sole founder or do you have a co-founder?

Garett:

Co-founder. I came from a general catalyst company and we just got some pre-seed money from some VCs in Silicon.

Kevin:

The first thing I would do would be you and your co-founder, if you haven't already, sit down and talk about "what do we both care a lot about?" What do we care about and what do we detest? That is, essentially, your first collection of values. When you hire, look for people who, at least, share the majority of those values and don't display the things you detest. If you detest politics, make sure that the people you're hiring don't have that kind of political bent. I mean office politics in this particular case.

That's important because if that's something that-- Especially when you're early-stage and you're really just trying to find talented people, and you're not careful about that, that early team is really going to decide what the company grows into no matter what. It's the people you hire really determine that stuff. That would be the first step. Just hire for values fit from the beginning because that's going to mean a lot. The way I normally talk about it is, if you like the office cold, don't hire somebody that needs the office to be 80 degrees Fahrenheit.

On the team scaling, the cool part about early-stage startups is when the team is small. You think of Dunbar's number. 50. I think about it as, "Can you fit all in a single room?" Whether you're virtual or whether you're co-located. You don't actually have to worry that much about structure because stuff is just going to work out. It's really when you start getting past that, that you need to start thinking about it because, in the early team, everybody's going to do whatever-- You're trying to find people that are going to play all the positions, are going to do whatever they need to do. That's a good thing because the communication bandwidth is so high in that small group.

As you get to that point where that's not really working out anymore, that's when you start thinking about, "How do we organize in a way that's going to make sense for our customer? Do we want to organize by our customer? Do we want to organize by problems to be solved? Do we have a log of running features? Do we want to organize by features? Markets? How do we want to organize?" A lot of that's going to be determined by the company and how the company is growing. I wouldn't stress out about it until you really get to the point where you have to.

Garett:

Awesome. Super valuable. I appreciate that. I'm going to sneak one more question here if you guys don't mind. Are there any--

David:

Garett, before you do that, let me just ask if anyone else wants to raise their hand because we only have a few minutes left. Raise your hand. Now, Garett: Sneak your question in but I might cut Kevin off to let someone else if they have one. Go ahead.

Garett:

Kevin, for the early employees, does it make sense to be doing one-on-ones? As a lot of the information is free-flowing and things along that nature, is there any other things that you would recommend on that front?

Kevin:

Yes, again a lot of it's going to depend on how you're structured. If you are co-located, I think the necessity of those kind of formal communication things is lessened. Again, small group, everyone knows what's going on because you're all sitting within a few feet of each other. If you're virtual, I do think that is actually more important and more valuable because those kinds of informal communications don't naturally happen.

You don't overhear the conversations, you don't see the people visiting the office, those kinds of things. If you're going on a full virtual route or if you're virtual right now because of the pandemic, I would actually put some time into making time for every one of the employees, knowing they have your ear until you either all show up in the office or until you start ending up with multiple levels of management.

David:

Actually, this will be the first time tonight I disagree with Kevin.

Kevin:

Okay. Good.

David:

Even in small groups, I think one-on-ones are valuable. The reason one-on-ones are valuable are not to trade as much information about what you're doing, but to trade information about who you are, and to know people personally. The value of breaking bread with someone and learning about if they have a spouse, if they have kids, if they have a dog, if they have a cat, to know something about them, is hugely valuable. You don't get that in a relationship unless you devote some time to a person individually. Other than that, I'm good with everything else Kevin said tonight.

Kevin:

That's totally fair. I think that happens anyway, but if you want to do it formally, I think there's no reason not to.

David:

Well, we have-- Sorry, Garett, you had a quick question, if there's another one?

Garett:

Oh. No. I was just going to say thank you. I appreciate both those replies. Very valuable.

David:

It is now the top of the hour. 7:00 PM in Pacific Time Zone. Some other time where each of you are unless you're in India, in which case, it's half an hour in. We're going to close the room. I'll let Alexander do some final comments. Thanks to every one of you for showing up tonight. I particularly thank Kevin for his insight and sharing his brilliance with us. Thank you, Kevin. Thank you, everybody. Alexander?

Kevin:

Thanks, David and Alexander.

Alexander:

Yes. Kevin, if you have any last remarks that you want to say before I go ahead and close this out?

Kevin:

Thank you. Again, I really appreciate this opportunity to talk to everyone. If you have other questions or anything else you'd like to chat about, feel free to-- Twitter's probably the best way. Just reach out to me there. Always happy to talk to folks.

Alexander:

Great. Well, thank you so much, Kevin. Thank you everyone for joining us tonight. That concludes tonight's interview. If you enjoyed this interview, be sure to follow the speakers on social media by following the links in their respective bios. You can reach David on Twitter at @dsubar. That's @D-S-U-B-A-R. On LinkedIn, his name is David Subar or on the Interna website, interna.com/contact.

You can reach Kevin on Twitter @KevinGoldsmith @K-E-V-I-N-G-O-L-D-S-M-I-T-H or on his website, kevingoldsmith.com. We'll leave the room open for one more minute for a final opportunity to connect elsewhere and continue the conversation. Thank you all for joining us. Have a good night.

David:

Thank you again, Kevin. Kevin, I'll reach out to you offline and we'll chat some more.

Kevin:

Yep, thanks.

[END OF AUDIO]