Chris Power: How Do We Massively Scale Our Manufacturing?

We're here in Torrance, California, in Hadrian's Factory 2. I suppose it's a headquarters as well. Yep. Uh, and I'm here with Chris Power, the CEO and founder of Hadrian, in this kind of small, kind of small little space, you know. Dear God, you guys have basically spun this up from nothing in like less than 2 years, right?

Yeah. Yeah. So we've been, the company is just under 3 years old now. We've been in this building for 13 months.

What was your kind of professional background before founding AJR? What led you to that?

I actually studied accounting and tax law.

Okay.

Which accounting is actually very useful for running a real business.

Turns out.

With not automated software, 70% gross margins. And then I started my career in e-commerce in Australia when there was the very early days of eBay, no Amazon. Helped a couple of founders grow a small but very fast-growing e-commerce business in Australia. Went to work for the largest e-commerce player in Australia doing a lot of software, digital e-commerce, and then ended up being the head of sales at a very technically focused startup that did workforce management software. And you can think about that. If you've got 5,000 employees, very heavy on industrial businesses. So scheduling, time, payroll, basically we would go into companies with massive workforces and help them load balance their facilities so that, you know, you're auto-scheduling facilities or security guards or retail stores to optimize for the customer outcome, sales or throughput. So that background is really important for getting very good at going into real-world companies that are operationally complex and figuring out where and where not to build software and what products really mean for the real world and how to stitch together data systems and people to actually make businesses run with software in the right way instead of building cool software that is great for software engineers, but doesn't necessarily create the real-world impact, which is a country mile from software works and someone buys it to actually creates business value in operationally complex environments. And that really led me to this overall thesis that the only way to automate the industrial base of America is to basically vertically integrate the automation company with the industrials company so that software engineers and people who can actually automate things are literally one foot away from the problem and you're owning your own risk and cost to build the correct automation solution versus building software that doesn't necessarily solve the real problem for the end industrial company.

I know a lot of people that have similar passions and ambitions towards starting an internet manufacturing base and all dream, I think, of either owning a factory, building factories, helping with that, and then either work on a specific technology or maybe software that'll aid that. You're like, no, you kind of need to do the whole thing from the get-go. Can you talk a little bit about either— I think that decision's clear why, but Talk about either, I don't know, was it the balls that it took to do it? And like, to be like, yeah, like, I'm gonna go raise the capital to do this. Was it, what kind of made you, like, what were the kind of tough decision points that you had to make to do that?

So I think the tough decision point was once I committed to this philosophy, everything is hard. It's like, what hard do you pick, right? And I never wanted to build a software company where I felt like I was going to work for a decade on something and it didn't really have the impact that I wanted. Like all companies are hard, basically, whether you're a small software company or a small manufacturer or a large software company or something like Tesla, everything is hard. And my view is whether we succeed or fail, I would rather spend all my energy and all my time on something that if it works is a generationally impactful company versus something that if it works, like, hey, it's a great software company. It's a great company in general, but maybe it doesn't have the impact that, you know, that's what I care about is what do I work on for the next decade or 2 that can have the biggest impact to the country and the thing that I care about. In terms of the balls, once you kind of understand that like the first 5 years of any company are kind of equally as hard and equally as complex and you get over this thing and you realize most of the problem is Can you find enough smart people who believe the same things you are to go solve these incredibly challenging problems? There's something that I learned from Sam Altman is that it's kind of easier to start a hard company than it is to start an easy company because most of it is, can you get the right people and the right skill sets with enough momentum to build this talent base that can generate the vision? And it's actually easy to do that with Something completely insane. And I'll give you like a recruiting example is software engineers are super smart these days. It's not 10 years ago. Like they all know what the value of their time is. They all know what the value of their equity is. And a lot of our early people, they'll say this, literally joined because it's like, this is so insane that we can see a path to like changing our lives versus, oh, we're making like a CAD software tool. It's like, yeah, it's equally as hard, equally as challenging. But it's like the grand vision of the thing and like how insane it is, is kind of part of the point in the first place, quite frankly. Yeah.

