Erik: Johan, thanks for joining us on the podcast today. 

Johan: Thanks, Erik. 

Erik: Yeah, great. So, we're going to get to do a bit of a deep dive here on LoRa and LoRaWAN, and the network, and then, of course, the tech stack that's built around the network today. So, I'm looking forward to hearing your thoughts. You really have quite a bit of expertise from different sides. If I'm looking at your profile, you can maybe fill in some details here. It looks like you, on the one hand, do software development for customers. Then you also have your own product company, which is The Things Industries. Then if I'm correct, you're also tech lead of a network, which I'm assuming is more of maybe like a nonprofit or a network that's trying to develop an ecosystem around this. Can you help me put the different pieces together of the activities that you're involved in? 

Johan: Yeah, so my main activities are I'm the CTO and co-founder of the The Things Industries. We'll get to that later in this podcast, I guess. But it started before that with The Things Network. That's our developer community that's focused on LoRaWAN. LoRaWAN is a wireless communication technology for constrained devices. The Things Network, we started with that around eight years ago in spring of 2015 — me and Wienke Giezeman, my now business partner. It started off really as a hobby project, as a side project. Because at the time, I was doing contracting work. So, software engineering for customers that wanted to have a specialty software that didn't exist in the market. That's how it got started. It really started as a hobby. Then it got so much traction that we decided half a year later to start a business around it. That is The Things Industries. I'm still doing both, but my day-to-day activities are being CTO in The Things Industries. 

Erik: Whenever I'm talking to a co-founder, it's always interesting to understand the question why. Of all the different problems that you could devote your life to solving, why is this the one that you focused on? 

Johan: Maybe it's good to look back at what I did before founding The Things Network. When I was in university, I was already doing software development work for some companies that wanted to have some custom software. One of my clients was the Dutch Speed Skating Association. As you know, in Netherlands, speed skating is the number one sports. It's so big. It's leading in terms of results, sports results, but also anything related to speed skating — ice making, the suits that they wear. A lot of technology development all happens in Netherlands. Naturally, also, the software and all the software for managing competitions, and timekeeping, and also training is all being developed in the Netherlands. There's nothing you can really buy off the shelf as the speed skating Federation. 

I, sort of through friends, got into the business of developing a software specifically for speed skating. Then I focused on competition management, timekeeping, rankings, results, all that stuff. It was a great project. I got a lot of freedom. I was in my early 20s at the time. So, it was a great time to do that next to my studies. But I also realized that there was basically only one client in the world that would be interested in that kind of software. It was the Dutch Speed Skating Federation. Maybe other speed skating countries would be interested like Norway or, Italy, or Canada. But I figured already quite soon that they have their own stuff. They didn't have the money really to get a license of my huge advanced system that was built for the Dutch's speed skating association. 

I realized, after a few years doing that, that I wanted to do something scalable. I wanted to build a product that many people can use in many different industries and many different geographies. So, I decided to be open to that. I wasn't really planning on going in Internet of Things. It didn't really matter as much, as long as it was business-wise, interesting but also fascinating technology. But first and foremost, scalable. 

I was working in a co-working space in Amsterdam at the time. There I met Wienke. We knew each other from Amsterdam intrapreneurial scene, which was quite small at the time. And so, we were meeting up for coffee just to chat. Then he said, "Yeah, I was at an IoT meetup in Amsterdam. There was a presentation about LoRa. This is a really cool technology for setting up IoT networks." He said, "Yeah, we can set it up ourselves." Because everyone can set up such a LoRa network. So, we got into that and dived into that. That was in 2015. We started this, The Things Network. It started really as we were both aligned on going into a scalable new field and really as a side project, because I have my clients still who I was working for, and he had that as well. So, that is how it got started initially. 

Erik: Okay. Interesting. I guess this is a good technology to look at if you're really focused on finding an opportunity to scale here. Remind me. Where were we in 2015 in terms of LoRa? What was the development level at that point? 

Johan: For us, I think the time was right because it just got started. I think LoRa already had a history of a few years. I think Semtech — which is an American company — acquired Sicario, which is a French startup who invented LoRa. That was, I think, one or two years before we started. Semtech was actively investing on creating an ecosystem around LoRa. LoRa is just a modulation. It's getting data through the air from one point to another using very little power. But there was no standard around the message formats or any stack, any protocol to communicate. 

