Defending Democracies With Rust

Drew: Helsing's done a good job of getting ingrained in the Rust community, but a lot of people probably still don't know what it is. Could you give a brief pitch on what Helsing does?

Jon: Helsing is a software-first defense company. There are some companies that have been in the defense industry for ages, and they build primarily hardware, like actual physical weapons, and then they've realised over the past couple of years that they need to introduce more advanced software into the mix. This is because the threat space that we're exposed to is also getting smarter. The adversaries are getting smarter, and so we must also get smarter. So, they are realizing they also need to write software.

Jon: Helsing comes at this from the opposite side. It started as a software-only company, and then recently we've had some work where we're also developing our own hardware, but it very much comes from the software side of things—we think about how to build software for the defense space, for real-time battlefield management and real-time weapons systems, as opposed to tagging the software on afterwards. The intent here is to take the hardware that, in many cases, governments already have and already spent money on and make it behave better. We want to give better accuracy and give humans more insight into how to use these most efficiently, rather than just keep buying new stuff.

Drew: That makes sense. When I was researching a little bit, I saw Helsing has some hardware, but if I'm understanding right, Helsing writes a lot of software that can be used with other hardware as well?

Jon: Exactly. We used to operate entirely just partnering with industry partners and governments and working with what they already have. All of that was writing software that operates on and with those systems. Then, the hardware of our own came into view because there's some gaps where there was no hardware we could integrate with to the extent we needed. So, we built that hardware as well. But, generally, Helsing was never built as "you have to only buy our stuff"—quite to the contrary. It was “take the stuff that's already out there and make it be smarter, more efficient—have a longer shelf life and more accurate use.”

Drew: That makes sense. To that end, could you actually describe the main products that Helsing has or works on right now?

Jon: It's a little tough to describe them as products. Though, we do have some things that are labeled as products. Very often what we do is work with the government- the French government, the German government, the British government—and talk to them about what they have and what they need. It's not so much that we come in and say, "We must sell you this thing and otherwise we're not interested." It's more looking at gaps in their current capabilities. Where do they feel like they're falling short?

Jon: There are a couple of things that we have announced as actual products. There’s the HX-2, which is a strike drone. You can think of it as a fire-and-forget missile, but it is much better at striking the right target and not being interfered with by whatever might be along the way. It also gives humans more insight into what they might hit and how. There’s a really interesting challenge in making sure that those things operate well when you have, let's say, environments in which you have degraded communication links or jamming of GPS and the like. We want systems that work reliably even in those contexts. That’s HX-2.

Jon: Then we have recently announced something called SG-1, which is unrelated to the Stargate franchise. SG-1 is an underwater drone. The intent here is that you want to deploy lots of these throughout a large body of water. They might be throughout the Baltic Sea for example, to surveil for ships, submarines, or whatever traffic might be going that way. You want a mesh network of these things using AI to figure out what's going where and then communicating those insights. When you're in the ocean, you need to have things that operate for very long periods of time. So, these are built so that you can leave them in the water for three months without having to gather them in, and they're continuously monitoring the space.

Jon: Then we have more long-term things we're working on. For example, we have Centaur, which is an autonomous AI for operating a fighter jet. Think of if you are training jet fighters, for example, and they need to have an actual opponent that they can train against. Centaur can be the agent that can fly the plane that you're training against. The goal here is to get it to human operating level, where it is actually a match for real pilots in these realistic simulators that they use for training. It goes beyond training too —just the other week, we had Centaur autonomously control a fighter jet mid-flight!

Jon: We have a bunch of other directions we're working. We work in the air domain as well with the Eurofighter, for example. We work in the land domain for more tactical ground station battle operations type stuff. We can get into any of those if you want, but I think that's at least a high-level survey of the things we do.

Jon: One thing that's interesting about working for a company like this is, you know, we end up dealing with things that are really secret, right? Not just "don't tell your friends," but actually really secret. That is both really interesting and really challenging. It's interesting in the sense that you get exposed to some problems that are important, but you can't talk to people about them. It’s challenging because it puts a bunch of constraints on the operating environment that we use when developing solutions. When we do programming where we handle secret data or classified data we have to change our engineering practices to make sure that they work with code that can't be seen by people in certain geographic areas. Or, for example, can’t be seen by people who aren't directly involved with that particular project. So, there's some—I think "interesting" is the right word—some interesting challenges in operating in that environment, but it does also mean that you get exposure to problems that are super fascinating that you would not get exposure to otherwise.

Drew: They say constraints always foster creativity—it's probably a space where you see a lot of that. I would like to actually ask you more about that in a minute. One more question about Helsing in general. What do you know about the founders and how they ended up starting this company?

