Building a Culture of Reliability with Adam Bahret, Owner and Reliability Engineer at Apex Ridge Reliability

(Intro Narrator at 00:00:03) Hello, my friends. Today, Joel is talking to Adam, the owner and reliability engineer at Apex Ridge Reliability. And they discuss what it's like consulting for companies like Boston Dynamics, Boeing, and Amazon Robotics, how to see crazy high ROI from reliability engineering, and why it's imperative to catch errors in a product early. All of this right here, right now, on the Modern CTO podcast.

(Intro Narrator at 00:00:35) Here we

(Joel Beasley at 00:00:35) go. This is the Modern CTO podcast. I saw you did something with Boston Dynamics, those robot dogs. I was in the prep meeting, we were talking about it, and we're like, what? Did you make one of the dogs?

(Joel Beasley at 00:00:55) What did you do with them?

(Adam Barrett at 00:00:58) Yeah. Back in 2013, actually, it's crazy enough. Boston Dynamics was my first customer when I started as a consultant. And what I was working with them on was actually the robotic mule. So it's the size of a horse.

(Adam Barrett at 00:01:13) So it's a predecessor to the Spot that you see out there now. And this thing was crazy. I mean, it was the size of a horse, right?

(Intro Narrator at 00:01:20) And it's

(Adam Barrett at 00:01:20) and what was really neat is we had this one day where we did testing in the woods with the Marines. So you had that classic, like, how we always treated it, and then you find out how the customer treats it. But in this case, this is war-hardened Marines, so it was even up a level. We didn't realize they used everything as a battering ram. They were taking this mule that we so carefully loved and crafted and just running it into the trees and through bushes and everything, which was fantastic.

(Adam Barrett at 00:01:48) So myself, as the reliability engineer, I come in with a very different perspective than the designers. The designers are designing something and they want it to work. They want things to stay nominal. In my mind, the failure rates that exist for this product are always there. Eventually, somebody will find them.

(Adam Barrett at 00:02:05) And I always hope we are lucky enough in the limited amount of time we get with the product to find it. And that's exactly what happened. And the craziest thing was, for this testing day I was doing, Popular Mechanics came out to do an article on it, which I was like, what? It was great. And they snapped this one picture, and you can still look it up online in Popular Mechanics, the article.

(Adam Barrett at 00:02:26) And what had happened was they had run it through a tree that was like three and a half inches in diameter. And it went right into the shoulder, and it broke the protection we had in the shoulder and ripped out a sensor. And the article right under the picture, the quote is, it sucks that I broke it. And it was one of the Marines who was driving it who said that. And you can see the engineers are all bummed out.

(Adam Barrett at 00:02:48) I'm the only one who looks happy in the picture because what had occurred was any tree size smaller than that, it would have pushed down. Tree sizes much bigger than that, it would have hit and then gone around. We got so lucky that I later figured out between a three and five inch diameter tree was exactly our Achilles heel that would go in there, fit just right, and be strong enough to break the shielding. So to me, I was like, this is gold. The fact that we got to experience this and see this and now make design changes to mitigate it, this is treasure.

(Adam Barrett at 00:03:22) I'm so happy because, in my mind, I want to find everything that can go wrong with it because, in my mind, those issues exist whether you see them or not, and somebody will eventually. That project was so cool. After that project is when they decided to do basically what became Spot, the small dog. There was a couple of big things that changed. One was scaling it down because we realized the energy we were consuming, we had to carry so much fuel and whatever potential energy we could carry in whatever form, electric or gas, that it was burdened by its own weight and couldn't do a lot of things for the Marines.

(Adam Barrett at 00:03:59) And shrinking down to the dog size and making it entirely electric, all of a sudden, all the ratios worked really well, which is why you don't see electric airplanes yet. You see electric cars, right? Because when you scale up high enough, the equation doesn't work anymore, which now battery energy density is about to get to the point where airplanes will work. But yeah.

(Adam Barrett at 00:04:23) So then at the end of that program is when Spot was born, and I worked with them for a while on that. And it's out on the market, which is really cool.

(Joel Beasley at 00:04:32) That's crazy. I get updates. I'm on the email chain, so I get updates as the price changes. They've come down in cost a little bit. Yep.

(Joel Beasley at 00:04:39) I get updates for when they're doing new things with the SDKs and whatnot. So I was curious to ask you, because I'm thinking about reliability engineering at this moment in time through somewhat hardware, but typically people are talking about servers. So most of my reliability conversations have been about web applications, right? So is there a difference in principles between when you're dealing with reliability engineering, doing physical products like a Spot type dog, and then web servers, or do they transcend that? Explain the difference there.

(Adam Barrett at 00:05:12) Yeah. So pretty much the partition is electromechanical and then software. So when you say a server, server obviously has two very distinct components. You have the hardware, the electrical system or whatever mechanical system, which is usually based around cooling or hard drives that aren't steady state, and then you have software. And so when you're looking at engineering technology from a reliability perspective, that's a hard partition because reliability is fundamentally the study of how variability affects performance.

(Adam Barrett at 00:05:44) If you have a design that works, a technology that works under nominal conditions, it works exactly as you intend. So we're looking to understand what variabilities can exist and how it affects performance. And so for electromechanical, the three primary variabilities are manufacturing variability, use variability, and environment variability. And with electromechanical, the first thing you want to do in understanding the design and its performance now from those variabilities is, there's three basic types of failures. There's early life, which are driven usually by quality manufacturing defect, primarily.

(Adam Barrett at 00:06:21) There is use life failures during life that a lot of times are categorized as random failures because there's a bunch of distributions mixed up. And then in the end, you have wear out failures. And this is really the way the life of a good product ends, right? This is where you have a degrading characteristic from a stress.

(Adam Barrett at 00:06:41) I like to use talking about a car tire as a way to describe those three failure modes where, you know, the tread wearing down in a car tire is a wear out failure mode. But that's how it's supposed to end if it did its job. If you had a chunk in it break out when early in life from a bubble, that was a quality defect, right? And then you have random failures during life from variability in use and other things that happen and you get a flat tire.

(Adam Barrett at 00:07:07) So that's electromechanical. Now software, software doesn't have manufacturing quality defects. That's not manufactured. It doesn't have wear out, right?

(Adam Barrett at 00:07:16) Because it doesn't wear out. There's nothing being consumed. So what it experiences is variability during use life of combinations of inputs and outputs that drive failures. And what is so fascinating to me about that and why it's an entire, you know, I work with some people in software reliability who are specialized in it, and I'm just always amazed, is

(Intro Narrator at 00:07:41) one of the

(Adam Barrett at 00:07:42) big differences is not studying how the product, how the software performs. It's studying how it was made is one of the best ways to predict reliability, which sounds intuitively strange. But then when you stop and think about it, if there's no variability in manufacturing and there's no wear out, the variabilities that occur are variabilities of input, combinations of inputs that you've studied, right? So picture simply your cat walking across the keyboard, right? As a simple kind of concept, that's a set of variabilities that you wouldn't have done before, right?

