Software Misadventures - Uncrating the Oxide Rack | Bryan Cantrill, Steve Tuck (Oxide)

Episode Date: September 24, 2024

Oxide co-founders Bryan and Steve are back on the show to give an impromptu peek at the Oxide server rack and to chat about writing their own manufacturing software, overcoming false summits before shipping the first rack, the #1 reason startups fail and more. Don't miss the full-circle moment on their "meet cute" story from last time, shared at the end of the conversation :)   Segments: (00:00:00) The Oxide rack uncrating experience (00:02:40) The office tour (00:04:03) Challenges of shipping and unboxing hardware (00:11:04) Hybrid hardware company? (00:13:38) Custom designing a crate for the rack (00:18:12) Optimizing for time to value (00:20:43) Writing custom manufacturing software (00:23:25) Taking ownership of the customer experience (00:25:29) Buy vs build (00:27:46) The false summits before shipping the first rack (00:30:05) “Missing just enough context to be optimistic” (00:33:07) The #1 reason startups fail (00:38:49) Hiring the first sales role (00:44:53) The dangers of “happy ears” (00:47:18) The pitfalls of rushing to market (00:51:03) The “third VP of sales” problem (00:56:06) The value of a good sales leader (01:00:07) Curiosity and empathy in sales (01:03:41) Grooming sales skills as an engineer (01:07:33) Learning from current customers (01:09:13) Talk to prospective customers “that we have 0% chance of closing” (01:11:25) Actionable bad news (01:14:11) The role of GPUs in data centers (01:18:50) Cloud repatriation (01:24:23) Full circle to the “meet cute”   Show Notes: Our previous convo: https://softwaremisadventures.com/p/oxide-ditching-the-rules Bryan on Twitter: https://x.com/bcantrill Steve on Twitter: https://x.com/sdtuck   Stay in touch: 👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! [e-mail]

I think we should do a de-creating experience. I think that would be an amazing video, yes. So Steve is our lovely host. Thank you, Steve. Steve is now going... Yes. So I'm very curious, because Steve is going to do something

that I would not have done, I guess. Or I guess it's that... So... All right... Yep. One of those signs. Oh, wow. Oh, that looks pretty cool. All right.

So that is the oxide rack as it arrives. And then you can see that we've got rack as it arrives. Whoa. And then you can see that we've got a built-in ramp there. Oh, right. And you can just drag it out. Oh, shit. That's so smart. Yeah. So this is where you get to, like, all these little bits that are engineered, right? So those bolts come undone. That small piece comes out. And then the whole rack rolls out. Side panels are shipped along with it.

So these are the side panels here. You've got the front and rear doors. Wow. And this particular, oh God. Oh, wow. That looks heavy. Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Gwan. As engineers, we are interested in not just the technologies, but the people and the stories behind them. So on this show, we try to scratch our own edge by sitting down with engineers, founders

and investors to chat about their path, lessons they have learned, and of course, the misadventures along the way. Take it away, Guan. Oh, yeah. Maybe it would be fun to start with the office tour. Sorry, I opened it prepared. But then it's like, okay, we're doing an office tour. Let's do it.

Context, context. So we started talking about this right before we hit the record word. And thanks, Guang. And Brian, we see this amazing background behind you. It seems like a warehouse, but actually it's a very cool office. We got a glimpse of it last time we spoke. We thought it'd be really cool for our listeners to also get a glimpse of the office. So if you wouldn't mind, can you just briefly show us what the office looks like and what it is?

Yeah, sure. Absolutely. So we are here in Emeryville, California. This is the Oxide office. Let's see here. So it's, you know, it's funny because we were really born right before the pandemic. So we got this space in late 2019

with the idea that we would be doing, you know, we knew we were going to be a hybrid local remote company, but assumed that a lot of stuff was going to be local. And we definitely use the office a bunch, but we use it as you can kind of see as kind of as a lab more than almost anything else. So very open plan, but then importantly, we've got a lot of hardware.

This is our switch. Yeah, exactly, right? this is our switch this is a our manufacturing station so we've not something we've really talked about too much but we actually wrote all of our our own manufacturing software at Oxide and in addition to everything else um and this is what that manufacturing station looks like at our manufacturer so to be clear that is not where we manufacture people think like oh this is what that manufacturing station looks like at our manufacturer. To be clear, that is not where we manufacture. This is not where we manufacture. I know. People think, like, oh, this is like the factory.

It's like, no, no, no, this is not that. This big crate here is an oxide rack. Inside, there's an oxide rack. Actually, the crate itself has been um engineered so one of the things that was really interesting i mean i feel we've learned so much about so much in building this company but one of the things we learned is all the engineering that goes into shipping things and it is extremely important that when we ship the oxide rack that we are able to ship with all the sleds in the rack. So these compute sleds, so here are our compute sleds kind of down here.

Actually, I can give you a better view of them over here. These compute sleds slide into the rack, and that's a compute sled there. And it will slide into the rack, our oxide rack over here. Nice. And it is very important to us that we are able, and here's our rack that's actually, this is what we call the the dog food rack this is actually a running rack um that we run all of our own software on um and it was very important that we were able to ship the sleds in the rack because one of the things that we're really optimizing is the time from when that crate arrives and the rack is not just powered on, but you've got developers provisioning VMs. And in order to optimize that time,

it's really important that you don't have to de-box a bunch of compute sleds. This thing ships with 32 compute sleds, and 32 boxes of computers, it's a lot of de-boxing you need to do. And you're going to spend just a day de-boxing and disposing of stuff that can't happen in the DC, that has to happen in another room.

And it just adds time. And so one thing that's really important is that we can ship it with the sleds in, we can roll the rack in, plug it in, and go. But in order to do that, you have to engineer your own crate. And Steve, this is, what, the third iteration of the crate? It took us a while to get this to get this right um but yeah it's this has been a it's been a fun space let's go we're in emeryville california um and when we were um looking at at various space um you know it's

very hard to find the kind of space that has um that is um conducive to making hardware. And we're not looking for a space that a law firm would occupy. We're also not necessarily looking for a space that is a true industrial space. You're looking for something that's kind of that hybrid, where it has industrial aspects with respect to power and so on, but is also something where people can reasonably work. I feel we've hit the balance reasonably well. The heat has been an adventure to get this place properly heated.

I can imagine. Yeah, you know, it's the Bay Area. So, you know, I know we talked a lot about HBO's Silicon valley a lot um and i'm sorry to go back to that well again but there's so many just like nuances of hbo silicon valley that are just absolutely genius and one of them is there's an episode in which it's cold cold you have to understand in the bay area is like 57 degrees which for most of the country would be like 57. I mean, 57 degrees is like, okay, it's like maybe got a little chill to it, but like, there are plenty of days that I would love for it to be 57 when it's, uh,

you know, Steve went to school in Madison and there are plenty of days in Madison where you're like, that's shorts and tank top weather. I live in Toronto, so that is still shorts and tank top weather. Yeah. And in the Bay area, because we're so spoiled stupid like we don't have double paned windows we don't have any of the things that you would normally need to survive in other climates so everyone just like freezes their tails off and there's an episode of Silicon Valley where everyone is wearing like parkas inside because it's so cold.