Jon: There are three founders that started the company. There's Gundbert, Torsten, and Niklas. Niklas is a physicist and machine learning engineer by trade. He started a company called Hellsicht, which I think is part of the origin of the Helsing name. That was a machine learning engineering company first and foremost. Gundbert is the one who came from the most defense-focused background. He worked for McKinsey for a while, but then worked with the German Ministry of Defense. He's the person who's worked on these kinds of problems in this space before. And then Torsten originally ran a game development company. He was an investor for many years. I think all of them came together and were like, "Okay, there is a need for European defense here. We can't just rely on the nations outside of Europe to help safeguard Europe. That makes no sense, and no one is doing it. Or, at least no one is doing it in the way that we think it needs to be done.”

Jon: I think especially Torsten and Niklas came from the background of thinking this is exactly what software is for—- rapidly adapting to a quickly evolving adversarial space. This can't all be encoded in hardware, and I think Gundbert had seen that from his exposure to the Ministry of Defense. So, the three of them came together saying let's start a company that aims to do this in the proper way: s. Software-first is what I mean by that. Rather than yet another hardware defense company that takes many, many, many years to go through cycles to develop new hardware.

Drew: That's very interesting. I can't help but notice the parallels between the background of the Helsing team and their approach and some of the newer defense companies we're seeing in the US right now as well.

Jon: Yeah, it seems to be a developing sentiment. Although, I think it’s important to note that traditional hardware companies also still innovate. The difference is that they are focused on the hardware first, because that's what they know how to build. I just don’t think that's the place to focus right now. If you look at the way the war in Ukraine has evolved, the way Ukraine gets an edge, despite being at a disadvantage from a purely physical point of view, is by using new technology and evolving that technology quickly. They use whatever hardware there isis there and then stitch it together with spit, tape and software, right? You can iterate on software much faster. You can adapt it much faster than you can with hardware.

Drew: That makes sense. Maybe the right way to say it would be better adapted to the current battlefield situation.

Jon: Yeah.

Drew: How did you end up at Helsing?

Jon: I actually didn't have Helsing on my radar at all initially. When I left the US about two years ago now, I was moving back to Norway from LA. And, I was really looking all over the place, openly soliciting work, wherever might be interesting. I had a bunch of companies that reached out, and I reached out to a couple. The whole defense sector wasn't something I was considering in the slightest. If anything, I was maybe antagonistic toward it or at least skeptical that it was a place I would want to end up. Then, someone who worked at Helsing, just an engineer at Helsing, reached out to me and said, "Hey, do you think you might be interested in checking this company out?" So, I started looking through and looking at some of the stuff they'd done. I was like, "Eh, I'm not so sure, but tell me more about the experience you've had there." They gave me their view from the inside and why they joined. And, I said, "All right, let's hear some more." I got put in touch with one of the engineers who was leading a team internally. They talked about some of the work they were doing, and I thought, "Hmm, that's interesting." I heard about some of the rationale for why they chose to take the job. Then, I asked to be put in touch with more people. I ended up talking to the CTO about some of the bigger tech problems they were facing.

Jon: They were using Rust almost exclusively internally, so that obviously was interesting. And, I felt like they had an approach to defense and a way of thinking about defense that appealed to me and felt important. That’s maybe something we should dig into further later. But, the combination of it feeling important and the technology being interesting really sold me. Also, the company felt like it was in a place where I could have both a good opportunity for growth and also learn a new field. And the people seemed like they would be good to work with. I was put in touch with one of the founders to investigate even further toward the end of the process. Really it was just a sequence of positive signs and feelings that there's actually something really interesting and important to work on here. In the end, I was between Helsing and two other places. One offer was to work in the open source world on a very specific toolchain that I didn't have a lot of experience with. But, there was not really a growth trajectory. It's not a company with lots of customers. It just works on this open source thing, which seemed like it could be interesting, but it wasn’t a very good growth path. The third was a startup that was in stealth mode, working on a really, really interesting distributed systems problem. That again seemed really interesting, but it was a startup with three people where I would have been the fourth. That would have been fun, but it would be a different kind of fun. I think it came down to really wanting to try this new field. I've done the distributed system stuff. I've done the open-source stuff. I wanted to stretch my horizons a little bit. I'm very glad that I did.

Drew: Awesome. That's a great way to pick a job—asking yourself where can I grow?

Jon: It was a little bit of a luxury too, right? I'm at a place now in my career where I get to solicit job offers a little bit. That makes it easier for me to pick based on things I want. I think that's a luxury. And, I recognize and appreciate that I have it. But, even without some of that flexibility, this was something I have realized over time is a really good opportunity.

Drew: What do you think put you in a position where you can be picky with the jobs that you take? I know that you've worked at Amazon before. A lot of companies are very excited about engineers that come out of big tech. But your social media presence and streaming must be a factor as well?