So, the LoRa Alliance was formed, which is a standards body to develop LoRaWAN, which is the protocol that uses LoRa. That was at the time, I think, when we started that, the LoRa Alliance released the 1.0 specification of LoRaWAN. But it was very, very, very early at the time. We had to explain everyone what LoRa and LoRaWAN was about and what you could do with it. 

Erik: Great. Okay. Interesting. So, you kind of made a bet on a technology. It seems like you've been on the right one. Sigfox was more or less a direct competitor. Is that right? 

Johan: Yes, absolutely. Yeah. 

Erik: Was it a couple years ago that they went out of business? 

Johan: Yeah. Well, I think, only last year that they sold everything. Now it's actually quite interesting that the new Sigfox owner are one of our customers now. So, they are switching, or at least they are making their networks ready for LoRaWAN. A lot has happened in the meantime. But indeed, at the time, 2015, 2016, Sigfox was very big, investing heavily in what they call 'Zero-G'. It's just being able to send just a few dozen bytes from an endpoint to the cloud or maybe a few times per day. They were doing good business. 

Another competitor which didn't really exist at the time was Narrowband IoT and LTE-M. Everyone was talking about 5g that it was coming, all the big promises. I think a lot of companies in the market at the time were quite hesitant adopting LoRa and LoRaWAN. Because they were like, "Oh, yeah, 5g is coming in next year or two years from now." That also changed. Indeed, we had to bet on the right technology because it was available. The big advantage still today with LoRa and LoRaWAN is that everyone can set up their own LoRaWAN network without being reliant on a single entity like Sigfox, for instance. 

Erik: Got you. Okay. So, that's one big, let's say, differentiator of LoRaWAN. What else do you think is behind the success? Because this is a market — I mean, it's not exactly a monopolistic market. There are certainly many competing protocols. But it's at least semi-monopolistic. You can only have so many protocols that are addressing the same kind of bandwidth and problem there. There's a handful that can probably co-exist. What do you think it is aside from — is it this? Is it really just primarily the convenience or the independence of the ability to set up your own network? Any other factors that contributed to its success? 

Johan: I think it's a combination of different things. Indeed, it's the ability to own your network and to be able to set up a private network with exactly the same technology as a public network, which is quite unique in this field. Cellular networks, obviously, narrowband-IoT, LTE-M, you really rely on the network operator. A private 5g may change that. But that's going to be very expensive and for really big enterprise networks. For smaller SME, it's just as simple as setting up a Wi-Fi network. You can set up a LoRaWAN network. That's definitely one contributing factor. 

I think another one is that in the design of LoRaWAN, it was never designed for a particular industry or a particular geography even. From the very beginning, the people who wrote the LoRaWAN specification were aware that LoRaWAN can be used anywhere in the world. In the first release of LoRaWAN, there were regional parameters for Europe, United States, Australia, and China. Now there are, I think, almost 10 other regions which covers 80% of the world, I would say. But also, not only technology-wise but also not in the collaborations between alliances or in marketing things. It's not focused on metering, or logistics, or smart buildings, or things like that. Whereas in other wireless technologies, you often see focus on those industries. The versatility of LoRaWAN, that's really in the design of the protocol but also in how the LoRa Alliance works and operates and how specification is drafted. Yeah, I think that's also quite unique that you can use the same technology for tracking cows in New Zealand as monitoring meeting rooms in a building in New York. 

Erik: Well, let's get a bit into then what The Things Industries is doing within this space. This is a market where, basically, any company can set their own network up. But obviously, you're a company that is providing a tech stack around this and the service stack around this. What's your value proposition to supporting companies that are using LoRa? 

Johan: We are horizontal, so we focus on providing a cloud service that allows our customers to set up their own LoRaWAN network. That's really the core of what we do. Our customers set up their own LoRaWAN networks. They buy their gateways. They connect that to our cloud, where they have their own virtual environment, their private network, where they can manage the gateways. They can onboard devices, and they can configure how they want to receive, how they want to get access to the data that their devices send. 