(Adam Barrett at 00:08:06) It's like mashing five keys at the same time. And how does it respond to that? And it's an infinite combination of things to study, so studying it is difficult. But if you look at best practices and methodologies in developing software, you can predict trends of the likelihood of what's going to happen. And of course, at that point, it gets very interesting and complex. But here's one simple kind of basic concept: if you do a methodology while you're developing, like object-oriented software, if you look for, study lines of code as you're developing each object that don't get used or get used at a low frequency, and if you do that and either eliminate the ones that don't get used under your normal functions or not, that dramatically changes the likelihood of, reduces the likelihood of a failure because effectively, that's like stepping on a mine, right?

(Adam Barrett at 00:09:02) It's a place you've never stepped before. It never got tested in all the debugging, things like that. So it's very interesting, the different strategy, and the reliability curves look dramatically different.

(Joel Beasley at 00:09:14) How long have you been doing this? You seem really smart.

(Adam Barrett at 00:09:19) Well, thank you. And also I'd like you to speak with my two teenage daughters who have a different opinion. But so yeah, I guess, I mean, I started my, my bachelor's in mechanical engineering in the early nineties. I went off to Europe and did diesel engine development over in Europe for supertankers. It was like 90,000 horsepower, four-story tall, turbo diesel motors. You could walk inside the crankcase.

(Adam Barrett at 00:09:50) I did a lot of piston and cylinder design. I designed pistons that were six feet in diameter, so like my wingspan. My career at that point was very much finite element analysis, which is the mathematical modeling. In that case, it was structural and thermal, so I had optimized piston shapes to be the best for thermal and structural and vibration analysis. After a few years of that, I came back to the States, and I ended up working in semiconductor and ion implanters.

(Adam Barrett at 00:10:17) And ion implanters, the size of a trailer, basically the size of like three car lengths. What it does is it creates a plasma arc cloud in vacuum, accelerates it, and manipulates the beam with 5,000 pound magnets and those robotics, ultimately shooting ions in the silicon crystal to make microchips. So our customers were Intel and Motorola, people who made microchips. And nobody grows up wanting to be an ion implant engineer because nobody knows what it is, but holy crap, I loved it. It was because they were inventing physics there.

(Adam Barrett at 00:10:50) There was this whole physics team in R&D. I was in R&D and I thought finite element analysis would just be a small early part of my career. But then I ended up starting messing with the physics guys because, at that point, I was running the FEA department. And they were like, oh, could you do some FEA for magnetic fields? And I was like, yeah, I'll learn that.

(Adam Barrett at 00:11:08) That's cool. Can you do FEA for the ion beam optics? Yeah, totally. And I just kept going and going and really helping these guys push the frontier of physics with, you know, supporting them with this engineering and analytical. So I got to cross over there. And actually, I'll be honest. It's the only time in my career where I really realized, I always felt that I could do a Herculean effort and learn something new and whatever. That was the only time in my career where I hit a hard wall and I really realized that I wasn't these guys.

(Adam Barrett at 00:11:37) They all were way smarter than me. They all pioneered stuff. They all had PhDs in physics. It was really funny. I realized that turnaround point that I was so far beyond my abilities and that I was able to do these analyses for them.

(Adam Barrett at 00:11:51) What was happening was usually I could use these analyses and results to make better designs. And once I got into the physics side, I would be able to do the analysis and they're like, what do you recommend? And I'm like, I don't know. I don't know. I got the answer for you. I don't know what to do.

(Adam Barrett at 00:12:07) So what occurred next was, the history of reliability is interesting in how it's integrated into technology over time. This was then around 2000, I guess, early 2000s. Reliability is really more the focus of the testing to generate data to do analytical work. Whereas the finite element analysis work I was doing was really much more of, you're doing it entirely as a model, a math model. So one day I was, and most companies, their reliability initiatives are scattered and just people dabble in it. One day I was walking to the bathroom and I heard my name yelled. A director was like, hey, Adam. I was like, what?

(Adam Barrett at 00:12:52) He's like, we're kind of curious on understanding reliability engineering a little more formally. Could you look into it and write a paper? And I was like, sure. I'm like, I'm going to the bathroom first, but I'll get around to it and I'll do it. I did seriously say that.

(Adam Barrett at 00:13:05) And so I did. I wrote a little paper for them and they kind of liked it. They're like, do another one. Would you do another one? I was like, sure.

(Adam Barrett at 00:13:13) And then I kind of saw the really cool discontinuation of my career with now designing specific tests to generate data to improve design and stuff. And they said, look, we want to start a whole department here, a reliability engineering department. We're thinking that if you're interested in kind of redirecting your career, we'll grab a 30-year industry expert. We have one in mind whose whole career was like IBM and Dell and stuff. And maybe you and he could build this department and kind of mentor you.

(Adam Barrett at 00:13:43) And I was like, I always love a new challenge. I was like, yes, absolutely. So we ended up building this reliability engineering department with two labs internally, and it was so cool and so much fun. And I was kind of going up the chain of command there. I had an executive mentor and all that, and I kind of realized how much I didn't want that, to be honest. I didn't want to get that far away from engineering, basically. I watched people go up that chain and it's like engineering was just a thing in the past, right? And I also just, it wasn't of interest to me.

(Adam Barrett at 00:14:29) So, and I didn't want to just keep running this department because that guy obviously was going to retire, and because I don't like static, I kind of always want something new. So there was a company that, a medical company that was 50 years old, kind of the same thing where their reliability initiatives were scattered and they wanted to consolidate it. And it was super cool. It was blood analysis instrumentation, so microfluidics and robots and all kinds of really neat stuff. So again, this is kind of like amazing cornucopia of technology and all new to me because I didn't know blood analysis stuff. And they were looking to build the department and through word of mouth we found each other, so I went there and I built another department, a reliability department.

(Adam Barrett at 00:15:02) And then again, the same thing. After five years, I was like, this is about the right size. I don't want to go up chain of command anymore. I just didn't love that as much.

(Adam Barrett at 00:15:15) And I also kind of have a habit of just, I'll say whatever I'm thinking regardless of the person's position I'm talking to. So I would go to the executive steering meeting and to the CEO, I'm like, what we're investing in is bad. And I like that guy over there is really into it. But I'm like, I'll just flat out say it. I'm like, this is a bad idea and da da da, and I disagree.

(Adam Barrett at 00:15:36) And some people appreciate that and some don't. So then I was like, alright, what am I going to do next? I don't want to just keep running this department. And that's when I left and started Apex Ridge.

(Adam Bahret at 00:15:48) I'm like, you know, consulting fits me. I want the adventure. I want the fast-paced, diverse, constant, you know, feed of information, and it just fits so well. I mean, it's terrifying. I was, you know, two young kids in elementary school.

