Georgia:

Hello, and welcome to “Watt's up with energy?”, a gridX podcast.

‍

I'm your host, Georgia Knapp, Senior Content Manager here at gridX.

‍

Because this season, we're talking about HEMS, what it is, why it's important to the energy sector, and the energy transition, and where it's headed. I wanted to bring in two of our gridX employees who have actually been with gridX, basically since the beginning, and who have a lot of hands-on experience, what it's like to scale a HEMS, home energy management system solution, basically from the ground up, to what it is today.

‍

So I would like to introduce Baptiste Feron and Robert Fritzsche.

‍

So, Baptiste, if you want to get us started, just tell us what you do at gridX, and then we'll go from there.

‍

Baptiste:

So, I'm Baptiste Feron.

‍

I'm currently Head of Energy Management System by gridX.

‍

So we're leading all the different development teams who are working on the energy management system logic, running on our gridBox, so the Edge device, or on the cloud side of the gridX stack.

‍

Georgia:

Nice. And then, Rob, can you explain your role here at gridX?

‍

Rob:

We had this, it's a little bit tricky. So my role, official title always stays the same. I'm a software engineer. But maybe deep dive on this later. I did a lot of different things.

‍

Right now, I'm back as an individual contributor and building some, I would say, of the special initiatives right now, for instance, Ready for gridX, I'm working on. But prior to this, I was also team lead, working with people, developing people.

‍

And before this, I was an individual contributor again. And so I'm always jumping between the two extremes.

‍

Georgia:

And so now both of you have been with gridX since it was a start-up, because right now we are a scale-up. We have over 200 employees. But I believe, Rob, you said that you were the fifth or sixth person to join gridX?

‍

Rob:

Yeah, that's right. I mean, it's not really 100% sure which person I am.

‍

I remember a bit of number – I'm joined basically, because there was Dominik also joining, I think at the same time, and P starting a little bit earlier. But it should be around five, six, maybe seven-ish person, almost more than seven years ago.

‍

So it's a long time, a long time in software industry, I would say. Yeah.

‍

Georgia:

And then, Baptiste, you've also been with gridX since almost the beginning, right?

‍

Baptiste:

Yeah. I joined a bit like a bit later than Rob. I was like around 10th employee at that time, at gridX was around 10th employee.

‍

That was full-time because before I started as a consultant, so that was around like same time Rob joined. So seven years ago, I started as consultant part-time when I was still doing my PhD.

‍

And then six years ago, I joined as a full-time employee.

‍

Georgia:

Okay. Could you both speak to what that was like to like join this new energy company gridX's mission and like what initially drew you guys both to hop on the energy management train?

Rob:

Sure. Can I start? And yeah, initially, I was working for bigger corporations like on the software side of things, big data and also in automotive companies. But I was a little bit frustrated with the long decision processes. There's a lot of, let's say, people mainly focusing on their career than on the mission on itself.

‍

So I was then looking for something small, driven, really focused team. And yeah, I encountered actually Joel, one of the co-founders, in the Go Developer Forum, and we chatted there.

‍

I came to Aachen, I'm not sure when it was, 2017 or something, 2017. And yeah, I got to know the rest of the team, and then joined them.

‍

Pretty easy because they're super curious people. They had a big mission like the AWS of energy transition. They wanted to be the leading player in the market.

‍

And my main focus was they're working on the IoT side of things, on the gridBox, when it was first the gridBox version one. I think we're right now in version five or six, so some iterations after.

‍

And yeah, I mean, early on in the startup, we work very different heads.

‍

So you work on anything. You're working on customer support. You're working on sales. You're working on development. And you do everything. But main focus was IoT and gridBox and how to connect different assets.

‍

So talking to inverters, heat pumps, meters and anything related in the energy domain. And yeah, it was pretty interesting because we were working everywhere and every time.

‍

We have long days of work, even working in the train. And sometimes I had all the parts lying around from the gridBox and working there on the bootloader to bring up the software and all the wires and the blinking LEDs.

‍

And then the crew even from the train come to me and say, is this a bomb? No, I was saying, it's not a bomb. It's energy management hardware.

‍

So it's early days, a lot of work. And then I also started to touch the EMS, the energy management system.

‍

But at this time, it didn't work. So working on this iterating and also having intense discussions with Andy, one of the co-founders.

‍

And so we needed external help and reached out to Baptiste. We knew, as he said, right, Baptiste works as a freelancer.

‍

We knew him before, and he jumped on it. And then together, we were building on the EMS.

‍

Georgia:

And so, Baptiste, what about you? What drew you to an energy management software company?

‍

Baptiste:

Yeah, mostly for the mission of gridX. So the mission was bold, as Rob mentioned, becoming the AWS of energy, revolutionizing the energy industry, and as well enabling a faster adoption of renewable energy. So that was really driving me.

‍

Second point was my impact.

‍

So having a lot of responsibility, going into a field where few companies were, and innovating a lot. So that was the key to my main driver.

‍

And on top of that, I was coming from my PhD, where I studied that more from a theoretical perspective.

‍

So really doing simulation about the energy management system, here was really a way how to make it happen in reality.

‍

So all those aspects was really the key driver to join gridX at that time.

‍

And as well great people, because at the end, you get inspired by people at that time. Rob was one of them, and like all the different confounders as well.

‍

So that was as well a key aspect of it.

‍

Georgia:

Nice. And have you guys seen any evolution in gridX’s mission or approach to energy management as the years have gone by?

‍

Rob:

Yeah, definitely. I mean, as I said, we're in a scale up phase also right now.

‍

And initially, with the limited resources we had at the beginning, we relied heavily also on partners, investors and every customer, actually, when we did the testing with real hardware.

‍

So we reached out to partners, hey, can we use your test lab at the customer side? Hey, can we test some certain new features at your place?

‍

And now we have a super facility and also people working in a dedicated test lab. We have more frequent access to hardware, so we can test more often, more frequently.

‍

Yeah, so that's definitely changed.

‍

Also, our, I would say, mission got more clearer over the years because initially we pivoted in many different directions, so finding the market, finding the right fit.

‍

We were in the beginning, selling to end customers, every household, and being an energy supplier, but with a limited number of people, so 10 people, maybe 20 at some point, you cannot do all the, let's say, support, right, having customer support, having marketing, customer acquisition.

‍

So we were pretty heavily engineering focused, I would say, build a really robust, cool platform, and then decided to actually offer this as a product, rather than going to the end customer, going to the big player in the energy market, and allowing them to use our platform, building their solutions on top.

‍

And yeah, I think it pivoted slightly again during COVID, or beginning of COVID, but a lot of people also got this EV market discovered for themselves, right?

‍

And then they got also the government incentives for buying EVs. And so we also then got into whole e-mobility area as well.

‍

And yeah, now we probably can mention there are so many different regulation services and in the market, FCR, Time of Use.

‍

So we reached out to basically deliver a wide range of energy-related services. We couldn't imagine this, I would say, in 2017 working basically in the kitchen somewhere or in the train with using other customers and the test facilities from partners.

‍

Georgia:

Or, Baptiste, you want to add something?

‍

Baptiste:

Yeah, maybe, at least, I would say that the mission of gridX didn't change in the way that we weren't really still becoming the way to access all distributed energy resources and steer them in a smart way and bring them most to the customers, to the end customers.

‍

So the mission didn't change, and that as well, one interesting fact is to look at the EMS and what we built like six years, seven years ago, at least all of the pieces are still there, right?

‍

And we build on top of that, which means that at the end, the mission and the approach didn't change much from a code, or at least from an infrastructural perspective.

‍

Now, speaking from a structural perspective and more like the organizational one, we got much more professional, I think. There is much more structure. So as a new joiner, you don't have to go through ten or hundreds of pages to understand what we are doing.

‍

Now, we have a much more linear process and so on. So I would say that's for me like the key stuff that change in between, but from a mission and in an approach perspective to the energy management, that didn't change much.

‍

Georgia:

In terms of developing a HEMS solution, what were some of the biggest technical challenges that you guys saw the company facing in the early days, despite the working from the train, the kitchen, and things like that, but from like the actual HEMS software?

‍

Rob:

Yeah, I mean, probably, but just, you know, most of them, because you joined basically on this topic, working and because for me it was, I'm a software engineer, I was not so skilled in all the control concepts behind it, right? You came from academia and brought in all this knowledge.

‍

My main frustration relied or was in the area of communication between the devices or the assets. And this was always something head scratching because it didn't work, right?

‍

Sometimes the network breaks, we had a lot of long latency doing communications with even different assets.

‍

All the good, I would say, control algorithms from academia are pretty nice, but they have to deal with now real world scenarios of unreliable hardware and communication paths and also especially early days, the hardware was, I would say, well, the products in the market were also pretty, I would say, had their flaws.

‍

For instance, the EV chargers or also the first EVs, they had different weird behavior.

‍