Right, exactly. And it's like, actually, that's just not that cold. But so this office is very like on brand for the Bay Area in that like it's, there are days in which we've had employees who have worn winter hats while working here. If we only knew someone at a heating and air conditioning company. That's right. We can try and solve for that. By the way, thank you for giving us this tour of the office space. I think it's really cool. Like first, so I studied electrical engineering and this really reminds me of a lab. And that is

just really exciting. You actually feel like a real engineer, not a fake engineer who just works with a keyboard and a screen. So it's pretty amazing what you've done with this pace. And I think the rack part that you mentioned, so pretty much if someone gets this rack, they pretty much need to, well, unbox the rack, but then plug it in and it's ready to go, more or less. That's right. Yeah. It's pretty incredible. Add power, add networking and go. Wow. Which was the intent because, I mean, today it takes, it still takes companies on the order of two three months from the time that all the boxes land at the warehouse to being able to get them unboxed god forbid that you've got the wrong rack rails that shipped even if you've nailed everything else in terms of getting server

assembly storage assembly networking assembly uh the facilities person that comes in because they can control uh being able to wire these things up and then getting all the software licensing taken care of. And you can have been invoiced for something and have an invoice due and still be months away from developers being productive, which is the exact opposite of the public cloud experience, right? Where you swipe a credit card and go. And a lot, as Brian mentioned, I mean, even just the crate and what we had to go through

to make sure that we had a repeatable process for crating and shipping to make that unboxing and that final assembly, which is, you know, if you want doors on the side and side panels and doors and those sorts of things, all of that shipping with the rack itself. Do we not want to tour the conference room? I mean, this is so exciting. The one drawback of the space was not a ton of separated off space, but it works well. I think it would be really good for serendipity. Like people would be going around and just, I don't know, whiteboarding together.

That just sounds fun to me. Yeah. It's been a good space. Yeah, it has been a good space. I mean, I think that the, it's interesting you mentioned the serendipity because, you know, you see all of this kind of the return to office mandates, which we all kind of rolled our eyes at because the reason we need the physical aspect of the office is not for the collaboration. It really is for the physicality of what we're building. And the fact that we are people like,

you are a hardware company. I mean, we're a hardware and software systems company. But you're also like all remote it's like well yes i mean a lot yes there's a lot of lab work that's involved in hardware there's also most of the work is not most of what our double e's do you are interacting with software you're acting with eda software simulation software you were you know you're in solid works or you're an ancestor you're an altium in Altium or you're collaborating with your peers and that collaboration for us is all going on.

Or you were going to a manufacturing site to do bring up. You are going to, like there's, you know, very, very hard to go build a company like this where everyone's in one spot. And let's not forget, I mean, offices are valuable. You've got child avoidance that is paramount. That is actually critical. That's right. I mentioned last time, we're expecting our first baby in three weeks. So I'll take that. Congratulations. I keep hearing that from people. You would want to come to the office after that you will thank god it's

monday for sure um the uh yes yeah that that's great uh and that's your well congratulations it's it it's it's it's exciting and i think that it will be uh you know every a part of what makes parenting interesting is that just when you get really at your wits end, things change. So just remember that when you're at your wits end. Or when you get comfortable. Just when you get comfortable. I figured this out. Now we know how to keep

him or her asleep. Right. This is so exciting. This is very encouraging. Thank you. I think we can do an entire episode on parenting. Which maybe we should at some point. I would love that. like the way you think of other people when you've got it you because you you've got this other person that you are going to love unequivocally despite all their faults and it it's it's good it's good for your empathy it's good stuff for sure uh so i want to question one go ahead go go for it go for it i was going to talk about the crate so uh i was gonna say that too i thought it's such a attention like a nice example of y'all's attention to detail.

Because that thing is like 9,000 pounds, y'all said somewhere? And is the crate, I think... I know the showcase, the rack... Yeah, the rack's in there. But I think I can... Yeah, you should be able to pop it. Actually, no, no, no. It's a...

I should come out there if you want to pop it. Uh, sure. Do we want to if you want to pop it. Sure. Do we want to... You want to see the inside? Yeah, let's do it. I feel we should do a de-creating experience. I think that would be an amazing video, yes. And we can make it...

We should. Okay, so... So Steve is... Our lovely host. Thank you, Steve. Steve is now going. Yes. So I'm very curious, because Steve is going to do something

that I would not have done, I guess. Or I guess it's that. Are those the locks, or are they just hinges? This is the part that you made. So and, um, yep. One of those sides. Dang. Oh, wow. Oh, that looks pretty cool.

All right, so that is the oxide rack as it arrives. Whoa. And then you can see that we've got a built-in ramp there. Oh, right. And you can just drag it out. Oh, shit, that's so smart. Yeah, so this is where you get to, like, all these little bits that are engineered, right?

So, like, the... So those bolts come undone. where you get to like all these little bits that are engineered right so like the so those um those bolts come undone that that small piece comes out and then the whole rack rolls out side panels are shipped are along with it so nice these are these these are the side panels here um the um you've got the the front and rear doors wow and this particular, oh god oh wow

that looks heavy yeah exactly wheel it out so that gets wheeled out and then it's on wheels and then once you actually get it in its destination, then you will, these will actually screw down. Oh, so you can stop it. Yes, you can actually, yeah.

Sorry, terrible analogy probably, but looking at this, it reminds me of that using an oxide server rack is probably easier than assembling IKEA furniture. Is this the pattern? Yes, it is. So, no, it is definitely, it is easier than assembling IKEA furniture in that the, it actually is. It's kind of funny to think of it that way, but in part because it all comes pre-assembled, right? So it was very important that we were able to ship this thing completely intact to optimize for that time. So, yeah, the idea here is, of course, that rack will get wheeled into your data center. You plug in those power whips and configure networking,

which shouldn't be trivialized. I mean, there's a lot to actually, and the whips too, right? The power is not trivial. Yeah. This is pretty cool. Thank you for showing us what was inside of the Crate. So we're going to touch on Crate a little bit. And so last time we talked, Thank you for showing us what was inside of the crate. So we're going to touch on crate a little bit.

And so last time we talked, you mentioned that you wrote your own network switch. This time you mentioned that you wrote your own manufacturing software. You're also designing the crate. In building this sort of rack, you're also designing not just parts of the rack, but everything around it too. And I was curious to know if there is one goal that you're optimizing for, like all of this is an optimization of something. If I think of social media companies, they're optimizing for the amount of time you spend on the screen. Search, not necessarily any particular engine,

but any search engine's goal is to take you off of that page as soon as possible. So in this specific case, what is that one goal that all of this is an optimization for? Well, I think it's, I'll give my answer. I think when we talk about this end-to-end process of doing our own manufacturing software, which by the way, requires having the right partner in manufacturing that is open and willing

to you doing your own manufacturing software. You don't just have like the the agency and the ability to go kind of control the entire end-to-end process if you don't have the right partners and i think we talked a little bit about the san yodanki partnership uh last time we met and how important that was for us to be able to customize and just the fan speed as an example but i mean at the end of the day what we're what we're striving for is delivering the benefits of cloud computing on premises. And so what does that mean? Well, a lot of what we just spoke about is time to value. One of the paramount things of public

cloud computing is that 16 digits of freedom. It's like I swipe a credit card, I have access to this elastic infrastructure that allows me to go start deploying software that is this idea I have or this job I have to go complete. And I don't have to think about any of the rest. And it's fast. That is the exact opposite of that on-premises experience. So one of the paramount goals is to collapse that time to start from 100 days to, you know, I mean, seconds once this is installed, but that installation process to go from months down to hours. And to do that, you know, why do things take longer well obviously we talked about the assembly all the integration the assembly and the checking and the testing that one has to do before they can turn this over to development teams um and and then another is quality what is how do you get to known