Speaking of, you know, building hard things, can you talk a little bit about the technology stack that your— that Adrian, it uses and maybe how it's different than other approaches to factory automation?

Yeah. So we try and learn from as much of the previous failures to build automated factories as possible. And categorically, there are a couple of key learnings. One is if you automate, let's say there's 6 basic processes that have scarce resources or they're expensive or they're unautomated, right? If you just start with one of those and you automate one of them, so you know, you drop the, you can think about it like a software API or some compute costs, right? There's like 6 transforms you need to do. One of them's super cheap, but the net result is the thing still sucks, right? The first thing is you have to do full-stack automation across the board at like roughly the same automation rate. And then it becomes obvious what to build. And basically you start with the meta factory. So we had to build our own ERP and manufacturing execution system, which starts from customers and ends with ships part, but is the workflow and process layer that runs through the whole factory as well as a lot of scheduling, and load balancing to do the complex coordination and shuffling. Then at each task node, right, which could be as simple as printing a shipping label, it could be as complicated as automating CAM programming, that drops onto a separate engineering team that is focused on kind of the API between those links and massively lowering the time cost while having that node in the factory be as error-prone as humanly possible. And the tech stack is different, right? If you're automating, you know, you don't need a machinist. There is a whole team of machining automation plus a robotics team that does that part of the stack. For our CAM programming automation, it's a mix of frontend engineers, backend engineers, computational geometry, a lot of like machine learning, a lot of like algorithms to parse data. So we really look at it as one big engineering team, but the engineering domains across each internal product at Hadrian are so different that we're really looking for people who can understand the problem in the factory and can run a team of 5 to 6 people themselves. But often on a single team, it's like, cool, you've got a guy that used to build workflow software and a computational geometry engineer and a robotics engineer or a machinist that learned how to write code. And we try and pod people together so this team can operate autonomously as their own separate startups within Hadrian versus this grand complicated— there isn't a backend engineering team or a frontend engineering team. We push it down into small SWAT teams as much as humanly possible, obviously with common design standards, common APIs, common shared services like infrastructure, computation of geometry, but really at the product and engineering management layer, you have to run them as separate nodes. Because otherwise the complexity of the coordination kills you. Like, that's kind of a core part of the stack.

Yeah. We're sitting here in the middle of this factory. There's machines here that are loud. Maybe like, I'll turn off the noise reduction for a second so you can hear that. And yet the engineering, the software engineering desks are right here.

Yep.

And while we were filming, you even mentioned like, you know, to build your guys' software, you don't just like figure it out and then hand those requirements to software engineers. You make them do it for a few weeks.

Yes.

Then you have to do it. Can you go, I know you were just talking about that. Can you go a little bit deeper on that and maybe even give like a specific example of like a recent way that's manifested?

So philosophically, the greatest companies in the world get their software engineers closest to the customer problem as humanly possible. And there are different ways of doing this. Rippling and Ramp have this great thing where engineers do the customer support tickets for as long as possible. Ramp does it with product managers, but it's the same thing of basically like, People lose context as they get further and further away from the customer. So a lot of the game is how can you push the people that can solve the problem, software engineers, manufacturing engineers, as close to the problem as humanly possible? And you have to forget that we're all just people, right? So it's like the conversations you have at lunch, who you're sitting next to at your desk is really what tricks your brain into like, is this a real problem? Is this the wrong problem? And because we're building so much simultaneously, one of the decisions we made was let engineers engineer and like, it generates a little bit more chaos than like a centrally coordinated product and engineering team. But what you get is localized nodes of incredibly smart people making their own decisions bounded by API contracts, of course. So they can't break the meta system. But the entire point is, yes, Firstly, for a cultural change, like as a user of our software doing very complicated manufacturing, how do you trust me to build the right software that I have to use to get my job done on a day-to-day basis and still ship parts to customers while using some great software, but the first version's always shitty? Working hand in hand next to you doing your job is a great way to build that trust between software engineers and people in manufacturing who'd maybe never worked with a software engineer before. And the second thing is you want to remove product management as much as possible so that the person writing the code has seen the whole picture. And the easiest way to do that is write code next, as close as humanly possible to the problem that you're trying to solve. We get as close to possible as the software engineer or the product manager can actually do the job. Sometimes it's not possible because some of these roles and what we do takes 5 to 10 years to learn. But yes, that's the whole thing is how can you push the people that can solve the problem to the context level that's as close to the metal as humanly possible and then let them rip.