My favorite is, for instance, the Renault Zoe, you probably know, it's one of the early EVs in the market.

‍

They monitor the noise in the network when they start charging and stop charging if there's too much noise.

‍

But if you plug them in and they start charging, they produce a lot of noise as well. And they stop charging immediately because they monitor their own noise in the network. And this means they're always starting and stopping of charging processes.

‍

And you have to adapt your hemp solution to actually smooth this out and have a good product in the end for the end customer, which doesn't start and stop charging all the time.

‍

Georgia:

You said the noise in the network?

‍

Rob:

Yeah, the home grid network, basically the electrical network in the household.

‍

Georgia:

I guess, can you explain? Because when you tell me the noise in the network, I'm thinking literal noise, like a literal buzzing or something like that. Is that what you actually mean?

‍

Baptiste:

It can be seen maybe as harmonics. So, when you initiate a new charging event, you can create harmonics, or it's like high-frequency power variations.

‍

And then some equipments are sensitive to that. Or at least, yeah. And normally, you have as well some regulation to avoid such kind of harmonics, because it can destroy some electrical devices.

‍

So, that's such kind of noise, like electrical noise, you can see, or harmonics you can see on the grid.

‍

Georgia:

Okay. And then Rob said, Baptiste, that you came in during the early development stages of the HEMS solution.

‍

So, what was that like for you?

‍

Baptiste:

Yeah. At the beginning, first of all, it was like deep diving into a new code base and understanding all the concepts behind it.

‍

Quickly, it became like, indeed, deep diving in all the different challenges.

‍

And yeah, most of those challenges that we are dealing with gridX, which is one of the key USP, but as well, one of the key challenges is like the diversity of assets we support.

‍

So, we try to support all of them, but that means that even though it's a battery, they don't react from an electrical perspective on the same way. So, they're like, maybe you send a command and they take like 10 seconds to follow.

‍

Sometimes it's one second, so which makes that it change like the dynamics of the systems and how fast you can react.

‍

And your algorithm has to be able to capture such kind of behavior in order to keep your control stable.

‍

So, it's becoming more like a control theory driven, but that's one of the key challenges, like to keep your controlling stable.

‍

And what do I mean by unstable?

‍

It's like toggling between charge at max power and stop charging potentially for an EV, which is never good as an end customer's perspective, that your car start charging, for example, and stop every two minutes. So that was one of the key challenges.

‍

So at the end, like really to capture those different behavior in a way that the EMS is able to react and to be stable in a way.

‍

Second point, which is quite challenging, it's more regulation driven in the fact that we are at least looking at all European countries.

‍

And if you look into those countries, you have like different use cases.

‍

Just one of them was at that time, like maximum power feeding for the photovoltaic panels in Germany, that was typically limited to 70% of the maximum power, which is really specific to Germany. So you have to implement such kind of logic to meet that.

‍

In all other countries in Europe, that's not the case. So that's the diversity of use case you have to deal with as soon as you want to enter new countries.

‍

It's not like you pick up your products, you just roll it out and that works. No, you have always to adapt to understand as well the regulation on that hand, which is a second challenge.

‍

And finally, as Rob mentioned, it's like those real life behavior of the assets.

‍

Like you send a comment to an EV, saying, okay, charge now, but at the end, it doesn't, or it does it two minutes later, or it starts charging, stopping, and so on.

‍

And if you rely on some strong assumption that your vehicle will follow directly your comments, then quickly you will have problems.

‍

So based on all those learnings, you only make your algorithm or your EMS more robust to all those kind of learnings we got from the field at that time.

‍

So that was basically all the key challenges we faced at that time.

‍

So it was a lot of bugging, a lot of, I would say, innovation to find a way, a smart way, how to counter those challenges and to make at the end that we had a smooth product for the end customers and even does not notice all those aspects.

‍

Georgia:

In addition to having to adapt the software every time you enter into a new market, is there anything else unique to scaling a HEMS solution compared to other types of software?

‍

Rob:

I would say there's, I mean, I always have the software engineering lens on it, on things. For me, HEMS is like an event-driven system.

‍

So events like new measurements come in, they report basically a state change in the system.

‍

And yeah, every, I mean, if the EMS reacts as quickly as possible, it can deliver the most potential.

‍

So the state changes and the new measurements are really crucial that they happen really fast, really in time.

‍

And I think this, if you compare it to other solution we had in the past, also competitors reacted in one-minute intervals.

‍

And especially when all the e-mobility phase came up, that reacting really fast was really crucial to control the load in the network. And so we re-tuned the EMS really to be that fast event driven by new measurements.

