Hacking Climate Policy
Policy and technical spaces often seem very far apart, not least in the rarified and increasingly crowded world of climate policy. Do we really need technical people present to learn and navigate the vocabulary of NDCs, GGA, GST, Paris Alignment, NAPs, L&D, and climate finance?
I have to admit that I often need to refresh my vocabulary for COP, not least because some words shift in meaning over time. Loss and Damage, for instance, is far more refined in its range, as is the GGA. This year, AGWA has its largest COP delegation to date, spanning climate mitigation, national level policy, funding, and a wide mix of technical issues.
Getting up to speed as a technical person in climate policy is not easy — there are lots of barriers, and shadowing other colleagues can help. The technical perspective may be the most necessary in the climate policy space, though.
For instance, I have been advising and observing a large water project in the US that aims to bring a climate adaptation perspective to decision making across a wide new range of stakeholders. From afar, you might imagine that the sheer scale of rivers and canals and pumps would be the issue. How do you think about coherence at the scale of a medium-sized European country? How do you adapt one of the most productive agricultural regions in North America and bring back endangered fish and habitats too?
Actually, the challenge in this case is that a highly developed and evolved software platform has managed water allocations in this system since the 1960s. The managers of the software (who are spoken of in the hushed tones of dangerous wizards) are themselves the real interface with stakeholders and management agencies, while the software itself is climate-stationary (includes no climate change options), and thus is making the communities, ecosystems, and farms in this region increasingly brittle to climate impacts.
In this case, policy actually is expressed through the software itself. Change the software, change the policy. Altering the software is not that simple, however — especially since the software is effectively a regulatory instrument. The issues are not just coding. They are institutional. And coding. And real judgment about how to open up the decision space in a way that is useful.
The latter point may be the most difficult. The software in question presents a narrow range of options and solutions for water allocation. Given the uncertainties in climate options, how do you create more options, without adding significant new barriers to decision making, so that a farmer or an indigenous group actually knows how much water they can count on?
What might have seemed like a simple issue — adding a climate resilience perspective to a water management system — is actually involving some 40 people, millions of dollars over two years, and a bewildering array of highly opinionated institutions. Yet change must come — has to come — and everyone knows it. The most impressive part of the process may just be the decision for a lot of people to connect their disparate concerns and to sit at the same table.
In my mind, this is what climate policy should look like, and what global climate policy should be supporting.
Are these the kinds of problems that should be reflected in an NDC? That are eligible for climate finance? That can learn from practitioners in other regions?
The reality is that they won’t, unless we bridge technical and policy perspectives, learn each other’s languages, and meet.
John Matthews
Corvallis, Oregon, USA