Jon: Oh, for sure. I think it's a combination of all of the many things I've done. I was in the education system for a long time. I have a PhD from MIT in distributed systems, and that counts for something. I worked for Amazon for many years, basically owning their Rust build tool stack. That was a big "I've done Rust in industry" sort of credential. I've done a lot of work in the open source world, which means that people have seen me code, they've seen me interact with other people, they know that I know how to think about codebases, even large codebases. I've shown that in public. And, obviously they know that I know Rust because of my educational stuff. And, they know that I can communicate because of that, right? Both in terms of written communication, like the Rust for Rustaceans book, but also in the more real-time sense. I give a lot of talks. I go to conferences. I do my live streams where I both code and talk about the code. I think that all nets out to make it very low risk for companies to hire me. Usually you take on a lot of risk when you hire someone. They’ve seen me do well in all those areas publicly, so they’re probably thinking, "This is not just not a risk, but actually someone we would like to hire."

Drew: You basically have checked every box. You've done everything that a company might be interested in seeing.

Jon: It's entirely by accident though! It's not like I set out saying, "Well, I need to make sure I check all the boxes for companies before I apply there." It's more that I followed the things that I thought were interesting. I continued my studies, because I really liked to learn. In the process of doing so I found that I had enough spare time, and I was learning enough interesting things that I figured I should also teach because that's what I enjoy doing. When I was looking for where to go next, I thought industry seemed interesting, Amazon seemed interesting, and I already knew Rust well, so how about it? It just evolved very naturally, without much of a plan. But, when I look back on it, I do realize I have ended up with a well-covered background.

Drew: I think there's a lesson there for people to just keep following their curiosity. I think that creates energy for you to do a lot of things.

Jon: I think that's true. Although, I also think part of it is pushing yourself a little bit to do something outside of your comfort zone. Going from my master's to my PhD thesis, for example, I moved to a different domain. My master's was on wireless networking, and my PhD ultimately was on databases. I didn't know Rust at all. I just randomly was thinking "I like programming languages. This seems kind of interesting. How about I try writing my PhD thesis software in this." Same thing when I was joining Amazon. I thought, "let's go to a big company to see what that's like." Now it’s "let's try to go into defense because that's different. I want to learn something new." “What would it be like to do a stream? I don't know. Let's figure it out.” “What would it be like to write a book? Well, let's try that too.” But none of this was effortless, right? I think having a little bit of comfort with discomfort in that way helps you grow as well.

Drew: Yeah, that's absolutely huge. One more question about your personal experience joining the company… This one feels important to me. As you know, I run a job board for Rust jobs. I've already gotten a lot of criticism of people saying that we shouldn't be platforming defense companies. I've had to articulate my point of view on why we do, which seems silly because it always seems to me that filtra.io is not that big or impactful. But, in the Rust community particularly, there seems to be a lot of concern about the defense sector. Could you maybe explain why you think, as you said before, this is an important place to work?

Jon: Yeah, this is a question I get a lot, and I'm happy that I get it a lot. If no one questioned this, then I would question why no one is questioning it. It's also the question that I spent the longest time trying to figure out before saying yes to the offer. This is not an industry I went into lightly. I recognize a lot of the dangers here. But, the thought process I went through actually turns out to be pretty straightforward. My conviction is that someone needs to do this work. I do not think it is feasible for Europe to just not keep up with military technology. I think what you end up with is your adversaries continue to do so, and they end up just taking you over by force. And, as a result, we lose all of the things that we hold dear in our lives. So, someone needs to do this work.

Jon: Now, I have a lot of opinions on how that should be done and how it should not be done. But, I have to make a choice. Either I can yell at the people who are doing it from the sidelines that they're doing it wrong, or I can be in the room where those conversations happen, where those decisions happen, where the technology gets built, where the trade-offs get made, and influence those conversations. Between those, it seems pretty clear to me that one is more impactful than the other. That's really how I convinced myself that this was the path to take—I want to be in the room. I believe that I am both well equipped to be part of those conversations, and I think it's important that my views are represented in those rooms.

Jon: That's an argument for why I'm willing to go into defense in general. Then there's a second-order question, which is, why Helsing specifically? For me, Helsing came at this from a point of view that I liked. First of all, it's not a company that makes products for general sale. They don't work with the highest bidder. Instead, they work directly with specifically democracies—European democracies at the moment—and figure out how they can develop sovereign technology for defense of their own borders. The focus that was highlighted to me pretty early on is really deterrence. It's not about building technologies to, I don't know, build a nuclear bomb or something, right? The goal is not destruction. The goal is to avoid conflict, but the way in which you do so is by having technology that keeps up with the adversaries.