‍

And the other aspect was also that we dealt with external systems, so with hardware, with energy assets, as I said, inverters, batteries, EV chargers, which we cannot expect that they do exactly what we think they do.

‍

So we had a lot of uncertainty to deal with and also shifting strategy while interacting with the assets and while doing certain optimization target, and also multi-optimization target, but probably Baptiste can talk more about optimization.

‍

And yeah, and also the lack of standardization, and especially earlier days that you said, right, the communication miss and behavior of the different assets, we are not standardized, so we had to adapt to every new kind of setup.

‍

So we had an inverter from this manufacturer, a battery of this manufacturer, with a wallbox, with a meter of two of totally different manufacturers.

‍

And you have a huge variance in the field of setups with all different behavior, different unexpected behavior, and you had to experiment, you had to test a lot, and you had to adapt your software solution, which is hopefully only one software solution, right?

‍

But it has to adapt to so many different scenarios.

‍

This was an extreme challenging, extreme challenging by scaling up in different markets with different hardware setups.

‍

So yeah, this, I would say, software engineering perspective was the main challenge at this time.

‍

Baptiste:

Yeah, and I will follow maybe. So I think that I will rebound on the high diversity of assets.

‍

But there is one crucial point as well. You can have one dedicated battery from a specific OEM, but it can even have different firmware version on it.

‍

And that can have a massive impact on the connectivity or how fast you get the data or how fast you can control it.

‍

Which means that at the end, if you have potentially 10,000 gridBox in the field, you can have 10 different, I would say, environments for gridBox to adapt to.

‍

And you have to capture all the aspects of it to make that the solution is smooth in all of those cases. Which means that in such cases, you cannot test everything in the lab.

‍

So you test the most critical features, and you have to release those kind of new features or new software as we do on a weekly or on a monthly basis, really carefully and having like any counter actions, easily possible, at least a way to roll back the previous version if you see any weird stuff on the field. So that was the way for us to mitigate.

‍

So having a really good release process to make that we don't fear to release.

‍

And on the other side, if there is a problem, we can quickly roll back simply because we cannot test all those different configurations and constellations on the field.

‍

And on top of that, you need as well a really good observability and alerting stack to make that as a developer, as soon as you roll out, you cannot look at every system individually.

‍

You need to look at a global matrix or KPI to look at that and say, okay, I see that this KPI is too bad, so we need to roll back.

‍

But you cannot look at every system individually because as soon as you have too many, it's not any more feasible.

‍

Maybe a second point, which is not directly related to the HEMS, but to the growth of a company.

‍

At the beginning, we had like two developing teams within gridX. One was taking care of the local gateway, so the gridBox, and another one was taking care of the cloud. If you look today, we have like 10 teams, but it's still managing, I would say, the same stuff, which means that each of those teams should be able to deploy individually or independently from each others.

‍

You need to know as well the potential impact of their change on the others, so you need to have like really strong and good interface between all of those teams and so on.

‍

But we started from, I would say, the monolithic approach, where we had like one code base and we split this up. So that's a long way to move towards like a more smaller teams with smaller scope and so on that can roll this out individually from each others, and can understand still the big pictures of if I change that, that could impact maybe these.

‍

So there is always a lot of work to make those interface really clean and to make that at the end, everyone can work individually or independently from each others.

‍

Georgia:

Do you know what was the reason to go from like two big teams to a bunch of smaller teams?

‍

Baptiste:

Yeah. The reason is like, yeah, probably at least from my experience, having a teams of five to six developers is probably an optimal size.

‍

As soon as you are more, then the scope of the team is too large, so which means that when you meet, there is so much context change that the guys cannot follow or cannot intervene because it's not anymore in the scope of his understanding potentially.

‍

So that means that with the growth, you need to split this up to have a well working environment and having a scope which is fitting a team of five, six.

‍

Otherwise, all the communication struggle pops up and that becomes, from my perspective, more inefficient than efficient.

‍

That's the reason for splitting and as well can be as well like from a software perspective, that's as well some logical steps to isolate different, I would say, functionality from each other's in order to have more maintainable and stronger software in that way.

‍

Rob:

Briefly to add here is also, I mean, we needed to scale because we had also more functionality to add to the product. So the initial EMS when only we two worked on it, had also a certain scope of functionality, but it got more and more markets, right?

‍

We talked about more and more setups, more and more customers. They also had slightly different demands, and then of course you need different teams and more people to actually deliver it in time.

‍