Yeah. Sometimes I think you and I both, like, both in this hard tech world level, you're building it and I'm just kind of documenting it. But I think we hear a lot of rhetoric maybe about like, software's bad, stop building software, go build hardware, go build hardware, go build hardware. Obviously you're manifesting that too, but you also clearly have a lot of respect and interest building great software alongside that. How do you in your mind kind of balance, balance between, obviously, like you're engineering more, but mentally, when you look at other people who are building software, building hardware, both, how do you, how do you sort of judge, or like, what are some of your kind of core tenets in analyzing and making thoughts, having thoughts about those two different lanes?

So I think one of the automated factory tricks is knowing not what to build and what the real value of that is. And often the hardest engineering problems are the cheapest for a human to do. And we got a lot of clues from Tesla crew, like, you know, one of the things they learned is if you over-automate everything, you have to wind it back because the system's too brittle. The other thing we think about is you could spend hundreds of millions of dollars engineering the perfect factory. Maybe that actually doesn't make sense. We've got to grow. We're a commercial business. We don't have infinite amounts of funding. I'm certainly not a billionaire. By far not. So some of the decisions we've made to make is like, okay, there are really hard engineering problems that actually cost someone like 2 minutes to do in the physical world and we can train them really easily. So don't do that. Even though it's the hardest, most technically complicated, like robotics computer vision problem, it's not actually like real-world valuable. And I think you see a lot of robotics CV teams especially like solve these really hard engineering problems. When you look at the impact in the field or look at the impacts to like a factory or whatever, it's often like the hardest engineering problem they solve because they don't have the context of what the real problem is. Whereas you can get this like nice arbitrage layer by having engineers like really understand what the time, risk, cost of doing that process is. That's really important. The second thing is we really believe in guided workflows and and software that teaches you how to use it. And the reason why that's important is ultimately companies scale with culture, mission, and like process. And if you think about like any piece of software you've ever used, usually enterprise software is extremely hard to use or you train people like Salesforce. What you get in factories is like what that amounts to is like you can't just hire someone and train them in 20 days 'cause they have to use the software. So a lot of the things we focus on is consumer-grade software that's so easy for someone to use that it kind of trains them to do their job as they're going through it with a lot of— and that's a big product philosophy we have. And then the other thing is you can't break operations. So like the actual process of continually upgrading this factory with code or robotics is really important because we have to simultaneously run it while deploying automations into it. And that process of Building new software, testing with one person, rolling it out to that 10-person operations team once we know it works and like tracking it over time is like a really complicated dance. It's something we focus a lot on.

Yeah. There's like this manufacturing idea, like by Elon Musk, I'm sure you're familiar with the algorithm where it's like you do all these, you want to reduce all the requirements, really, really hone in on everything. And then the last step is to automate. And he's of the strong belief that there's no other way to do it. I personally wonder a lot that in general, there's no way to mass manufacture things. Like you have to take it by product. A lot of smart people have to spend a lot of time figuring out how you're going to manufacture at scale that one thing. There's no general algorithm or general company, maybe other than Hadrian that's developing this, that can take anything and derivatively have this ability to mass manufacture it. So you're going from the reverse end. You're saying, let's start with automation and work back. Backwards to making, making these, these great things, products. And I know today it's specifically customer parts, but how do you think about kind of the future of mass manufacturing from that, from that perspective? Like, do you believe that there will ever be a general approach or general company that can tackle pretty much anything you want to mass manufacture? Do you think it'll always kind of be this kind of linear process we've had to date since like the 20th century?

