Why Deep Tech Unicorns Fail: Lessons from Lilium and Arrival’s Billion-Dollar Mistakes | James Arnold

What can we learn from the collapse of two billion-dollar Deep Tech unicorns? James Arnold held senior strategy and operations roles at both Lilium and Arrival - European companies that raised over a billion dollars each, employed thousands of engineers, and still ended in insolvency.

This conversation reveals the hidden pitfalls that destroy Deep Tech companies: why rapid team growth kills startup agility, how too much capital corrupts decision-making, and why applying software ‘blitzscaling’ to hardware development creates catastrophic risks. James provides insider insights into what actually went wrong at companies that had everything going for them - brilliant technology, massive funding, and world-class talent.

Essential listening for Deep Tech founders, investors, and anyone who wants to understand why breakthrough technology and vast resources aren’t enough to guarantee success in the lab-to-market journey.

Key Topics Covered:

- Why blitzscaling from software doesn’t work for Deep Tech hardware companies

- The hidden dangers of rapid team growth in complex engineering projects

- How vertical integration multiplies complexity and resource requirements

- The critical difference between proving you’re ‘not crazy’ vs building for investors

- Why scale models in aerospace don’t teach you about real engineering problems

- How too much capital can affect decision-making and resource allocation

- The importance of focus when developing multiple breakthrough technologies

- Finding revenue streams before your moonshot product is ready

- Leadership challenges in maintaining stakeholder confidence during long development cycles.

Learn more about Lab to Market Leadership: https://www.deeptechleaders.com

Follow us on LinkedIn: https://www.linkedin.com/company/deeptechleaders

Podcast Production: Beauxhaus

Transcript

James Arnold: 0:00

Is there something on the technology journey that you are on that you can monetize before your final product without having to do very much incremental engineering or, or, or incremental production work? It'll never be zero and you'll always be diverting resources a little bit, but the earlier that you can get to some sort of revenue, I, I believe that's, that's better.

Chris Reichhelm: 0:31

Welcome to the Lab to Market Leadership podcast. Too many advanced science and engineering companies fail to deliver their innovations from the lab to the market. We are on a mission to change that. My name is Chris Reichhelm and I'm the founder and CEO of Deep Tech leaders. Each week we speak with some of the world's leading entrepreneurs, investors, corporates, and policy makers about what it takes to succeed on the lab to market journey. Join us. I've been reflecting on lab to market journeys for the last 14 years, and I've been doing that in the context of my role as an executive recruiter. I've been a recruiter for much longer, for, uh, over 30 years. And, uh, focused on startups and spinouts for the last 25 years, always focused on advanced science and engineering. And the reason for reflecting on the lab to market journey is so that I can develop a keener sense of the skills, experience, and talents that are required at each stage of that journey so that companies generate and develop the right profiles so that they have a better chance of hiring the right people and they have a better chance of accomplishing their goals. One of the ways we learn about what works in the lab to market journey is by studying companies that's not unusual. And generally we focus on, if I look at most of the deep tech companies, we get to study, they're generally in between TRL four or five. TL seven. And I would venture to say that most of the deep tech companies that are out there today sit between that between early pilots or early prototypes and advanced pilots. And then you see a sharp cutaway when you get to commercial grade first of a TL eight, and you see a sharper fall away still when you get to market ready products and uh, and true TL nine. And then advanced, advanced settings in manufacturing readiness levels, commercial readiness levels and so on. And remember, our goal in the deep tech industry, if you're trying to build up deep tech companies, our goal is to create companies that become active value chain participants supplying other companies. So this means that there is a dearth of active. Mature deep tech companies in the market today. DeepMind? Yes. Uh, SpaceX, C Brass, uh, Nvidia. Uh, but you know, beyond that, maybe Tesla. Beyond that, there aren't that many. So we have to learn from the failures. And there are two companies in Europe that I'm gonna be talking about today. Uh, one of which is Lilium, the electric vehicle, takeoff and landing company, aerospace Company, uh, from Germany. And the other one is arrival. And both of these companies when they set out were actually super exciting. Um, they, they, they had bold missions. They employed thousands of people. They, uh, raised lots of money. Uh, I think arrival, I think Lilium raised over a billion, maybe a billion and a half. Arrival was, was around a billion, I think, uh, they both listed on nasdaq, or, oh, they both, uh, reversed into a spac. So it was, uh, SPAC listings. Um, and uh, and, uh, and they both achieved unicorn status. So these were super exciting companies. And over the last two years, both have gone into insolvency. And so what can we learn from the failures? What can we learn from arrival in Millennium because these companies actually got pretty far helping me understand this. Today is James Arnold. James is, uh, an executive I've had the pleasure of knowing for, uh, a little while now. Um, and he served in senior strategy, operational and engineering roles within both companies. And so I am, I'm, uh, I'm delighted to be able to talk to James today and understand what actually happened within those organizations, how far they really got what we should be learning from those. Uh, if you're interested in the space, if you're committed to, to, to all of us doing better on the lab to market journey, you've gotta watch this. Let's get into it. James Arnold, thank you so much for joining me.

James Arnold: 5:36

Pleasure. Good to be here.

Chris Reichhelm: 5:38

It's, um, we're in August, 2025, and you've worked for two of, in my view, Europe's more exciting deep tech companies because I think these companies really embody the spirit of deep tech as, uh, as, as so many, uh, see it. They were tackling bold, big challenges. Mm-hmm. Bold visions, Lilium and Arrival. Um, we're gonna kind of dive deep into the whys and where fors and what's and so on, but as you kind of stand back from your experience in these companies, what are some of the headline impressions or observations that you have from your time there?

James Arnold: 6:38

So, you know, as, as you say, they're both very exciting European companies, right? Tackling important problems, raising lots of money, hiring lots of amazing people. I think one thing that is consistent, and I think we're going to talk more about this, is that they both grew quite big, quite quickly after raising, you know, various different funding rounds, even from quite early stage. And I think there's something interesting to, to talk about there. Of course, there's nothing wrong with, with growing, right? But, but there's some, something consistent that I think is, I think is interesting in, in the one case arrival. There's also something to talk about around, around focus and knowing what product it is that you're really developing. And, and there are some aspects around product requirements and so, which I've just been thinking about, which are related to, to Lilium as well. So I think there's a few common, there are a few common threads in each, in each case.