But if all teams work on the same code base and have to talk to each other all the time, there's an overhead of communication, as Baptiste said, also an overhead of understanding what do you need to understand, right?

‍

So your cognitive load of the code base, you need to read and understand on a daily basis.

‍

It's just getting larger and larger, and that's why partitioning it and putting it in smaller focus areas just reduces the overhead here, and the team can focus.

‍

But it was definitely a challenge to figure out the scoping, what is the right size, what is the right working mode here.

‍

Georgia:

It makes me think in the US, we have the same too many cooks in the kitchen, which might also have in Germany. I don't know.

‍

How do you ensure that the software remains adaptable and scalable as new energy technologies and devices enter the market?

‍

Rob:

Yeah. I think the main, well, a good approach already initially when gridX started was that we assumed that software, whereas everything can change always, so we have to be adaptable always.

‍

So our software stack is kind of set up in a way that we can update anytime, anywhere. So it's not like we have to go in physically on-site to do an update, right? We can update remotely from any location.

‍

Also, the update mechanism is set up in a way that you do not need to know the individual customer to do an update, right?

‍

We don't have to select something.

‍

We have an approach for IoT, which is similar to updating cloud infrastructure with a lot of independent services running.

‍

It sounds nowadays not so innovative anymore, but back then, seven years ago, it was pretty new to use similar architecture on the IoT side of things than in the cloud environment.

‍

Also, the chosen language we have to Go, main, I would say, 90%, 95% or software stack is written in Go, which is, I would say, a good scalable and also simple language and software stack around.

‍

And we have there also a nice fluidity between the teams. So teams are not isolated in their tech stack they're using. They can actually exchange know-how and skill between them by just editing or changing the code base of other teams and then releasing the software there.

‍

And so an adaptable software stack also being easily deployable anytime everywhere, I think, was good decisions. Also, that we have, I would say, in the growth of the company looked really for good cross-functional teams.

‍

So we have software engineers in a team with energy management experts, with mathematicians, and also people really close to the customer still, to knowing what's needed in the field, what's the issue in there, that we quickly can understand, hey, this is your problem. Okay, the developer team directly knows the problem.

‍

So there's not a long chain of reporting and then getting the issue to the team in the road map, there's actually much closer connection.

‍

So quickly knowing the problem, reacting and updating, I think we have chosen the right software and process there.

‍

Baptiste:

Yeah, and I will follow then. I would add as well that you need as well really good abstraction layers or interfaces. So as I mentioned already, the key to scale as a team and as a software is at the end, you don't need to read the code to understand what's going on. You can read an interface, what does it need as an input and output without going deeper.

‍

So having a segmentation of all those functionalities, the key from my perspective to have a scalable software in terms of people, in terms of capabilities.

‍

And just to give you an example, we are dealing with hundreds of different devices from different OEMs. So we cannot have a specific model for each of them.

‍

So you need a good data model in that case to capture that. A battery from an EMS perspective is a battery. You don't care. It's like an SMA, a Sungrow, a KOSTAL or whatever battery. It's just a battery, right?

‍

But for that, you need to capture all the important aspect of these.

‍

So interface is the key from my perspective and on all sides. And second point is, as Rob mentioned, you cannot know what you don't know yet, right? And that was the key start of any software-driven company.

‍

You start at a point and you end up at a completely different place because you searched the product market fit.

‍

And seven years ago, EMS was really, really early stage, even though we can still speak that EMS is still early markets. So seven years ago, it was even earlier.

‍

So at that time, our software evolved really in a lot of different directions, right? And the key is really to stay flexible on the software you build and being able to iterate fast, to deploy fast, to learn fast on that end, such as you can explore, learn, and rebuild or refactor at a later stage.

‍

I think that's all the key to be successful in that end.

‍

Georgia:
Would you say that EMS right now is in like the teenager phase? Or like are we still toddlers, young adults?

‍

Baptiste:

It depends probably on the country already, because regulation is so different from countries to countries.

‍

In some countries, there is potentially no interest to control smartly your assets, because simply the price doesn't matter if you self-consume or not.

‍

So I would say it's really country dependent.

‍

In Germany, I would say like probably teenagers, you have quite a lot of incentive to install such kind of EMS. Started with self-consumption. Now we are at dynamic tariff. You have as well those 14A aspects coming in.

‍

So the value of controlling smartly your assets is really growing. Germany is one of the leader, I would say, in Europe with that regards.

‍

But in some other countries in Europe, there is really little incentive to make so. So yeah, market is really segmented on that side.

‍