I think about it as 2 different philosophies, which is Is your goal to build a manufacturing service as a contract manufacturer, or are you optimizing for like the end product, right? And the algorithm is brilliant, but it's most effective where you can kind of control your whole stack because you're iterating on the design, you're iterating on the product, the parts change, the assembly process changes, and like actually sort all that stuff out before you go automate something because you're automating something that's a dumb With our industry and a lot of like supply chain in general, the way we manufacture stuff is largely defined by the customer requirements. So we don't actually get to say often, hey, customer X, you're doing this a slightly wrong way. We can control this abstraction stack. They say, make this thing, right? And the industry has been making these things really well for a long period of time. It's extremely efficient. So it's a slightly different strategy, but it's very similar. Like, you don't want to take a bad supply chain process and then write software on it. You want like a genius operations person to make this stupidly simple operations process and then put software in it. And I agree like philosophically with this. Yeah.

What technologies or research that could or is coming within the next 5 to 10 years are you most excited about and will have the most impact on manufacturing, on the work that you do?

I think a lot of Robotics, mostly because of the progress that's being made in reinforcement learning and large language models in the context of robotics, is really important because it takes something that is very deterministic and turns it into something that's more of a generalized solution, which I think has been a huge blocker for adoption of robotics in real-world environments in general because it has to be adaptive. I think there are huge, huge advances in Everything around AI for specific use cases, like mostly translating, labeling data and capturing things and closing these reinforcement learning loops to like train, train a model. That's really important. Um, otherwise, to be honest, a lot of it is just like pure brute force software engineering. Yeah. There are no, there are no silver bullets.

Yeah. What do you think most hard tech startups get wrong?

It's hard to say. I think like—

Very top, very, very wide-ranging kind of question.

It's a very wide-ranging question. I think a lot of the robotics companies build something that's like great, but the customer doesn't give a shit about it. And a lot of hard tech companies, one of the most important things that you get with software is the ability to iterate with your customers to find product-market fit really quickly. With doing hard tech stuff, a lot of the time you lose that link because you're so focused on building this cool plane or whatever, like maybe it doesn't have commercial value. The other thing is, I think a lot of hard tech companies are still not aggressive enough. They're solving really important problems, but they're kind of point solutions in the whole stack. And you lose a lot of the cost context and transfer. Um, yeah, but. Most of the people who are building product companies like Anduril, Castellion, stuff like that have really gotten the model right of like the kind of SpaceX vertically integrated model. I think for people building machining automation, casting automation, industrial software, that sort of stuff, there are some real puzzles to be solved of like, what is the correct way to build a company that generates a great financial outcome as well as like builds the right product for the customers and automates the stuff? Yeah.

What do you think has been the biggest thing you've learned since calling Adrian for the past 2, 3 years?

Yeah. The complex coordination problem of building the product is the most important thing we've learned and where the costs are. And I'll give you an example. If you're doing a task and I have 3 software engineers that are working with you to automate yourself, but you're smart, with 1 person as the user, you can iterate super quickly. And the cost of iterating to a good product is very cheap. When there's 10 people doing your job, that cost actually explodes. So you have to find this nice balance of you can't just perfectly design a product and then ship it because you always get it wrong. You also can't iterate with 10 people because it's disruptive to operations. Like the cost doesn't make sense. So having that coordination where there's, you iterate with one person in operations, then it propagates to a good solution, then you roll out to the entire team and doing that dance is like, I think a unique thing about actually how to incrementally deploy automation to operations and having it stick and people actually use it versus like you build a bunch of software and operations team kind of hates it, you lose context as a software engineering team over here, as an operations team over here. That is the biggest piece of learning. And then the other thing is continually getting people out here back to what's important to the customer because there are many, many hard problems to solve. Not all of them are equally valuable to our customers. So by focusing so much on internal automation, there's also this inverse trap of like, well, it's good for us. Is it good for the customer? Actually, we should take more pain sometimes and have that trade correct. So those are some of the core learnings.