(Adam Bahret at 00:16:02) You got a mortgage. I was, you know, in my forties. Or, you know, or no, actually, I wasn't even 40 yet, I think, when I started. I think it was late thirties. And yeah, I mean, so basically, I learned about the difference between the animal brain and your logical brain. And when you wake up at 3AM, the logical part's asleep and the animal part's awake and you're like, what am I doing? This is nuts. So really solidly for three years, I would wake up at two or three in the morning and you just are like, what am I doing? You know, but then, you know, then you really get up in the morning and you're so excited to work. So I started at Apex Ridge and like I said, right out of the gate, my first customer was Boston Dynamics.

(Adam Bahret at 00:16:42) I was like, this is gonna work. You know, this is, this works. And I knew it would work because I kind of knew everybody. You know, it's one of those things where I knew everybody in consulting companies, in industry, and I was always involved in so many things. And, yeah.

(Adam Bahret at 00:16:56) So, you know, my customers are, you know, since then have been all household, you know, big household names, Boeing, Amazon Robotics, Hyundai Motors, Keurig Coffee, tons of, you know, medical companies, Boston Scientific, Medtronic, Covidien. And, yeah, it's really neat. And so I do in the same day, I'm working, you know, I have a couple projects going. One, I'm doing a surgical robot where the surgeon doesn't even have to be in the room to operate. And then, you know, on the other side, I'm working on, you know, a device that if there's a, you know, it's able to handle EMP blasts to control power line stuff.

(Adam Bahret at 00:17:34) And another one's with FLIR, a small camera that goes on a helicopter. It's really fun. Yeah, I've written two books. The first book I did is with a friend of mine, Mike Silverman. It was about the reliability toolkit.

(Adam Bahret at 00:17:51) The idea was that, well, for me, why it was important was so many reliability engineering books were written for reliability engineers to advance them. And to me, that fundamentally goes against the design for reliability philosophy because the design for reliability philosophy is that everybody designs in reliability, right? There's a more fundamental DFX philosophy, which is the X is whatever you want it to be. You know, design for quality, design for a cost point, design for manufacturing, design for, you know, ergonomics. So in that idea, you don't have specialty departments adding things later.

(Adam Bahret at 00:18:29) You can't test in reliability. You can't, you know, that idea that you can add things later. So everybody should have some basic understanding of the tools. And there really wasn't a book I felt that did that well. So my first book, How Reliable is Your Product? 50 Ways to Improve Product Reliability, kind of gives a good overview of the design for reliability toolkit that really anybody who's technical can pick up.

(Joel Beasley at 00:18:51) That one is on Amazon.

(Adam Bahret at 00:18:53) It is on Amazon.

(Joel Beasley at 00:18:55) There's a Reliability Culture. Is that the one?

(Adam Bahret at 00:18:58) That one's on there too. Yeah. Both my books are on Amazon.

(Joel Beasley at 00:19:01) I want people to be able to find this. I was on your culture book. All right. Let's see. Reliability Culture.

(Joel Beasley at 00:19:08) How Reliable is Your Product? Yeah, it's there. You're by Mike Silverman and Adam Bahret. But, a quick search, it adjusts to this too. So there it is.

(Joel Beasley at 00:19:17) You could just type in How Reliable is Your Product, 50 Ways to Improve Your Product Reliability. And then the other one is Reliability Culture. That one came second, right? That's a new one, Reliability Culture.

(Adam Bahret at 00:19:27) Yeah. Reliability Culture just came out this year, actually, January, and it's published by Wiley. And here's how that came about. So through all my experience as an engineer, somebody who, you know, built departments from scratch, somebody who, you know, as a consultant sees different cultures and companies at a very high pace, there's a fundamental element that I've always seen that's a bit unique to reliability engineering, and it has a disconnect from the higher level program, business objectives, and program and product objectives. It kind of always has had that a little bit.

(Adam Bahret at 00:20:05) I can talk a little bit about the history of what I see for reliability, you know, how reliability engineering has progressed. But what kept happening was, as I would come in and work with technical teams, I had so much to say about how it should connect to the program and business that I began to develop tools to help leaders do a better job getting the maximum return on investment from their, you know, investment in reliability and making better designs. And that kind of caught word of mouth. And other leaders wanted, like, oh, what is this tool you made called focus rotation? What's this bounding idea you made?

(Adam Bahret at 00:20:37) So I even started presenting it at conferences. I actually got invited to present it in Stuttgart, Germany at a conference once. What happened was, I kept seeing over and over again that there was a lot of need here. I was onto something that the next phase for reliability engineering and making reliable products is within the leadership part. I mean, right, we all know the Toyota way. Right? I mean, that's the same thing, right, for quality is that the Toyota way was you can't just have a quality department. You have, quality has to be fundamental to the culture. So, I mean, I'm not truly, I'm not trailblazing in an insane way here. You know, I'm doing something that's, you know, with regard to reliability just hadn't quite happened yet.

(Joel Beasley at 00:21:21) Yeah. There's, like, Amazon. Right? They're pretty popular for how they do their leadership. You got Netflix. They release their decks. So, yeah.

(Adam Bahret at 00:21:29) Yeah. Yeah. So, what kept happening is I would work with, I'd be brought in by, you know, middle level leadership or even higher leadership would, you know, want me to come in. But then I would be working with the technical teams. And before I knew it, the CTO would be like, hey, Adam, can we do one-on-one meetings with you and me every week?

(Adam Bahret at 00:21:47) You know, like, just kind of like on the side, you know, because, like, I think you can help me with this and that. And, so my tools kept developing more and more and, Wiley, through, you know, some connections we had, were like, you know, this is something we would like to see happen, you know, be published. And it became a book. So Reliability Culture is out now. And, it's really exciting.

(Adam Bahret at 00:22:11) And now I've started to change my services to really be where I come in now and directly with executives and help them directly rather than that way that was happening before where I kind of floated up from coming in the technical part. So now I've really divided my business into both working with technical teams, you know, to help the engineering teams understand, learn, and apply the design for reliability toolkit, is best, you know, a great way. But now I also work with leaders to make sure they develop a reliability culture that fundamentally, they just always make reliable products. You know, the subtitle in the book is How Leaders Build Organizations that Create Reliable Products. You can just fundamentally operate differently. And—

(Joel Beasley at 00:22:57) Can I recap that so I understand it? I just wanna make sure, like, I'm super clear on it when I, because, people ask me for your stuff all the time. They're like, hey, do you know somebody that does this? Or do you know somebody that does that? And so I want to make sure I categorize you correctly.

(Joel Beasley at 00:23:09) Okay. So when you started Apex Ridge, the main line of business, what you're doing is you were joining as engineer. You had this, you know, toolkit and then inevitably you would like float up through the engineering teams and then begin to help some of the leaders develop this reliability culture. Right? That was like step one?

(Adam Bahret at 00:23:29) Exactly. Yep.

(Joel Beasley at 00:23:29) And then step two—

(Adam Bahret at 00:23:31) came from a long legacy of that. Right? When I built departments, that's what would happen. Right? I would pretty quickly be, you know, wanting to make fundamental changes to the organization and not just in engineering. So—