Georgia:

Rob, from an engineering perspective, what's been the biggest shift in your day-to-day work as the team and the project scope grew?

‍

Rob:

Yeah, as I initially said, so my title always stays the same at gridX, but I do so many different roles over the last more than seven years. And initially, I was developing also being on the support hotline, where I was directly answering the call as the customer calls and then understanding what's the issue.

‍

Also going on site, doing the installations, so understanding, hey, what's actually going on during hardware installations, or how is the customer interacting on all levels, installation, using, getting the insights and interacting with our product.

‍

I think this was a great help initially to fully understand how everything works and also to quickly adapt to the customer's needs.

‍

I would encourage actually any engineer also to do support hotline or interacting with customers.

‍

And I mean, if the company grows, it's harder to get to touch the customer because we have specialized people as well, which is also better in talking, right?

‍

An engineer is normally not really good in explaining and talking.

‍

They're sometimes too deep into the matter and then maybe lose the customer in the conversation.

‍

And anyway, I would suggest talking to customers. That's always a good idea.

‍

But this shifted a little bit while the company grew. Also, my focus was on the newly hired people, right? Hiring new people, also working with them, growing them, also forming teams. So it was a lot of inward focus now, so actually working and scaling the company.

‍

And I would say pretty exciting because my kind of knowledge about books, I re-shifted from engineering books to now understanding people, leading and organizational structures. So it was a new area to explore.

‍

And yeah, so the prioritized hiring, I think what we really did well at gridX is hiring people fitting to the culture, having the same spirit, delivering a really high quality product to drive the energy, renewable energy transition.

‍

And they have all this fire in them, and they're all really nice and, I would say, friendly people. And yeah, and in general, there are a lot of challenges, of course, coming with this.

‍

So knowledge transfer, as I just mentioned, right, abstraction, don't understanding everything.

‍

And my day-to-day work was then basically being a lead for the people, developing the people, and also having pair programming session to transfer knowledge, writing down a lot to actually transfer the knowledge to the different teams that they can work independently.

‍

And, but since this year, I actually shifted back to being an engineer more again.

‍

So I'm doing some, as I said, some key initiatives at gridX where I do hands-on coding again. So it's kind of going for some back between people and building stuff. And it's pretty exciting.

‍

So my day-to-day work, I would say, and I really like that the gridX offers this kind of working mode.

‍

Georgia:

And then, Baptiste, you lead the EMS teams. Could you talk about how your role has evolved with, like, the company's growth from start-up to scale-up and the increasing complexity of HEMS?

‍

Baptiste:

Yeah. So I think that's, if I'm looking back after six years here full-time, I think that was really a great opportunity to explore a lot of different roles.

‍

And as Rob mentioned, potentially our title didn't change, but on the factual perspective, it changed a lot in the sense that when I joined gridX, I started as a EMS developers, really working closely with Rob on developing all those energy management system solution and architecturing at the end of the EMS at that stage.

‍

Yeah. At that time, we really build up all the foundation of what we have today on the EMS, and we get so much learnings.

‍

Then, with the team growing, at the end, you move to another role, but it's not really explicit.

‍

Then at that time, you become more a team lead, a product manager as well, and Scrum Master potentially leading the teams and organizing all the dailies and the weeklies with the team. We still have a really strong technical involvement.

‍

Then as soon as you have multiple EMS teams, then you become finally more a people manager and strategy person looking from a more global perspective, looking what's the next move, who is the good hires or what do we do next, and ensuring still a coherent EMS architecture.

‍

So I think that that was a bit my way, and now I'm as well going back more towards a more technical role.

‍

I think that's really nice because I didn't get a lot of working experience, especially in a real company.

‍

I was working at university basically, so a bit specific, right?

‍

But it was a perfect opportunity to explore, to test, and to see, okay, at the end as a person, what do I need to be happy? Where I'm the most driven, and where do I get the most of fun?

‍

Yeah, so I would say that's my way or I evolve. Now speaking about the complexity of the HEMS, I think that that's still one of the key challenges.

‍

And we already touched on a little bit, is the fact that the team are growing, complexity is growing, and the people joining have even less context understanding about the global architecture of gridX.

‍

So which means that you need really to slice these in a way that it's comprehensive for them, such as they can be, I would say, productive as fast as possible, and create impact as fast as possible. And that's the real challenge.

‍

Where do you slice your product or your logic, or your product in a way that a team can work on that, and that's meaningful in the way it is architectured? So that's probably like the challenge we had, but the challenge we still have today within gridX. At least it's a continuous challenge.