Jon: That doesn't mean that the stuff that we build only ever gets used for defense. That would be a naive stance. Of course, it’s designed to also be usable for offense, because that's how deterrence works. But the company comes at it from the point of view and intent to avoid conflict, and that was important to me. In addition, there's a pretty sturdy backbone inside of Helsing that lends itself to making ethically sound decisions. For example, we have a lot of ethics workshops internally where we all come together and discuss difficult decisions that are in front of the company, but also difficult hypothetical scenarios that might come up. We try to set up realistic scenarios that are difficult and debate through what is the right thing to do. That obviously doesn't mean that we're going to get it right every time, but it does mean that we're regularly exercising that muscle and trying to think through the nuances here.

Jon: One hard thing is even defining a democracy. What is a democracy? That's not an obvious question, but it's something that we spend a lot of time internally debating, trying to get to a bar that we can meaningfully use when making decisions. At the end of the day, the decisions are made by the executive team of the company. So, no matter how much you like the company culture, you need to also trust those people to make reasonable decisions going forward. When I had the chance to speak to many of those people as part of my interview process, I pressed them pretty hard on the concerns I have about how this could go wrong. I found that they were very thoughtful in all of the ways in which I wanted them to be thoughtful. They were very realistic. They have a pragmatic and nuanced view of the world. They think about the future. They don’t seem to be profit-maximizing. This is all my perception of them, of course.

Drew: That's great. I appreciate you sharing that. You mentioned when you were talking about the founders how the invasion of Ukraine was this catalyzing moment, and I think that has been for me as well. I think for a while the West was operating with a certain amount of complacency. The western world seemed very safe.

Jon: Yeah. I think the realization for me was slightly different. It's not that the world isn't safe, but that you have to work to maintain it. It's not as though you achieve peace and stability in a region and that's what will happen going forward. You need to achieve it and then maintain it over time. I think that maintenance is what there was effort lacking in. I think the invasion of Crimea and then ultimately mainland Ukraine was the realization moment for many that we actually need to do some maintenance work here. We've been resting on our laurels a little bit too much. There was a certain realization of that for the US, but I think even more so for Europe. For Europe, it was not only a realization that we need to work for this, but also that we'd become very reliant on the current world order to maintain that peace and stability. That can't continue. We need to be more self-sufficient.

Drew: Yeah, I totally agree with that. I think that's been an important development as of late. There’s a newer idea that says “let's not just have a west that's covered by this blanket of US protection, but let’s have real allies, where everyone's striving together to maintain this thing that gives us these really blessed lives that we have.”

Drew: So, let’s shift gears a bit. Helsing obviously has a very deep investment in Rust, and that's the main reason why we're talking. Can you talk about the place that Rust occupies in your tech stack and why it's the right language for the stuff you're doing?

Jon: Rust is used almost everywhere in Helsing. There are only really two places where we don't use Rust extensively. One of them is in frontends. We have a lot of web-based frontends, in particular for things like ground station control and such, and those are primarily written in TypeScript, but then usually with Rust backends. We have some use of Wasm where we generate TypeScript code from Rust, but much of the frontend code is just truly TypeScript. And then in the machine learning space, we have a decent amount of Python for things like orchestrated training, pre-processing, and also some of the more experimental stuff. It's just easier to iterate and experiment using Python, both because of the technology itself and because of the third-party ecosystem. Also, many of the people who are experts in that field know Python very well. If we tried to move them to Rust, they would lose a lot of velocity. Everything else—anything that gets deployed, anything that's in production—is all Rust code all the way. The same thing goes for a lot of our internal tooling and internal services. Those are all built in Rust.

Drew: That's awesome. I think your point about Python is pretty interesting. I hear some people in the Rust community talking about their aspirations for Rust to take over all of the data science work. I don't think that's going to happen. And, I don't know if you want that to happen.

Jon: I think that's the wrong goal, right? The goal for me with spreading Rust was never spreading Rust. That's not the goal in and of itself. The goal for me is to have people use the language that is best fit for the purpose. For building systems that go onto a Eurofighter or building stuff that runs in a quadcopter or building stuff that goes into these underwater subs that have to run for months on end without service or interruption—you're not running Python there. There's just no way. You could write it in C, but it's extremely risky. You could write it in C++, and that's arguably just more risky. There's not really another language that's a contender here. In addition to that, Rust is actually a really good choice. It gives you a lot of nice benefits that make it pretty pleasant for work in that environment.

Jon: If you look at the machine learning space, Rust doesn't really have very compelling attributes there. The iteration cycle is slower. The safety benefits aren't really as beneficial. They are for things like the internal engine that drives training, but they're not for where you write the code that glues everything together—things like the neural net construction. None of that needs to be type safe. None of that needs to be in Rust. Maybe it would be a little nice, but it's probably not worth the poor ergonomics, the poor iteration speed, or forcing lots of people to learn a different language. We contemplated a goal internally to have Rust used everywhere. That was quickly discarded as not the right goal, precisely because it would mean that for the ML use cases you would force people to use something that's not the best fit for purpose.