Just like LoRaWAN, we are not focusing on particular industries. Also, we are not building an IoT platform. So, we are one layer below an IoT platform in a typical architecture. So, we really focus on the network layer. Any application layers or time-series databases, visualization, things like that, we are not doing that. Because we believe that's a different business, and it's often something that our customers want to have a lot of freedom in, or they want to develop themselves. So, we are a very thin horizontal. But it's a really essential element in a typical LoRaWAN network architecture — that you need to have this network server that terminates the LoRaWAN sessions. Security onboarding, network management, optimizing data rate, and optimizing battery life and things like that — that is what we do. 

Erik: Got you. Okay. Who would be the the customers here? Because you're horizontal, I guess it could be anyone. But then, companies always — they do have to make choices about who they want to serve in terms of the scale of the customers, the verticals, the problems to solve. How would you define your primary customer base? 

Johan: That is also indeed quite broad. We have customers that are building their own products and services on top of our stack. So, they build their own devices, and they have their own solutions that they sell in a box. For instance, building monitoring. So, devices that can monitor meeting rooms, and desk occupancy, and toilets, things like that, they sell that to real estate companies. So, that's one. We also have smart metering companies as customers that also have their own physical infrastructure. They already shipped meters to their customers. What they add is a LoRa transceiver so that they can get the data from the meter directly in their cloud. Those are customers that build their own solutions and products. 

Another one. A great example is WeWork, the co-working space company that's also active around the world. They have a building operating system where they can manage their buildings worldwide. They have one system that they use everywhere. They also have a LoRaWAN support in that. But we also have customers like system integrators. They focus on integrating solutions for their customers. Then the system integrator is specialized in LoRaWAN. And their customers, if they need an IoT solution, then this is just one of the things that they have in their toolbox. Those are the customers that they know typically what they're doing. They know a lot about LoRaWAN. We don't necessarily have to educate them to become successful, because they have been successful with multiple LoRaWAN projects in the past. So, it's quite broad, I would say. 

Erik: Maybe we can focus on WeWork, or if there's another customer. I think it's always useful to focus on one specific case and do a little bit of an end-to-end of what was your role in supporting them, whether it's in the tech stack, in advisory, in operations. If you think WeWork is a good case, we can use that. If there's another one, you prefer. But can you give us a bit of a walk through, an end-to-end of how you were supporting one of these customers? 

Johan: Yeah, let's take Deutsche Bahn as an example. That's German railway company. It's always a great example because they have been working with LoRaWAN since the very early beginning. They had some really visionary, innovative people in their own system integrator company at the time. They are really big. In Europe, they are by far the biggest railway company with a huge infrastructure, owning not only the rail but also the trains. They manage the stations. So, it's like a massive European infrastructure company that's not only active in Germany. But also, they have their high-speed trains that go through Europe. They use LoRa and LoRaWAN for many different things, not only their buildings. They are already a big real estate company apart from the rails and the trains. 

How it works is that Deutsche Bahn is a company that's typically not willing to use a cloud service provided by 25 people, a startup from Amsterdam. I mean, their operations are too critical. We would also not easily go through a whole certification process to be able to manage a cloud service for them. The way we work with them is that they license our products, The Things Stack enterprise, which is our flagship product. They operate it in their own cloud. We don't have access to that cloud. We visit them to train them on how to install and update their environment. They have operation specialists that manage that product in their own cloud. 

We provide them with the software, with licenses, with training. They build their own network themselves. Wherever we can help them become more successful, we help them. But we typically do that through making introductions within the LoRaWAN ecosystem. Because we are not really in the business of writing custom software. Like I was with the speed skating Federation, I still learn from that, that I don't want to go back into custom contract work for customers. But there's a great LoRaWAN ecosystem around us that we can make introductions to make them successful. That might be in building applications for coverage mapping, or finding the best gateways, or figuring out which dashboards they should use, or other IoT platforms and things like that. 

Erik: Got you. Great. Very clear. Thanks. Let's then look at your tech stack. On the website, the way that you map it out is — or maybe this is not the tech stack. Maybe this would be more looking at the function set or the process of adding end devices, bulk import of end devices, registering gateways, inspecting live data, network operations. Then separately, you have a set of features that you're providing around this. So, how would we break down the capabilities and then the processes around the platform? 