(Joel Beasley at 00:23:43) And then now you, so you still offer that service. Right? Like, if somebody wanted that, do you still offer that service, or do you only do the leadership stuff now?

(Adam Bahret at 00:23:49) No. No. No. That's still the core part of my business. I mean, that's part of who I am. That was part of my thing was staying in industries. I didn't wanna just keep floating up the ladder to the top. You know, I always wanna be a part of the technology, but I think that's a good thing for leaders to do too. The two shouldn't be totally separate. I still do help people design products that, you know, won't fail in their customers' hands. But at the same time—

(Joel Beasley at 00:24:13) Five years, do you think you'll be more like, in five years, you think reliability culture will be your larger line of business?

(Adam Bahret at 00:24:21) Oh, I think, oh, yeah. Yeah. Without a doubt, it's beginning to, well, that's the thing. I want this to grow because reliability culture is really my unique, I feel like with my first book and so much of my career, you're in some ways regurgitating what you've learned. Right? You know, Isaac Newton figured out basic physics and you learn it in engineering school and you regurgitate it in a way that's distilled for the exact situation it needs to be and applied. And, you know, my first book was very much about that. This book is really my unique contribution, you know, I think, which is why I was very excited about it, about how some things can be fundamentally done different. So my business and my work is very much going to continue to grow in that area. And, you know, the other parts, I can have other people on my teams, you know, do the technical thing, and I can try to be more hands off. But, yeah.

(Joel Beasley at 00:25:15) You know, what I have found in my experience is that when you have great leaders, whether they're just great leaders or they're great and they're technical leaders, they'll just start having these other talented people orbit them, sort of like the next generation. So when you do these projects, you have some other people around you that, you know, you involve in this, like the next generation of these really bright people?

(Adam Bahret at 00:25:38) Yeah. So, when I started at Apex Ridge, there's so many different ways you can build a consulting company. And I really took a lot of time to think about what I wanted to do. And I decided I wanted to be a boutique firm, which means that I always am executing, designing and executing my part, you know, how I'm engaged with the project as something totally custom to exactly what they need. Second was, if people get sold on me, Adam Bahret, they get me, Adam Bahret.

(Adam Bahret at 00:26:07) I'm not handing you off to anybody ever. I also wanted to make sure that when I have other people on a project that I bring into the project, that they are the experts in that area. I always say, only hire people smarter than me. I know the person who wrote the book on a topic and I'll get that person. I wanted to leverage the fact I seem to know everybody.

(Adam Bahret at 00:26:27) I didn't want to have people on staff that I need to bill hours for. What would happen is, you know, I'd put that person on the project because I need to keep them busy. I don't keep a staff. What I do is have my network of people that I bring in on projects as needed. It has worked so well where I serve my customers, you know, in a very efficient manner.

(Adam Bahret at 00:26:48) I'm not spending a lot of my time doing overhead running a company. Right? Because you lose yourself in that. I see people lose themselves in that just managing a company and, you know, and I don't do that. So, yeah, that's the structure of it. And as I continue to do more and more of the culture work and the executive leadership work, you know, I have, you know, I can always, if with projects that are very technical, I can always bring in more people to do more support work in there.

(Joel Beasley at 00:27:14) I'm curious to know about your reliability culture type service. So, you know a lot of people, so basically you just put your sign out, like this is what I'm doing and word will spread right through your network. But I'm curious, being an entrepreneur and developing products myself, there's always a problem that you're solving. There's always some moment of pain the individual's experiencing before they say, I need to go find a product or a service to the solution. What is the pain?

(Joel Beasley at 00:27:45) What is the signal people are receiving before they say, I need, I need Adam, I need help with reliability culture? Yeah.

(Adam Bahret at 00:27:54) So unfortunately, so often they do have to experience the pain to really be aware of it. Because, you know, when you're excited about technology and you're developing, you wanna get it out there. And that's one of the things unusual about reliability compared to other things you can invest in because the return on investment's kind of far out there. Right? Because you can get the product out, but in a year, year and a half, issues start rising.

(Adam Bahret at 00:28:19) There's high warranty costs. Now you're losing market share because customers aren't happy. They're canceling orders. You're hemorrhaging money in trying to recover and fix things. You're not investing in next generation products.

(Adam Bahret at 00:28:31) And having gone through that, quite often, you know, leaders will then, when they're doing a new product, be like, I think we need help here. You know? And I actually came up with a term for this called time to reliability. Right? Because we're, leaders always talk about time to market.

(Adam Bahret at 00:28:49) And, you know, time to market is, you know, when they launch the product. And, you know, these programs, you know, they kind of become freight trains and you wanna stay on target, you know, on schedule. And, you know, you release a product and then there's kind of this hidden, unspoken phase of this kind of recovery phase nobody really labels of when you're trying to quickly address and fix things and effectively finish maturing the product in the field till it does what it needs. But it really is a program phase because it has resource going to it. You know, it's taking time, it's taking money, it's taking talent.

(Adam Bahret at 00:29:21) So when that's complete and you can shift resource away from it, I call that time to reliability. And I wanted to give it a name because I wanted people to really acknowledge it because that's the real cost of not doing that earlier. Once you do that and you begin measuring, you know, the real cost, the real time to market, time to reliability, you begin to really clearly see the insanely high return on investment of doing these reliability tools early on, which when you're not seeing that or really measuring, you know, that outcome. And, you know, your design team and reliability team are like, hey, we found something that we don't think has a lot of margin on it for variability or this feature, we're kind of questioning it. We wanna study it for four more weeks and look to improve it. And the project manager says, hey, my bonus is tied to this thing getting out in July.

(Adam Bahret at 00:30:14) And the leadership's like, yeah, we gotta get to market. The pressure's high. Sorry. No four weeks. But then when you can tie that to, recovering that seven month recovery of issues, millions and millions of dollars, you know, between, you know, service diagnosing it out in the field, engineering stopping what they're doing, and you can really make that connection, it's a no-brainer to be like, yeah, let's let's take the four weeks, time to market.

(Adam Bahret at 00:30:39) The real time to market is with that recovery in there. There's something called the rule of tens. The rule of tens is for every stage in a program that you find the same issue, it costs 10 times more. At first, I thought that was, the first time I heard it, I was like, nah. Now, I see that that is insanely conservative.

(Adam Bahret at 00:30:58) It's far more than that. The idea being that if in first design review you caught an issue in a design review when you're not even at prototyping stage, and somebody points it out, the engineer can go fix it at their desk in their CAD modeling or whatever. You can put $100 on that or yeah. If you then go a couple more stages down the line, that same issue, you don't catch it. It's much more expensive when you're at prototype.

(Adam Bahret at 00:31:24) It's much more expensive than manufacturing prototype. It's insanely expensive out in the field, right? That same simple issue, and the rule of tens is really true, and you can turn a $100 problem into a $10 million problem pretty easily. But you would think with all of this that it would be obvious, right? And people, after just even experiencing that once, would do it differently.