Drew: I totally agree. For those places where Python maybe falls down on performance we've already seen great work done using Rust to accelerate it, and I think we'll only see more of that.

Jon: Yeah, we do end up using Rust at the boundary next to Python. There are places where we've built tooling in Rust that we make callable from Python precisely so that the machine learning engineers can use Python to experiment with their algorithms and whatnot. We use things like PyO3 in a bunch of places because that's how you bridge that gap. There's also places where it doesn't have to be machine learning people, or it can also just be people with more of a background in algorithms research, for instance. Take radar signal or sonar signal analysis. If you're operating with that signal processing, your background is probably also in more of a dynamic programming language. Maybe it's MATLAB, maybe it's Python, but that's where you're coming from. You're not going to be productive if we make you write all that stuff in Rust.

Drew: Totally. So, you mentioned earlier that one of the primary things that attracted you to this work was interesting technical problems. Could you speak to what some of those are, or maybe recent ones that you've run into and found really compelling to work on?

Jon: There are some things I would love to talk about, but I can't. Of the ones that I can, one that I'm really excited about is something that I realized pretty early on when I joined Helsing. We noticed this gap. It’s a gap that exists when you have a battlefield situation where you have lots of assets that are distributed— some of them are just people with radios, some of those are vehicles that have mounted radios in them, some of them are maybe quadcopters or other flying vehicles that have radios on them as well. On top of all that, you have jammers out there. There's such a rich signal environment. Yet, you're trying to get an overview of what's happening and where in real time. That's really hard to build.

Jon: What you effectively have is a very dynamic, very lossy mesh network where there are hostile actors trying to jam you. You don't have reliable connectivity between any two nodes. Everything is mobile, so which things can connect to which is anyone's guess from one second to the next. Yet, you need to exchange information over this, right? Nodes need to be able to report where they are and what they're doing. You need to be able to send out tasks to different assets. You need to acknowledge those tasks and figure out what you do if you don't hear the acknowledgement. There's a whole communication network problem there.

Jon: So, one of the things that I built when I first joined the company was this tool that is essentially a distributed system for battlefield real-time storage. It's an exchange system that allows all of the different nodes in this distributed network to exchange information in a way where conflicts are handled and surfaced and nothing relies on a consensus protocol, so you don't need everyone to be connected all the time. It can operate in extremely degraded environments where you might only have connectivity very rarely. That connectivity is maybe less than a kilobit per second, sometimes even significantly worse than that. You have really poor networking conditions, but you have a system that can reliably—or as reliably as the network allows—exchange information over that. That was a really cool problem that dove deep into distributed systems and we ended up basically making research contributions to that field that we're currently working on writing up. That was really fun to work on.

Jon: We also sometimes operate with very constrained hardware. If you're going to install a compute board into something like a jet fighter, there are really tight constraints on how big that board can be, how much heat it can produce, and how much power it can consume. As a result you have constraints on what cores and software you can run on there. But, we still want to run these sophisticated algorithms. We want to run machine learning on there, and trying to figure out how to run the algorithms that need to be run with the fidelity that they need to be run and the speed that they need to run is very interesting. It's at the intersection of a lot of really interesting questions. It’s not just GPU compute optimization and CPU optimization and optimizing memory layout and communication protocols and stuff, but also things like model compression. You can compress your neural net such that it fits on the GPU that’s available on the board without compromising the performance too much. So, there's some really interesting intersectional problems.

Jon: Maybe the third challenging thing that I've worked on is at the intersection of tech and ethics. In this case it’s not so much about whether or not the thing can be built but about what the implications are if we decide to implement it one way versus another. As a hypothetical example, imagine you have a drone that has flown over hostile territory. It spots a tank, and it's one hundred percent certain it's a tank. It flies back, and then you decide that you want to take out that enemy tank. So, you send some other drone an hour later. It also spots a tank in the same place. Should you tell the user that this is the same tank? Answering that question is really, really complicated. On the surface you might say, yes of course it's the same tank. But, at the same time, an hour has passed. It could be that the tank has driven away and a new tank has driven into the exact same place. So, maybe you start looking for markings on the tank. But, maybe those markings are exactly the same. So, do you show the user "target acquired” or do you surface "yes, this is also a tank in the same place, but we're not sure if it's the same one." You’re creating uncertainty for the user. That might be a good thing, but they might also only have a split second to react. Do you really want them to read a paragraph of text on screen in order to make that decision? Some of it is going to come down to mission configuration. Does it matter whether it's the exact same tank, or is all that matters that you're destroying an enemy tank? If what mattered was a particular type of new munition that was in that particular tank, you might care about it being this one. You don't want to destroy the other one because you don't want to give away the fact that you've spotted this location. So, it's a really interesting decision you have to make. I think this is just really, really interesting and something I feel like I haven't been exposed to in most of the other work that I've done.