‍

Georgia:

And then the majority of people who listen to this podcast are obviously people who are either working in the energy industry or they're interested in the energy industry or it's my mother.

‍

So for people like that who maybe are looking to start their own energy startup or already in an energy startup, looking back, what are some things you wish you had known about scaling a HEMS before starting?

‍

And what tips might you give to people who are currently in a similar situation?

‍

Rob:

Yeah, I would say one tip I give everyone, actually, starting something when they want to build something new, is really describing their problem, really detailed, extremely detailed.

‍

Sounds boring, but often when you really write down what's your problem you want to tackle really in detail, you kind of have half of the solution at the end, if you're really detailed.

‍

And in general, about HEMS, it's, I mean, we talked along about the issues with hardware interaction.

‍

And so being really close to the people or the partners you have, who actually build the hardware, who bring the hardware into the market, be really close to them, have a good relationship, talk to them intensively so that you know how their hardware works, that you can really adapt your software, your HEMS solution to the hardware.

‍

Because in the end, you're shipping one solution from a customer perspective, right? It's one energy management system, one final solution they have in their household.

‍

But it's actually assembled out of many companies, and the hardware is really crucial, and that's interacting really closely with the software.

‍

So be there really close to the hardware or reduce the number of assets, you'd want to control the variance. So be focused. So have really clear problem statement and be focused on one or two setups in the field.

‍

And yeah, I think this would give you already a good start. And try to be simple, really simple solution, and don't over-invest in two perfect solutions over architect. Be practical.

‍

Work with the actual hardware. Don't do too long in the simulation, I would say. Simulations are nice. Don't look at me. So, right, simulations. But be really close to the real world is really crucial.

‍

Baptiste:

Yeah, I would be in the same direction as Rob. So basically, defining really well your interface between what do you want to offer to the external world, but as well internally within your architecture, what's the key interface between your components.

‍

Second, is like test as soon as possible. So indeed, again, Rob said not too many simulations.

‍

I think that we all have like a mental model of how it should look like, and you build your software with plenty of hypotheses.

‍

As soon as you don't test those hypotheses in the real field, you will never know what could go wrong, and that could completely destroy at the end what you have built.

‍

So go as fast as possible for testing with real hardware and learn from that and iterate based on that. And the key learnings is like at the end, real hardware never behaves as expected. That's really a statement you can take as granted, and you need to evolve.

‍

So for that, you need to be iterative, you need to test quickly, and you need to abstract well all those diversity of hardware in the field.

‍

Georgia:

What's been some of the most surprising benefits of scaling a HEMS solution?

‍

Rob:

Yeah, surprising. I mean, we also talked about it's the communication with assets, right?

‍

Don't expect that everything works as expected. So act always on unexpected things and be resilient in your implementation.

‍

This was one learning and surprises that you have to be a really resilient software dealing with a lot of unexpected things.

‍

And also that, I mean, we're building also hardware critics. So choosing the right hardware is also a benefit, how the software will scale later on it.

‍

And having a tight coupling between the software and the hardware developers is really good.

‍

I mean, initially, I said I was working on the bootloader on the train, and it was painful because the hardware was, at this day, is coming also externally, and I had to jump to some hoops to make it work there in the past.

‍

But now we're having a more closer relationship to the hardware guys, right? So I see myself always as a software developer, and then talking to them, actually communicating the needs and the capabilities of the hardware at which point.

‍

And often, it's not really important to look always at the bill of materials, how much the hardware will cost, but also looking how easy the software can be integrated onto it will definitely save your time.

‍

And yeah, so this was one, I would say, two learnings I have.

‍

So be really resilient in your software and don't look at hardware costs. Always look also how easily your software can run on the hardware.

‍

Baptiste:

Yeah, on my side, it is a great surprise to see that at the end, most of what we built six years ago is still running on the gridBox and still delivering as it should.

‍

So that's a good, that's great to see, but that means as well quite a lot.

‍

That means that basically, even though we have even more assets or even more diverse assets we control, at the beginning, we capture most of the biggest pain or most of the variation within those assets and we make that at the end, the EMS is capable of dealing with that.

‍

So which means that at the end, you don't have, if you have 10,000 potential constellation of assets, you don't have to test for all of them.

‍

But potentially testing already with 10 of them will enable you to highlight what's other key variation and what you have to consider when you are building your EMS or your software based on that.

‍

And the second point to that highlight is actually that the number of bugs doesn't scale linearly with the number of assets or gridBox we roll out.