good quality of system before of the complete system before it's being installed because the worst place to find out that something is wrong is at the customer site, just generally. And so back to the manufacturing software, being able to integrate that into our end-to-end process just gives us better visibility and confidence about the quality of system that is going to get plugged in and be able to test the end-to-end system, not test individual components, the server separate from the switch, separate from the control plane, but being able to kind of do that end-to-end test. So one, I mean, two of the very important kind of higher level goals are delivering that efficient experience to customers and then delivering that kind of high level of quality of product.

Certainly for things like the crate manufacturing software, when we talk about kind of some of the things we took on ourselves. And that's exactly it, right? And so that's our lens is, you know, because we're not seeking to actually do everything on our own. And we would be, you know, we want to take off-the-shelf solutions where we can. But there are a couple of these points that are the, they're actually the off-the-shelf solutions are either poor or they're expensive or they're so proprietary we can't meaningfully integrate with them i mean so manufacturing software is a good example where the manufacturing software is uh it's kind of ridiculous that anyone would buy off-the-shelf manufacturing software because your manufacturing process is so i mean it is at some level

idiosyncratic to what it's unique to what you're building and you want to be able to control all the aspects of that and um you know i think that our contract manufacturer definitely thought we were it's like okay you guys are gonna okay you're you really do need to do everything on your own but when we uh boy talk about something that we've got absolutely no regrets over that was emphatically the right decision that's enabled us to control every step of the process and the thing that we're always braced for hasn't happened to date but the thing that you want to get ahead of is that you do have a manufacturing quality issue that god forbid does show up in the customer base it's really important that you were able to get on that

very very quickly and you want to be able to, from that first failure, be able to realize, oh, we've got a bad lot. And now work with our partners to figure out how did we get here and then improve the process such that it doesn't happen again. And that comes from us controlling the whole thing. Soup to Nuts, that that also by the way allows us to because we don't have 18 different vendors in here slicing away at our margin it allows us to deliver a product that is way more cost effective for our users so um i mean economically

it's very important that this this and this has to deliver terrific value to our customers and it needs to do that and it needs to do that. And it needs to do that in a way that we can take responsibility for any problem that that rack actually has. And that's the lens by which we make all these different decisions. And honestly, like a bunch of these decisions, we were, we didn't make them, you know, we came to it reluctantly. Things like manufacturing software or like doing the switch even i mean we did not when we first set out we were not going to you know doing our own switch is really complicated but we also came to the conclusion that it was absolutely necessary

and in hindsight is essential it's not something we could have partnered for yeah you hit on a super important one which is being able to take ownership of that entire customer experience. And that, I think we talked about this last time, but when, just when you think about doing all the hardware and software together in product form, one of the biggest driving forces there was to make sure that if customers have an issue, we can take complete ownership of it, whether it's part of our product or not. And to do that, you need to be thoughtful about how you get telemetry throughout the system and also that you don't have parts of the product that are dependent upon third parties where you don't need to, so that when there's that issue,

you avoid the classic kind of gaslighting of like I don't know what you know what X are you running on this or what what are you an individual customer doing that that is creating an issue that we don't want to take responsibility for it's quite the opposite being able to say you know to Brian's point of its manufacturing issue if it is kind of anywhere in that end-to-, ensuring we can, we can take ownership of that and correct that issue for the customers is maybe the biggest driving factor to areas where we hit that fork in the road of like build versus buy. And, um, it, it, we, we definitely look back with no regrets on the things that we have taken control of in that process.

I think the aspect that you mentioned that you have reluctantly come to that conclusion, I think that word reluctantly is very important because it's very easy to get distracted by many of these things because from an engineering standpoint, it's like, oh, it'll be fun to solve this problem. And sure, we can do it better. But then if it's not in the service of your overall goal it can end up distracting people a lot which i mean all of us have seen happening enough whether the team is big or small whether it's a company young or big and i think it comes down to having that balance in terms of where you are intentionally making that trade-off to say we'll spend more time here but it's going to

be worth it but i'm glad to hear that these decisions have worked out so well for you yeah and i think you're exactly right i think it is because it's overly reductive to say oh well of course the engineers want to build their own crate like every engineer fantasizes about building their own crate and it's like the um so you can't assume that when you got a group of engineers saying, I think we actually need to write this ourselves. I think it's a mistake to assume that like, well, of course they're saying that. Because oftentimes engineers are coming to that out of the, like we are trying to use this other thing. And we are, and that's part of the reason why it's actually helpful to have a disposition of like, all right, we are going are trying to use this other thing, and we are, and that's part of the reason why it's actually helpful to have a disposition of, like, all right, we are going to try to use this other thing, but we're going to keep an open mind, and if we begin to hit friction here,

like, we're going to, we want to, like, go reevaluate that determination a little bit, and, you know, a lot of the things that we have gone our own way on are because we tried to not go our own way and came to the just, we got lucky enough to come to an early enough conclusion that, like, no, actually we can't. And then we're also, we are willing to take on this stuff ourselves. And we are willing to be like, yes, we'll do our own switch. We'll do our own network operating system. We'll do our own embedded operating system. Like, we've got the boldness to do that where it makes sense. We're not, but not foolhardy.

Nice, nice. So speaking of the server rack, so back in June of last year, so this was like four years after founding Oxide, you guys shipped the very first server rack. This was a huge moment, and I think someone on Reddit was forced to eat their shoes. Just kidding, but not really.

So then I was listening to a Austin Friends episode that you guys recorded like right after. And Brian, so I loved how you described the moment of like you finally shipping being a bit like surprising. So I'm paraphrasing here, but you said it was like, it's like climbing a mountain and there's so many false summits and you get to a point where you're just grinding and all of a sudden you're at the actual summit and you're

like oh wow like we're actually here like were there any um what were the sort of the memorable like false summits for you guys oh my god getting all this question oh god well because i think in and when you are on a peak with many many many false summits at some point like you just break along the way and you're just like okay they're all false summits at this point like i'd and i mean that's it's kind of an important mental breaking to go to because you really just need to be focused on the I've got to go take the next step and the but no there were so many times when the and it wasn't so much that like the boy we thought this was the the end and it wasn't so it's not that this is where the false summit metaphor breaks down a little bit but you have so many experiences along the way that when you're

building an artifact like this um nobody wants a machine that doesn't boot um like that's not it's not like that's an it's not like oh that product is like less desirable it's like that product has got is no zero desirability nobody wants that um and there are so many things along the way that like if we don't resolve this problem it's not like we've got a product that's not quite as good it's like we don't have a company like we are actually dead if we don't resolve this problem and you know in those moments you always like, you need some number of folks, obviously, that are heads down engaged on the problem. Then it's also helpful to have some folks that are just missing just enough context that they can remain totally optimistic. Of like, oh, we'll nail this.

And it's like, okay, glad you're optimistic. And this is true not just on the engineering side, but certainly on the go-to-market side, too. That, you know, like, we've got the, you know, we've got that customer that was really excited that has now gone totally silent on and has not replied to the last, like, you know, three emails. And, you know, this is where I'll be with the Steve. I'm like, they've said, like, they're really interested and they've got a project. And Steve's like, oh, I'm glad you're so optimistic. Like, do you want me to explain to you? Like, do you want me to talk you out of your optimism?