Drew: That is fascinating. It reminds me of the silly things in web development where you’re thinking should this button be here or there? Or, what color should this button be? How does that support the user's decision? Except for here the consequences are so great.

Jon: Yep. Sometimes it's even the question of how big do you make the button? Or how green do you make the rectangle? You really want a human in the decision-making loop. And, it can be very easy to say, "Oh, there's a human in the loop because a human looked at it and clicked the button," but that may not really be a human in the loop. What that means is a human was shown a thing and then clicked the thing. It's on us to make sure that the human knew what they were agreeing to. How do we make sure that they know the implications of hitting that button? How do we make sure that they know the uncertainty in the data they were fed? And, how do we do that in a way where they can still make decisions quickly because they're in a battlefield situation and they might not have more than three seconds to decide or otherwise they're going to be shot down themselves.

Drew: When I was researching and reading for this interview about signal jamming and these things, I was starting to realize something that I guess should be obvious, which is that you’re dealing with a whole other level of adversary. When you're doing regular programming, you worry about bad actors, and you try to defend against that, but this is a situation where you absolutely will be attacked in every possible way.

Jon: Yep. For example, if your quadcopter gets shot down or something you have to worry about whether the enemy is going to try to jailbreak it so that they can access your software or so that they can put it back in the field and rejoin your network, stealing insights from the communication channel that device is authenticated to. So there are these kinds of things that you need to come up with technical solutions for. Sometimes there's a hardware solution, sometimes there's a software solution, and often it’s both.

Drew: Yeah, absolutely.

Drew: Since our focus is hiring and highlighting companies that people might want to work for—I do like to ask some questions about culture. I'm not sure if you do a lot of hiring or if you're involved. Are you?

Jon: I am involved. I'm not so involved in hosting individual interviews. I mostly do that for particularly senior candidates, but I'm involved in a lot of the hiring pipeline and stuff.

Drew: What does Helsing tend to look for in new hires, or at least what's unique about Helsing's approach there?

Jon: I think there are three things that are unique. First, there's a certain amount of tolerance of ambiguity needed. Very often you need to think through the problem carefully. Some of the things we've discussed already are good examples of this. Sometimes even small decisions can have a huge impact on what actually happens in the real world. That means that there will be tasks where you have to apply sound judgment. We tend to look for that. We tend to look for the ability to handle ambiguity in your tasks, and if not necessarily solve that ambiguity yourself, know when to raise questions further. You have to know when to ask questions and when to ask for help.

Jon: I think the second thing that we value quite a bit is a healthy skepticism. One of the Helsing guiding principles is that we do things “from first principles”. We try to not take established practice as fact unless we have good evidence that it is actually the right practice for us. We tend to like candidates who ask questions to try to clarify problem statements. We like people that interrogate even just things like why we as a company do what we do? Why is this the problem that we're choosing to solve? But, it also comes down to technical decisions. If you're given a snippet of code, you should ask why it is that way in the first place. So, an ability to think for yourself and a willingness to speak up if you disagree is also something we look for.

Jon: And then I think the third thing is some amount of ambition. When I say ambition here, I don't mean "I want to be paid a million dollars." It's not that kind of ambition but ambition in the sense of wanting to work on things that matter. We work on things that impact human lives. We work on things that impact nations and the spaces that we occupy and the worlds that we live in. If someone comes in and doesn't really care or they just want a software engineering job, we're not the place for that. With that said, I think we have a good working culture internally. I don't think it's "you must burn for work." It's not that attitude. We just need people who actually believe that what we're doing is important. This ties into things like the ethical questions. Someone who just does software engineering won't ask the hard questions. They wouldn't care about the impacts of the decisions they make. We need people to care.

Drew: That all makes a ton of sense. There's a book called Good to Great about doing turnarounds in companies, and one of the things it talks about is starting with people. It talks about finding people with the type of ambition that you are talking about, where it's ambition for the mission, not personal ambition.

Jon: Personal ambition is fine too, but we don’t measure for that. But it certainly does matter that you care about what we do. That's not something I would say for every company. I think many companies claim that it's important that you care about what they do, but it doesn't really matter. For us, there's actually a pretty serious implication if you don't. That raises risks that might surface later.

Drew: Is there anything interesting that you would mention about the way Helsing handles issues of compensation like salary, equity, or benefits?

