How Backstage Made Our Developers More Effective — And How It Can Help Yours, Too

What’s the best way to assess your developers’ experience and performance to discover what they need help with? Is it by measuring something arbitrary, like how many lines of code they’ve written or how many commits they’ve made? Nope. How much useful data are you really getting out of those numbers anyway?

Instead, it’s more helpful to think of performance in terms of “developer effectiveness”. Suddenly, it’s not about the quantity of work and time spent, but the quality. Are engineers wasting a bunch of their days just trying to find what they need to get started, or are they able to jump straight into the work they really want to do with as few blockers as possible?

Pia Nilsson, Director of Engineering and Head of Platform Developer Experience at Spotify, addressed these and other questions on the Thoughtworks podcast: What types of problems do Spotify engineers face? And why did we create Backstage to address those issues? Read on to find out how exactly Backstage helped us, and how you can use Backstage to boost the effectiveness of your own team.

Growing pains

As Pia explains in the podcast, when she started at Spotify in 2016, we were facing an interesting problem. We were in the middle of a hiring boom during a period of exponential growth. From the outside, everything seemed to be moving along swimmingly. But internally, a few metrics were giving us pause; specifically, our productivity wasn’t increasing at all, even with all the new hires.

So we did what we always do: we looked at the data. We had a few metrics for determining and monitoring developer effectiveness — deployment frequency, for instance — but the most crucial was our onboarding metric. You see, we gauge how well our onboarding process is working by measuring how long it takes for a new engineer to make their tenth pull request. And in the midst of our hiring frenzy, that number was getting incredibly high: over 60 days. Clearly something had to be done, but what were the issues developers were facing to begin with?

Pia and her team looked into the issue, and this was the feedback she got back from the engineers, in her own words:

1. “First, it was the context switching … because we had a very fragmented ecosystem. Why did we have a fragmented ecosystem? … Every single team is like a little startup, and it’s free to charge ahead and reach their mission by themselves … This is very conducive for speed, but when we grow, that’s where stuff starts to break down. Of course, this leads to a lot of cognitive load for our engineers.”
   
2. “The number two blocker was that it’s just hard to find things. Which service should I be integrating with as an engineer? Should I use the user data service that the customer service team has built? Or should I use the slightly different user data service that the premium team has built? Or should I just go ahead and build my own? This, of course, leads to further fragmentation, and we’re back to problem number one.”

Considering both of these challenges, it’s clear that as Spotify grew, our famously autonomous culture was also driving our working environment to become increasingly convoluted and disparate. No one was on the same page, and it was starting to weigh us down. The obvious solution, of course, would be to mandate our engineers use the same technologies and microservices so that we started acting more as a monolith.

But that just wouldn’t fly at Spotify. Again, our autonomous culture, and all the freedom that comes with it, was a big reason a lot of people liked working at Spotify to begin with. It’s key to our identity. Mandating our problems away was out of the question.

What else could we do? What we needed was a solution that prioritized developers and their ways of working. What we needed was a place where everyone could go to find everything they needed, no matter what it was. What we needed was Backstage.

Backstage: a platform for your platforms

As Pia notes, Spotify developed Backstage to help our engineers do three different things: find stuff, manage stuff, and create stuff. In other words, it’s built to address all the blockers our engineers were facing, especially in terms of discoverability.

Where our engineers used to spend hours of their week just looking for things — documentation, platforms, systems and their owners — all over the internet, now they can find everything in one place: Backstage. Similarly, rather than moving from tab to tab, checking to see the health of, say, their Kubernetes clusters or the status of their recent deployment, engineers can now use Backstage to bring together monitoring tools, logging, their CI/CD pipeline, and whatever else our engineers needed to manage.

Now, let’s say our engineers want to spin up a new ML model, data pipeline, or some other component or microservice. Rather than building something on their own, introducing yet another instance of boilerplate code similar to a dozen others in our ecosystem, they can now use Backstage to do that work for them. Not only does this save them time if they choose to do this, but these new components and services are also set up using our own best practices and tech standards — what we call our Golden Paths.

Because of this, we’re able to have our cake and eat it too. Our engineers and squads can remain entirely autonomous, even as Backstage nudges them toward walking down these Golden Paths, thereby increasing our teams’ alignment and keeping our ecosystem from becoming more fragmented. Additionally, because Backstage is a rapidly growing open source tool, more and more features and plugins are constantly being added for a variety of use cases beyond the ones mentioned here.

So, with all that being said, was Backstage worth all the time and money we invested into it? Well, let’s go back to the onboarding metrics one more time. Remember when Pia discovered that it took over 60 days for onboarding engineers to merge their tenth pull request? After Backstage was introduced, that number dropped to only 20. “And if you have numbers like that in your organization,” mentions Pia, “I find that it’s easy to get buy-in for investments in developer experience.” 

Interested in hearing more about Backstage and what it can do for you? To hear more from Pia discussing Backstage and developer effectiveness with other engineers, check out the Thoughtworks podcast episode. And if you’re curious about how to get started with Backstage, read more about that here.

Tags: backend, engineering leadership