And I think that you need both, right? You've got to be, you need to have that kind of paranoia and know all of the ways that, like, because you've got to take it seriously, right? And, like, you need to, like, this is an existential threat that we actually can't get this thing, can't get this nick to come out of reset or, you know, can't. And that's kind of an obvious existential threat. But it's also as much of an existential threat of, like, no, like, I know we were, like, this customer was, or this prospect was very excited but has now gone silent. And it's, like, actually, there are lots of reasons to be paranoid about what's going on, and we need to make sure that, like, we're on that. When, you know, you've got a customer that's deployed, you've got to, you can't take that for granted you know kind of at every stage and if you've got something that is like a wisp of smoke at on on a production deployment like you need to be jumping all over that because and then you kind of need that balance uh of um because it's very easy in

any of those moments to be like we're done it's like it's over everybody go home this is i you know i god what the hell were we thinking that we could pull this off? Like, no, it's like fold up the tent. And there's a part of your inner voice that's doing that. And I think that for across the company, I think we are all, you know, domain experts and veterans. So we all have that own, our own inner voice in our own domain. But we can also be optimistic of like you know like we don't we'll get through this and I think as a company

we've knocked so many of those down now that I've got a much more I would say robust sense of optimism and I'm less plagued by the idea that like we'll never pull this off because we've now overcome so much that we know like we can actually go we can do this stuff um and we want to not be you can kind of become foolhardy in those moments too where you get you know overly bold so you have to like retain that that fundamental humility uh but fortunately reality has a way of continuing to dish that out to us so starting with a little bit of delusion and then working towards optimism a hundred percent and it i mean this is like the whenever you're doing something new like you've

got to balance the world as you're seeing it the world as it could be with the world as you're seeing it, the world as it could be, with the world as it is actually. We're like, no, but actually, we don't boot right now. I know, I see a great vision. Meanwhile, it's like, actually, this customer's gone totally silent on us. Meanwhile, back in reality. So it's like, you've got it, and it's at that intersection that you kind of have to constantly live. So as we think about the entire development process and eventually shipping the product to a customer,

now having customers agree that they want to buy something like this and actually pay money for it, not just say, oh, yes, I'm interested, you require someone to talk to the customer. So this is where the go-to market team comes into picture. So we touched on this last time, but we didn't get to talk to the customer so this is where the go-to market team comes into picture uh so we touched on this last time but we didn't get to talk enough about it uh so we wanted to get your take on two aspects here and you can go in either direction in whichever order you see fit but the two aspects are when you're starting to build the company you haven't necessarily validated the product itself meaning you don't have a working product yet so at what point do you start building a go

to market team and then when you decide you need to build it how do you actually go about building yeah and and i think we we touched on it a bit last time but this is possibly the number one place where companies fail like if you if you kind of like walk backwards from a company that didn't make it, um, very often I would say ascribe, you know, a high percentage of it is from thinking that you're further along than you are and starting to pour a bunch of money into go to market. And, you know, I think there's plenty of blame to be left at the feet of VCs in this regard, because where a lot of that emphasis and pressure comes from with a lot of young companies is from the investors that have been, you know, in their minds, patiently waiting

for a long time for this thing to be ready that they poured a bunch of money into and took a bunch of risk in and had to make the case internally into their LPs and everything else. But, you know, there's this anticipation of, okay, it's go time. And, you know, I'm speaking now about many colleagues and many past companies where they have gotten to a point where, yes, they're now shipping a product, but they know that they still need to get kind of affirmation and also just proof points back in terms of what aspects of the product are hitting what pain points in the customer. And then quickly optimizing that product to eventually find patterns and build those patterns out. And everyone kind of lazily collects this into product market fit, but it's a whole set of stages that incorporate finding repeatability in the sales process, the deployment process, the retention of customer and expansion of customer

process. But back to that moment where there's the launch and there's the pomp and circumstance and you know, the PR firm is out beating the streets and it's like, let's go, let's time and gas it. And that is where I think a lot of companies understandably feel that they need to. They need to kind of live up to what everyone expects of them. And that can be an extraordinarily expensive mistake. Because you are just shoveling cash into the furnace with the expectation that you're going to be able to start scaling some of the early signs that you have seen. And, you know, now back to Oxide, in our particular case, we had an even earlier stage problem, which is we had a lot of potential customer interest and we were still years away from having a product we

could sell to someone. So in our case, it was, you know, at what point in the development process do you start investing in people that are going to begin developing these customer relationships? And you have to, I mean, you do have to start developing those relationships long before you're selling a product, because in particular with the markets that we're selling to, you know, kind of the Fortune 1000 space and regulated industries, you don't have the privilege of just showing up and saying, OK, we're ready. You know, write a big check. You have to have really understood how that company operates. And you have to have gone through the fundamentals process of discovery and understanding,

what are the things that are driving their business and what are the kind of the highest order strategic imperatives in the company? And then how do those map to the, the product that you are delivering and, or what, what sorts of pain points are you solving for? So we did invest in that early, but kind of the approach that we took was trying to find someone who had the kind of had the versatility to come in and be a pioneer, someone who was sort of unafraid of blazing some, some tough trailheads, and that was able to be equally comfortable in a conversation where they were kind of the business sales front door for Oxide, but also had the depth and credibility

of a technologist. And so we were kind of looking for what some companies will call like a sales engineer, solutions engineer, but who was interested you know, interested and experienced in engaging with larger enterprises. But then we had kind of the next part of the equation that we had to figure out, which is like also find someone that was going to be willing to do this work for a year plus without having anything to sell, which is,

yeah, adds a little bit of complexity to the search because there are great, and I think this is where, forgive me, I'll get on my sales soapbox, but I think the sales industry generally can catch some flack slash be like routinely denigrated for some of the bad patterns that exist in sales. And there are plenty of them. And that is very well warranted in many, many, many cases. there also is and i've why it has been so deeply enjoyable to work be able to work closely with brian over the last 15 plus years is seeing actually how many surprising patterns there are between sales and engineering and uh and it is when when done right uh sales is a real craft. And it's a craft that is born out of, when done the right way,

it starts with deep, deep, deep curiosity about everything around someone and really deep curiosity about how products work and how technology works. And then deep curiosity about how this particular company ticks and wanting to understand what are the different constraints and pressures that are going on in this company and then in this person's role and uh and and what are the things that you you really want to understand if you are going to qualify mutually qualify whether this particular product is a good fit for them and vice versa. And so it is a, but at the same time, then you have the other side of sales, which is much more transactional. And what sales done wrong is more predatory. And it's it is it unfortunately can also stem out of curiosity.

But it's a curiosity around how you can convince someone to do something, which which is kind of the perverted sort of the dark side of where curiosity can go wrong. And and there are amazing, amazing salespeople that are very good at that, that are very, very good at that. And they are very good for their management team and their investors. And so and then you've got everything in the middle, right, which which is you have good salespeople that are good for certain stages of companies that are good when there is product market fit, and they're very, very good at scaling an organization, at implementing a system that provides a foundation for being able to bring in more team members and do it in a repeatable manner that allows you to start really building