Jon: I think we have a fairly standard process in the sense that there are compensation bands. There are 360 reviews every year that affect how you are paid. There is a split between cash and equity. So, we have those kinds of standard things. Maybe there are some things we do a little differently. Helsing is very focused on the transparency of that process internally. We have different levels of engineers, just like most companies do, but we have a full listing internally of what those levels are and what the expectations are for each level. We also have published internally the compensation bands for both equity and cash compensation. You know what you're getting, and you know what it takes to get to the next level.

Jon: The levels are also private, so no one else knows what level you are. The level is just there for us to be able to meaningfully give performance reviews and figure out your trajectory. People don't go around with a label attached to their name. This is very much intentional, because we want to have a culture internally where you can make your point and people will listen to you independent of what level you are. I guess there are some exceptions to this. If you're the CTO, everyone knows you're the CTO. In my case, I have the title of Principal Engineer, which is a specific title in the company that is explicitly public. Most people are simply software engineers or AI research engineers, regardless of whether you're a junior right out of college or you've worked for 20 years. You can choose to share that level, but we don't make you. That is precisely because we don't want that to affect how people interact with each other and how we evaluate ideas. The levels are more for your own understanding of where you're at, how you could grow, what your compensation should be, and to know that you're being treated fairly compared to the others when it comes to things like equity.

Drew: That's actually really cool. And that is different. I'm glad I asked that question.

Jon: There's actually a second thing that is a little different. We have the same standard benefits as most companies in Europe do, but we also have things like a learning allowance and such. We have a bunch of different allowances. And, the way the allowances work at Helsing is very agency-based. There's not a process for getting something approved as part of your learning allowance. It is just, this is your allowance, spend it however you see fit. Obviously, if you spend it on completely ridiculous things, that would eventually come back to bite you. But, there’s this real focus on agency over process. We've hired you because we trust you, we trust you to make reasonable decisions about things like how you learn or whether it's appropriate for you to travel to a different office. That is a little different than how things were for me at Amazon, for example. There they have much more process for things.

Drew: So there's a higher degree of autonomy and ownership of your decisions.

Jon: Yeah, I think I would describe it that way.

Drew: Are there any other peculiarities of Helsing as a company or culture that you think are worth mentioning?

Jon: Hmm, good question. There are two bits I'd mention here. The first is that we are primarily an in-person company. With a lot of the work that we do, you need to be in a particular place in order to be allowed to work with particular software, particular data, particular partners, particular hardware, and so forth. Not every position is like that, but many positions are, and we don't want those people to be alone in the office. We also don’t assign teams to specific locations. For example, we have a lot of people in London that work with people in Munich, Berlin, and Paris on a regular basis. So, despite being in-person, the communication culture is quite asynchronous. So, if you work from home for a few days, that's usually not a problem. Everything is set up for people to be remote anyway. I'm permanently remote, which is a bit of an exception. But, I end up traveling to one of the offices maybe once a month. I don't feel like I'm missing out by being remote, because I feel like everything is built around the fact that we're all distributed anyway. I think that is an interesting aspect- that we’re primarily in-person but cater to asynchronous work.

Jon: The other bit that's interesting to me is there's a decent amount of flexibility internally for people to move between projects. It’s not that you can just pick up and leave at any time, but there's an understanding that people want to get exposure to different aspects of the business. That sometimes can be "I worked in the air domain for a while. Now I want to work in the land domain." But, it can also be things like, "I've been doing the software engineering side of things for a while, and I really want more exposure to hardware engineering." We have a job title that's “Deployed AI Engineer.” We used to call them “outside engineers” for a while. They are basically the people who sit in the field in the rain with a laptop. They’re people that want to hook in cables and see things fly and get mud on their boots. We have software engineers and AI research engineers who are like, "I want to get more of a feel for what's happening in the real world." To be clear, this is not necessarily on the front lines. That's not what I mean. But, you’re in the field when we do flight tests and experiments with the real hardware. So, you can do a rotation with them in order to get exposure to that. There is a real culture of people who want to learn and understand the other bits and get to view different parts of the tech stack and problem space. We lean into that.

Drew: That's cool. I saw that Deployed AI Engineer role on your website, and I thought that's a cool job for somebody for sure.

Jon: Yeah.

Drew: Okay, so last question. Is there anything else you wish we had the chance to discuss?

Jon: Not off the top of my head. Although, in a way, I feel like this interview has been too easy. As you yourself have experienced, defense companies or anyone who hosts a defense company tend to get pressed a lot with "but why?" type questions. And, I think that's totally fair. I want to make sure we have done our best to satisfy people’s questions. Has the interview been easy because you feel like you got reasonable answers, or did you not want to pry too much about the issue?

Drew: I think it's because there was alignment in what you said and the way that I think about this dilemma.

