Icebreaker One is trying to work out how to rapidly evolve our financial and energy systems to embed net-zero into all investment in a manner that is demonstrable, provable and uses data to hold organisations to account. Its flagship projects include: Project Cygnus, Open Energy and SERI.
Project Cygnus is looking at how ‘economic recovery’ money can be directed to net-zero. Open Energy is looking at how we can share information across the entire energy grid to keep the lights on and drive towards net-zero. SERI is looking at how insurance can be a lever of change by ensuring that things like net-zero solutions can actually be protected (e.g. some insurers won’t insure EV) and drive change so that net-destructive industries are no longer viable.
These programmes examine the same underlying challenges through three very different lenses. One reflection is that, as we iterate through these programmes is how ‘hard’ it is to innovate in each area.
Open Energy is [relatively] straightforward from a technical perspective—there is a clear and proven architectural approach, the complex piece will be collaboration: getting buy-in from the sector. However, it’s not ‘the product’—it is enabling to the broader market as a layer to unlock secure data sharing across a national data supply-chain. It creates the potential for product innovation.
Cygnus has complexity in modelling and data, but it has clearly defined boundary conditions: to create economic analysis that will help cities and regions look at risks and opportunities for investments that can drive towards net-zero. It is also ‘enabling’ and not the ‘end product’.
SERI is right at the sharp-end. Its mission is to create climate-ready financial products. This means the creation of market-facing things that can be purchased for a specific area. It needs to provide that it meets a direct and current user (customer) need.
Product innovation is hard at the best of times. It’s harder when companies are potentially lacking ‘mandatory’ incentives, whether improving existing products, changing the underlying ‘wiring’, changing the architecture of components, or changing how all those elements interact. The incentive structures here are directly coupled with immediate user-needs, and users/customers are the least forgiving when trying out ideas: either it works for them or it doesn’t.
I find it continuously fascinating (although not surprise) that there ‘we’ [everyone] finds it so much easier to think about developing ‘enabling conditions’ than ‘direct solutions’ to the point that our research and public funding are massively skewed to ‘platforms’ and ‘portals’ which, invariably, end up with yet-another-data-lake rather than solutions that have direct relevance to the end consumer, citizen or organisation which it sets out to help.
Do we prefer ‘platform’ development because it’s easier to outsource failure?