Erik: That's a great one. Like I said, we focus really on the network layer. But in LoRaWAN, that means also that you would need to be able to add and manage devices. If you look at onboarding devices, then it's almost a rabbit hole of things you have to deal with. Setting up a small LoRaWAN network is quite easy. You can set up a gateway. We have documentation to do that. There are many, many different gateways that work with The Things Stack. But onboarding devices is the same thing. You can buy devices off the shelf, and you can add them to your LoRaWAN network. But doing things at scale requires additional features, like the ability to import thousands of devices at the same time, and make sure that all those settings are correct. Because with a protocol like LoRaWAN, you don't really have a channel with those end devices to negotiate capabilities, or the device cannot advertise the version that it's using or the payload format that it supports. So, you have to have a lot of out-of-band knowledge about a LoRaWAN end device before it can join your network. And so, for that, we introduced a device repository, which is an open-source repository on GitHub, where device makers can contribute their device profiles and their codex. So, it's really a collaborative effort with device makers. It helps our customers to make sure that all the settings of their devices are correct, because we can load those LoRaWAN profiles and codecs. That's just one aspect. That's just device onboarding. 

But indeed, if you have your devices then in the fields, and you have hundreds of gateways covering your devices, you also want to be able to see how your network is doing. You want to see if your gateways are working in the first place. But also, what are the noise levels? Are there frequencies that are problematic? Because there are other users of those frequencies around you. Maybe you need to do some optimizations. Maybe you need to add another gateway somewhere to add capacity to the network. So, that level of insight is also one of the areas where we invest heavily in to provide that insight to our customers. That's really on the network level. Just the ability to see how the devices are doing — if they're healthy, if the link is correct. Just like in traditional Internet, you can have packet loss. It's similar in LoRaWAN. We also measure that in the network to see, is there a high packet loss with these devices? Should we do something about it? 

Then on the application side, extracting the data from our network, that's also one of the areas where we invest heavily in. Because this is most important for our customers. They want to have a reliable data stream of telemetry that their devices are sending. They want backups. They want us to support different formats. Maybe they want to have a simple MTT connection with The Things Stack, or they want to use web hooks or another IoT platform integration. That's all part of the solution that we call The Things Stack. 

Erik: Let's see. So, you have this tech stack. You also have a number of different deployment options. I guess the deployment options are going to be — I mean, these are fairly standard, right? So, it's cloud. It looks like you have particular integrations with AWS launcher or with AWS that you've built. There's enterprise. There's a dedicated private cloud. To some extent, those are the standard options. But I'm still interested in how you, as the CTO, view the tradeoffs between these different options. I guess those can be viewed from a cost perspective, maybe a simplicity feature set, et cetera. But if you were advising a customer, what questions, what criteria would you want to evaluate to determine which of these deployment options would be a better fit for them? 

Johan: Indeed. We have different deployment models of The Things Stack. That is also one of the design choices that we made when we designed The Things Stack back in 2018, I would say. That's the foundation of the product as it is today. One of the requirements was that we wanted the same product to run embedded even on site, on premises. For industrial customers that are running factories, for instance, and they don't want to run operations through a cloud service, because it's so critical what they do, or it's hard for them to have a reliable internet connection somewhere remote, in a remote factory or on a platform on sea, for instance. That was one requirement. 

But also, we have customers that, like Deutsche Bahn, are using their own clouds. They already have everything set up — their own processes, security, compliancy, all kinds of requirements. They want to be able to run The Things Stack in their own domain. Then, of course, we have our managed service, our SaaS service, The Things Stack cloud, which is what we prefer that our customers use. Because it's already deployed by us, it's really easy to onboard the customers. But sometimes there are reasons to go on-premises. Again, because you cannot always rely on an internet connection. Or you have to go with our enterprise deployment for private cloud because of compliancy, or other certification, or a reason like that. But typically, I would say 95 of our customer base is using The Things Stack cloud. 

Erik: Okay. So, that solution works. 