Chris Reichhelm: 7:52

Yeah. I find, I find the comments on, um, uh, on growth. Interesting. You know, growth is okay, growth is good. We need growth. Growth is good. I'm not gonna get far without growth. But I think when we, in the venture world in particular, and so much of the venture world. As you and I have discussed before, has been defined by its experience with software in SaaS and the dynamics of that industry, which are very, very different, are totally different from the dynamics in deep tech. But nevertheless, we kind of superimposed the playbook. We tend to superimposed that playbook over deep tech and that, and then assume, but with certain caveats that we're gonna see a, a similar, similar outcome. Yeah. Kind of model. And so the kind of, to quote Reid Hoffman's book The Blitzscaling and the Go for Growth at all costs, and raise as much as you can and hire like hell, even if you don't know where you're di, even if you don't know where you are, directionally where you're going. If you know, even if you're not sure product market fit, even if you don't know what that early application's gonna be or what that first product, or even if you don't have all the answers figured out, it doesn't matter. Just grow. And it, it makes, you know, and maybe you can make allowances for that in software. I don't know enough about the industry. You know, maybe you can, but in these industries, I just don't know that that's true.

James Arnold: 9:20

No, I, I I don't think it is true. I, I think it's super risky and there, there are all sorts of things that happen when you start to grow your company beyond a certain size, right? And many of those things are negative or at least they're difficult to, to manage. Uh, I was, um, it's interesting you, you mentioned Reid Hoffman. I, I came across Paul Graham has these bunch of essays that he, he wrote about things and one of them is called What Makes Startups Fail. And one of the items in there is actually growth in terms of team, team growth. And one comment in there stood out for me. He says, when you, when you grow your team, your startup moves to the suburbs and has kids. Uh, which I, I thought was quite funny as a, as a kind of observation about what happens. Um, yeah,

Chris Reichhelm: 10:16

that's so funny.

James Arnold: 10:17

You know, I, I I think obviously what he's getting at is it's not really a startup anymore, right. It, it, it, it, it's, it's no longer agile. It has, it has certain risks maybe that it didn't have before. And, um, definitely there are pressures. People can put pressures on an organization to grow for the sake of it. I, I do believe that, that this is something that some investors believe. This is something that you'll, you'll hear from, from some people that just growing the team to a certain extent adds value on its own, right? Yeah. And it may be, it does in the sense that it makes other people perceive the organization as a big and successful organization. I think maybe it does in the sense that in theory it gives you this capability that you talk about. Right? Okay, maybe we got the product wrong, but it doesn't matter because we've got a thousand engineers. So if we have to do a, a car instead of a plane, we can, you know, in theory we can do that. Um, and, and, and I think, of course there's value in hiring a great team, right? But also Sure. It's, it's, it's not quite as, it's not quite as simple as that, obviously, in terms

Chris Reichhelm: 11:39

it's not as simple as a map. How did, let's, let's talk about you a little bit. How did you kind of find your way into this industry or these industries? Where did you know, where did all of this start for you?

James Arnold: 11:52

Hmm. So, you know, as, as, as you know, I, I've been an engineer kind of my whole career, and I, I spent a long while in, in consultancy, but at some point I. Wanted to work less with big companies and more with small ones. Let's put it like that. I I and, and,

Chris Reichhelm: 12:13

and just so we're clear, sorry to interrupt, but just so we're clear, you, you know, some of those big consultancies were McKinsey?

James Arnold: 12:19

