Climate work becomes an engineering discipline at Spotify
Spotify has made climate action one of its five technology pillars as part of a company-wide commitment to reach net zero emissions by 2030. The push now extends into daily engineering practice: climate responsibility is a chapter in the company's engineering handbook, and the theme of its 2022 company-wide Hack Week was "Making the Planet Cooler." The company has also partnered with Thoughtworks to ship a Cloud Carbon Footprint (CCF) plugin for Backstage, the internal developer portal platform Spotify donated to the Cloud Native Computing Foundation.
Bottom-up problem solving, supported by climate education
Spotify's approach mirrors how it tackles other technical challenges: give engineers knowledge, tools, time, and space, then let solutions emerge organically. To feed that process during Hack Week, the company hosted talks and curated online content from climate experts, including podcasters covering environmental issues and Saul Griffith, an inventor and MacArthur fellow who has advocated for widespread electrification as a decarbonization strategy.
The five-day event drew 2,441 Spotifiers working from over one hundred locations. Hundreds of ideas and prototypes came out of it, from a green tour planner for artists to a climate footprint calculator for listeners. Among the outputs that persisted beyond the event were two projects with broad reach: a climate engineering handbook and open source tooling for measuring cloud emissions.
Putting climate guidance in the engineering handbook
The Spotify Engineering Handbook is the reference for how internal R&D teams build software, covering architecture, reliability, compliance, security, cost management, and documentation. A new climate engineering section adds emissions awareness and responsibility to that set of core priorities.
The section walks engineers from fundamentals — what a metric ton of CO2e actually means — to the main sources of emissions in Spotify's streaming business. These fall into two categories:
Direct emissions from product usage, including all cloud computing resources and the devices running the Spotify app.
Indirect emissions from upstream partners such as CDNs and mobile networks.
The guidance goes into operational detail. It asks engineers to consider the emissions cost of activating a phone's radio chip, or to break down server power consumption by component: CPU, disk, cooling fan. The goal is to help engineers target efforts where they can make the most impact.
Practical recommendations are tailored by role. Backend engineers are directed toward autoscaling and rightsizing cloud resources instead of relying on alerts. Mobile developers are reminded that reducing app size by just 1 MB — multiplied across downloads and updates — can save as much as 500 tons of CO2 per year.
The framing is explicit: climate-aware engineering is not a separate discipline. Optimizing for efficiency and reducing waste often produces the better-engineered solution. The handbook's role is to make climate responsibility a stated engineering goal from the start, not an afterthought. Spotify maintains dedicated climate squads alongside dedicated security squads, but expects all engineers to weigh both concerns in their daily work.
Emissions visibility, embedded in the developer portal
The Hack Week collaboration with Thoughtworks produced the Cloud Carbon Footprint plugin for Backstage. Built for AWS, Azure, and Google Cloud, the plugin translates cloud utilization into estimated energy use and carbon emissions, presenting the data in dashboards within Backstage.
Key features include:
Emissions estimation using best-practice methodologies to convert cloud usage into environmental impact metrics.
Equivalency calculator that maps emissions estimates to relatable comparisons like one-way flights between New York and London, millions of smartphones charged, or tree seedlings grown.
Forecasts, recommendations, and carbon intensity maps in a data-rich dashboard.
The plugin extends the logic of Spotify's earlier Cost Insights plugin, which shifted resource management left — toward the engineer who knows what resources are for and how to optimize them. Backstage is the natural venue for this: developer portals are where engineering teams manage their day-to-day responsibilities, so putting emissions data there makes climate part of existing workflows rather than an extra step.
Distribution through the Backstage Plugin Marketplace gives the CCF plugin potential reach across a wide range of organizations. Backstage has been publicly adopted by more than 200 companies, and making the plugin freely available could put emissions tracking in front of tens of thousands of engineers.
Turning climate concern into engineering practice
Spotifiers can work from anywhere — but no matter how far apart we are, we all still share one address. (Image courtesy of Seat Map, another Hack Week project.)
Carbon offsets have a role to play in reducing emissions, but for many engineers they don't feel like the real answer. Offsets are a way to buy down impact after the fact; the work that feels more genuine is building solutions that are themselves sustainable at scale. The goal should be constructing a better future, not paying to compensate for a flawed one.
A problem that is both technical and personal
Experience so far points to two truths that sit side by side. The first is that sustainability is an engineering problem like any other — something that can be designed for, measured, and optimized. The second is that the climate crisis is deeply personal. Many engineers feel a genuine urgency to contribute, and treating the work as a technical challenge is how that concern becomes concrete action.
Engineers are trained to think in terms of multiplied impact. A script that saves a couple of mouse clicks matters because those clicks repeat across hundreds of millions of users and billions of interactions. The same instinct drives the pursuit of 99.9999999% uptime, shaving a millisecond off a request, or cutting a megabyte from an app download. That mindset already governs work on features, security, reliability, and resource management. Extending it to climate responsibility is a natural next step.
The bar should be set accordingly. Sustainability ought to be part of how a feature is built, a bug is fixed, an API is designed, or a system is architected — not a separate initiative bolted on afterward. It should live in the job description, not the side-project backlog, and count as a criterion for judging whether a solution is genuinely good.
Scale through many small changes
A bottom-up approach works well here because it leverages the speed of many distributed but aligned teams, and the urgency of the climate issue adds real energy to those efforts. Reducing an app's download size by 1 MB takes on different weight when you consider that megabyte repeated across hundreds of millions of downloads and the resulting effect on carbon output.
The premise is that no single silver bullet will solve climate change. Progress will come from many people across many teams making many incremental changes that add up.
That realism extends to how work gets done. Not every line of code will live up to an elegant ideal, and that is fine. Hacking has its place, particularly when it uncovers new approaches to stubborn problems. A focused week of experimentation, drawing on the creativity of a large and distributed developer community, can show that even unpolished code sometimes points to the most promising path forward.
