“We would also classify ourselves as a disruptive technology company”
James Eddison is Octopus Energy CTO. He co-founded the business in 2015 with Greg Jackson, the company’s CEO.
Octopus has developed a novel cloud-based customer service platform, Kraken, which it uses to meet the needs of its 1,500,000 customers, and licenses to other energy suppliers.
An engineer by background, James tells us how cloud technology has been central to the growth of Octopus and why he believes in putting the power of the firm’s novel technology back into the hands of its customers through APIs.
Hi James. Give us the low-down on Octopus Energy and what you do…
On the face of it we’re a new entrant energy supplier, with two key drivers; providing good customer service to a sector which has been not particularly successful in doing that, and a desire to make a green dent in the universe.
We would also classify ourselves as a disruptive technology company.
Greg and I come from a background of using technology to solve other people’s problems, and now we’re doing that in the energy sector, or the “Entech” space if you want to put an acronym on it.
We started out aiming to build the experience of customers and the experience of our support staff around technology. Because we’ve designed Kraken with those objectives in mind it gives us a much lower cost to serve and much higher customer satisfaction levels than taking an SAP or Oracle-type system which has its strengths but isn’t designed for that purpose.
Ok… So are you an energy supplier or a technology company first?
That’s a bit like asking which of your children you like better. We’re a family with both, and if we weren’t an energy supplier we wouldn’t have the practical hands-on experience to know what’s really important, and if we weren’t developing our own technology we wouldn’t be able to do the energy supplying part as successfully.
We’ve spent 20 years building large systems, so we’ve got and I don’t think it’s immodest to say we’ve got a few ideas of how it should be done. There’s a McKinsey report we like to quote on why most IT transformation projects fail, and it says it’s because the IT department is still acting as order takers rather than decision makers.
In our company the IT department are the decision makers: I’m a director, Greg is the CEO and is very technically astute – he was writing video games when he was a kid. And the wider board and management team have been incredibly supportive about the opportunity and the challenges of building your own platform, so we’ve been able to deliver it progressively.
Tell us why the cloud has always been central to your business. Are there any particular tools which have been useful?
Using the cloud has enabled us to develop our platform in a highly agile and innovative way. You hear about CICD – continuous integration, continuous deployment – a lot, but this is something we’ve done since day one; every change in the code base can be tracked back and replayed
We used Terraform and deployed to the cloud since day one, so every change in our infrastructure is also tracked in code and auditable back to Day One; who did what, when and how. And when we deploy, we’re rebuilding infrastructure because it’s all part of the same deployment pipeline. We’re currently doing that between 40 and 50 times per day.
We use load balances and also scaling groups so that the availability of resources flexes to to meet what we need. The average life of a server is probably it’s going to be measured in minutes, it’s pretty transitory in real terms.
How does this differentiate you from your competitors?
We were once asked how long it takes us to do a run of 10,000 bills on our platform compared to the industry’s traditional approach. Normally energy providers are constrained by their hardware, or by their software even if they chose to run that in the cloud, and you get these long processes [to produce bills].
If we’re doing a run of 10,000 bills, it becomes 10,000 tasks, and the question then is how quickly do we need to do it? We could spin up 10,000 servers to process one each, or we could have ten servers each doing 1,000. We want the run to be done in an hour so we assign the appropriate number of servers.
Now a big bill run can comprise 100,000 bills, but it still just takes an hour because that’s the time we want it to take. We’re able to use the same code and infrastructure and perform the task at a different scale.
You recently became an AWS partner – why did you plump for this platform over others?
We’ve always used AWS and I think the latest evolution is that we’ve got off the fence a little bit. Theoretically we could take our application and port it to Google Cloud or Azure, but when you’ve got a large amount of data installed and you start to use the value-adding tools around things like security that AWS offers, there’s a significant upside in investing as a partner rather than just dipping your toe in the water. We also know they’ve got global data centres and can help us extend our reach internationally.
You have made a lot of APIs available – how do these help your business?
There was never a discussion around whether we would offer APIs to help customers access their data. At the time we thought people might want to do things like writing a Windows Mobile app; we didn’t make an app ourselves because it wasn’t a market we saw much future in, but we figured if you give people the data they could do it themselves.
Fast forward six years and APIs are helping us with our goals of providing transparent pricing and sustainable energy. When we launched Agile [a product which tracks energy supply every half an hour to allow customers to lower their bills by syncing their times of high consumption to times of high network capacity] we made an API available immediately, and within a couple of weeks of the product hitting the market we held a hack day where about 30 companies turned up with ideas, several of which are now in the market.
The APIs provide an eco-system where other companies can help solve the challenge of making our data easy to access for customers. We have the geeks who will write code on a Raspberry Pi and do amazing projects, but we also have guys building apps for phones and watches so that information is available to customers all the time.
This is an industry which is [otherwise] still using technologies and processes which were devised in the 1980s at the time of the market deregulation. The current pace of change means even a relatively small alteration gets built up into a long multi-million pound project, but we need to be making a material impact on climate change this decade. So technology needs to enable change, and APIs will be an interface that will be a big part of that.