Johan: Yeah, one of the trends that we see here is that we thought, I thought also, 10 years ago that everything, all the workloads were moving to the cloud. And it was just a matter of getting better internet connection. If the internet connection were fast and reliable, then there would be no reason for shops and factories and things like that to knock you as a cloud service. But we also realized — I changed my opinion about this as well — that there are really good reasons to have also a LoRaWAN network server on site for critical workloads, and also for edge intelligence, having business logic close to the devices and the applications that are also running on the edge. 

I think this is also a broader trend that we also see in cloud services in general. If you also look at what Amazon Web Services and Microsoft Azure is providing, they also realize now that edge is a deployment model that has to be working closely together with their cloud services. It will not only be everything in the cloud. One of the things that we are exploring is an embedded distribution of The Things Stack, which runs somewhere on site. It can run completely offline. But if there is an internet connection, it would synchronize with The Things Stack cloud, where everything is ultimately managed, and hold security keys are and things like that. Then customers can still run The Things Stack embedded in their shop, in their factory, on site. Those are also the hybrid deployment model that we are exploring, because this is one of the trends that we see in the cloud space. 

Erik: Yeah, I know. It's interesting. I mean, there's certainly a lot of movement towards edge computing. Cybersecurity threats are not going anywhere. Even if internet connectivity improves to a point, there will still be a set of devices that people want to manage from the edge. 

Let's look a little bit at pricing as well. I really like the transparency that you have here on your website. And so, it's interesting to understand the logic behind a particular business model or pricing model. Here, you have it broken down into a few different decision stages, what's your entry level. Here, you basically have a, I'd say, standard option, and then maybe an entry level option for people that are more in exploratory stage. Then you allow choosing the different deployment options, the number of device bundles, or the number of devices in your bundle, support plans, terms. This is all very transparent on your website. Anybody that wants to look through can do that. But I'm interested as an entrepreneur, as a business owner, what was the thought process that you walked through to determine that this is the best pricing model for your business? 

Johan: This was actually really hard. It was actually so hard that a few years back, we decided just to come up with pricing and just put something out there and see if it sticks. So, it was really a trial and error. Because LoRaWAN is so versatile, it can be deployed in so many different industries, so many different regions. It's really hard to have one pricing plan for all markets everywhere. We wanted to come up with something because we want to be transparent. We also don't have the capacity in-house to negotiate with each and every customer about pricing. So, we only have the two FTE sales in our company, which is very, very little, I would say, for a tech startup. I think a lot of tech startups are sales heavy. It's what I see around us. 

In our company, it's only less than 10% this is doing business development. And so, to make it easy for them and not spend time with too much pricing negotiation, we decided to just put the pricing out there and make it public. It's also a great conversation starter. If there are customers that really have special requirements that are outliers in our model. Because they consume a lot of traffic, or very little traffic, or they have very large deployments of devices, like way more than 100,000. That's part of our list pricing. Then we obviously have room to negotiate. 

But for us, making the pricing public and also making it only based on a number of devices, and not taking into account number of gateways or the number of messages that they sent. Yeah, I think that was a bold move a few years back. Sometimes it baits us, because there are customers who are consuming quite some traffic with us, and they are not reaching the margins that they should be having with us. Sometimes it's the other way around. And it's also, I think, a move that really keeps our competition sharp. We notice from customers, when we have these sales conversations, is that competitors are — they have to match our pricing. Because it also sets a reference in the market, I would say. It has multiple benefits, for sure. 

Erik: Absolutely. It's funny how challenging it is, right? Because you're solving often as a tech company. You're solving these really difficult technical challenges. But then often, it's the pricing model and the business model that's the most confusing. Because, at least with the technical challenge, in the end, you can validate that it's correct. You can test it. You can say, "Yes, this is the solution. We've got it." With pricing, you don't really know. There could always be some more optimal business model, optimal pricing model. The only way to know is get in front of a lot of customers and try to test the results. But even then, it's hard to do A/B testing with a pricing model when you have 20 customers, and you're scaling up. 

Johan: Yeah, exactly. So, we did that before. We published our pricing. We did a lot of trial and error. But at some point, we decided, okay, this is going to be it. Exactly as you say, building a LoRaWAN or building a low-power IoT network in general is already hard enough. So, if we also come up with a complicated pricing scheme, then we make it even harder for them. If we can make it easy, then we do that. One of the ways we do that is building The Things Stack and making it easy to onboard devices and not having to deal with all kinds of parameters that you have to know. But at the same time, also the pricing, we want to make it really easy. 