(Intro Narrator at 00:31:46) But there's some really interesting situations that happen,

(Adam Bahret at 00:31:46) and I'll describe one that kind of leave people accidentally in this perpetual cycle of experiencing this. And you watch companies just drive themselves into the ground. There's a million examples where you're kind of like, why didn't they, how come they didn't correct this or see it? And I'll give you an example. One is you have a new program and you have this very intense time to market. And one of the fundamental problems, and this actually drove one of the earlier tools I made called bounding, and based on the product factor balance, and that's in my book, Reliability Culture, is when the company starts and they're going to design a new product, they have a very specific balance between time to market that's critical.

(Adam Bahret at 00:32:36) If it's a toy for Christmas, you better have it on the shelves by Thanksgiving, right? If you have a competitor coming out with something in August, you don't want to be a year after because they will at that point be the market leader. You have cost point. That's very important as well. You have reliability. There's a lot of factors. How you balance certain features. Does it need Bluetooth? Does it need whatever new feature? And those are all competing factors for time and money, and you figure out a balance that really works. There's, like, if you go to look for a power drill at Home Depot, there's like 12 different to pick from, right?

(Adam Bahret at 00:33:13) And there's the one that's $25 and then there's the one that's $300, right? The $300 one is the right one for the contractor because it has insanely high reliability and features that save time, which to him, $300 is nothing because if that breaks, he has his crew standing around not doing any work and that's really expensive. Whereas the homeowner, you're probably mortgage poor and you're only going to use this thing a few times. And even if it does break, you're like, cool, I can take the rest of the day off. I'll get a new one next weekend. So that balance, each one is the exact right balance for a specific customer. But here's where it always goes wrong. You create this very careful balance.

(Adam Bahret at 00:33:50) And then what leadership always does is they split up the goals and give them to individual people. So they say, hey, project manager, time to market. That's all that's important to you. That's what your bonus is based on. That's what your promotion is based on. It's very personal. Okay. R&D. You're going to develop this new feature and have it ready in time, and that's going to dictate your career path whether you pull this off or not. Hey, reliability quality team.

(Adam Bahret at 00:34:15) Make sure it doesn't fail. If it does, it's your fault. And so you split up the goals, give them to individual people, and you put them in an arena to compete, fight to their death, right? So when you do that, you're going to have winners, right? There's no way that product is coming out the other end with that balance. It's just not possible. I mean, there's no way those gladiators in the arena are going to end up all coming to an agreement at a table of this is the correct balance.

(Adam Bahret at 00:34:41) That project manager is like, I'm not losing that bonus. So what happens is you have winners, and they get rewarded, right? So let's say it's the project manager and time to market, and they had all the right social connections inside, and they were really able to make it to where it went out on time regardless of if the design was mature or regardless of a feature design.

(Adam Bahret at 00:35:04) And they will get rewarded and congratulated. And then maybe the R&D engineers did get that feature done and pushed it out there, but it really wasn't ready yet. And they didn't do all those testing things that we found were concerned about. They kind of were like, nope, we're getting it out there. We'll fix it. You always hear that. We'll fix it in 2.0. I'm like, do you really want your customers to be your test engineers? That's what you're basically saying, 2.0. Everybody is excited and there's congratulations.

(Adam Bahret at 00:35:33) Then what happens? Let's say six months or a year later, field issues start popping up. First, there's a little bit of noise and they're called gremlins. And then there's more and more. Now it becomes a serious situation. Leadership says, hey, we need to make a tiger team, if you've heard that term. What they do is they pull together the people who, from the project, at that point, have left and gone on other projects, right? Because, I mean, their accountability ends after release, and they're not even around for that part. So they get pulled back to, hey, you guys have to come back and save us and figure this out.

(Adam Bahret at 00:36:06) You guys know how to do this best. And what is kind of unsaid is, hey, can you come back and fix the problems you made? And they, as a tiger team, they go at it and they figure it out and they solve it, and they get things worked out and there's a big banner and a cake celebrating it. And in the end, the leadership, the CEOs, CTOs, those guys are left holding the bag for this whole calamity. But the insane part is they incentivized that team twice to make a poorly reliable product.

(Adam Bahret at 00:36:35) The first time was get it out on time, get your feature developed, you get rewarded. And the cost is going to be things like reliability. And the second time is you brought them back as heroes. You gave them face time with leadership, right? Because leadership is like, what's going on with this? They got face time and all these things that helped them. So, here's a CEO and CTOs incentivizing their team to twice make a product that's not going to be very successful. And the leaders are the ones left holding the bag, and then the cycle continues. And it's how do you do it? Everybody kind of sees the bigger picture on how to do it differently.

(Joel Beasley at 00:37:11) Yeah. How do you do it differently? That's the question on everybody's mind right now that's listening. It's like, okay. We get it. This sounds like it does, it sounds like an intentional disaster waiting to happen. It's like, if I wanted to ruin everything, that is my best plan. What's the right

(Adam Bahret at 00:37:24) way to do it? So the right way to do it is that product factor balance has to be held by everybody all the time, right? So those goals and that balance has to steer decisions and be visible throughout the entire program. The only way you are possibly going to release the product that you intended in the beginning is if they're all present.

(Adam Bahret at 00:37:45) And there's a couple of ways and tools that I've written in my book to help with that. The analysis is if you're driving down the road, you have to always keep that destination in mind in front of you that you're driving towards, right? You can't be shortsighted and just letting the car drift and when you hear the guardrail on one side jerk the wheel the other way into oncoming traffic and jerk the wheel again. It's that having that goal in the far distance and making all the small corrections and everything you do—acceleration, braking, turning—to continue to go there. If you're doing it right, there are no big corrections. An experienced driver is not jerking around. You're almost effortless. You can't even tell they're steering. So that's the fundamental difference. And a lot of it I put under this one methodology I have called bounding methodology.

(Adam Bahret at 00:38:34) And the bounding, you can imagine, the concept is all those things are steering you all the time and tools and techniques and programming where that occurs. Obviously, one of the first things is you can't hand off the goals to the individual people in their roles. That right there, you just made a gladiator arena. Everybody is holding all the goals. Now, they're bringing their specific discipline, their role to this as an aid, as a specialist, but at no time are they being measured only for one of the goals.

(Adam Bahret at 00:39:03) And I have methods like the focus rotation methodology. I have the strategy bounding. I have PUREA, Program Risk Effects Analysis, is another tool I made. And all of these tools working in concert kind of just make sure that that basic principle that we have a specific destination in mind that we set in the beginning very carefully. I mean, marketing and business very carefully made a product balance, right? They stopped and said, there's a homeowner here that just got their biggest mortgage and they're dirt poor and they need a power drill to do this project they're doing. And the duty cycle is very low. So even a poor reliability is not going to—they're using it, whatever, 20 hours a year, whereas a contractor is using thousands of hours a year. So they can't even have a lower reliability.

