The Metric That Ended a Hiring Spree’s Advantage
Around five years ago, Spotify’s rapid growth started producing a counterintuitive result: adding engineers was making the company slower. The Platform team’s productivity metric — the time it took a new engineer to merge their tenth pull request — painted a stark picture. The average was over 60 days.
Director of Engineering Pia Nilsson recalls her reaction to seeing that number for the first time. After 15 years as an engineer at other companies, she says it hit her “like a cold shower.” The question became: what was making new hires so unproductive?
Diagnosing the Slowdown: It Wasn’t the Code
Spotify’s Platform team treats internal developers as customers, which meant the first step was user research, not mandates. Asking engineers directly surfaced two main culprits behind the productivity decline:
- Context switching: Engineers were constantly interrupted because documentation was scarce. New joiners had to tap someone on the shoulder to get basic answers.
- Discoverability: Engineers couldn’t find existing services. With so many near-duplicates — 15 versions of the same service, each tailored to slightly different needs — teams often built yet another version rather than sorting through the options. Spotify’s engineers gave this pattern a name: “rumour-driven development.”
This was the dark side of Spotify’s small, autonomous team model. What had once accelerated the company was now fragmenting its ecosystem and making onboarding a slow, confusing ordeal.
A Centralized Solution That Wasn’t
The obvious fix was centralization: a single platform team that standardizes and dictates. But that approach conflicts with Spotify’s engineering DNA. As Nilsson puts it, a centralized, mandated solution would never work — no one would use it because the culture prizes autonomy too highly.
Spotify’s VP of Engineering Tyson Singer echoes that sentiment: “If we go out and we tell people to do X, they just shrug, and they do wherever they want.” For any tool to succeed internally, it had to be demonstrably better, not just enforced.
The team needed a way to deliver speed and scale without sacrificing autonomy — what they came to call “aligned autonomy.” That tension led directly to the conception of Backstage, a developer portal built as a market-based solution: engineers would adopt it because it made their lives easier, not because they were told to.
Adoption by Choice, Not Command
Backstage isn’t just installed at Spotify — it’s actively embraced. Today, over 280 engineering teams use it to manage more than 2,000 backend services, 300 websites, 4,000 data pipelines, and 200 mobile features. The contribution numbers are even more telling: 200+ engineers inside Spotify have contributed features to Backstage, with over 120 plugins developed by 50+ teams. Crucially, 80% of those contributions came from outside the core Backstage team.
The portal gives any employee — engineers, compliance teams, security staff — a centralized way to discover software, identify owners, and access technical documentation. For a company as decentralized as Spotify, that accessibility is a game-changer for both productivity and developer satisfaction. Company-wide surveys show that 80% of internal users are satisfied with Backstage.
What Backstage demonstrates is that treating internal developers with the same care as external users can solve problems that top-down mandates cannot. The full story — including how much the onboarding metric improved and how Backstage became Spotify’s biggest open source project — is covered in the podcast episode “When to build vs buy — and when to open source.”
