September 23, 2021
What is the best way to evaluate your developers’ experience and performance to discover what they need help with? Does it arbitrarily measure something, such as how many line codes they have written or how many promises they have made? No. How much useful data are you actually extracting from those numbers?
Instead, it’s more helpful to think about performance in terms of “developer performance”. Suddenly, it’s not about the amount of work and time spent, but the quality. Are engineers wasting a bunch of their day just trying to figure out what they need to get started, or are they able to jump straight into what they want to do?
Pia Nielsen, Director of Engineering and Head of Platform Developer Experience at Spotify, answered these and other questions. Thoughtworks Podcast: What kind of problems do Spotify engineers face? And why did we create backstage to solve those problems? Read on to find out exactly how backstage has helped us and how you can use backstage to increase the effectiveness of your own team.
As Pia explained in the podcast, when she started Spotify in 2016, we had an interesting problem. We were in the middle of an employment boom during the period of index growth. From the outside it looks like everything is swimming. But internally, a few metrics were giving us a break; In particular, our productivity was not increasing at all, even with all the new recruits.
So that’s what we always do: we’ve seen the data. We had a few metrics to determine and monitor developer performance – for example the frequency of deployment – but the most important was our onboarding metrics. You see, we estimate how long it takes a new engineer to request their tenth pool by measuring how well our onboarding process is working. And in the midst of our recruitment frenzy, that number was becoming incredibly high: more than 60 days. Obviously something had to be done, but what problems were the developers facing to get started?
Pia and his team saw the problem, and he got the response back from the engineers, in his own words:
- “First of all, it was to change the context … because we had a very fragmented ecosystem. Why did we have a fragmented ecosystem? Leads to many cognitive understandings for our engineers.
- “It’s hard to find things that were number two blockers. Which service should I integrate with as an engineer? Should I use the user data service that the customer service team has created? Or should I use a slightly different user data service to create a premium team? Or should I just go ahead and make my own? This, of course, leads to further division and we return to problem number one. ”
Considering both of these challenges, it is clear that as Spotify grows, so does our famous autonomous culture, making our work environment increasingly confusing and diverse. No one was on the same page, and it started to make us lose weight. The obvious solution, of course, would be to order our engineers to use the same technology and microservices so that we could start acting more exclusively.
But that just won’t fly on Spotify. Again, our autonomous culture, and all the freedom that comes with it, was a big reason why so many people like to start working on Spotify. It is the key to our identity. Putting our problems away was out of the question.
What else can we do? All we needed was a solution that prioritized developers and the way they worked. All we needed was a place where everyone could find everything they needed, no matter what. All we needed was backstage.
Backstage: A platform for your platform
As Pia notes, Spotify has created backstage to help our engineers do three different things: find things, manage stuff, and create stuff. In other words, it is designed to deal with all the blockers faced by our engineers, especially in the case of discovery.
Where our engineers used to spend their few hours a week just looking for things – documentation, platforms, systems and their owners – all on the internet, now they can find everything in one place: backstage. Similarly, instead of going from tab to tab, checking to see the status of their Kubernets clusters or their recent deployments, engineers now have monitoring equipment, logging, their CI / CD pipelines, and whatever else our engineers have to handle.
Now, suppose our engineers want to spin a new ML model, data pipeline, or some other component or microservices. Instead of creating something of their own, introducing another example of boilerplate code like dozens of others in our ecosystem, they can now use backstage to do that for them. Not only does this save them time if they choose to do so, but these new components and services are also set up using our own best practices and technical standards – which we call our golden path.
For this reason, we are able to take our cake and eat it. Our engineers and squads can be completely autonomous, even backstage ignoring them walking on these golden paths, which increases the alignment of our team and protects our ecosystem from further fragmentation. In addition, since Backstage is a fast growing open source tool, more features and plugins are being added for a variety of uses beyond the ones mentioned here.
So, with that being said, was backstage worth all the time and money we invested in it? Well, let’s go back to the onboarding metrics one more time. Remember when Pia discovered that onboarding engineers took more than 60 days to assemble their tenth pool request? After the backstage was turned on, that number dropped to just 20. “And if your company has numbers like that,” Pia notes, “I’ve found that the developer experience is easier to buy for investment.”
Interested to hear more about backstage and what it can do for you? To hear more from Pia to discuss backstage and developer functionality with other engineers, watch the ThoughtWorks podcast episode. And if you’re curious about how to get started with backstage, read more about it here.