Yeah. What's something that you wish people asked some more about when talking about Ninja?

I think that the people side, the people side, the culture and How complicated it is to run an operation while continuously upgrading it and what change management and training really looks like in the real world and scaling operations at the same time as building software. I think that is a very unique thing that a lot of like large operationally heavy with software-enabled services companies get wrong. I think the other thing is like the mission behind the people is we talk a lot about automation, but One of the reasons why we don't automate absolutely everything is because the side benefit is we're taking people from, you know, jobs that they might hate, or they're from hospitality, or they're from Home Depot, or from wherever, and really rebuilding the American manufacturing workforce by pulling people into this environment where it's an awesome job, they can be proud of it, versus like, you know, I go to work in a crappy factory where my boss yells at me. And that cultural transformation of people who are early 20s, 40s, whatever, that have never set foot in the factory before, now operating this highly skilled level is really important. And I think the difference is, if you look at self-driving trucks, you automate self-driving trucks and one of the downsides is it's the biggest job for American men and women under 40. It's a great wage. It's a perfect job. With the industrial space in America, the shortage of skilled labor is so scarce You're not, by automating, you're not taking away jobs. What we hope to generate is a smaller number of jobs that are more highly paid. And that's how it should work. Otherwise, you should be offshoring or doing mass immigration or something like that. So I think that people side of the equation, how that scales out across the country is going to be like really, really important.

Can you go? So I had another question, but I would like to hear a little bit more on, so like a lot of software companies, when they get the culture thing wrong, And that culture, people focus is really, really important. Let's talk about how you're doing it differently here. I think that's probably hard for people who aren't more engineering to maybe see or understand.

So I think the most important thing is if you actually want people to use automated software in a factory environment, you can never accidentally have this thing where engineers rule the roost. And it's like this top-down thing of like, hey, Screw you, use the software, you don't know what you're doing. Even if they're right, it doesn't actually lead to adoption of the automation and actually generates things. So as an example of the tricks you've got to pull, you've got to teach people that like this guy or girl who's like packing this box or doing something, that is your customer. And you can be the smartest software engineer in the world, but if that is not a good solution for them, it's not good enough.

That's so interesting. You have end customers that you're building products to, but then you're also treating your employees who are using the software like customers. That's so cool.

Yes.

I know, I know, have other companies tried their forethoughtful approach? It's very unique.

So people have done it before, but they get it slightly wrong. And what it leads to over time is like, you have this operations team, this software engineering team, and they don't talk to each other. They're not, they don't feel like they're part of the same team. So you build a bunch of software, but no one ever adopts it. And you actually like waste all this time and money. And there's a lot of lessons out there from large companies that use software leveraged operations that I think are really important.

Yeah. Talk to me a little bit about kind of the next big phase for Hadrian.

So we are so early. I mean, we're just coming up to 3 years old. We only launched to customers this time last year. So about 12 months ago, we're growing revenue faster than the fastest like enterprise software company, which is really, really painful to do in the real world. The next trick is we have to fill this factory up and get it really humming. You can see there's a lot of empty floor space. So this time next year, this should be like full and we've got to figure out where to put all the people. I guess we're going to run out of space again. The next phase is really, can we then start copy-pasting facilities that run the exact same way across the country as fast as really possible? And that's where you really get the scaling vector is being able to take the factory in a box and clone it. And have all the software training automation work so well together that you can just like copy paste and scale really fast.

Well, will you start copying pasting when in your manufacturing box is like 100% or 99% done? But like what percentage of kind of completion would you start doing that and kind of where do you guys start?

