Backstage’s journey from spreadsheets to global IDP standard | Spotify’s Tyson Singer

**Andrew Zigler** (0:06)
Hey there, and welcome back to Dev Interrupted. I'm your host, Andrew Zigler. Today, we're joined by Tyson Singer, Spotify's head of technology and platforms. He's the person responsible for turning engineering chaos into harmony for teams. And Tyson's fingerprints are on everything at Spotify's internal developer experience, from backstage to the open source platforms that reshape to how engineering orgs operate across the industry. And he spent nearly a decade steering Spotify's massive tech ecosystem. And now he's doing it again with Portal, a next generation internal developer platform built from hard earned lessons from this whole experience. And we're going to dig into some of those learnings today, as well as where your team could take it. And Tyson, welcome to Dev Interrupted.

**Tyson Singer** (0:54)
Thanks, Andrew. Appreciate you inviting me, and I'm excited to have this conversation.

**Andrew Zigler** (0:58)
We're really excited, too. Spotify comes up a lot in our discussions with engineering leaders. It's a widely accepted adopted leader and tool to look towards for getting teams aligned with their own internal practices, which is something that we talk about constantly on the show, as well as like making for a superior developer experience. So, you know, we're going to kind of dive into the journey of how Spotify ideated and created and scaled and delivered this kind of experience. But we're going to start by looking at a little bit at the past from where this kind of technology even comes from. Because inside Spotify, before Backstage even existed, engineers were living in effectively like whisper networks, right? You're asking around for docs and for services. Who owns what? Where's this resource? How do I get started with this? So, how every good journey starts, how did that chaos evolve into what then becomes now such a widely influential platform model for developer experience?

**Tyson Singer** (1:59)
Yeah. So, one thing to maybe call out in that question is that even today, Spotify is actually a very network-oriented company. It's really important that we stay synchronized across everything we do, and that has a very human element to it. But we are so large now, the weight of all the connections between all the people doesn't scale very well. So, if we look back to about 20, sometime in the 2010s, what was going on in the software industry was in order to enable scale, and also scale on a couple of different dimensions, one from just a compute perspective, like the number of consumers hitting your platform, and then the other from like a people perspective, we were shifting from these large monolithic software approaches, where all the dependencies were resolved to build time, to much more smaller independent scale software components, where things were resolved more at one time to maybe oversimplify it. So, at Spotify, that was really happening on steroids. Spotify has always been a very extreme context. We were growing fast, and we had a very microservices-oriented architecture, so thousands of engineers, tens of thousands of software components. And we had to make sure that the system was reliably running and scaling. We started doing that, kind of using sticks and wires, aka spreadsheets, and to kind of map out how things really work together. And that was sort of fine initially, but what we found was that as we scaled out, we had to figure out who was behind the software. And that was changing really rapidly. And so if you're dependent on a component, you need to talk to the person who you're dependent on to make changes. You have to find the relevant documentation. You have to understand things. And what we also saw is because we had a really, really autonomous culture, trying to hire the best and the brightest, everybody came in with their own background and how they wanted to develop software and wanted to do things independently. So we saw a lot of people duplicating capabilities in our ecosystem because they couldn't quite see, has somebody already built that or can I reuse it? So we cut away from this like, all right, we have a bunch of spreadsheets to, we need to be more organized about this, have a single managed repository for our entire software catalog that provided this both a build time and a runtime visibility into the dependencies, and most importantly, the people who were involved in that, so that we could really manage this rapidly changing ecosystem.
We had this idea of a squad team and squads would split and the software they owned would move from here to there, and we wanted a system that could move at the pace that we needed. So that's the starting point. I'll pause to see if you have some more thoughts about that.