(Adam Bahret at 00:39:49) Technically, that performs very well. All these things they do in analysis, a cost point. They're not going to buy it if it's $35 if we can do it for $25. They don't need all the fancy features. They just want to turn screws. So much work went into that. How do you not let that continue to drive all the decisions? And that's really where most of my tools come from is that basic principle.

(Joel Beasley at 00:40:11) It's pretty clear to me the bad way to do it, right? Break up the goals, throw money at the people. You're explaining from what I'm taking from it is you have a centralized goal, like a series of things that need to happen and you have everybody go towards them together and maybe this bounding concept. But where do you throw the money?

(Adam Bahret at 00:40:31) Where do you—oh, so what's the—a simple way to do it, here's a simple analogy, is think of balancing a home budget. You have a home budget. You have money allocated to food, money allocated to rent or mortgage, money allocated to vacation each year, money allocated to entertainment each weekend, all these things. And it's not throwing money at it. You have a set amount of money. You have income, right? You have your income, whatever it is

(Intro Narrator at 00:40:56) from—how

(Joel Beasley at 00:40:57) do you—how do you bonus them? How do you bonus people? How do you bonus people?

(Adam Bahret at 00:41:04) Oh. I see what you're saying. How do you incentivize people to do this? Yeah. The right way. Oh, they're accountable for the product successfully being what it was originally, right? So before, I'll put it this way. In that previous version I gave you with the project manager and their bonus is tied to time to market, me as somebody who spent my entire life passionately wanting to make highly reliable products, if you made me that project manager, I'd be like, screw reliability. Screw everything. Forget it. I want to keep my job. I got kids I got to feed. I mean, it doesn't matter. You've put me in a situation where I'm—that's why I call it a gladiator thing.

(Adam Bahret at 00:41:33) I'm going to find a reliability guy, trip him in the hallway. The R&D guys, if they're going to be too late, I'm going to sabotage what they're doing. Like, I'm sorry, but this is literally money in my bank account. That's how that was incentivized. What if you switched my incentive to, as a project manager, that idea of time to reliability, right? What if what you measured me on was not the time to market when I put it in the customer's hands, but when are we able to drop the resource? So, we've allocated X amount of resource. We'll call that 100% in development. When does that resource for the product drop to 10%?

(Adam Bahret at 00:42:15) That's your time to reliability. That's what you're measured on, buddy, right? So when that's what you're measured on, you switched the project manager, and they hear about early in the program, we're concerned about this. We think it's about four more weeks of test, but we think that it's going to reduce our statistical confidence risk by this much. They're going to be like, do it. I got to keep my job. You know what I mean? You've connected the project manager now to the accountability the leadership has, the accountability the stockholders have, the accountability the company has. You've connected them now to the—everybody's in synchronicity with each other and what needs to happen.

(Joel Beasley at 00:42:55) Yeah. And then they can balance the trade-offs. For me, I don't have experience developing physical product, like electronic type designs. I do have experience building software. And if we set a deadline, then we don't cut quality, we cut scope. So we get the most utilitarian version out and get it delivered according to the deadline and the bells and whistles get chopped off accordingly.

(Joel Beasley at 00:43:19) And then we just go into another iteration. That way, every iteration you end up with something solid and reliable that does one thing that you couldn't do before. So it's useful to some degree. It's reliable. It's there.

(Joel Beasley at 00:43:33) And then you add on as you go. So how do you do that? And like the—would that apply at all to physical products?

(Adam Bahret at 00:43:42) Oh yeah. Well, absolutely. No, because if so, I'm talking about maturity of technology. So if you have, like, an airplane, right? We're designing the next generation airplane. And a lot of the technology in airplanes is going to be the same year to year, right? Airplane wings work the same. You're going to use standard wings the way they've done a hundred years, those principles, the controls and stuff.

(Adam Bahret at 00:44:04) But our thing is we want to include this new kind of engine, a fusion engine or whatever you want to call it. That's a huge step in what we had before. And you want to include one or two other things. Now, if it turns out that this plane offers a lot of benefits in a lot of ways, but it seems like the fusion engine thing's going to really push out your time to market by two years or something, you might decide to not include that, right? And include it later is another thing. And actually, very sadly, with Boeing, that's what happened. Actually, I wrote an article about the Boeing—it was in Bloomberg Law.

(Adam Bahret at 00:44:40) The Boeing incident, where we had the 737 MAXs crashing, and that's basically exactly what happened. What occurred there, in principle, is so simple. There were new, much more higher efficient engines created, not as the type that Airbus and Boeing would both incorporate into their aircraft. And these more efficient engines had very different physical dimensions and things like that.

(Adam Bahret at 00:45:11) So Airbus designed an entirely new airplane that was based around the idea of incorporating these engines. Boeing realized there was no way they were going to get time to market competitively with Airbus, who had started ahead of them much earlier on the airframe. So what they did is took their old 737 design, which had been around forever, and modified it to accept these engines. And in doing so, they took it to the extreme of barely—it really, it just, it's a bad, it was a bad idea. To make it work, they had to incorporate all kinds of software controls because it really was beyond what a pilot would normally be able to handle.

(Adam Bahret at 00:45:54) It was inherently a little bit unstable, so to speak, which is not an uncommon thing in fighter jets and things like that. They're inherently unstable aerodynamics, but you use computers to keep it stable and use the pilot's inputs. And they kind of had to go to that arena much more than before in a commercial aircraft. So they let time to market drive them to where they should have said, "You know what? We're just going to keep the older motors with not as good fuel efficiency."

(Adam Bahret at 00:46:20) We're probably going to lose sales and market share because airlines aren't going to buy it compared to the Airbus, and we'll take our time and make a new airframe for these motors and be later to market. And they didn't. They let the pressure of time in the market drive, which unfortunately ended up with two very severe accidents. And so, you know, from a software perspective, you would have said, "Sorry, we'll just use the old motors and, you know, take our time and release later generations." That would be the software equivalent to the hardware equivalent to what you said.

(Intro Narrator at 00:46:50) Robert Leonard (zero fifty seven:forty seven): Yeah. That's

(Joel Beasley at 00:46:53) I'm glad we have things like the FAA. Typically, I'm pretty limited government, but when we have things for the cars and the planes—because I'm an entrepreneur and I know how attractive it is to just cut a corner, and I know how things can snowball. You cut two corners, you cut three corners. So I do like the regulations that we have as far as the public transportations and keeping us safe.