One of the main reasons why we went with this pricing model is that we wanted to match the value for the customer. We believe that if you deploy 1000 devices, then that is twice as valuable as having 500 devices. Because you have twice as many devices that generate data. You can use that to measure stuff. So, it scales with the value that it generates for customers. Whereas if you have a message-based model, then you can't really say that 10 messages are as valuable as 5 messages. Because it really depends on what is in that message. What is the density of the message? Is it a redundant message, or is it an alarm that's triggered? Sometimes the device sends one message per day, but it could be more valuable than 10 messages sent by another device. We wanted to stay away from that discussion. We thought, okay, we do everything by the number of devices and keep it very simple for our customers, so they can just put it in Excel and see if the return on investment works for them. 

Erik: I'm looking at your website here. I've chosen The Things Stack, The Things Stack cloud as the deployment model. Then if I look at the pricing — let's say, a standard support plan, 1000 devices looks like it's going to be about $480. So, I would say about $500 a month. So, that's $0.50 per device per month. If I scale that up to 100,000 devices, that moves to $5,000 a month. Then we're looking at $0.5. It looks like there's a lot of economy of scale for moving those up. Does that reflect the total costs that somebody should assume to obtain connectivity? Are there other costs in the tech stack? Obviously, there's a lot of other costs related to the tech stack. But just in terms of connecting the device, does that reflect what the price level somebody should expect? 

Johan: Yeah, the price that you mentioned of the 1000 devices, that includes support. You can also go with the 1000 devices without support. We have customers who are confident that they can figure out everything themselves through documentation, or because they already had other successful deployments in the past. I think then the price is 190, at least €190 euros. That's the starting price per month. So, that's even less. But indeed, we have a very progressive pricing model with high volume discounts for larger customers. That's really what they pay. Our customer base pays the least prices, typically. You can get some discounts if you commit to one year or a quarter upfront, things like that. But that's just typical. 

The other costs that customers would have to need to consider, of course, is the hardware. They would have to set up gateways and purchase end devices. They have their own application workload. But typically, we want to be certainly not more than 10% of the total cost of ownership of their IoT solution. So, we certainly don't want to be cost heavy in their entire picture. 

Erik: Okay. Great. Thanks. Well, maybe we can wrap up here, Johan, with a bit of a discussion about the future. I guess we could look at this from two perspectives. One would be the LoRaWAN perspective. So, what is exciting on the horizon for LoRaWAN as a protocol, as a technology? Then second would be The Things Industries. What do you have, either in your product development pipeline, in your market expansion pipeline? What is it that you're personally excited about in the business? 

Johan: I think in LoRaWAN, I would almost say that the less exciting things happen in LoRaWAN. It's also a good thing. The stability of the specification and making sure that all the puzzle pieces fit well together and that there is a certification program, I think that's the most important thing. I spend about a day a week contributing to the LoRa Alliance Technical Committee, in various subcommittees working on the LoRaWAN specification, but also APIs between LoRaWAN network servers, if you want to use roaming with other networks or external security services, things like that. 

I think one of the most exciting things that I see now is that things are coming together, but not necessarily that we add a lot of features to LoRaWAN. Because I think LoRaWAN is already suiting most of the needs in the market. One of the things that I think are quite interesting is that we started adding support for different cipher suites, different cryptographic schemes in LoRaWAN. That allows LoRaWAN to adopt to a requirement set by NIST or the European Union about how to protect data, how to encrypt it, which algorithms to use. It's a bit of a long-term thing. But I think it's a great thing to have in the LoRaWAN architecture, that it's ready for also future cryptographic scheme requirement set by different regulators. But it's also quite boring. A lot of things are just putting the puzzle pieces together, making sure that certification works. And that customers, if they see the LoRaWAN brand, that they know that it works basically. 

On our side and as a company, we really focus on product leadership and operational excellence. A lot of efforts in our engineering team are making sure that our services are running better, smoother, faster, more cost efficient. That is not always visible on the outside, so we do a lot of effort, a lot of exciting things. 