And so the way we think about it is we obviously have automation metrics and automation goals, efficiency, throughput, rate, quality, and we are far from done on that. It should be done by the end of the year. The other thing is everything has to be so good that you can take someone on their first day of training, they start using the software, it just works, they get it. It's like very slick, it's very contained, right? And what we expect to happen is we will think this factory will run perfectly. We will copy paste the second one and we will realize that 30% of what was working no longer works because The product was not, someone was used to using it and they're getting away with it. And when you put a new team in it, then it will take 3 months of shaking that out and then it'll be like perfectly copy-pasteable. And then the product should be like quasi-done. And you get into all sorts of other interesting like multi-factory problems. Like now you have a load balancer for 2 factories and you can see all these systems and how you coordinate it. But that's really the next phase is We're halfway through building like a fully automated autonomous factory. The next trick will be, can we do multi-factory at the same efficiency levels as this current one? Or is it just like, is the software really that good? Or is it just a bunch of genius operations people working with the software? We will get there, but you kind of have to like copy paste once to like learn where the problems are and then go from there.

I love your realness on it too. You're like, hey, it might not work the first time. It's going to get like, that's really cool about that. If you're like, It will be perfect.

Oh, yeah, yeah. We will get it perfect.

Yes.

But you have to step it out in a way that reveals the problems and then push the gas down.

Last kind of 2 questions here. This one's weird sounding, but I think it's a really interesting thought experiment. You kind of try to describe how you think. And I guess what I mean by that is when your brain comes up against a problem, What are some of your brain's knee-jerk solution reactions? Or are there any mental lenses you commonly find yourself at work outside of just commonly looking at the world?

At least with engineering, I try and think about it like a game board. And a lot of people fall into the trap of, hey, I'm trying to solve this really hard engineering problem, and don't take a step back and go, actually, are we even in the right meta strategy?

Yeah.

So pulling out and going, okay, this is working, but we just need more people to push the gas down and write more code. Or you get 40% of the way through a really hard automation problem and it's solved the first 40%, but actually it's not a CompGeo problem anymore. It's a reinforcement learning problem or it's a data labeling problem. And you can get really stuck in hammering on an engineering strategy for a really hard technical problem. And sometimes you need to go like, Oh, actually we need to find a, like, it's like a hill climbing problem. So I think about that all the time. And the second thing is, it's like, where do you invest the resources the fastest to like keep the game going as long as, because all these problems are really hard to solve. What do you do? What do you don't do? One of the mental models I have is like, what can be this? What can be a spreadsheet the longest? You can never build all the software instantly. So you have to make all these trade-offs all the time and think about, okay, what's the most important thing? Is it equipment uptime? Is it stability of the whole factory? Is it the customer experience? Is it our unit economics where we're making things more and more over time? Like, what's the right place to put effort in at different phases of the company to like make those trade-offs actually work?

Last, last question is, what's your career and life philosophy?