that customer engagement across a much bigger market. But winding it all the way back we needed this pioneer we needed this person that was willing to to to deal with that kind of nuanced period before we really had before we had a product in market and long before we had product market fit and and yet this person was going to be super super load-bearing because they were collecting all of this important data that was going to inform, in some cases, decent shifts in how we were getting to a finished product. And in other cases, just slight little tweaks on what we were building up and down the stack. But we needed to make sure that we did not overemphasize that. I mean, we couldn't afford to go invest in three or five or 10 of these folks until we were getting closer

to launch. And I have to say, I think we found a pretty darn good one. We found someone who had really good technical depth and experience in the networking world, had been at Cisco for a number of years, Arista for a number of years, had kind of worked with companies big and small. And it was a hire that we had to get right. And it really helped the engineering team, the product team, kind of shape what we were doing and how we were getting that product to market. And Travis, who was that? Yeah, I can even call him by name. Exactly, that's the name. But Travis also, I think, has got exactly the right disposition,

which is a tough balance to hit of you need to be optimistic and forward-looking, but you can't have happy ears. And happy ears is, and there are plenty of, because sales folks can be kind of naturally optimistic and they get this kind of natural enthusiasm that can be infectious when they are actually not reading the customer exactly right and they think there's an opportunity that's actually that's bigger than it actually is or they think that they they have not read what they haven't totally understood what the customer is trying to do completely. And they earnestly, not out of malice, but they just, they end up believing that things are further along than they are.

And in some cases where they're very charismatic, they can end up closing a sale that makes no sense. And that's like, well, okay, but a up closing a sale that makes no sense and that's like well okay but the sale's a sale it's like well not not not really and because if you if ultimately what you're leaving in your wake is a customer that's dissatisfied or has something that they actually don't need they like that's a problem that's not a way to actually build a sustainable business like yes you got a sale congratulations you've got a quarterly number up there um but you haven't actually because because you you're not on the right foundation um and you know as an extreme example of that um you know at at joint we took our software software that we were running our own cloud on, and we sold it to other folks so they could run Elastic infrastructure on their computers.

And we signed a new customer who was very, very excited to be a Joyent customer. We were very excited, and it's like, okay, we closed the sale, great. And I'm on kind of like the first call to figure out what this actually looks like and i'm like okay so i mean one thing that that's important is like you know what are the the actual machines that you're running on this he's like i don't know like whatever machines you all ship me and like the the computer like the computers that you buy we make the software you buy the hardware and they're like wait what like so they literally had been led to believe and and this is one of these things where it's like i don't think that they'd necessarily been lied to i think that they had they had an enormous misunderstanding they were not corrected that they were not

corrected and this is like you know this is where it's like you're in a gray area right where it's like you know is that is it dishonest to sell to someone who has a grievous misunderstanding of the product it's like well dishonest is probably a bit strong but it's like not prudent to do that and you're gonna end up and in this case you're you like the customer's like well okay wait a minute then like i'm paying that amount just for the software like this is like a lot more expensive than i thought it was because i mean you're just like oh my god and you can be of course you're just like how are you possible how have you managed to like safely get out of bed in the morning um if you've got such because like the customer's

grievous misunderstanding at some level like this is on them right but the ultimately it was not a sale and because ultimately it's like that's not what they wanted and it was a huge waste of time and energy and effort and it came out of big time happy years but but it's a byproduct of a bigger problem though and the bigger problem was that that was that was one example of what was a rush into go-to-market. It was a company that raised a lot of money. And in raising that money, we're kind of influenced by those investors, some of which had a stake in the joint turning from a public cloud computing company to an enterprise software company that was going to then go kind

of quote unquote be the arms dealer to telcos everywhere that wanted to build their own aws's and that is an interesting idea and financially it sounds really good because now you can kind of be selling the picks and the shovels to this growing global world of federated clouds. And yet it had not been tested. So before testing, going and hiring a giant go-to-market sales army and marketing engine, because you can't sell without marketing. I say that with tongue squarely planted in cheek and you which by the way like marketing is its whole whole other topic which is incredibly important and when done right is company making but but you know building a top-down sales organization the moment that you've got a good idea and you've

got a little bit of market kind of like indicators and tailwind and themes is the kind of classic pattern that ends up not working very often. And, you know, you can do any of these to the extreme that, that, but, um, I think it is, it is super important and really healthy to, um, rather than that pattern of like, okay, and this is a pattern that we saw a lot over the last 10 years, like two technical co-founders, they look at each other and be like, oh, well, who's going to be the CEO? I don't know. I don't want to talk to people. You talk to me. You be the one to deal with those like investors and all those, like, I want to, I want to go build stuff. And that person's like, okay, yeah, sure. I'll do

it. And then start building the engineering team and start building the product and getting some good signal from customers and then uh you know it's sometimes getting gas lit a little bit but like getting told that like hey you need to bring in that that sales leader like you you got to have the the business person needs to be brought in and that is a point in which i think you know, those founding teams need to think very carefully about who that next hire is. And, you know, I will always make the case that that next hire should not be the VP of sales. That next hire should be that on the ground pioneer who is gonna go out and learn as much as possible, learning from the engineering team and the product team,

learning from these prospective customers that have come in enthusiastic and are like, oh, we totally need your product. And some of the best selling is digging in and understanding that that customer doesn't need your product and getting to a short no instead of a long no. And, and, and that's best for both parties and that you are going to hire a better VP of sales

with that next three to six months of intelligence that you can go gather. And the, the, the concern around the opportunity cost of like, yeah, but if we don't do it now, I mean, these things take so much time, you know, even to find a VP of sales to hire and onboard. And then for them to build their team, because they don't do that. I mean, they're not in the car. They're not, you know, in the meeting. Like for them to build the team that is going to go get then onboarded and warmed up. And, you know, we're not going to see real repeatable revenue for 12 months, 18 months. If we even get started today, we can't afford to wait.

And it's like it's actually the that that is the moment that your company hangs in the balance. And what you need to do is if you want to think about it this way, one way to convey this to to to your investors is like what I heard just a couple of months ago with a bunch of folks that are running go to market and big, you know, what you would consider kind of like big, big, big startups now. And they call it the third VP of sales problem. And the third VP of sales problem is that you is not even that there were three in this particular company, but in a company, you've got the first VP sales and they do a bunch of like heavy lift hard work, but guess what? There wasn't repeatability. There weren't real patterns. There weren't real kind of repeatable pain points and customer segments that they could go attack. So they would get onesie twosie sales

all over the place and moving too slow. And they got fired. Next VP of sales gets brought in and they kind of carry this momentum forward and they get to a point where they're right on the precipice of success. But again, too slow, they get fired. And that third VP of sales comes in and just crushes. Now, that third VP of sales crushing, the bigger problem that is building is for that next company that hires that person away as their CRO.

They found the absolute great white shark. Like we found our person. And they hire that person based on a pattern of success that they had almost nothing to do with building. As a concrete example, we the uh we were and i'm gonna anonymize this just enough we were referred to someone who's like this person is extraordinary they built company x they they were responsible for like they were built company x from nothing and are responsible for companies at company x's success um i'm like they arrived at company x after it was public i had competed this is like this is you know years ago but i like i i know this company pretty well and it's like they so you looked at what they were