Jon: The reason I probe about it is because people will read this and have their own opinion based on their priors. There will be some people who come into that with a hostile attitude of, "This is bad. You should not be working with these people. Why are you talking to them? Why are you letting them speak?" I'm trying to put my head in their space and trying to figure out what are the things that they would want answers to that they feel like you didn't ask me. We're not going to convince someone who believes that every aspect of defense is bad that defense is not all bad in this interview. But, sometimes asking another hard question could be useful.

Drew: Yeah.

Jon: I don't immediately have one that comes to mind, but maybe you do.

Drew: We were talking about the hypothetical of the tank that you want to hit- the situation where one drone has seen that tank and then another drone goes out with the intent to hit it, but it's going to ask you for confirmation. We talked about wrestling with designing UI in such a way that you’re engaging the human in the decision process as much as possible. That’s a lot more art than science. It’s hard to precisely measure if you have it right. And, the consequences are so high. So, how do you know when something's ready to ship?

Jon: That’s a great question. I think the answer to an extent is that you will never know based on just lab experiments. There's no test you can do to check whether it's good enough. You have to build up confidence that you think it is ready for the next stage of trials, right? You can almost think of medicine here. How do you know when a treatment is ready to try on humans? I think it's because you feel like you've done enough of the legwork to make that the only next path that you can try. The way that looks for us is initially we do everything in software only. Then we go to flight tests. Then we might work with a partner to run a battle exercise of some kind with the equipment. That gets us as close as possible to the real thing. We have a saying internally that “the truth is in the field”. I think that's the thing to lean into here. Until you have demonstrated it in as close as possible to real battle situations, you do not know that it's ready.

Drew: I have one more challenging question if you're willing to field it.

Jon: Sure.

Drew: We talked about how Helsing is pretty specific about saying that the mission is to defend democracies. And, I think you mentioned that the definition of a democracy can actually get fuzzy. Even if we look at history, you know, countries toggle between political systems more than we might like. What are the safeguards that are in place? Let's say Helsing has a relationship with a nation state, and then that nation state starts to tip into something that doesn't really look like democracy anymore. Are there safeguards in place for that sort of thing?

Jon: There are actually two really interesting questions here. The first is, can you do anything as a safeguard? And, if that does happen, what do you do? The other question is, how do you avoid getting into the situation in the first place? For the avoiding question, part of this is how do you evaluate whether something is a democracy? It's not just a question of whether or not their last election was free and fair, right? It has to be more than that. We've got a lot of debates about this internally. What does it mean that we only work with democracies? Some of that is looking at the stability of the nation. It's looking at things like the freedom of the press. It's looking at things like the ability for citizens to express themselves. How long have they had free and fair elections? There's a lot of components that go into that. None of them are black and white. We end up trying to form as complete a picture as we can of not just whether the country is currently democratic, but also how long has it been and how likely is it to continue to be so. So that, I think, is part one. We try to make the decision to work with a country as informed as we can.

Jon: The second part is really hard. I don't think there are any ways to build these safeguards. This is actually something that gets pointed out a lot when I have conversations about this. Whoever you work with could always just choose to sell it to someone else, and now it's in the hands of people you don't want to have their hands on it. And the reality is that you don't control that. The only thing you control is what you build and who you provide it to—the first person you provide it to. These are the only two things you control. We can control that we do not want to build certain kinds of technologies, and we can choose that we only want to work with certain countries. We cannot stipulate, "You are allowed to use this, but only within this geographic area," or "You are allowed to use this, but you're not allowed to give it to anyone else." If we did that, they would not work with us in the first place. Would it really be better if we had all these really stringent requirements on use but no one used the stuff we built? In that case, those requirements don't have any impact anyway. So, you have to balance the potential risks of your partners doing things with which you might disagree with making sure that you have an impact or an influence on them at all. At least when you are working with them you can sit at the table for some of those conversations.

Drew: I think that's right. If you're trying to promote the sovereignty of these democracies that you serve, you can't somehow have sovereignty over them as a company.

Jon: Exactly. If you really think about it, do you want us as a company to have a veto over, say, the UK government? Would we want a world in which a decision to strike then sends a message to Helsing, and Helsing also has to approve an action? That makes no sense. And, I wouldn't want that responsibility. That is the sort of thing that governments are for. That's why we have elected officials that are part of the chain of command. That power, that ability, should not lie with a single company. They answer to the people. At least that's the intent of a democracy.

Drew: Yeah, absolutely. We're talking about democracies drifting off of their purpose, and that can certainly happen with a company as well. Those were the only questions that were in the back of my head.

Jon: That's good. I'm glad we got them out. They were good questions.

Drew: I appreciate your earnestness in answering all of these questions. I do personally think the work you're doing is important. I hope in some small way this could be helpful in maybe putting Helsing on the radar of some of the right engineers.

Jon: I appreciate that.

Drew: Great. Thank you so much for chatting.