CTA: Success Factors, Measurements and Driving the Right Behaviour

Posted on February 10th, 2022

Business leaders need to set a direction. To do that effectively it is necessary to know what you're trying to measure to promote change, and drive the adoption of green software engineering practices.

CTA: Success Factors, Measurements and Driving the Right Behaviour

There's a growing understanding of the need for organisations to be green or consider sustainability. But what metrics can we use to measure success?

In the first article in the Call to Action on Green Software, I talked about spreading the message of green software within organisations. Spreading this message will be the basis for change, and help us to drive the adoption of green software engineering practices. That said, how do we know if spreading this message is creating change and moving us closer to success? What is success in this context anyway?

To answer these questions, and to ensure we're moving in the right direction, we need to define success and the measurements which demonstrate success.

Where measurements align with our personal values, or individual motivation—career success, drive, desire for a better world, or pay—then our behaviour can be influenced.

Success factors - how can we be successful?

As Peter Drucker is famously (mis-)quoted: "If you can't measure it, you can't manage it." Putting aside the fact that he never appeared to have said this, the underlying basis of the idea is sound.

In 1961, Ronald Daniel defined the idea of "success factors," as activities that must be done well for a company—or appropriating to our context, any group—to be successful. He was also very forward-thinking, noting that we should also be considering non-financial factors.

If we want to drive the adoption of green software engineering, we need to think about our success factors and how they relate to the outcomes we want to measure, either quantitatively, or qualitatively.

Frameworks for green success

There are many frameworks and models we could draw upon to identify our success factors.

  • UN Sustainable Development Goals (SDGs) - The United Nations has identified 17 goals, each with their own targets and indicators. Target 13 relates specifically to climate action.

  • Doughnut Economics - In 2017, Kate Raworth talked about the "doughnut of social and planetary boundaries" the idea that there is a ceiling of resources, and if we exceed them (e.g. air pollution) then we drive unacceptable environmental degradation; and there are twelve social foundations, which we need to have as a minimum base, for the world to be socially just.

  • Global Reporting Initiative (GRI) Standards - The GRI is an international and independent standards organisation that provides a common language for reporting on economic, environmental, and social impacts.

The problem with these frameworks is that data points being measured are often beyond the ability of individuals to make a difference. Either the level of focus is on the macro-scale, at the level of governments and nation-states (and don’t get me wrong, this is still important) - or at the enterprise level. Even GRI standards that drill down to business units, or delve deeper into corporate processes and value chains, still have an impact limited to smaller groups of individuals. But, in terms of software, if we want individuals to be able to have a meaningful impact, we need to identify what is within the software engineering span of control.

Let us bring in the Principles of Green Software Engineering. Looking at each Principle, we can see the aim is to reduce the carbon emissions of the applications we create and use.

So, our success factor here is our carbon intensity. That is a rate of carbon emissions for software, rather than an absolute measurement of emissions - allowing us to monitor the impact that small changes can have on the sustainability of our software. This means we need processes that allow for effective, and ongoing optimisation of our software. Working backwards then, our measurements need to be related to those processes.

What is the business case for green?

Why, ultimately, are we doing this? What's the business case to support green software? 

There are many ways to look at that, but we could divide them into two categories.

It's the right thing to do

The Principles of Green Software Engineering are excellent in highlighting that sustainability should be enough, all by itself, to justify our work and the change.

In my own words, I frankly don't want to die in a global heatwave, or from some other climate disaster. I'm sure there are many other equally unpleasant eventualities on the horizon!

Also, being more sustainable as an organisation can help us to attract talent, and to retain individuals that want to make a difference. It demonstrates a corporate commitment to doing the right thing; not merely greenwashing, but identifying that there is no planet B, and driving actions aligned to the desire to live within our resource means.

It's the pragmatic thing to do

Drawing on the Principles, whilst they might see this as an added advantage, carbon-efficient applications can be more resilient, and more performant.

Going further, if social responsibility isn't enough, in many cases, there is almost a direct (albeit non-proportional) correlation between carbon reduction and cost reduction. 

Here’s how that works: 

On-premise electrical spend is lowered

Carbon-efficient software running in an on-premise data centre can be more energy-efficient, which leads to lower overall electricity consumption. This in turn leads to lower electricity bills, which leads to lower electrical spending.

Cloud usage can be optimised

Carbon-efficient software in the cloud can have even greater benefits.

Firstly, your infrastructure can be right-sized and optimised, to use the minimal compute necessary to achieve your goal. This could involve resizing a virtual machine, or moving to a containerised solution.

Secondly, your software can be optimised to run only when necessary. This could involve the use of another containerised solution, or serverless computing.

In both situations, your cloud usage is reduced, which then reduces your cloud spending.

Key performance indicators (KPIs)

Having identified our success factors, key performance indicators (KPIs) are the measurements that relate to those factors. We might want to measure the absolute carbon emissions of our software, the software carbon intensity or rate of carbon emissions for our software, our cloud spends, or the electricity usage. We might want to measure individual teams, and the amount of time they spend optimising or maintaining code.

Ultimately, deciding your KPIs will be up to you and your organisation. But, you should strive to also identify measurements that will prompt discussions if they go awry, to ensure your green initiative is on the right track.

Pulling it all together

For any green initiative to be successful, I believe we need to have a clear understanding of why the organisation is greening, that is, the business case. We need to ensure your activities, and success factors are aligned to that. And finally, you need to identify KPIs that you can measure over time for improvement or stability.

What can I do?

Let us be clear here. Green Software Engineering is a rapidly evolving space. For some of these activities, there are readily available tools you can use to support your measurements right now. For some of these activities, there isn't, and we might need your help to change that. 

What could you help with at the Green Software Foundation?

Feel free to jump in and lend a hand. The Green Software Foundation is developing open-source projects to make this easier.

  • Carbon Aware SDK - Developing a software development kit (SDK) to enable applications to do more when the electricity source is clean and low carbon, rather than when it is not.

  • SCI Open Data - Creating freely reusable data sources as an input to the Software Carbon Intensity Specification.

  • SCI Open Ontology - Creating a standard way to define the software boundaries of your applications, to ensure we are all using the same terminology.

  • SCI Reporting - Creating the infrastructure and processes to store, host, and report the software carbon intensity score of your applications.

But what can I do now?

You got me. Many of these things are still a work in progress. However, now is the perfect time to start a conversation within your organisation about your sustainability goals, and software development practices. This is the right time to consider the best business case for your organisation.

The first version of the Software Carbon Intensity specification has been published, and you could identify the current rate of carbon emissions for your software. Consider what actions you might take to improve it and provide feedback on the specification itself.

We all have actions we can take. And I'll be continuing to suggest other concrete activities you could start, from establishing a centre of excellence to the instrumentation of your software. Honestly, every time I (metaphorically) pick up my pen, I consider new topics to cover.

Feel free to reach out on Twitter, Linkedin or the GSF forum, and share with me other topics you'd like me to cover, for practical actions you can take to spread the message of green software.

Other Articles in the CTA on Green Software Series

CTA: Spreading the Message on Green Software

This article is licenced under Creative Commons (CC BY 4.0)


Chris Lloyd-Jones
Chris Lloyd-JonesHead of Open Technologies