claiming it's like they this this company had a hundred million dollars of revenue when you showed up and it's like you didn't build that hundred million dollars revenue because you weren't there when that was built and there's a big difference between having a hundred million dollars revenue and having 10 million dollars of revenue there's big difference having 10 million dollars revenue having one million dollars of revenue and the the10 million of revenue. It was a big industry having $10 million of revenue, having $1 million of revenue. And the kind of the, but the person that was referring to this was like believes in their heart that that individual was responsible for the success of that company,

even though the company they arrived at had already enjoyed quite a bit of success that they were not responsible for at all. And so this happens a lot, that third VP of sales. That third VP of sales, and that's the one who doesn't necessarily know that they've kind of force-gumped into this thing. And it's like, because they also may believe in their heart that they themselves are responsible for it all. And, you know, I always, the opening of The Simpsons, you know, where they've got, Maggie's got the little steering wheel in the car that Marge is driving. And I always think about that little steering wheel so frequently.

And what's going on in Maggie's car? Yanking the car. Yeah. Yeah, Maggie's's like i'm driving and it's like oh no no you we've merely provided you the delusion that you're driving and i feel that so often that third vp of sales i'm not to take anything away from them who can get who and it certainly may have had the prudence to realize this is a company that was that was in the right position but it's like very often it's like there was a company that was in the right position. But it's like, very often,

it's like there was a bunch that came before you that is responsible for laying the foundation that you are now believing that you've created. Well, and again, then to go back, I think it is not a question of should this early stage technology company hire a VP of sales. It is just making sure that they are thoughtful about the timing and the steps that should, in most cases, this is of course, nothing is uniform for all companies, but it really should make sure to learn as much as they can to hire the right one. It's just, it's really, really important to find the characteristics that are gonna be the fit for the stage of the company. And so you also don't get a situation

where you did hire a good one, but they bounce out in 18 months because you weren't prepared for them. And so, but it's hard. I mean, of course it's hard. You've got all this pressure, companies that have raised money. There are expectations where once the product is done, you've got to go scale. in a company's life cycle, because if you get it wrong, it is actually like an 18 month pause on the business because you have to go rip all that up again and then go like rebuild that again. When you have the right fit and, but when you have the right fit, it's gold because now to

speak to the value of a good sales leader in, in, in an organization. You know, these folks have a depth of experience around building the fundamentals for repeatability in the sales process, in customer engagement, building the right culture so that you have a culture that is anchored around responsibility for a customer and doesn't think about it in a transactional manner where it's like, to Brian's point, like, oh, I hit my quarter.

I threw my deals over the fence. Now I'm on to the next ones that I want to go land and hit my number again that are thinking about how these customer relationships are not measured in 90 days or 180 days but are measured in 90 days or 180 days, but are measured in like five years, 10 years. And when that is the case, when you have a culture where folks are thoughtful about that reputation and relationship, as you can imagine, there's more empathy for the customers. There's more curiosity and discovery and there's more discipline around when having tough conversations where it isn't a good fit for a particular customer and helping them understand that, you know, a prospective customer. And so, you know, there are really important, there's really important foundation that a good sales leader puts in place for a company.

It's just that so often we just see so many, so many, so many examples of companies either rushing in or being rushed in to that and then being entirely deferential to that all-knowing person. And it takes a very, very long time and a lot of money to realize how costly that was. So I both can tell the cautionary tale. And also, I think, again, when done right, it can be a company-making hire. It's a very, very important part of the team. So as you were describing some of the traits of a good sales leader or even the first person that you hired to get a lot of that data in the first six months, for example, I was just thinking about in my head for engineers or for companies who only have technical co-founders initially and don't have the salesperson on the team,

as you mentioned, CEO, whoever, maybe they flipped a coin and said, this person's going to be the CEO. They can also learn from the characteristics you described to play that role for the time being. And a couple of things that I gathered from what you said is, one is just curiosity. I think we touched on curiosity as a trait last time too,

like just be that curious. Yes. It's so good. It's so good. It is so imperative and it is, it's kind of, it's hard to overstate

how important it is and I guess I've been frustrated recently. So I think that when you look at a company that has a great technology but is struggling to actually build a business around it you often have behind that company folks that are actually in curious about how how it's being used and And so we saw a whole, and sorry, this is kind of under my fingernails at the moment because there was a whole era

where you had these open source projects that tried to build companies around those projects. And the projects themselves were wildly popular. But there were exceptions to this. But if you look, you can go through, there are many of these. There's not just one of these. There are many of these examples where if you talk to the people who are behind the open source project, they weren't that interested in why this thing was popular, how it was being used,

or how they would actually, in their mind, like the project is the product and it's the project is like super interesting to folks that's why people were using it but the product they actually wanted they wanted something more than that for the product and the you know again there have been there have been a bunch of these and i think that if you are and people have wondered it's like well okay so we can't actually ever turn it's impossible to turn an open source project in to a to a product and it's like well it it does require like more work and it especially requires some real curiosity about like what does someone want around this because often like by the way like some the things

that people want are like hey yeah i would love to have like ldap integration of this ad integration or i actually it's very important to me that the quality of the support experience is terrific around this and if you were the you know you're one of these vc funded open source projects you're like oh like quality of support like really that really? That's, oh, man. Like, AD integration. Like, I don't know. That just does not sound, that's not that exciting. It's like, okay, then you should not,

just, like, don't go into business. Like, that's fine. Just don't do, just the, or find someone who's more interested, because you've created something that people are using. Get curious about why they're using it and how it is a part of the thing that they're building. Get interested in that.

Because it is interesting. I think this is, you know, I think that that curiosity is something that really binds us as a company. Certainly, like, I mean, like if you're the kind of person who, if you're going to like nod off at a factory tour, not be interested in, you you, like, I'm going to take you inside of my business and show you what my business looks like, that should be really interesting to you.

And especially if that person is going to be like, oh, and by the way, here's how your thing, I envision your thing might fit into the thing that I'm doing. That should be like lighting you up. And if it doesn't, you should really question whether you should be starting a company around this. So many engineers who are not necessarily finding a company right now or starting a company right now, but they're working at another company. And in their heads, they're like, at some point in the future, I definitely want to start one. And I think at that point, for them to be in a position where they can do a little bit of the go-to-market work when they don't have let's say the right product yet or they don't have the

salesperson yet what are some of the things that they can start doing from even now at their current job to just kind of groom the skill a little bit because this takes a lot of practice and i think all engineers would be better off if they were good at talking and at selling i would say and selling is a skill that i think everyone should have but what are some things that engineers can do to get better at this yeah i think the last time steve suggested taking someone to lunch and understanding what their their pain points are. Someone else in the company. And that remains really good advice.

I think the other advice that I would add to that is go take a customer to lunch. Go sit with an actual customer. You know, if you're an established company, great news. That company has product market fit at some level. Like that's putting, I mean, I don don't know maybe you're at one of these like vc fueled disasters that like literally has got no customers but hopefully not hopefully not hopefully you've actually got customers and you like go sit with those customers and understand what how they're using your thing and why and you know even if that's just confirmatory even if it's just like oh this is why the thing that i'm making is important to to you as an end user of this thing i just make those

connections and i think in some companies that i think that you know these companies do themselves an enormous disservice i think google does this infamously, where it's really, really hard for a Google engineer to go understand what a Google user is going through. But it's like, come on, you're at Google, you're smart, go figure it out. Like, go find one. Like, you know, go like, yes, you're gonna, I get it. You're gonna need to go, you know, fight through some brush to get there but go get there go to a customer and get again get curious about how and i think that's a a way that you can start to build that interest because you're also going to see just as steve said last time you're going to see a whole bunch of problems that you yourself may have perspective on and i think i was going to give a similar answer on go meet with customers.