(Intro Narrator at 00:47:16) Anthony Vaughn (3five 30:

(Joel Beasley at 00:47:16) Yeah.

(Adam Bahret at 00:47:17) And the FDA, all my work in medical and medical robotics and medical systems and the FDA is a big part of that. Right?

(Intro Narrator at 00:47:26) Clay Finck (3eight 40: So

(Joel Beasley at 00:47:27) What else do we want to make sure we get out there? We definitely want to send people your way if they are interested in reliability culture. So how would they reach out to you?

(Adam Bahret at 00:47:36) Yeah. So I actually just, between you and I, I created a new URL that's easier to remember for people who are driving in the podcast. I can't remember. Instead of apexridge.com, it's reliabilitywins.com will take you to a special summary for executives, which then there's the culture section of my page and all that. But reliabilitywins.com will, you know, bring you to Apex Ridge and specifically the culture leadership services.

(Adam Bahret at 00:48:04) Jason Kelly

(Joel Beasley at 00:48:05) (3five thirty three): Excellent. I just pulled it up. Yep. Lovely. I made that video guys.

(Joel Beasley at 00:48:09) Yeah, that's so sweet. You got your headshot, you got your book, and then you have a talk to me button, like, reach out. You. Yep. I see seminars. So you do seminars?

(Intro Narrator at 00:48:19) Oh, yeah. No. I yeah.

(Adam Bahret at 00:48:21) I actually have a webinar coming up. Actually, if people want to register, I have a webinar coming up in January. I speak—I mean, before COVID, I spoke all around, you know, tons of seminars and stuff. I'm going to actually as soon as COVID's done, I used—I would host seminars in Boston, the Boston area, for my customers in this area. And everybody loved getting a Friday off from work, legit.

(Adam Bahret at 00:48:46) And I would have it sponsored and food and the whole thing. And I would do this one man show where I would basically just ramble on for four hours and just talk about, you know, everything that everybody's interested in. A lot of these new ideas is where I'd roll them out. Then we'd play in the lab the second half of the day because I did it at a local lab that I'm partnered with. But, actually, you know, now with the culture stuff, I want to start doing seminars specifically on that.

(Adam Bahret at 00:49:09) And, you know, I wanted to plan one. I'm waiting for COVID to kind of cool off a little bit. But I was thinking of hosting one down at Miami Beach or something, you know, at a resort and,

(Intro Narrator at 00:49:20) you know, invite leaders, you know, the leaders I know from

(Adam Bahret at 00:49:20) around the country and around the world to come to it. The leaders I know from around the country and around the world to come to it. But right now, things are online, and I have a webinar that will be coming up on January 10. So it'll be coming out on January 10. It's called The Alchemy of Rapidly Transforming New Technology.

(Adam Bahret at 00:49:40) And, you know, it covers a lot of this. But I do have one of my funniest speaking stories is so I got invited to Stuttgart, Germany. I'm a huge car guy. I'm a crazy car nut, and I love Porsche is one of my favorite ones. If you go to my website, you can see Porsches I torture in the name of science.

(Adam Bahret at 00:49:55) The one that I just took a 2006 Porsche 911 997 and modified it to where I could carry a 13 foot catamaran sailboat on top.

(Joel Beasley at 00:50:04) That's normal.

(Adam Bahret at 00:50:05) To demonstrate my use case seven. Because I have this whole use case seven idea. This other tool I need to build.

(Joel Beasley at 00:50:11) What is that? I saw that I saw that in the prep, and I'm like, use case seven. I was like, that sounds like some top secret lab or something. What is use case seven?

(Adam Bahret at 00:50:21) So use case seven is, I—the idea is, you know, when you are developing products, you, you know, think of the base use cases. Right? Usually, you come up with three base use cases that you then extract what the stresses are and the conditions that are going to affect the design and use them as inputs. And they also help drive what the testing is and how you interpret results. And people tend to want to, you know, keep with the stresses the way they want the product to be used.

(Adam Bahret at 00:50:47) So I started—you know, at most I've ever seen people create a six. And I was like, what about use case seven? This is use case seven. Think of the most ridiculous thing you can come up with, like the guy who uses his lawnmower to trim the hedges. He picks it up and holds it sideways kind of thing.

(Adam Bahret at 00:51:00) And I said, let's do that for a minute. Let's come up with our use case sevens. Crazy abuse. You know, somebody who uses their, you know, their cell phone as a hammer, you know, kind of thing. You know, what happens?

(Adam Bahret at 00:51:10) A couple of things came out of it that were really interesting, that always were interesting. One was it did serve the base purpose of, you know, what are the stresses that can happen that are unusual. Sometimes it turns out to be some of those should be in the base use cases. Sometimes just simply they make the product more robust because when you mess around with them, you find that it fails in ways you didn't expect. You know, maybe that was a failure.

(Adam Bahret at 00:51:32) Nobody's going to use their phone as a hammer, but you might find out that you can easily modify the phone, you know, outer shell in a way where it's much more robust to being smashed like a hammer. And what you just did was mitigate against poor manufacturing quality not resulting in a performance issue. You know, if you have a bad injection mold now because you changed the way it handles stress. Then there was a few other things that happened, new markets. I did this exercise with a team and we found actually a new market for their product that they're going to develop a different product for.

(Adam Bahret at 00:52:02) So you might, you know, think of something ridiculous. So let's say, you know, with the guy using the lawnmower for the hedges and, you know, let's say hedge trimmers weren't really a thing yet and people did it just by hand. You might all of a sudden be like, wait a minute. What if you did make an automated way to trim hedges, you know, with a rotating blade? And you could end up developing something new and that's actually happened with some of my customers.

(Adam Bahret at 00:52:24) And then another one is litigation. You know, I've been an expert witness in some big litigation cases, and it always kind of breaks my heart to be on the prosecution side. And there's all these things, you know, the engineers have documented and, you know, said that, you know, then can get used against you, and engineers know that. And they will be very cautious in how they talk about risks or potential things or document them. And that's really unfortunate because that limits, you know, improving the design against those things.

(Adam Bahret at 00:52:54) And lawyers and engineers within a company kind of have that little bit of a standoff thing going on, you know, to the point that, you know, a fire is described as a thermal event or an explosion's a spontaneous disassembly event. You know, just it just gets, you know, silly. And the thing is with use case seven, if you do it as an exercise, use case seven helps you document it in a way to bring collaboration between the legal side and the engineering side, where even if you don't address these things, which of course you won't address a lot of them, what it does is it documents your sincerity in trying to understand all the possible things that could happen with your customers and mitigating as many things as are reasonable. And I ended up with this and putting it out there, had law firms reach out to me who want to help their customers be more proactive and have—that's how that Bloomberg Law article came out. I wrote it with some colleagues at White and Williams, which is a big law firm who reached out to me and liked the use case seven idea.

(Adam Bahret at 00:53:54) And, you know, I've done other series on it. So this use case seven thing kind of became it organically grew into this tool that really is helpful in a lot of ways for engineering teams to kind of really explore these other areas and get much more from their products. So, since I am an engineer at heart and, actually, my wife put in our wedding vows that she knew I'd modify everything in our house. She seriously she felt like she had to say that in front of all our friends and family we got married, and she's right. I am an endless—the fire department knows this firsthand.

(Adam Bahret at 00:54:25) I'll put it that way. So I like to do my projects, and I kind of wanted to do things to, you know, help, you know, get the use case seven idea out there. And I was like, oh, what if I'm a big car guy. And I'm like, oh, what if, you know, Porsche, they design and engineer things so well, so far exceeding, you know, what needs to be there, to where I think Enzo Ferrari once said, "Thank God there's no 48 hours of Le Mans or only Porsche would finish." Because the engineers always win the conversations, I feel, in those in their boardroom arguments.

(Adam Bahret at 00:54:56) And so what if we did a use case seven kind of thing for a Porsche? Like, let's pretend we were designing it. So I grabbed the one of my favorite ones is the 997 911. So this was a 2006 with 25,000 miles on it. I grabbed it from a little old lady who was—she was hysterical because she loved this car so much and she was moving to Costa Rica.

(Adam Bahret at 00:55:17) It had 25,000 miles on it. I just—this was in January. And it's 15 years old. Right? Like, what is that?

(Adam Bahret at 00:55:23) Let's literally go in and get coffee once every other Sunday. And when I bought it, she insisted I have it shipped from Texas to my house in an enclosed trailer. I'm like, this isn't your car. Like, what do you care? She's like, "Well, I bought white shirts to put over the seats in case the guy's dirty who loads it in the truck."

(Adam Bahret at 00:55:39) I was like, oh my god. So with the Porsche—so what I thought was, you know, Porsche had a big transformation back in the 2000s time frame where they went from just making sports cars, they rolled out the Cayenne and, you know, SUVs and all that. So I was like, what if you knew you were going to make an SUV at some point and you were a sports car company? Why not see how much utility you can get out of a 911? So I was like, that's what I'm going to do, to the horror of everybody in my Porsche community.

(Adam Bahret at 00:56:06) So I designed a two inch trailer hitch that, you can see all the calculations, a whole article and video series I did on it. Did all the calculations and the trailer hitch is behind the license plate. So it's this two inch trailer hitch behind the license plate. And it actually was kind of hard for a car that has a crumple zone, right, to get all that structural stress. But it worked.

(Adam Bahret at 00:56:26) I got my goals. I got 300 pounds of tongue weight. You could stand on it, 300 pounds, which is about what you need. And I could pull some pretty big stuff. And then next, I welded up an aluminum frame for the roof and I got—I could carry six wooden pallets on the roof of this thing.

(Adam Bahret at 00:56:42) And then I made this frame that goes into the hitch because the ultimate goal I wanted to do was to carry this 13 foot catamaran sailboat that once I fit on this Crosstour I had. That was my final, my final thing. I had other things in there like be able to stuff the family in there and skis with a roof rack and go on trips and stuff. It worked fine for me. My daughters wanted to murder me putting them in the back of a Porsche for a few hours.

(Adam Bahret at 00:57:06) But I drove it through, you know, I did all kinds of snow stuff and put snow tires on it. And, yeah, it was really great. A lot of people really enjoyed it, the project. And, you know, so it was a fun way to do show use case seven. And so I have other use case seven ideas coming up, but

(Joel Beasley at 00:57:23) We'll do a use case seven episode, and we'll go through all your past crazy inventions and fire department calls.

(Adam Bahret at 00:57:30) I was about to just now do just as of last week, it's not going to happen was a Lamborghini Gallardo. I was going to turn into a shooting brake. I was going to make it into a station wagon. And it was a friend of mine's car, and he was kind of doing a contest of who could come up with the craziest idea he would sell to them dirt cheap. And so we all made these videos.

(Adam Bahret at 00:57:49) I made a video on it, you can find on my channel, of what I would do. He wanted everybody to make videos. So he called me out specifically. He was like, I want to see what you come up with for this. But he ended up doing it for a lady who wants to make a—she's calling it the Lamblence.

(Adam Bahret at 00:58:03) She wants to make it to carry sick kids around. Like, she works with, you know, kids of different disabilities.

(Joel Beasley at 00:58:09) That idea wins 100% of the time. Right?

(Adam Bahret at 00:58:12) Yes. Yeah. Yeah. Yeah. Exactly.

(Adam Bahret at 00:58:14) And I was like, oh, my station wagon. Goddamn it. I wanted to go to Home Depot in a Lamborghini and load in, like, two by fours. I think great idea. Oh my god.

(Adam Bahret at 00:58:23) So my—so I don't know if you know the McLaren F1, you know, one of the greatest sports cars ever made, but it had three seats. It had the driver who was in the center, like in a Formula One car, and two seats behind it like this. In the Lamborghini, I was going to move the motor back about eight or 10 inches, And there were—it was going to work out to where you had the two seats in front, but you could have one person in the back in the center with their legs going in between the other two seats. So now it's a three seater, which is way more applicable. And I was going to extend the roof line and make the whole thing with a hatch, you know, to. So I wanted to be able to go to Home Depot with me and my two girls, load two by fours in, maybe an air conditioner or whatever else we buy, a Shop-Vac, and then be able to go and like thrash the car around.

(Adam Bahret at 00:59:02) That was my ultimate goal. But it's now a Lamblence, so we'll see what happens. I'll find it in a private jet.

(Joel Beasley at 00:59:11) All those sick kids getting transportation.

(Adam Bahret at 00:59:14) Come on.

(Intro Narrator at 00:59:17) I love it, man. This is great. Oh, dude, this is so good. Do you

(Adam Bahret at 00:59:21) know what? I would've taken them around the station wagon. I mean, come on. Now you could carry two kids at the same time. You still could do mine, and then she could do that, but, you know.

(Adam Bahret at 00:59:28) There you go.

(Joel Beasley at 00:59:29) Yeah. You can collaborate with them. Yeah. Jason. This is great. All right.

(Joel Beasley at 00:59:34) So people that want to learn more, they can go to apexridge.com. What else? Do they fill out a contact form?

(Adam Barrett at 00:59:41) I made reliabilitywins just because you'll remember. Yeah, I thought it might be more memorable.

(Joel Beasley at 00:59:45) Apex Ridge is better.

(Adam Barrett at 00:59:49) Oh, okay. All right, cool.

(Joel Beasley at 00:59:49) It's easier to spell. It doesn't have the I-L-I-T, but for us non-brilliant people, A-P-E-X-R-I-D-G-E is just real simple. What does it mean?

(Adam Barrett at 00:59:59) I wasted $12 on reliabilitywins for that domain name. Thanks a lot.

(Joel Beasley at 01:00:03) You did, 100%.

(Joel Beasley at 01:00:11) What does Apex Ridge mean?

(Adam Barrett at 01:00:13) Oh, so in thinking of a name, you know, Apex is hitting the top of what you want. And I was like, oh, a ridge is a three-dimensional apex. So take it and extrude it out, and you have this infinite apex. So, Apex Ridge.

(Joel Beasley at 01:00:29) That's awesome. And if that didn't work, you could have gone with Infinite Apex, because that sounds super cool too.

(Adam Barrett at 01:00:35) Infinite Apex. That's a good one. Yeah.

(Joel Beasley at 01:00:39) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.