Yeah, so I worked in McKinsey for seven, a little bit over seven, seven years. And al always on product development, engineering, manufacturing, operational topics and across many different industries. But obviously McKinsey's clients tend to be FTSE100 or equivalent type companies. And these companies have their own, you know, uh, pros and cons and sorts of, uh, structures and cultures that are somewhat different to the, to the startup world. And just, just personally, I, I find smaller companies or earliest stage companies a little bit more. More interesting. And, and so, you know, when I, when I decided to step away from McKinsey, I, I went in, in that sort of direction seeking out some, you know, opportunities to work with, with, with smaller companies. And I was lucky enough to come across, across Lilium and, and, and meet the, the founders there through it, through one of our mutual friends, and, um, was very excited by what they were doing. And, and indeed is, was a very interesting engineering solution to a very important problem and, and, and question. So I, I, I wasn't necessarily seeking aerospace or even seeking these kind of deep tech companies, but more ways to build on the operational and engineering background that I had. But with smaller and more dynamic, more sort of exciting companies. Okay. So you have, and just for the benefit of our viewers and listeners, you've got a mechanical engineering degree from Imperial. Uh, you then, uh, over time you join up with McKinsey. The kinds of work you're doing there in product development, is it mostly of the mechanical engineering variety? Is it product development as it relates to mechanical engineering domains? Or is it, is it, is it broader than that? Yeah, it's, it's, it's a good question. So, so I, I actually started my career at, at Dyson after I graduated. I went for two and a half years or so to, to Dyson. And I, because I love engineering, I still fundamentally, I'm a bit of an engineering geek, right? And I always enjoyed that. So I started out that way, but I did want to kind of broaden my experience and that was the reason for moving into, into consulting. At that time, so we're talking about sort of 2008, McKinsey was the really, one of the only big sort of business consultancies or cross-functional consultancies that really looked like they did proper operational work on real manufacturing or engineering topics in a, in a serious way. Not, not just the strategy, but actually the sort of hands-on tactical stuff as well and turned out to be true then indeed they did and do still work on that stuff and, you know, that was what I focused on. So always, you know, in, in, when it comes to engineering actually being hands-on with products, thinking about topics like design to value, design for manufacturing, design to cost, uh, thinking about engineering transformations, so how to make the engineering function work. Better. And then, you know, through into manufacturing. So big lean transformations of manufacturing or, or production of supply chain functions. And, and I, you know, I, I worked on these kind of topics across so many different industries. I've, I've done, um, you know, everything from, from packaging food and food packaging through to power stations and aircraft, right? And, and everything in between, over that, over that period. So very, very broad. Can McKinsey, can that kind of background be useful in storms, do you think? Yes, definitely. There are certain, you know, there's, there's two ways, right? There's two, two things. I, I think McKinsey and any of these consultancies, they do give you certain tools around structured thinking, problem solving. Day-to-day team leadership and these kind of topics, which are obviously helpful in any, I think any environment. The other thing is that it gives you a good picture of how different organizations work, what good looks like, what bad looks like, um, and, and some sort of very wide set of reference points of different ways that things might be done. And I, and I think you can, you can always take something from, from, from many of those and from the individuals that you work with as well. It gives you a very fast, very broad exposure to a lot of different companies and, and, and leaders. And, and so this is, I think, very, very helpful to take as a set of reference points into a startup. Yes. You know, they get, I think the strategy consulting firms, McKinsey being the bellwether for that industry. Uh, you know, they're having a, well, they're having a moment right now that, uh, especially in the, you know, in the age of ai. I think for some time there have been questions as to how valuable that kind of background is to the startup community, uh, with some being violently opposed to individuals or to skills from that background and those feeling quite the opposite. And, um, so it's, uh, it, it's, it's interesting to, it's interesting to hear your view, it sounds like, and my gut feel on it has always been that there is such a place, there is a place they're gonna expose you to amazing talent. They're gonna expose you to best practice in some areas, not all of which you're gonna be immediately relevant, right? But there's an exposure to quality, to an expansion of thinking to different analytical tools to pace. The importance of pace, because McKenzie is an organiz organization, as I understand it, with pace. Yeah. PACE is so important in these, or in these organizations, pace and quality and precision and all of that dealing at you, dealing with pressure. I think McKinsey is, uh, you know, those kinds of environments, uh, have those qualities and if you're trying to create that kind of culture, if you want to create that kind of organization based on similar qualities or with similar features, it can be very helpful. I'm, I imagine, yeah, I think that's, I think that's true actually. You, you know, you do, and you, you, you, you have to work at pace in, in these, in these consulting engagements and to be able to do quite fast iterations of getting information, analyzing it in some way, producing some kind of output to explain it, and then, uh, working with a team to take a decision. That that sort of loop, that that loop, you need that in every business, right? Yeah. And that, that, that's just a sort of fundamental mechanism of day-to-day work in a sense. And it's, you need to be able to do that quickly in, in a startup in the same way so that, that, that habit, let's call it a habit, I, I think is, is good. Yeah. So you get to Lilium, you meet the founders, where are they in their development and their thinking and I guess their ambition when you go and meet with them? Yeah, so, so Lilium was at a really interesting stage when I, I joined. So, so they were in a kind of shared working. Space, I think it was their first kind of proper office, let's say, with a workshop area attached. Pretty small, pretty grag style set up. Very, you know, very startupy from that, from that point of view, maybe about 30 people, I think almost all in engineering with a handful of people on the, you know, on the other business functions and, and production and and so on. But they had just raised the first significant sum of money and it was at that point where it was time to accelerate everything basically. So it is ever a very, very exciting time. And you know, they were just in the process of hiring the first few external senior leaders. So up until that point, the founder's been running everything. And they actually continued to do so in certain teams for a little while. But that was the point when the first, you know, sort of chief commercial officer, senior production people, senior program people and so on, started to come on, on board and take over certain, you know, certain functions and certain areas. And in terms of, in terms of their development, where were they by this point? So they had the very first working prototype. Oh, not the, no, that's probably wrong to say. Not the very first. They had a fairly large, fairly sophisticated early prototype, let's say, all off the shelf parts, lots of 3D printing again, bit garage style. Handful of people had built it, you know, in this little workshop. And they were in the process of engineering and then getting ready to build a much more serious, pretty much full scale composite, uh, version prototype with a lot of in-house design and developed systems in it. So really a transition from the kind of thing that, you know, you can knock up pretty quick with a handful of people and, you know, doesn't necessarily teach you much about the problem you're facing to a quite serious prototype. You know, I'd say TRL five or six perhaps, depending how you want to consider it. Mm-hmm. Made in complex materials with suppliers getting involved and adding a lot of complexity to the whole production and supply chain system as well. Yeah. What was the. As I look at Lilium, they had a number of innovations going on. They had, uh, but I think it would be better if you kind of explain for everyone where you felt the innovation actually was. They had this, obviously there vertical takeoff and landing piece. They were also thinking of an innovation around the, uh, around the air taxi. Um, and, uh, you know, they weren't the only ones thinking of that, but air taxis were becoming a thing. Were starting to become a thing. Right, right. Um, you know, so was where did they see the innovation? Was it the air taxi? Was it, uh, you know, the engine design and the lift and all of that? Was it, was it something else? Yeah, I think it's on the engineering side, right? I mean, o obviously at that point in time, they were still one of the first people saying, okay, we believe that there's a market. For this. So, you know, now, now it's different, right? There's a lot of people following that, but they, they were definitely one of the pioneers for the business model, but really it was on the, on the engineering side and the whole aircraft architecture and the use of these relatively small ducted fans in a relatively high number. That's a very novel solution to the general problem of building a transition aircraft. Right. And it's a very, in many ways it's a, it's a very elegant solution that has bunch of advantages. So, so, and it's quite different to what anybody else was, was doing, you know, later on, at, at my subsequent companies, I, I looked, you know, across the industry a lot as part of the strategic part of my role and. We found that, you know, some of those decisions were very unusual and there weren't a lot of, uh, precedents for, you know, for example using a large number of small ducted fans as some kind of array or, or arrangement. There's some, some studies, a lot of them done a long time ago, you know, and so they were really doing some quite novel, you know, almost science, stroke, early stage engineering research, you know, as they were going through that, that phase. So, um, what kind of, you know, generally for any, any deep tech company with a novel platform, they've got to do a minimum amount in order to attract, well, they've gotta do a certain amount in order to attract the interest from industry, a certain amount of investment. Where was that line for Lilium? What was that kind of minimum amount that would've represented a stretch, but for which on the back of that milestone, they would've been able to start getting serious attention from the broader industry and, I don't know, maybe regulators and maybe, uh, partners and investors. Yeah, so, so I, I think really that the, it it, they had to have done enough to show that this architecture had some chance of being viable. Right. And at that point, I wouldn't say, you know, that perhaps, except on paper to some extent, they proved that it had the advantages that they wanted it to have, but they were at least able to make that argument to investors, to potential customers, and they were able to show their previous smaller prototypes that they'd built to say, look, okay. Know, this might not be fully comparable to what we want in the long term, but at least it proves we're not crazy. Right. I think you, you kind of have to prove that you're not crazy. I think that that's the first, the first step and uh, I've come to feel more and more that quite important to think about why you are building the prototype that you are building. So are you doing it because you are solving some engineering problem or exploring some engineering problem and you want to have a, a reference point, excuse me, or something that you can test? Or are you actually building something because you want to show something representative or sexy to investors or potential customers and. Very often they're not the same thing, uh, unfortunately. Um, and the, the greater to the extent to which you can make them the same thing, the better, obviously, so that you're not wasting engineering time doing fancy things that don't teach you anything and or you're not doing. And I think, maybe I'm wrong, probably more people fall. Well, actually, I'm gonna comment further on this. So I was going to say that I think more people fall into the trap of just doing science and not doing enough to demonstrate that they're not crazy from a business perspective. And you do hear this anecdotally a lot, right? You hear investors on LinkedIn complaining that they talk to a engineering or science-based founder, and they spent an hour talking about why their, you know, engineering is so amazing and they didn't learn anything about what it's for. Um, and it's very interesting, of course, to spend and important to spend time on, on, on that stuff. And from an engineering development point of view, you have to do that, but it's not necessarily the right prototype or thing to put in front of, uh, uh, you know, these external, external parties. And, you know, the, the, the other direction is, is of course, that you just build things that are effectively mockups of your final product. In, in aerospace, good example is building a scale model, right? So you build something that looks exactly like your wonderful renderings, but it's only a meter and a half wide instead of 15 meters wide. And this looks great actually. Investors love this. Customers you can fly around, but the problem not just in, in aerospace, but in, in, in many sort of. Aspects of engineering is that the problems don't scale in that way. So you are very unlikely to learn much about building a 15 meter wingspan aircraft with the real battery systems and so on by building a, a 1.5 meter remote control aircraft and, and flying it around. There's a few things you can learn, but, but, but a lot of the stuff, it just doesn't scale, so you just don't learn anything. That's, that's very interesting. So why is that, that's, is that just a function of, of, uh, of the dynamics of air hitting the wings or of the whole, you know, the whole vehicle in operation? Why doesn't, because in other areas when it comes to scaling up, that's true. You can, you know, of course it's always the trouble with scale up that the larger scales you get to. The more demand it's going to make on the system itself. And then you can have material falling up, you know, not working. Um, you can have performance start to go awry. That's why you scale up so that you can learn about that. So it's not unusual for scale ups to not perform, but it is usual for there to be an expectation that a smaller prototype is going to be a, a representation of some kind of a larger one. Yes, yes. There, there, there is. And, and, and it creates risk on both sides, right? If you're a customer or an investor and you see a scale model, you might think that more progress has been made than it, than it really has and vice versa. You might actually think that in, you might think that internally, although I think engineers and physicists are probably less prone to, to thinking that than some other people are. I think there's a bunch of reasons, right? Some things are just basic physics reasons to do with fluid dynamics, to do with heat transfer. Um, some are more related to, uh, just things which have certain physical scaling properties, like, and I mean parts, right? Like batteries for example. You know, battery cells only come in a finite range of sizes and physical arrangements. So it, it, it doesn't mean at all that that, that they, the way they behave or the way you can join them together or the way you can thermally manage them, it doesn't mean at all that it scales from, from one size to another. And, and then there's all kinds of other odd things that are important to, to think about, like supply chain related things, right? So, you know, in a lot of electric machines, power electronics, for example. Cost is highly non-linear with power, in fact. So, you know, if you think you are, you're just going to get a, you know, as you, you start with something this big and it's off the shelf, and then I'm gonna build my own one that's 10 times the size and 10 times the power, and it's gonna cost linearly the same. That's wrong, right? So there, there are things which are maybe to do with the supply chain. There are things which to do with regulation as well. Uh, either, you know, the things that you may learn from a scale model that have related to regulatory requirements. They, they may just not be applicable or, you know, when you discuss it with regulators, they may not accept that. Exploring it in that way is valid. So you have to be extremely careful on that side as, as well. How, how far did Lilium get? So this is an interesting and partly debated topic. So, so, um, for me, Lilium built and transitioned and in this industry, transition flight means moving from vertical takeoff at landing mode to cruise flight mode. And that's the key sort of engineering deliverable in, in some sense is conducting that, that transition, they built a close enough to full scale, uh, prototype, which was able to perform this and, and able to fly around. Right? And that's a huge engineering, uh, achievement, especially when almost everything is designed and built in-house and you have this very novel architecture. Um. The, the, interestingly, there is some argument as to whether that was a full scale model or not, and that's partly to do with the fact that Lilium actually changed the final product definition during that period from a four seat aircraft to a six seat aircraft and very wisely. I've subsequently looked into that question at arrival and SkyBridge and my personal belief is six seats is much better. So very sensible, uh, thing to do. But that also ended up meaning that their prototype was no longer full scale or matched exactly to, uh, you know, what they were selling to, to the world and to customers. And I suspect that that on its own caused a bit of a problem actually in, in terms of the perception of how much progress they'd make. Because people could look at that and say, well, if. You're showing me this thing flying, but it doesn't look like you're rendering anymore. So, you know, how can I be sure that you're actually as far along that development journey as you claim to be? And you know, some of that happened after I left, so I couldn't comment to the, you know, where they really got to at the end of that. But it's, I think it probably caused unnecessary confusion in the, you know, in the wider world. But that's a, you know, that's, it's easy to understand that happening. You can, you can appreciate how that would happen because as you scale, as you develop your platform further, changes are going to creep into the, to the design. You're gonna learn new things. Of course we talk about mission creep and design creep over time and we wanna kind of avoid it, but equally we can't, especially with novel technology and novel platforms, you can't always see what the end is gonna look like. Uh, so yeah, there's that. I can appreciate it from their perspective that we thought it was gonna be this, it's actually better with this. We don't have a prototype now, but we're actually making progress. This is part of the journey. This is part of that journey for sure, for sure. But this is, you know, this is part of that journey. And I guess the, when I look at other lab to market journeys, which are as expensive and which are where you have the weight of expectations from so many different stakeholders, investors and partners, you know, I know Lilium was signing from some fairly chunky deals. Too at the end, they were signing some big deals for aircraft. And so you've got, you've got this growing sense of expectation, you've gotta deliver on this. Yep. And yet you've also gotta make the allowance for, hey, we're still learning as we develop this. Yep. So I think it puts that, as I reflect on that, it puts pressure on that CEO or on that management team and the board, I guess, to be communicating all the time. We're, we're still learning here, we're still trying to get this, we are making progress, but it doesn't look like that anymore. And, but we're, we're, you know, we're, at least we're signing deals and Yeah. You know, we're keeping confidence. But then, so it's about, you know, I guess what I'm trying to say is, I'm trying to kind of wrap in this, you've gotta keep that trust with that community that you've built with these different stakeholders. You've gotta keep that. And within a, a, a domain area like aerospace, I imagine that so. That's so challenging because everything a, everything in aerospace has gotta be done to the nth degree and for good reason and, and, and for good reason in, in a certain way according to certain rules, even, even process wise. Right. And that's of course, reassuring when you go on holiday. So it has to be like that. But I, I think that, yeah, it is very interesting because it, in a sense, that was a kind of mini pivot, right? It, it was a, it was a sort of change, quite a big change in the, in the product. And they would've had to start a lot of things from scratch on that, on that new aircraft from on the six seat, one from an engineering point of view. But they would've had a lot of very. Valuable and valid learnings from, from the other prototypes. So it's by no means going back to the, the drawing board and it's absolutely the, the right thing to do. As you were kind of alluding to at the beginning. The cost of doing that in terms of program, timeline, line, opportunity costs, you know, financial cost of prototype building and so on is huge in a, in a deep tech, in a physical product company, right? You can do that pivot pretty much for free in software, but it's obviously not the same when you're, when you're building something. So it does create risk and I I, I'm sure there were many discussions about whether or not to bin the smaller prototypes and to try to build, uh, something quickly. Representative of the six seat version. Yeah, yeah, yeah, yeah. Yeah. That's interesting. You know, it's, um. That communication piece we, you know, we talk about a lot and it's kind of a truism, communication is one of the most important features of good quality leadership. But if you've got young founders who haven't been trained before or who are just not mature enough or not experienced enough, and I don't know what kind of communicators these guys were. Maybe they were great communicators, maybe they were amazing at all of this. But you see really experienced executives, mature executives who've been around and who've got a reasonable level of emotional intelligence. Um, you see them struggle with this kind of thing, uh, you know, in all kinds of industries. But here it's just, it's so important. Again, it's not just the fact that you're the innovator and you can Elon Muskett and go through walls and everyone's gonna listen to you and, and, and drop what they're doing and do, as you say. You're not gonna get industries to wrap around you. Uh, you know, even Elon can't do that. So, uh, so you've got to, you've got to, I think, bear that in mind for young founders and CEOs who are thinking about growing their deep tech teams and companies and innovations, thinking about how they're gonna keep it all together. I think building that line of communication, that trust is so critical. And I think something I've learned subsequently, and I wasn't as close, you know, Lilium, I wasn't involved in sort of investor discussions and so on, but, but subsequently, I, I have been, and I think it's very helpful to discuss explicitly what it is that people want to see or understand customers as well. Right? What, what is it for them that means progress actually? What is it that, you know, after you've explained. Engineering or regulatory journey that you are on, and you've said, okay, here are the things that I think we should care about and these are the KPIs and goals that I have. You need to hear what, what they think, because, you know, because of their background or their own understanding or their goals, they might want something completely different. Yeah. And that doesn't make it wrong. They're just using different senses almost to, to, to, to make their judgements about, about where you are and whether you are succeeding or, or not. And, and so I think that's a very valuable kind of conversation to have. Of course, you can't give, you know, if you have. 10 investors and 10 potential customers, and everybody wants 10 different things. You know, you can't, you can't give people a thousand different pieces of information about the company every month. Right. That's just not practical, but, but, but there's some sort of balance there. Yeah. How was it at Arrival? Tell me a little bit about when you joined, where was the company? Yeah, so, so arrival was very interesting. So, so I joined Arrival to work on a, a sort of secret stealth mode aerospace project within the group company, right. I worked a little bit in the central strategy team across automotive sides as well, and, and then laterally almost all on this, on this aerospace topic. So some things were still very small and very. So the, the group company that I joined had maybe 12 people at that time. Um, very early stage engineering development. Um, you know, the, the teams working on the van and the bus that arrival had were, you know, maybe between 10, 15 to sort of 40, 50 people at that time. Again, still, you know, not that big arrival as a whole had already grown quite big because there were lots of things going on within that, within that company. Lots of amazing technology development and very interesting things. But, but here we are gonna come to that, that question about, about focus. So in, in terms of the products, and the first product that Arrival had sold really to a customer was the van, right? The electric van. That was at a pretty early stage, right? There was some early stage. Working prototypes, some, you know, sort of skateboards that drove around on their own and some mockups of the cabin and this kind of, this kind of stage. So pretty, pretty early. And, and just to be clear and for the benefit of our viewers and listeners, it arrival was about electric vehicles and in particular vans, uh, uh, and different types of, of delivery vans as I understand it. And then it was also about obviously the secret stealth thing that you were working on in aerospace. And, and this was a, a very cool innovation. I remember thinking about at the time the concept of a microfactory. Yes. And so this is a whole vari, we could probably have a whole other hour on the concept of the microfactory, um, the, the, so yeah. Arrival had this sort of, was a. Commercial electric vehicle company at Core, right. The bus and the van were the first products, part of the concept was to be extremely vertically integrated, so to do, you know, down to very low level of engineering de development, in-house software, battery systems, motors, gearbox, composite materials, you know, almost everything Arrival was trying to do in house. And, and Lilium was as well, to be fair. So, so, uh, a lot of innovation going on at that system level too. And then this whole idea of the, the microfactory and, and, you know, I'll say something quickly about that, maybe to set the, the context, as I say, it's a pretty big topic. The, the, the idea was to make modular, highly automated manufacturing. Cells, a combination of cells that could produce, uh, the majority of the vehicle in an automated way and to scale up by replicating these cells. And, and this is actually, so it's completely the opposite of the gigafactory right's. Completely the opposite of the sort of Musk vision. The reason that it's very interesting, especially in these kind of companies and, and we, you know, my current company, we've been taking this forward and I, I do believe it's a good strategy when you don't know how fast your industry is going to scale up. It's, it's a very bad idea to spend a billion dollars on a factory, which builds your whole future volume in one year. Right? This is just a, a recipe for wasting tons of money. It's a, it's a much better idea to try to build something that can build maybe. 10 units a year or 20 units a year, and to be able to scale that up as the demand grows, right? So this is a sort of basic idea, and I think there's something very, very smart and sensible in that. Um, I think the risk and part of what happened in Arrivals case was it was also extremely ambitious in terms of automation and engineering development for the manufacturing itself. And that's not necessarily wrong, but it does absorb a lot of resource and it makes it quite slow and challenging to ramp up production. So it comes with, it comes with trade offs. Yeah. Because you are trying to innovate the way you're producing these vehicles at the same time as deciding, I'm just trying to, as, as you're trying to make a vehicle. Yeah. So it's one thing to, you know, and that's the problem with these, you know, you know, you know, well that's the challenge, I should say with the vertical, uh, integration. Yeah. Right. Um. They were also involved in a lot of activities. They were doing a lot. And I remember that at the time you were always, it was inspiring to read about, but it did make you wonder, these are big innovations they're trying to get to market here. Uh, how many of these can they realize? Can they do it all at once? You know, if you look at Elon for sure, he did the production line, he did his kind of, you know, gigafactory and so on, but then he focused on that first car, right? And that was it. It was one car and this production line. And, um, and, and I think that that's, that's very important, right? I, I think, you know, having all of these different activities and these different ambitious products and things being developed, technologies. It was doing lots of good things, right? It was building a huge IP base. It was building a big potential advantage for the future in lots of different areas. It was also making it a really cool and exciting place to work. Right? And that's not a negligible consideration. But on the other hand, as you say, I, I think it was probably quite distracting from delivering the vehicle that had been sold. And that creates, you know, that, that, that creates a, a huge risk, right? Interestingly, I, I, it's only occurred to me the other day, but when I, when I joined Dyson, so my first job, it was 20 years or so ago, Dyson had in early stage r and d, pretty much an entire portfolio of household goods. At that point in time, they had only the vacuum cleaner and the washing machine on the market. I dunno if you remember the, the, the contra rotating washing machine. Very fascinating. And, and, and cool product didn't last that long, but very interesting. But the sort of strategy seemed to be, to develop the whole lot. Tumble, dryer, dishwasher, kettle, you know, ceiling fan, rice cooker. You know, there were all kinds of mad stuff going on in, in, in RD and just launched 'em all to market at once because I, I, I, I don't know because I, you know, it's my first job, right? I wasn't involved in those decisions, but I, I, I guess the strategy might have been, well, okay, Bosch or whoever, that they're gonna copy whatever we do. If we only launch one product at a time, they'll just copy that one product quite fast and they'll steal away, you know, the market share that we've developed, if we launch the whole suite in one go, even a huge company won't be able to replicate all of that in any quick timeframe. So it's gonna capture a whole, a whole bigger market for us. Um, so there was all this crazy stuff going on and I was working on some of these things. It was very, very interesting and, and many of those things died out before they got anywhere. And I do think this was something that Dyson was exceptional and I it seems to still be very good at, from the outside is, is, is killing stuff when a relatively small amount of resource has been put into it. Um, and I, and I think that's, that's so important, knowing when to stop a particular activity. When to kill a particular avenue of experimentation is one of the most important decision making processes and skills that an organization can have. A deep tech organization and it's not just at the whole product level, right? It's within, within a single product as well. It's like, okay, we've got two options for this engineering decision. Let's quickly build a prototype of both, do some testing, we'll find out which one works fine maybe, but, but know when to stop pursuing one of those avenues and just focus on the one. Is that, is that something taught in engineering management? Did you see that at work at McKinsey where you would've gotten to see this and affect, um, you know, lots of different engineering organizations, I'm assuming, and is that considered a part of best practice? Yeah, I would say it is considered a part of best practice and there are, you know, lots of different frameworks and so on that people use to, to look at these kind of things. I think it's one, it's one of those areas where having that knowledge or even that framework or process is only a small part of the battle. I, I think the thing is, and everybody kind of knows this, you know, as an engineer or a product developer or a business owner, CEO, you grow attached to your ideas, right? And as a curious person, you also grow attached to the process of learning something and experimenting with it. So if it feels like something is not, maybe it's not exactly what you wanted, but these two pathways are still quite interesting. It's, it's kind of tempting just to have people still working on both, right? Or, or you know, it's kind of tempting to think, okay, well there's something in this. Let's, you know, spin off this little other idea and maybe we'll develop that for a future project line or, or, or something like this. And it's just very hard not to do that. And I don't, I don't think it's wrong to do that. I just think to have, I think the best thing to do is that somehow the easiest thing to do is not over to think, overthink it, but just to make sure you have some kind of mechanism for checking what are we actually spending time developing? Where is the resource deployed across the whole organization. Usually we're talking about engineering resource of some kind at, at these early stage companies. And let's sense. Check that once a month or once a quarter at a high level, whatever, you know, whatever works. Just look at that and openly discuss it. Does, does it make sense that we've still got three people spending two days a week on, you know, some side avenue of experimentation that we were using six months ago, or we've still got 25 engineers working on their vertical integration, you know, the in-house version of a motor or something like this. Does it still make sense? Yeah.'cause they, it's, it's about reducing the cost of your, of changing your decision. Right? And that the sooner you detect that you might be spending resource somewhere that's not valuable. The, the, the better it is. You need to learn as soon as you can that you've maybe done something wrong and then you can redirect the resources. Do I wonder if there's a, this feels to me. A lot like a leadership issue in that. Leadership always has to be doing this. They always have to be asking themselves the question of, you said it earlier, what are we focused on? What are we trying to do here? What is our goal? Mm-hmm. We can't be doing everything. So what are the few things we can be doing right now that are gonna get us to our goal? Everything that falls outside of that we leave for now, or we put on ice, or we Yeah. Or uh, or you know, or we spin out and Yeah, whatever. But it it, and I wonder, you know, these. Organizations, Lilium and Arrival, they both raised a lot of money. They had some smart people working there, really experienced managers and leaders, and lots of smart engineers and you know, people across different domains. Really smart people. So it's not a function of the lack of experience. It's not a function of of people the right backgrounds and skills. They've got 'em, no, but yet they all get together under this banner, under this umbrella where there's lots of resource and lots of different projects and, and it doesn't work. And I wonder, is it, is it something structural? Like when you raise so much money, you lose that sharpness. You're not, as you stop asking yourselves those important questions. With that sense of urgency lacing through it. I wonder if it's in a way that power corrupts, I wonder if too much capital raise doesn't corrupt, but it should, you know, it, it stops us being so sharp. It definitely create some kind of risk, right? You, you do, you do see evidence for this all the time and Yeah, I, I, I, I, I get that, right? It's, it's, maybe you do lose just, you know, it's not good to be constantly kind of on the breadline as a company either, because, you know, having a little bit of breathing space helps with other things, right? It helps with stress levels, it helps with, you know, not being distracted from, you know, for example, as an engineering leader, being distracted by worrying about whether I can afford. Have a certain prototype bill to, or whatever, that's not helpful. But it's also not helpful to not spend any mental energy on these kind of decisions because you think, oh, well it only costs a million quid to do that. And I'm not saying anybody really thinks like that, but maybe a tiny part of your brain does do that. Right. Oh, you know, it was only a couple of hundred grand to build that test rig. Let's do it anyway. That is also for sure not, not very healthy. So it's, it's, it's really, it's really hard. Right. It's, um, I'm, I'm sure there's no, I'm sure there's no right way to do it, but I think you're right. I think, you know, I think that's it. And, and, and so then the question is kind of where do you draw that line? Mm-hmm. Where do you draw that line? How much money is too much money? Or is it, does it come back to leadership again and does it come back to, I don't know if it's the CFO saying we're gonna, we've raised a lot of capital. We have a lot of capital, but we're gonna act like we're poor. We're gonna, so we're gonna eliminate the stress people have. So let's not make it stressy.'cause stressy is a bit shit and people feel, you know, for sure they can't relax and so on. So let's, you won't get good work in that environ, you're not gonna get, I agree, you don't get good work if people are stressy, but, so we're gonna remove that stressy feeling, but we're not gonna, you know, if you have to, you know, we're not also gonna say, oh, it's only a million quid. Forget it. Let's just do it. We're not gonna get to that point either. So, but that comes down to, I think, those values and that, that sense of, I guess that sense of, um, appreciation. If we let this get to our head, and you see this happening right now in an extraordinary way in ai, all the, how this is, I mean, AI is just the amounts they're raising. Oh. Um, you know, it's, um, it's, it's in the world. Um, but I think we have to be aware is that as humans and regardless of how experienced and how smart we are, we can forget very quickly. We can lose ourself in the moment. Completely true. Yeah. And, uh, even if we are surrounded by a bunch of colleagues who are super bright and experienced it, but you all bring us together and here's a, here's a whole basket of money go play. A lot of that discipline's gonna go out the window. And I think that's just a function of who we are. Yeah. I I think that's, I think that's definitely, definitely true, is just having, like anything that's. To a certain extent, human nature's about having that awareness that that is a problem and a risk, right? So that you do talk about it as a leadership team. And I also think, as you were talking there, I was thinking about responsibility for money and how do you realize that in the organization? Because I think having, doing things that make individuals at a relatively, uh, low organizational level, giving people genuine responsibility for managing the money that they are spending in some sense is really important with this, if everything just flows up to the CFO and the CEO. In some ways it might make you feel comfortable because like, oh, well, you know, every decision is gonna get signed off by this person, and therefore we're fine because that person won't waste any money. But the, the problem with that is that nobody else in the company feels any responsibility for managing the money. Right? So, so everybody just does whatever they want and, and hopes that if it's not sensible, it'll get stopped at the, or, or vice versa. Right? It's almost like a game. It's like, ah, let's see if we can, you know, let's see if we can buy this cool piece of equipment. And if she's not gonna notice, then it's all good. Right? Yeah. Then, then I think that certainly doesn't work. So I don't have an answer of course, but I, I think that. Trying to devolve responsibility to the, to the front line of whatever it is that's happening, engineering product. And this is always a good idea, right? But I think it's a, it's a, it's a good idea in, in terms of managing money as well, because then everybody is thinking about, okay, well, you know, maybe there's a different way to do this, or, you know, I shouldn't have hired that contractor to do that, or I don't actually need this tool, or, or whatever. And you take much smarter decisions closer to the action than you do as just managing all that stuff within. Yeah. What inevitably is a relatively small finance function, why, um, you were at arrival for much longer than Lilium, but what ultimately, in your view, what were the, what were the reasons it didn't work out? You know, I think j just, I, I feel that. Not enough of the resources and the money were focused on the product that had been sold. Actually, you, you have to get to revenue, right? This is the ultimate challenge of a, of a deep tech company getting to revenue before you run out of money, obviously. And this is the sort of value of death that many people fall into. And part of avoiding that is, is just making sure that every penny is spent on the thing that's going to return the pennies in the, in the, in the short period of time. And I, and I think this was, um, this was in the end the, the, the, the challenge. And I, and I think some, some something that I've thought about a lot during this journey. And because of arrival's level of vertical integration and. You know, we've been taking a, a similar approach in my, my current company laterally, is to think about what, is there something on the technology journey that you are on that you can monetize before your final product? Yeah. Without having to do very much incremental engineering or, or, or incremental production work. It'll never be zero and you'll always be diverting resources a little bit, but the earlier that you can get to some sort of revenue, I, I believe that's, that's better. I, if I were to try to build a company developing some kind of very large, complex product, I would be thinking a lot about that. Like, yeah. Can we, can we break that journey down into. Into steps whereby each of those steps can be something we can actually make money from. Yeah. We've talked about that a bit on this podcast we had, um, actually, and in one area, uh, where they really need it in the fusion area. So we had David King, who's the vice chair of Tomac Energy. They're building spherical, tomax cont mm-hmm. That contain plasma and create the conditions necessary for fusion. But fusion is such a moonshot deep tech domain. Uh, it's like quantum. And so it, it, it really applies in that area, whereas it's gonna be so long before we are generating revenue from generating electricity from fusion. Yeah. So what the heck can we do in the meantime to generate any kind of value? Yeah. So, and their answer was, we have to start, we have to act as a provider to the rest of the fusion industry. Whether that's I, so we have to get something. Uh, be it, uh, our superconductor, our high temperature superconducting magnets or advanced other advanced materials or other technology, we've gotta become a supplier to what will at some point be an industry. Hmm. Uh, and that is fusion. And so, uh, and so that's their answer to that. And I think there are lots of other examples, um, you know, along that journey, but I think it's a, I think it's a really good point. Um, I think especially for deep tech, I think that may be part of the journey They have to, you know, these companies have to think through, which is, okay, here's our big goal over here. That's 10 years away, right? What can we do in two years, three years, four years? That doesn't, won't deviate us too much from our plan, but that allows us to demonstrate progress, to generate some kind of revenue and to continue broadly and to be able to. To maintain the confidence of our stakeholders. So much of these, yeah, so much of the lab to market journey is about maintaining that confidence, maintaining the trust and confidence of all of your different stakeholders. You're gonna have a lot. Mm-hmm. But you've gotta keep doing it. And I think it's such a, you know, it's, it's a, it's a, it's a taxing job. It's a taxing job. Yeah. I, I, I think that's, that's, um, that, that's one of those, it's one of those kind of tricks that's quite, quite, quite difficult, isn't there? I think there's this topic there, there, there are some other interesting things that you can, you, you can do in terms of making revenue from a, from deep tech companies earlier on. Right. One of the things that we've done recently is, is basically sell spare prototype production capacity and. That's, it's, it's a little bit different because it's not like launching a product and it doesn't necessarily bring you a large and continuous revenue stream, but it does mean that you're not wasting sort of underutilized talent or physical space or production equipment and that you're getting some kind of revenue in. And, you know, something like that is also quite interesting because if you're in a prototype environment, one of the important things that you'll be thinking about obviously is how am I transitioning to series production and how am I thinking about things like, uh, quality, cost control, inventory control, all the things that matter when you're producing tens of thousands of units that are either easy or they don't matter that much when you're just building a prototype. The discipline of having a customer who's ordered something that has, you know, specific requirements and they're gonna pay you money for it. Producing that in your prototyping environment, I think is very good for the, for the production organization to experience as a, you know, part of the, the journey to sort of stabilize TI manufacturing. But you were delivering prototypes for them Yeah. For other people. Right, so, so, you know, the, the, in our case, we, we built up quite a lot of composite manufacturing capability. Some processes that are not easy to do and we're able to do stuff at high quality and there's lots of demand for that, right? There are, there are lots of people who will never build that kind of stuff up in house and they, they want a few composite parts for prototypes or, you know, small production runs and. And, and we were, you know, we were able to, to do some of that work for other people when we had the time. Yeah, I know. Uh, I have a client that I think has started out that way doing just that kind of thing. Mm-hmm. They're based in Oxford and actually they're one of the, I think, I think they started out, so I, I'll, I'll refrain from mentioning their name in the, in the event that they didn't, but I think in the very early days, that's how they got some early traction by doing that, and it did sharpen them. Mm. I think I, I think the danger that, I think the pit they potentially fell into, and this I is that it, if, if that becomes, uh, uh, a reasonable source of revenue for you, it may prevent you from really selecting your core application and product area because you're busy delivering on the service. So at some point a company has to choose what are we gonna make? Definitely what's our product to market as opposed to, so it's, it's always, so again, but it comes down to leadership at the end, which is, uh, we're heading in this direction. We'll do this for now, but only for now. Yeah, only for now. That's the thing, isn't it? I've, I've seen some companies, I think it can, if you, when you are very small and some kind of engineering startup, and you, you are, you know, maybe you're at seed stage and you're thinking about little bits of fundraising here and there. It can be very tempting to sell engineering as consultancy, right? Because if you've got a few people in your team. The team, a small engineering consultancy is actually quite a nice business. It can be very easily self-sustaining, make a little bit of profit. There's lots of demand for it. It's lovely. Right. Uh, so, you know, it can be quite, quite tempting. And I, I definitely have seen and know people who have, who have done that, started to sell that kind of work. But then you never develop the product that you've dreamed of. Right. You never pursue the, the vision of whatever it is that you're trying to bring into the world. So it's, it's, yeah, it's, that's right. Risky distraction. That's right. James. I've really enjoyed this. It's been, uh, it's, uh, me too. And I've, and I've really learned a lot. So thank you so much for joining. Pleasure. Very, very interesting topics and um, lots that could go on for even longer. Yeah, I know. I know. It's always the way. But thank you so much for contributing to this. My pleasure, Chris. My pleasure. You've been listening to the Lab to Market Leadership Podcast, brought to you by Deep Tech Leaders. This podcast has been produced by bowhouse. You can find out more about us on LinkedIn, Spotify, apple, or wherever you get your podcasts.