And when you meet with customers, you know, at minimum, figure out, you know, how they are using your product and why they chose the product in the first place and what they considered in terms of alternatives. What were the alternatives? Why did they not choose the alternatives? And that'll start to elucidate some of the thought process of what goes on behind the walls when a company is contemplating making a buying decision on anything. And then even better if you can get into understanding what that person's world looks like personally. And not personally, personally, but personally in that workplace. And what are the things that make them doing their job difficult? That may be specific to that company, but oftentimes these are pretty repeatable patterns where it's like, yeah, well, you know, unfortunately the finance team just doesn't understand the value of, you know, what this brings to the business. And it's like, well, how do you articulate that value?

Who articulates that value? And they're like, well, that's the problem. It it's like, well, how do you articulate that value? Who articulates that value? And they're like, well, that's the problem. It's honestly like, no one can. They're just literally looking at the bottom. Now I'm denigrating finance. There's a lot of finance, incredibly important as well. But then, or you're getting an answer where it's like, oh, well then this person in the organization

is who has to go deliver that message. And that is incredibly important information to be gathering about how these bigger organizations work. And getting into some of the fundamentals about, you know, what is the buying process in an organization? And who are champions? Who are coaches? Who are the decision makers, who are the economic buyers. And when you kind of come back to building a good sales culture in that company that this person has now started and they're looking at how do we go start to scale this, there are some real frameworks that you want to get in place. So again, you have repeatability but back to that person at the company today, there's so much opportunity to learn

from your current customers. That's where definitely is the best time spent for sure. And also just understanding things that have nothing to do with the product. Like, you know, you go read the 10K of that customer and just look at the risk section that get called out in the earnings. And like, because again, these are the things that are weighing on the executive team that are getting pushed down in the organization. And sometimes that person that you're having lunch with actually doesn't understand why this person is requiring a certain team to do things a certain way and there are plenty of cases where like there's perverse incentives or perverse

punishment that's coming down from pissed off investors or a board or these kinds of things that you can actually kind of glean out of those quarterly earnings reports that are all public information if you're curious i i tried to do like a version of this not great um at my first job and then sort of the pushback i think from like management was sort of like yeah do not put an engineer in front of the this was like enterprise uh sas and he said do not put an engineer in front of the customer and then you know let him go on about you know stuff so stuff. So that was a bit hard, I think, to just like directly trying to,

because, you know, these are like pharma or like kind of like, I feel like- Okay, so a suggestion there. If you're, if one finds themselves in that same situation, there's an easy answer, which is like, don't put me in front of a customer. Put me in front of a prospective customer that you think we have 0% chance of closing. Put me in front of someone that you think is like a dead lead i mean again there's a certain

uh if if the person's non-responsive it's kind of hard to you know but but hey uh who is someone we talked to that went with somebody else and i will tell you an engineer has a much higher probability of getting a next conversation with that person than anyone in the sales organization and you're going to be able to and you've got this credible like hey i'm an engineer i built the product reaching out because i would just i'd be so deeply grateful if i could get any feedback about how you think about just the problem space we know that we're not going to be a fit for you all. Like you're not going to be a customer, but man, it would be helpful to understand this. And you may have to reach out to four or five of these dead prospects to get one to agree to take a meeting. But, oh, man, you walk back with the information learned in that meeting and the CEO, like anyone in the organization is like, where is he?

We need him in the room right now so we can figure out like what we did wrong in this case. And you're going to get the other side of it. You're going to get why the customer didn't buy. And it may be product related. It may have nothing to do with product. It may be like, honestly, the rep didn't get back to me for seven days. And by the time they did, I was already, you know, down the path with this other person. And so I would, that's an easy one because the sales organization thinks that thing is a, not even a 1% chance, it's a 0% chance. So why not? What's the harm? Nothing to lose. Nothing like that. So to your point, and then, so what I tried to do was then to basically go to the account management side and then make friends with like an account manager and then sort of use

that as like a proxy. And that was like to a point like super helpful I was like oh I had no idea like this is how like they use the tool I was like very clueless but yeah like learned a ton from just like having even that perspective as a proxy yeah so quick time check we have about eight minutes I had three questions written down but I think we can only do one to wrap up so I'll list the questions and you get to pick okay so what one question I had was around transparency in sharing challenges with VCS and team members so for example when you're building the product at times as you said the machine is in booting so you don't have a product which means you

don't have a company how transparently do you share that with the team and the VCS as well? Because I've seen two versions of this, not necessarily in terms of a startup, but even at big companies, this glass of optimism, which everyone can see through, and it's like, that's bullshit. Or the other version is being very transparent

and sharing that. Go ahead. That's a short one. We can knock that one out in like 60 seconds, I think. Yeah, so I mean, so you've got to love the bad news. Yes. And you have to, you know, you know, a good,

I've got good news and bad news. Everyone should want the bad news first. Like, give me the bad news. And we, you need to be in an organization which it which includes like your potential investors and board where i know i want the bad news i want to know the bad news first like the and you want to be able to like you know give me enough context so i should you don't want to just like induce panic and everybody all the time but it's important that we have the bad news and that you're able to get.

So you need to be transparent about that. You've got to be transparent. But bring the bad news with one of two things. Either A, a concrete ask of who you're bringing the bad news to of some action you want them to take or with a having already thought through mitigation options for the bad news so either come with like here's the path we're going to be on you do not need to take action or i need you to take action and here's the action i need you to take the worst possible thing you can do is just drop bad news on the table and just say like i don't know we got it all figured i know like you tell me you love bad news so here's drop bad news on the table and just say like i don't know we got all

figured this i know yeah like you tell me you love bad news so here's some bad news it's like it's a little more nuanced than that yeah because i love that i love that those two actionable bad news i like actually bad news or having the mitigation for it i think that makes perfect sense and i think that we in terms of like our investors for example there's been plenty of times like look here's the issue we've got here's what we've done to mitigate it here's what we're just like this is purely informational you don't and i mean i think virtually those conversations are always like okay thanks for letting me know that this is obviously very high priority you know keep me abreast of any details and you know great that, great. That's what people want. Good advice.

Okay. Next two. Let's see if we can do those two. Let's do it. We're knocking them down. The first was GPUs. So right now, I think the Oxide Server Act comes with CPUs only, AMD CPUs, if I remember right. And you see so much investment going on just building out data center capacity with GPUs.

Is that a direction that you're planning to pursue with Oxide? It's definitely interesting. I mean, obviously, and the accelerated compute is extremely important, and there are different ways in which it's important. These training workloads are a little less interesting to us for a bunch of reasons, in part because the real value that we bring at Oxide, holistic approach, ease of management, multi-tenancy, running stuff on-premises, these training workloads don't look like that.

Training workloads are kind of these dragsters that you take out with ultra-high-speed networking, huge amounts of GPUs and data the gpus like are popping all the time you've got reliability problems everywhere they are then doing a bunch of things to kind of compensate for the reliability problems and then like when you it's like bitcoin mining like you're done with it you can just like push this infrastructure into the ocean i don't care by the way i need twice as much money to build the next one and like that is a little less those workloads are a little less interesting um and also like the folks that are that are really