My current life philosophy is if we get this right, I will have spent 5 to 6 years working extremely hard in like near Elon mode. And I cannot keep up with someone like Elon or even Baba Lucky, but like 90% of the way there. And then you should be setting up the business in a way where what I do on a day-to-day basis, making these decisions, is embedded in the decision-making culture of the company. Like, Similar to how Amazon performs, where the system of building automated things, finding new market opportunities is like self-generating at that point. Um, and then I think my life philosophy is you get to pick your costs. You get to pick your costs. And what I mean by that is a lot of people stumble through life, especially as a founder, and they go, oh, I don't have a great relationship. I don't have like a romantic partner. My employees kind of hate me. I haven't seen my friends for 2 years. Like, and it's really like you set out to sea, you dive off a boat into a maelstrom without a life jacket. And so I think for me personally, I think about Ulysses contracts a lot, which is a contract you make with yourself where, you know, you're sailing into the sirens, you know, you're going to get distracted by all this stuff and you forget what's important to you because you're like, You know, in this maelstrom of the sea and getting distracted. But I think people forget that you can't do everything and you just have to pick. You have to decide what's important and then pick. And you're picking your costs. It's like, okay, do you want to invest in like having a dog or having like great friends or like having a great romantic partner or building a generationally large company? And you can have shitty versions of all 5 or you can pick 3 good ones. And then like, holding yourself accountable to what your life wants to look like and trying to do that with enough intention that, yeah, you're picking. Like, do you want a romantic partner while you're building a software company? Okay, you're going to spend less time with friends. Like, maybe you don't get to travel as much. Like, you get to do life however you want if you're smart, young, hungry, and have high agency. But I think people don't think enough about what they want their life to look like in 5 to 10 years and like think through what that really means and what they're not going to get to do, you know, and you get to pick your cost and deciding that for young people, I think is important. It's so easy in this world to get massively distracted for a decade and you wake up one day and you're 35 or whatever and you're like, hey, I built this really amazing company, but like, I'm really unhappy. Like I don't have kids. I don't have a partner. And thinking about what you want your life to look like and picking what costs you're going to take and being realistic about it. And then like, How you live your day-to-day life minute by minute generates the macro. It's not about the big decisions. Like the little things are the things that matter. Do you call your friend? Do you call your partner? Do you like take care of your employees? Do you take care of your customers? And how you kind of build your own philosophy and system of work around what you want to see in the world is the most important thing. And annoyingly, as a leader, there are no tricks. It's all just downstream of, it's like having kids. You can tell them like, hey, don't eat ice cream. But if you're fat and like eating ice cream at dinner, like that's the culture that you think. And like, this is not an easy problem to solve because if you really believe it, you kind of just have to live it minute by minute. And I'm far from perfect, but that is the correct way to think about life and culture and how to like build a civilization or build a country is like deciding what you want, deciding what costs you want to take. how you want to live. And then like the focus is being present and living it like minute by minute. And that ends up generating the big outcome versus just like, hey, I got this big idea, I'm going to do this thing. You've got to pick the person that you want to be and behaving in that way as best as possible daily ends up generating what you want. I think people forget about that sometimes. We focus so much on metrics or building large companies or whatever that like, that's kind of my life philosophy and I have not got it all worked out, but that's That's the way I think people need to think about their lives, especially in this day and age where everyone's so distracted. There's so many algorithms pulling through your intent, like your intention. You have to really think about it and then hold yourself accountable to like, what am I focusing my attention on? And the universe will give you what you want, but if you get distracted with how you're behaving, it will give you the thing that you thought you want. And that's a really tricky game to play, but it's really important for young people especially who've got so many distractions as they're like growing up into like who they want to be.

Yeah, I know I said that was the last question, but your answer was great. It made me think of a question I also like asking people. And it also like leads to me kind of dunking on my own generation, where I feel like we are some of the most well-off, well-educated, economically like set up people, yet like the vast majority, I think, of young people are mostly just like consuming content online.

Yes.

We say this as we're recording content for the internet. But in an effort to hopefully change that, how do you think, what do you think society, people kind of needs to do to maybe get more, maybe when you're so freaking privileged and have all these great things to go and continue to use that to change the world rather than just kind of sit and grow fat and join?

I think it's really tough. So I think this is what happens to large companies and civilizations across multiple generations. And I'm a big believer in books like The Fourth Turning and like being a student of history. And I think young people have to realize that the problems of their grandfathers or grandmothers are not the problems of today. One of the big things I think about is I believe humans have a complaint bucket.

Have a what?

Have a complaint bucket. And everyone complains 20 to 30% of the time, depending on how neurotic you are. What you complain about as a young person today is actually extremely trivial compared to 3 generations ago where the problem is like, hey, we're going to war with like the Nazis or like the electricity grid doesn't work, right? And I think a return to reality and return to what's important is like really tricky to do in this day and age where like people are, we're extremely privileged in this country and we're forgetting what generated the success of the country in the first place. And again, it's the same thing as why our software engineers work next to our machines. It's getting back to that industrial civilization level of context and importance. And it's a really tricky thing to do because you're operating off market signals of these complex abstraction stacks. And it's going to be an interesting 10 years as we go through this generational turn of what really matters. Yeah.

Chris, thank you for this. Thanks for building Adrian. Thanks for having us.

Of course, man. It was a pleasure. Thanks for coming down. Boom.

We did it. Nice to see you.

That was great. You're a great interviewer.

Thank you.

Yeah.

Yeah. I think I've improved since starting.