Smashing Hour: the Four M's of green software
Smashing Magazine · Online
by Asim Hussain · 21 August 2023
I joined Smashing Magazine for an hour to talk about what sustainability actually means once you’re a designer, a product manager or a developer staring at a real codebase — not a slogan, but a set of decisions. It wandered through carbon, accessibility, who owns any of this, and why I think the real lever isn’t regulation or money. Here’s the map of the conversation.
AI-generated summary of my talk
Jump into the talk
- 1:30 What does sustainability even mean?
- 5:30 Sustainability's accessibility moment
- 8:30 The Four M's of green software
- 20:00 Carbon per user journey — the booking example
- 27:00 What drives change: culture, not regulation or money
- 32:30 Who owns sustainability?
- 39:00 What can a small agency actually do?
- 55:30 The vision: open-sourcing the chessboard
What sustainability actually means
When I started, “sustainability” mostly meant climate change and carbon. I’ve since broadened — water security and other impacts matter too — and the way we frame it at the Foundation is simple: there should be zero harmful environmental effects from using software. Crucially, that’s not a choice you push onto the person visiting your website. They shouldn’t have to opt into a “green mode”. It should already be green. The responsibility runs up the chain, to you.
When I talk specifically about carbon, the reframe that unlocks everything is this: stop chasing “zero carbon”. Everything we do emits carbon — accept it. The moment you do, you ask a better question: I’m doing X — can I do X and emit less? And then an even better one: do I need to do X at all? That second question is where design and product management walk into the room. If you’re a developer you rarely get to question the features coming your way; a designer or a PM can ask whether the whole user journey could be built to emit less by default. Once you frame it as minimising carbon per unit of user value, suddenly everyone has something to contribute.
The Four M’s of green software
Sitting at the fulcrum of a lot of conversations, I started seeing a pattern: every large, successful green-software project shared the same shape. I call it the Four M’s.
- 1
Mapping
Draw the boundary. What even counts as 'the application'? Map the whole user journey, top to bottom — every component that touches it, what's in scope and what's out.
- 2
Measuring
Put a number on each component, using models like CO2.js or Cloud Carbon Footprint. It's hard, and it needs expertise — and remember not every byte is equal: a JavaScript byte isn't an image byte isn't a video byte.
- 3
Simulation
Model the 'what if'. 'If we move this service, or optimise this code, emissions drop by Y.' This is the stage that unlocks serious investment — you can prove the return before anyone spends a penny.
- 4
Monitoring
Make it continuous and real-time. Watch emissions move with every code change — not once a year, but every deploy. This is the cutting edge, and it's where the real accountability lives.
Most projects that get real money — the multi-million-dollar kind — get there because they reached simulation: they could stand in front of leadership and say “give me X resources and I’ll deliver Y”. Monitoring is the future state most teams haven’t reached yet.
A neat example of why the boundary matters: a travel company I worked with didn’t want carbon per search, which is what we’d normally measure for a search engine. They wanted carbon per booking — carbon per user journey. If a better experience meant you found your flight in two searches instead of four, that was the win they cared about. That’s the user-journey thinking the whole framework is pointing at.
Who owns sustainability?
This is the tragedy-of-the-commons problem: if it’s everybody’s job, it’s nobody’s job. Right now a lot of the gravity is around the DevOps/SRE side — “GreenOps” — because they sit at the measurement fulcrum and can actually influence things. I’ve floated the idea of a dedicated, certified green-software role, and got pushback: the UX people and product managers in the room wanted to feel responsible too. Drawdown Labs put it well — every job is a climate job. So maybe it’s both: an involved specialist role and a thread you sprinkle through QA, design and product so the red flags get caught early.
What actually drives change
Not regulation, and not money. Regulation is a lever — mostly it makes a CEO who has fourteen seconds to think about it assign a team “just in case” — but it isn’t the engine. Money you can occasionally bend your argument to fit, but you’ll spend your life swimming upstream, getting a few strokes in.
The real engine is culture. The newest generation entering the workforce treats ethics and sustainability as a reason to stay or leave — a meaningful share of Gen Z say they’ve left a company over it. That’s what ultimately forces every organisation to make this a priority. It’s why I spend so much time teaching: we built the Green Software for Practitioners course with a target of a million people trained, and that number wasn’t plucked from the air. There are ~30 million developers in the world; there’s research (Chenoweth) that says you can shift a system by changing 3% of it. 3% of 30 million is one million. Get a million engineers thinking this way and you’ve changed the cultural consciousness of the whole industry.
And the punchline I keep coming back to: people anthropomorphise organisations — “that company is evil, that one’s good” — but organisations are just people. Change the people, you change the organisation. That’s all it ever is.
The pragmatist’s stance
I’m deeply pragmatic, sometimes to people’s frustration. Crypto? It consumes enormous energy, and yes, scaled to the size of global money it would emit more than money does today — but it’s happening, and it can also decentralise power in useful ways. Oil and gas? I work with people in that industry, and they’re human beings who do care and are trying. So my attitude is the same everywhere: you’re not going to ban crypto worldwide, you’re not going to swim against the stream — so work out how to make what’s already happening more efficient. People overestimate what they can do in a year and underestimate what they can do in a decade.
The vision: open-source the chessboard
What genuinely excites me is that the pieces have lined up to finally crack the measurement problem — in the open. The term rattling around my head is the eternal optimist: what if we could do to sustainability what open source did to software? Companies didn’t release software to the world because regulators told them to — they did it because the chessboard changed and it became the only sensible move. What if measurement went the same way? What if anyone could measure anyone’s emissions, transparently, and just publish it — measure Microsoft’s footprint and put it out there? That’s the tipping point I think we’re reaching, and it’s the argument I take much further in Doing for Sustainability what Open Source did for Software.