We're going to throw a party two weeks from now with the engineering team. Because we did a lot of technical debt removal in The Things Stack. Nothing is visible from the outside. Everything is backwards compatible. None of our customers would notice this. But for us, it's a very big thing. I think it's also good as a company that we invest a significant amount of time in making sure that our tech stack is up to date, and that we don't carry a lot of technical debt forward. Those are things that I can get excited about that is not something visible for customers. 

I think other things that will be visible for customers is our network operation center. It's a new product that we released a month back as part of The Things Stack. This allows you to have really nice dashboards where you can see gateway traffic rate, noise levels per channel. But you can also see which gateways are covering, which end devices and vice versa but, also, historical information about how devices and applications are doing. So, a lot of tangible insights and also getting alerts from when gateways go offline. Those kind of network management features, that is definitely on the horizon. 

Another thing that we're adding that we have on our roadmap is the ability to detect if there is something off with your device fleet. Because we are working with the device maker community, and allowing them to specify normal behavior of their devices in the device repository. By observing the actual behavior in the network layer, we can see if there's a discrepancy between what is normal or what is desired versus what we observe as a network. With that, we can give a very tailored insight and feedback to the device maker but also to our customers. 

Because again, with LoRaWAN devices, you don't really have this always-on connection with your IoT device. It's not like a Raspberry Pi that runs somewhere. You can always access it. You can always get information. But sometimes you have to wait a day. Or if it really gets bad, you have to visit the physical end device and see what's going on. So, making sure that our customers don't have to go out in the field. Because they have the network operation center, and they get insight from our automated insight from our product about how healthy their device fleet is. Those are big features that are really helpful for our customers to reduce their cost and their confidence in their LoRaWAN deployment. 

Erik: Okay. Interesting. I was talking to a cybersecurity company a few days ago. They were also basically looking at this topic of device operations. I think that this seems to be a big trend. The companies, it could be a connectivity provider. It could be a cybersecurity provider. But then, because of the nature of your core business, you have this data flow. You're able to mine that data and understand operational behavior, and then convert that into information that's useful for maintenance teams, useful for device users, et cetera. It seems like a whole new area to provide value for your customers. It's just a matter of converting that data into useful information. 

I'm glad you mentioned the technical debt topic as well. I feel like every company should have some internal award for technical debt removal. It's a very important work that doesn't really get recognized. But that's what keeps the world moving. 

Johan: Oh, yeah, for sure. We even invited former colleagues who worked with us two years, three years ago. We even invited them to our technical debt parties, when we remove something. It's really part of our company culture to keep an eye on that. Because it's really hurting the motivation of engineers going to work when they have to work with stuff that should have been fixed, or all dependencies, or that they're continuously thinking, okay, we should have done this differently. Then it's really good if the engineering leaders, or even me as a CTO, is making sure that everyone can commit serious time to removing technical debt, and that we don't always have this feature focus. Because I think that's the best way forward for us. 

Erik: I love that. I love the fact that you bring people. They say, "Hey, Johan. We finally removed the code that you wrote back in 2019." 

Johan: Yes, come bear with us. Yeah, I know. That is really what working for The Things Industries is about, for sure. 

Erik: Yeah, great. Well, Johan, I think we covered a good bit of territory here. Any details that we haven't touched on that are important for folks to know? 

Johan: In May, we are going to IoT World Solutions Congress in Santa Clara, where you can meet Wienke and myself. We have a really nice device, a wall of fame with all kinds of LoRaWAN devices. Then in September, 21 or 22 of September, if I'm not mistaken, we have The Things Conference in Amsterdam, which is the major LoRaWAN event of the year, as one of our site activities that escalated into organizing a big show with 1,500 people from all over the world. It's only about LoRaWAN, basically. Technology but also solutions and finding business contacts. If people are interested in learning more about LoRa and LoRaWAN, if they're in the US in May, then please come to us in the Santa Clara event. Otherwise, in September, in Amsterdam. 

Erik: Okay. Wonderful. Then folks, I guess, can also reach out at thethingsindustries.com. I think it's possible to connect with your team there. Johan, really, thank you for taking the time to talk with us today. 

Johan: Thanks. Thanks, Erik. Thanks so much for having me. Yeah, thanks a lot for this opportunity.