‍

So that's a surprise, but that was somewhat expected.

‍

So and that's as well highlight these aspects.

‍

Georgia:

And then, are there any upcoming technologies or innovations that you two are looking forward to, whether that's with hems or the energy space in general?

‍

Rob:

I'm looking forward for high temperature heat pumps for industrial industry use, especially in beer breweries so that we have more renewable energy there.

‍

Georgia:

I feel like that was an extremely German answer right there.

‍

Baptiste:

You need to feed your brain, Robert.

‍

Rob:

I mean, this is a pretty limiting factor right now, right? So heat pumps in the industry to having higher temperatures.

‍

Georgia:

But you did say beer, right? You said in the beer breweries specifically, right?

‍

Rob:

I mean, this is a good example. I mean, the other industries, of course, are using also this, but I think in Germany, it's the main motivator.

‍

Georgia:

Hashtag priorities.

‍

Baptiste:

On my side, I would say, like nowadays, if you look at those flexibilities behind the meter, they target like local objective, like maximization of self-consumption or potentially as well optimizing or minimizing their bill.

‍

We need, forwards, to bring all those technologies towards the markets or the energy markets in a way that's really steered by the energy markets so that you can incorporate even more renewables on that ends, and that's done on a explicit way.

‍

So which means that basically building up a virtual power plants.

‍

We have already companies who are doing that, but with like a holistic approach on all the assets, not only the battery like Zonan does, but really any type of flexibilities, EVs, battery, heat pumps.

‍

And second point would be really seeing hands becoming like just a typical solution you find in any household.

‍

As I mentioned, it's still early markets. Yeah, we are, yeah. We have still a lot of job to do, to bring TC in every house and to make this as simple as possible for the end customer.

‍

Rob:

And there's also this wild west of different asset communication still. There's no standard way that one manufacturer can talk to another manufacturer. I hope this will convert to some point, that we have more standardized ways of communicating.

‍

Georgia:

And then I always like to wrap up the podcast with a kind of fun question. And there's this concept that a lot of people get dogs that either look like them or share their similar personality.

‍

Like, if you're super excited, you most likely have like a golden retriever or something like that.

‍

Going off of this, if you guys were to identify with any energy asset, which would it be?

‍

Rob:

Yeah, the dog question would be easier, but the energy asset question is a little bit trickier.

‍

Yeah, this reminds me a little bit of how we had a team event where team members choose a picture or an animal for their team colleague and then explain where it is.

‍

And the members choose a capybara for me because I'm usually quite calm, demeanour. And in addition, I would say also easily excitable. Otherwise, I wouldn't have joined a five-person startup in the beginning. So easily excited.

‍

But also quickly too deep into topics, I would say, deep diving on certain technical aspects too quickly. So I would say for me, it's a geothermal heat pump because, I mean, it's a cosy, relaxing environment it normally creates.

‍

And also digging deep into the surface, right? To get this warm energy out.

‍

Georgia:

Nice.

‍

Baptiste:

That is a nice one. I like the energy asset Rob choose.

‍

On my side, I would go more for a battery because, first of all, I have plenty of energy, but that's quite easy. No, more seriously, I think that battery is an extremely flexible asset compared to any other energy technologies, like an EV or heat pump, where you have mobility constraints or thermal constraints.

‍

And I would say that I'm as well quite flexible to solve a problem and help a team. But not any type of problems, an impactful one for society, as a battery did.

‍

So if you look back at this, batteries have been invented in 19th century by Volta. At the beginning, it enabled light with flashlights, which is a nice and impactful impact from my perspective of our invention.

‍

Then it enabled telecommunication with the phones. And nowadays, it's one of the key elements towards the energy transition by powering our car or our house.

‍

So battery technology is maybe a bit old, but evolved with its time. And yeah, it's still tackling key challenges for society.

‍

And I hope when I do the same, at least I have the same ambition so far. So still fighting for the impactful solution for our society.

‍

Georgia:

Nice. I love both of those.

‍

Well, thank you guys so much for joining me on the podcast and for letting us try out this new format with two guests. And yeah, thank you so much.

‍

Rob:

Thanks, Georgia.

‍

Baptiste:

Thanks for having us. Yeah, it was a pleasure to share that with you. And Rob as well.

‍

Georgia:

If you'd like to learn more about the world of renewable energy or energy management systems, be sure to check out our website, gridX.ai, where we produce regular blogs and glossaries about the subject.

‍

You can also follow us on LinkedIn, or on Twitter and Instagram @getgridX.

‍