running those workloads aren't oxide customers anyway they're they're their own hyperscalers right they're they're the ones that are actually you know building their own power plants and so on. That said, I think what's very interesting to us is on the inference side. And I think that something that we're very interested in is what does it look like when we're doing a lot more inference in a lot more parts of the stack. And that looks like having, I think we're going to see the middle get muddy with respect to CPUs versus GPUs. CPUs adopting instruction set extensions that allow that inference to happen on CPU. And then also going to APUs

where we have these, you've got cores on die that are accelerated cores living alongside general purpose cores, is very interesting to us. So the MI300A from AMD is a super interesting part to us. Turin is the next generation AMD part that has things like AVX512, which is an instruction set extension just to kind of put some concrete meat on the bone there. And that's really, I think that, you know,

if you assume, which I think is reasonable to assume, that the rise of LLMs, generative AI, there's a lot that's real there, right? This is not crypto mining. There's a bunch that's real there. Because it's real real we are in this is going to be a a multi-decade trend this is not something that is going to evaporate in the next two years so we are much more interested in what does the intersection look like when this is in

that kind of mainstream on-prem enterprise and to us that that's got to look less like these kind of ultra specialized workloads and it needs to look more mainstream with respect and it needs to look less like repackaging of gpus and 1u chassis and has to look more like rack level infrastructure that includes cpu and gpu and the networking substrate and rack level power management and a control plane that goes from workload to all the resources underneath in a high efficiency manner and you know the NVIDIA has definitely demonstrated this playbook with the acquisitions that they have made they want to own all five of those points and be able to deliver a rack level solution around it and the good news such as it is is that we've been at work for five years now on four of those points and be able to deliver a rack level solution around it. And the good news, such as it is, is that we've been at work for five years now on four

of those five, a cloud computing control plane, rack level power management and networking management, controlling the network, having the CPU by way of obviously our partnership with AMD. And we just now need to figure out what the right hardware acceleration component is to integrate in to deliver a robust solution that is going to fit, as Brian mentioned, this more general purpose AI landscape in the next couple of years. So we'll definitely be participants for sure. It's just a question of doing it the right way.

And unfortunately, that question was too meaty. So we're now out of time for the third question. We got another six minutes. We got six minutes. Okay. All right. The next question kind of ties into this one, which is I saw this tweet recently where someone mentioned that they see this trend where companies now want to move out of public cloud, where, like, if you look at the last 10 years, everyone wanted to get into public cloud.

But I think Basecamp is one of the examples where they started blogging about their, like, this is how much it costs. We are going to move out and run our own cloud and it costs so little. So curious to get your perspective, like, do you see this trend overall in the customers you're talking to as well? Yeah, I think the trend that is absolutely the case is that five years ago, everyone got to the end of their probably five year evaluation of public cloud and said, public cloud computing as a architecture is the future. Like this notion of having programmable API driven elastic infrastructure resources. I want that. I want that foundation for all of my software deployment and management and operation. And so because of that, I am now gonna tell my board,

I'm gonna tell my investors that we are shutting down 80% of our data centers, and we're moving all this to the public cloud. And what's happened over the last five years is in various states, these companies have gotten 20% of the way through that project and been like, whoa, wait a minute, wait a minute. Why does this not match the spreadsheet

that I presented three years ago? Cost or data transfers, surprising one to many people. Yeah, what is this line item? I don't remember seeing this on the proposal. But the economics of renting are difficult for vast, large, persistent workloads over longer periods of time. And that does not take anything away from the value of cloud computing. I think that is not what gets mistaken in this narrative right now of the cloud repatriation of like, oh, we off the public cloud we don't want the public cloud anymore has absolutely nothing to do with the product uh in and has everything to do with the difficulty trying to push the entirety of one's

business into that model into a rental model into a model where it runs in you know eight regions instead of 80 locations uh you know where a model of share everything not share everything but a multi-tenant model that regulators are not totally comfortable with yet or that creates a a vector for attack that people are not comfortable with whether that's reasonable or not and so i think reasons that include economics governance not being able to control and understand what the dollars are being spent on security latency um is is why these are slowing i think it's actually a slowing of migration to the public cloud more than it is everyone running for the exits and people saying wait a minute i'm sold on the benefits of cloud computing as an architecture but i can't put as much there as I had hoped. So now what do I do? How do I square this?

And then yes, at the same time, you also have a group of kind of a part of the industry that maybe grew up 100% in the public cloud and are looking at the economics or the lack of control over the quality of the product underneath them. The inability when their customers are pissed off because something went bump in the night to tell them like why it did, when it will happen again, what they're doing to mitigate it. You it. Unfortunately, when you are outsourcing all those layers, you're not gonna have the best answers to your customers when they're frustrated about something. So maybe it's wanting to take more control

over the experience delivered to your customer. Maybe it's because you wanna lower latency. Maybe it is economics. There are another group of companies that are saying, hey, being 100% public cloud born is not enough. And all the way to the extreme of like, I'm leaving the public cloud. But I think, you know, 98% of this driving force of on-prem kind of coming back into favor and this conversation happening about, wait a minute, not only is it not dead, it's like, this could be one of the biggest growth areas ever

in the next 10 years is much more around people trying to answer the question of how do I get the benefits of cloud computing everywhere my business needs to run? And how do I, if I'm a cloud SaaS born platform, how do I double the size of my business in the next 10 years? It's going to be tough to do that if my total addressable market is only the data people put into the public cloud. So how do I go extend my platform to reach all the data on the planet? And to do that, you have

to have this hybrid model where you're using public cloud, using someone else's cloud infrastructure on a rental basis when it economically makes sense. And you're using your own, but you know, I mean, the reason we started this company is that you should be able to own the computers that run your cloud for the rest of the use cases, where from a perspective of economics or security or latency or other, makes the most sense. And when you're doing that, you shouldn't have to have this fractured front end to the system. You should have this same elastic infrastructure resource and API driven kind of primitive

that is in all sides, rented or owned. That's very well put. I know we can keep going, but we are at time. Steve and Brian, thank you for being so gracious with your time. We love our conversations with you. And hopefully, again, we'll chat again in the future at some point. But again, thank you so much for today. And also, thank you for showing us the office space plus the rack.

That was super cool. Okay, we have to end where we started last episode in the meet cute, which began with a person who had reached out to Dell with an inquiry and had submitted a web form to see if they could get someone's attention at Dell because Sun Microsystems was not paying them any attention or sufficient attention And here's this going Just you wait What wild coincidence or stroke of fate while we were recording this? That same person reached out to oxide And and that person's reach out to Oxide starts with the following I had met

Steve about 20 years ago via a web form I was hoping to do the same again we're looking for a VMware replacement and we're gonna be scaling our control plane across more sites so we are again going to be reaching out, and it is a nice closed loop here on the first and second podcast episode. Incredible. Incredible. Thanks for sharing that. Yeah, thanks for sharing that. I had to get you on a podcast. Awesome.

Any other company updates that you want to share with me via a podcast? Now that you mention it. That's right. You've got some tough news. Yeah, got some tough news. All right. Thanks, guys. It's been great.

Thank you so much. This was awesome. Take care. Take care, guys. Thanks. Hey, thank you so much for listening to the show. You can subscribe wherever you get your podcasts and learn more about us at softwaremisadventures.com. You can also write to us at hello at softwaremisadventures.com. We would love to hear from you.

Until next time, take care.