Brian Powell Director of Engineering at Tangram Flex

(Joel Beasley at 00:00:00) Today, we are talking to Brian Powell, the Director of Engineering at Tangram Flex, and we discuss lessons learned from previous startups, cutting through the noise when launching a product, and the core principles of prototyping for production. All of this right here, right now on the Modern CTO Podcast. Here we go. This is the Modern CTO Podcast. So your office that you're at now.

(Brian Powell at 00:00:35) Mm-hmm.

(Joel Beasley at 00:00:36) What's what's, what company is that? Because I know you did some moving around, some hopscotching.

(Brian Powell at 00:00:41) Yeah. So, you know, CompleteSet, the startup that I was with down in Cincinnati, actually, coming in the second week of January, we ran out of cash as startups do. So went back into the market looking for different opportunities and actually landed with a new spin-off that's soon to be announced here from the parent company called Galois, which is based out of Portland, Oregon, but I'll be based in the Cincinnati-Dayton area.

(Joel Beasley at 00:01:08) Interesting. So I want to know about CompleteSet.

(Brian Powell at 00:01:11) Yeah.

(Joel Beasley at 00:01:12) I'm just curious because this is, like, this is how we bring value. You know?

(Brian Powell at 00:01:16) Yep. Absolutely.

(Joel Beasley at 00:01:17) What did CompleteSet do?

(Brian Powell at 00:01:18) So CompleteSet was this hybrid mashup of eBay meets Amazon meets Wikipedia for collectibles. So we profiled and tracked close to 300 different brands of products that were coming out. Things from new stuff like Johnny Cupcakes, which is a t-shirt company out of Boston, you know, Homage, which is a clothing company out of Columbus, Ohio, to the big names like Disney and Hasbro and, you know, even the Kenner stuff that Hasbro acquired during that purchase. And so, you know, what we would do is we would sort of track those items as they were released and, you know, sort of track the value of them and what people were trading for them. But CompleteSet at its core was really about sort of taking collectors and matching them to the items that they wanted.

(Brian Powell at 00:02:14) So they could come in and track their collection, say, you know, hey, I want to go on the hunt for this particular item. And then, you know, what we were doing was sort of taking that information and exposing it to vendors that could then come in and go out and sort of hunt that inventory and match it to our audience.

(Joel Beasley at 00:02:32) So you're matching collectors with people who had those collectibles?

(Brian Powell at 00:02:36) Exactly. Yep. And we would sort of facilitate that transaction, but then we were also, to keep the marketplace full of stuff, we were doing a consignment model where we ran a warehouse. We're taking in six, seven hundred piece collections, and then we were liquidating it for people that were, you know, some of it was people were sort of changing focus. Maybe they really were into Star Wars at one point, and they wanted to transition over to movie props or something along those lines. And we would come in, we'd take that collection from them, we'd do a consignment fee, and then we'd liquidate it. And because we knew what people were searching for inside of our network, we had, you know, and we were able to send out the notifications when those things came available, really complete that with sort of a marketing platform for marketing to people who were looking for specific items.

(Joel Beasley at 00:03:19) Right. Because that's, like, your unique information that you have is who wants that.

(Brian Powell at 00:03:23) Yep.

(Joel Beasley at 00:03:24) So then how big of a company was that company? How many people?

(Brian Powell at 00:03:28) So we were about 13 people, including the four people in the warehouse. My development team was a team of six.

(Joel Beasley at 00:03:36) So I'm curious, was it a lack of the market? Were there a lot of people that were really into collectibles? Or I'm curious as to where it kind of didn't take off the way you guys thought it would or how the whole thing wrapped up.

(Brian Powell at 00:03:53) So, you know, I think the thing that kind of got us was the assumption was, you know, we had sort of unclear metrics into what our cost to list a particular item was until, you know, sort of right in the, we layered in the software in middle of September into the fulfillment center where we went in and we sort of, you know, we took six weeks and wrote a complete custom package for the fulfillment center from barcode scanners, bins integrated with photography software, a completely custom shelving system, and Android tablets for picking and packing orders. And, you know, we did that because, you know, CompleteSet was, it's not like any other inventory company. We looked around at a couple other solutions. You know, everything was a quantity of one. It belonged to a specific user. It was in a specific condition. It has a specific price that they wanted for it, or it was going to auction. And, you know, inside of that capacity, you know, most inventory systems that are out there are, I've got 500 of these items, they show up on a pallet, I need to stick them in a spot in the warehouse, I need to go get them when I need them. And, you know, that just wasn't the solution that we needed.

(Brian Powell at 00:04:59) And so, you know, we came in and we built that system, put in a very sort of complex, almost IoT-based eventing structure of, you know, knowing, okay, this item started to be received, it's been received, it's going to photography, it's in photography, it's out of photography. And that provided us a really granular view of the items that were moving through CompleteSet all the way out from when they came in all the way out through shipping and when they went into delivery. And we didn't really get those numbers until October, November time frame, and we sort of realized that our cost per item that we needed to hit to break even was around $15. And we started moving towards that through the month of November, and then December killed us. And you would think that December is a great month for merchandise, but you're talking about collectors who are using disposable income to buy items that they want, and they're using all of that for family trips and to buy presents. And so revenue sank. We were out raising a little bit of money, and we just couldn't get it done to come back.

(Brian Powell at 00:05:48) So, you know, it happens. It was, you know, the market kind of got us. And, you know, we probably should have focused on more features that really were less marketplace-y and more recurring revenue because, you know, every month we grew 45% for three months in a row, revenue growth. And every month we would start at zero because we were doing sort of that marketplace model, and we needed to probably put some features in place that allowed us to, you know, if the hill was, say, $330,000 and you equate that to 30,000 feet, we needed something that would move base camp up 5,000 feet each month to allow us to climb that hill a little easier.

(Joel Beasley at 00:06:47) Interesting. What, it's so valuable to take a look back at something like this because we're all kind of, we're all in business, and all businesses are susceptible to the market. It's the way the world works, and we all have to watch all the different parts of our companies, primarily the income. And so that's a nice reflection on that. So if you were to do it again, you would say you'd focus on the recurring revenue upfront so that when you guys had down months like December or seasonally down months that that recurring revenue would take you through.

(Brian Powell at 00:07:21) Yeah. I mean, you know, we were focused on being sort of almost a brick and mortar type of business model, right, where you've got to get this much foot traffic through the door or through your website, right, per month to hit that number. And you've got to figure out how to grow that traffic. But largely our income was tied to how many collections we could pull in. And you go through the holidays and, you know, people aren't going to ship you a collection of stuff. They're out there doing other things. You sort of hit that business lull between Thanksgiving and Christmas where you just can't get anything done. So it was a little bit of a constraint of inventory. But, really, if we would have had those recurring revenue pieces in place, you know, it could have changed the business pretty substantially because we could have figured out how to grow that specific recurring revenue stream and, you know, know that we, you know, that that was a steady input into the financial baseline, and then have the marketplace stuff on top of it.

(Joel Beasley at 00:08:25) So you had about twelve, thirteen people and—

(Brian Powell at 00:08:28) Mm-hmm.

(Joel Beasley at 00:08:29) Half of them were engineers. And then what were the other half?

(Brian Powell at 00:08:33) So we had some marketing people, sales guys that were actually working with people who wanted to sell their collections and sort of driving them through that process. And then we had warehouse staff. So we had a professional photographer on staff. We had receivers, packers, shippers, et cetera. You know, everything that you would need to run an Amazon-like warehouse to get stuff in and out.

(Joel Beasley at 00:08:57) Do you think it would have made a difference if you only had three engineers and instead got three more salespeople?

(Brian Powell at 00:09:05) Maybe. You know, the focus was, you know, when I sort of joined the company, I came into the company eighteen months before we closed. And at that point, they had already released an iOS application, and they had released an Android application, and then they had their mobile, they had the website. And, you know, from that perspective, you know, I think we all would have agreed that we probably would have pulled back on putting out mobile applications even though our users were sort of jumping up and down that they wanted them, because almost, you know, like, 70 to 75% of our traffic for the company was just on our mobile website. Right?

(Joel Beasley at 00:09:44) Yeah.

(Brian Powell at 00:09:44) So, you know, the mobile web was getting it done. Did we really need to make that investment in the iOS and the Android applications? But, you know, this decision was largely sort of already made that it was out there and, you know, the impression was that pulling that back would do more damage than—

(Joel Beasley at 00:10:01) Well, the money was already stored. Good.

(Brian Powell at 00:10:02) Yeah. Exactly. Yeah. Exactly.

(Joel Beasley at 00:10:04) Yeah. So what's next for you? What are you, where are you at now?

(Brian Powell at 00:10:09) So I'm at a new company that literally just formed about last Monday called Tangram Flex. And it's really focused on sort of taking functional approaches to programming and applying it to systems engineering. And that's about as deep as I'll go on it. A lot of their work is sort of focused on the government side of things. But, you know, it's really cool. It could, the technology that's been developed here could change the way that we sort of approach software development. You know, if it's sort of taking it back to the way that building codes, you know, there's a whole bunch of algorithms that have been in place for the way the CAD systems are used to sort of put structures together. And largely, a lot of that stuff doesn't exist in the software engineering world. And so when you look at that problem of how do we increase cybersecurity, how do you increase interoperability of components, and, you know, how do you sort of take a system and make it very flexible by focusing on the individual pieces of it, you know, Tangram's approach is really focused on doing that.

(Joel Beasley at 00:11:26) You guys are taking concepts from other complicated engineering projects and then applying them to software engineering projects.

(Brian Powell at 00:11:32) That's exactly right. Yep.

(Joel Beasley at 00:11:34) That sounds smart. At the end of the day, there's not going to be, like, oh, wait. So is there going to be building codes and stuff now for software?

(Brian Powell at 00:11:42) I don't know if it's so much that. I think, you know, I don't know if we'll get to that approach. It's really about sort of generating the tooling that allows people to ensure that the projects that they're building, you know, are secure and that they're really flexible and that they can be sort of reconfigured on the fly.

(Joel Beasley at 00:12:01) Good. Because otherwise, you'd call the company like Red Tape.

(Brian Powell at 00:12:03) Yeah. Pretty much. And I don't think anybody would buy that. So—

(Joel Beasley at 00:12:07) No. I don't think you're going to win the hearts and minds of developers that way.

(Brian Powell at 00:12:10) I don't think so either.

(Joel Beasley at 00:12:12) Have you ever wanted more oversight in your code?

(Brian Powell at 00:12:15) Yeah. The answer is no. So—

(Joel Beasley at 00:12:19) You wanted a board of nontechnical people deciding how you write software? No. Please. No. So that's cool. That sounds actually really interesting because you're taking principles that work in complicated engineering, and you're bringing them over just to another industry that seems to lack it, at least in my experience.

(Brian Powell at 00:12:38) Yep.

(Joel Beasley at 00:12:39) Very cool. Very cool. So you're pumped about it?

(Brian Powell at 00:12:41) I am. Yeah. It's, it was one of those sort of, you know, when the conversation started about it, it was even hard for me to get it into my head. And, you know, here I am three days on the job and just drowning in all of the information that's coming at me. But, you know, there's glimmers of hope of, like, wow, I now understand how this particular thing is going to go together. And, you know, we're very early on. I mean, I'm employee one of this company, and, you know, we're a spin-off or, you know, we're going to be fully funded. But, you know, we just got to get through this initial piece of starting to get the building blocks in place and putting together a great team. And, you know, hiring is something that's, you know, hiring effectively in the engineering space is something that's really near and dear to my heart because if you do it wrong, it can be really, really painful.

(Joel Beasley at 00:13:31) Oh, yeah. If you get people that don't know how to build a foundation to build a foundation, good luck building a house.

(Brian Powell at 00:13:35) Exactly. Right. Yeah.

(Joel Beasley at 00:13:38) So now you're on this hunt for the best of the best. Right?

(Brian Powell at 00:13:42) Correct. Yep.

(Joel Beasley at 00:13:43) What technologies are you partial to for this build?

(Brian Powell at 00:13:46) Well, you know, the stuff that we're doing is largely continuous integration type work. So there's not really a set of languages or, you know, or things that we're looking specifically for. And, you know, there's not, we're not inheriting much either. So the, you know, it's sort of a blue ocean here of what we could use. And, you know, we get the, unlike some roles that you step into where it's largely prescribed what you're going to build and what it is, you know, I think that the fundamentals and, you know, fundamental ideas and the concepts are there, but how it goes together and what it looks like and how it operates, all of that's to be determined. And so, you know, those are the type of projects that are kind of really exciting to step into.

(Joel Beasley at 00:14:31) So you're looking for more of a generalized architect to come on board first with you, and then you guys kind of make those decisions?

(Brian Powell at 00:14:38) So we have the people who've done the original proof of concept with our parent company that sort of prescribed the building blocks of those pieces. And now it's just trying to figure out how do we put those building blocks together, and what are we going to stick them together with.

(Joel Beasley at 00:14:53) Okay. So you're in that process right now of discovery, of figuring out what technologies you're going to use to take this idea, this proof of concept, this prototype that you have, and then make an MVP out of it.

(Brian Powell at 00:15:03) That's right.

(Joel Beasley at 00:15:04) Yep. That's exciting, man. You're in a very—there's lots of highs right now. You're in a—

(Brian Powell at 00:15:09) Oh, yeah. Yeah. I mean, you're back to every time something clicks a little bit better, you're like, oh, now I get it.

(Joel Beasley at 00:15:16) So are you the CTO of this company?

(Brian Powell at 00:15:18) I'm the Director of Engineering. The two people who've developed the technology have stepped into the interim CTO roles. So the expectation there is that as we get to this company being fully commercialized, then at that point they'll transition back to the mothership and continue to build all the awesome things that they do over there.

(Joel Beasley at 00:15:41) Well, they seem pretty smart. I mean, they found you, and you sound smart. So your primary language that you have the most experience—what is that?

(Brian Powell at 00:15:50) I write a lot of my stuff in Go.

(Joel Beasley at 00:15:50) Really?

(Brian Powell at 00:15:50) Yeah. So I started in PHP, you know, like most people do when they're sort of hacking stuff together. Got a lot of love with PHP, sort of meandered through Ruby, not really in love with that. Then Node popped onto the scene, became pretty popular. But then, you know, you start to realize all of the drawbacks of writing server-side stuff in JavaScript. And then found Go. And Go is just one of those things that—people find a language that just sort of clicks. And I can look at Go and just understand what's going on underneath the hood, but how to sort of build pieces and stick them together.

(Joel Beasley at 00:16:36) Yeah. I actually went to a meetup when Go was first coming out. Google had asked a bunch of developers to do talks and stuff, and they described the whole concept of Go. And the guy actually had the language deployed to a satellite, which was really neat. So he had the laptop with him at the talk, and he actually rotated the satellite in space at the talk. It was pretty cool. It was all done in Golang. You ever see that newsletter, the email newsletter Golang Weekly?

(Brian Powell at 00:17:05) Mhmm. Yep. Absolutely.

(Joel Beasley at 00:17:07) We had Peter Cooper of Cooper Press on the show this morning.

(Brian Powell at 00:17:12) Oh, nice.

(Joel Beasley at 00:17:13) Yeah. He puts together—well, that's Cooper Press. Does all those, like, Ruby Weekly, Golang Weekly. So he was pretty cool dude. We were talking about, like, startups and content and the concept of, like, when should the startup start making the content? Right? Should it be right when they have the idea, or should they be secretive and, like, build the product for six months and then write the content? Or, like, at what stage should they be writing the content? And overwhelmingly, the answer was, like, immediately.

(Brian Powell at 00:17:49) Yep. I agree. I mean, I advise right now—I think my advisory list is around a dozen different startups from, you know, Techstars, Brandery, Uptech here locally. And it's so funny because there's just this overcaution of sharing your idea with someone and the idea that they're going to go steal it. And in most cases, it's almost laughable because at the end of the day, it's, you know, just get out there and build your product as fast as you can. And, you know, if you're not telling anybody about it, you're probably not marketing or doing a very good job of getting people to your product. So you just need to be as loud and as noisy as possible with your particular marketing for your idea.

(Joel Beasley at 00:18:34) Yeah. So they also don't have to necessarily find and focus on the one thing that's proprietary and should be quiet, right? And then go pick that one. They could literally just start with the journey, start writing articles about the problem, start weekly up. They could just—you could generate all of this other content around it so that in six months when your product launches, or in three months or whatever, you have this long repository, this history. And when people start searching for that question, when you start selling the product in six months, they're finding you through the content you wrote from day one.

(Brian Powell at 00:19:09) Absolutely. I mean, you could just have a landing page saying, "Hey, sign up for my email." Right? I've seen a lot of companies get a huge following just from, you know, to your point, starting the content and just at the bottom of that saying, "Hey, to keep up to date with what we're doing here, you know, give us your email address, and we'll just include you in it."

(Joel Beasley at 00:19:27) So you guys going to be doing that then?

(Brian Powell at 00:19:29) I don't know. So, I mean, we're so early in this, and a lot of the clients and stuff like that that we're working with, I don't know if that would necessarily resonate with them. Probably the second to third phase of this particular company, that'll definitely be the case. I mean, we don't even have a logo yet. That's how kind of fresh this thing is. But we're engaging the marketing teams and stuff like that sometime in the near future to get all of that stuff rolling.

(Joel Beasley at 00:20:01) Very cool. All right. So yeah. Because I think that topic—the functional approaches or, like, taking ideas from other complicated engineering segments of the market and then applying them—there's, like, that's a huge pile of content you could write. You could write so much content.

(Brian Powell at 00:20:16) Yeah. I mean, it's literally bottomless.

(Joel Beasley at 00:20:21) I have on the sheet things that you want to talk about, the things that you have ideas about. Right? And one of them was prototyping for production. So I'm curious, like, what's running through your mind on that topic?

(Brian Powell at 00:20:32) So I actually do this as a lecturer at over at Miami University here locally in Cincinnati. And prototyping for production for me is really about—there's some core principles in sort of the process that you design when you're prototyping a particular feature or a particular product, like a full product, that if you follow them and you sort of use these guiding principles, you can make it really flexible and what you don't end up with is a bunch of code that you end up throwing away at the end of the day. So, you know, a lot of people won't take the time to invest when they're prototyping. They'll just try to get it done as quickly as possible and sort of building things in a very modular style. And if you sort of focus on building the components and the individual maybe, like, services if you're doing—if you think you're going to end up in, like, a service-oriented architecture—and sort of focusing on the pieces of it, you know, you can put together a pretty good LEGO set for building a prototype that will serve you as you even go into maybe future prototypes because you can say, "Hey, I need a service that just sends newsletters or emails or, you know, plugs into Twilio and sends an SMS." And you sort of have those tools in your toolkit as you're going into prototyping. And so as you're going through the wireframe process and sort of identifying that, what I encourage anybody that's engaging from a technical side to do is not to look at the features of what the product needs to accomplish or to do, but also, you know, what are the building blocks that compose the particular system and focus on dividing those into chunks with really good sort of clean interfaces on them so that they can be reused. So even if you're focused on the wrong thing and you decide, "Okay, this is a horrible idea. We—our market's telling us to go in a different direction," you still are able to sort of break apart those pieces and reuse them to quickly construct that next prototype. So you don't end up with one giant monolithic piece of code that then ends up needing to be completely reengineered when you actually go to—just even if it is successful, you need to scale it. Right?

(Joel Beasley at 00:22:57) Oh, so you did like—so write code the right way at the beginning?

(Brian Powell at 00:23:00) Yeah. And, I mean, so many people will just immediately go to, "You know, I'm just going to build it really quickly." Right? And they just start—they create one project and everything just slammed in that one project. And then when they go to change something, they spend the entire time chasing all the things that they broke because the code's just thrown together too quick.

(Joel Beasley at 00:23:17) Yeah. It only takes a long time to do it the right way if you don't know how to do it the right way.

(Brian Powell at 00:23:23) Correct.

(Joel Beasley at 00:23:25) So people that run off to do the prototype to do it as a prototype, it's like they've usually always done that. And then it's like, hold on a second, prototyper. Let's—let's build a product.

(Brian Powell at 00:23:36) Or let's take that and let's put that thing on two servers and see how it works. Right? Like, you know, let's try to run it with a load balancer in front of it. Oh, now somebody's logged out. Interesting. You know, that's always the—whenever I'm working with CS students, I always tell them, I'm like, "Okay, what happens if there's two of these? You know, does it all still work? Is there—are you sharing resources correctly? Are you using—is the app built state in the correct stateless formats?"

(Joel Beasley at 00:24:05) And that's kind of why you, I guess, like Go. Right?

(Brian Powell at 00:24:08) Yeah. Yep.

(Joel Beasley at 00:24:09) Because it dealt with those concepts. It was like Google's approach as "What if we build a language today?" Right? So what do you—in your mind, the differences between Director of Engineering and CTO, what kind of immediately stands out as, like, some bullet points differences to you?

(Brian Powell at 00:24:27) Well, I mean, Director of Engineering largely is—while my CTO roles in the past have been with startups that are sort of wearing that Director of Engineering hat, you know, largely this was a space where I knew that I didn't necessarily immediately come in with all the knowledge that I needed just inside of the sort of ecosystem. And so for me, I was sort of happy to take that Director of Engineering position to sort of learn what I needed to in that role and get the two people who developed and have operated in the space as mentors to sort of help me grow and learn what I needed to in this particular ecosystem. You know, the main things that stand out is, you know, as we build the team, the Director of Engineering, largely I'm going to be the one defining what the processes are, how the team works, how we plug into the other groups that are inside of the organization. While the CTO would take on those responsibilities without a VP or a Director of Engineering, you know, in this particular instance, the CTOs that we have are so close to the problem set that we're solving and such experts in it that it just makes sense for them to sort of focus on how do we continue to make sure that we have really great product-market fit and we're servicing the customer. And then I can take on all of the implementation and taking this out to the market.

(Joel Beasley at 00:26:02) Excellent. Because, like, when you take the mark—okay, so but you just caused fireworks to happen in your head. So at the same time you're talking about that, we got a question from the livestream says, you know, what if someone builds your idea and they steal it in, like, less than six months from the time you're able to talk about it until the time you engineer it? And at the same time, it's like, well, if you don't take your product out into the world and get feedback and start understanding, like, who your tribe is, who your audience is, then you don't even know if what you're building is useful.

(Brian Powell at 00:26:36) Oh, yeah. Absolutely. I mean, you know, part of that prototyping talk that I give is how fast can you set up your product feedback loop or your feature feedback loop. Right? Like, you can immediately get feedback on wireframes. Right? I've seen entire companies raise money on Envision Studio, like Envision, you know, sort of like demos.

(Joel Beasley at 00:26:59) Oh, I did this. I did this.

(Brian Powell at 00:27:00) And, you know, but if you get that feedback, then you're actually—you're iterating and already starting to turn the ship towards what the customers are saying provides value and what they'll pay for. If you're not focused on that, like, you might as well not be—you're going to end up six months down the road, and you're going to wonder why it didn't hit the market.

(Joel Beasley at 00:27:18) That's exactly the case. Also, it's cheaper. So I did an app, a fitness-related app with a company that did fitness stuff. And they were like, "Oh, we want to build that. This is version one. We want to build it, build it, build it, build it." I said, "Well, what if we just—" Or it's funny because I'm taking less money to just do something I think would be a better way to do it. Right? So I said, "Let's not build the app. Let's instead build a fully functioning Envision prototype. And you can take this prototype around with you on your phones to the gyms and, like, walk up to people or ask your gym customers and, like, have them tap through the app and, like, give you—ask them what they think." And they're like, "Oh, this is really cool." And then they did that at scale with, you know, probably 50 to 150 people. And then we did an iteration, and they went out and talked to 50 people, then iteration, then iteration. And we basically iterated the entire thing, which is designer hooking it up in InVision and us. And we got through that whole process. We weren't having to change code. We didn't have to change models. We weren't having to rewrite stuff. Like, we didn't have to do any of that. And I instantly thought, like, "Oh, man, I'm so happy Envision exists. This is such a better way to do it."

(Brian Powell at 00:28:28) But at the same time, all of that iteration's going on, you're off to the side sort of scoping your pieces so that when it is time to build stuff, you're sort of slowly accumulating. And then, you know, you're not waiting six months to take it to the market. The development time is largely cut short because you're cutting all of your rework, and you've already got a good idea of what the data flows look like inside of your app.

(Joel Beasley at 00:28:52) Oh, absolutely. It's cheaper, faster, and we know people want it.

(Brian Powell at 00:28:55) Yep.

(Joel Beasley at 00:28:56) Like, that's just recipe for success. Right?

(Brian Powell at 00:28:58) Pretty much.

(Joel Beasley at 00:29:00) Yeah. So I'm pumped about that. Okay. So did you watch the rocket thing yesterday?

(Brian Powell at 00:29:05) I did. I did. It was crazy.

(Joel Beasley at 00:29:07) How pumped were you about that?

(Brian Powell at 00:29:08) You know, as a kid who went through Space Camp, like, to see what he's doing, I mean, to land both stages right next to each other because, you know, that's just the flare that was needed for something along those lines. I mean, it could have been a complete, like, watching both of them topple in the largest explosion in the world, and he still would have been like, "Oh, you know, first time we tried it, whatever." But he stuck the landing on both of those, and it's just like, yeah, okay, alright.

(Brian Powell at 00:29:33) Yep. There it is.

(Joel Beasley at 00:29:34) It was so beautiful. I'm so happy because, like, the whole industry, all the investors, everyone's, like, pro-space. Like, that was important for the whole industry. You know?

(Brian Powell at 00:29:44) Yeah. I mean, even the competitors, right?

(Joel Beasley at 00:29:46) It's just...

(Brian Powell at 00:29:47) Blue Origin, you know, the private space flight and the investment that NASA's put into sort of driving into that is proving to be the right way. I mean, again, you know, if you allow innovators and money to flow into it, and if there's good business there, then there's probably gonna be good stuff done there.

(Joel Beasley at 00:30:06) Yeah. Because if you think about it, there's some families, a mother, father, and son and daughter who are sitting there watching that. And they land successfully, and everyone goes to cheer. And the kids are like, "I wanna be astronauts." They're like, "I wanna fly."

(Joel Beasley at 00:30:17) That's right. Or "I wanna go work on space." They'd be like, "Yeah, you could do it." Like, awesome. Like, that's gonna be it. But if those things would have blown up, the parents would have been like, "Good luck. No." You know? Like, "We'll see." And then, like, everybody would have been negative about it. So I was really pulling for it to work out successfully.

(Brian Powell at 00:30:35) Completely agree.

(Joel Beasley at 00:30:36) Did you hear our Mike Anderson episode?

(Brian Powell at 00:30:38) I did not. No.

(Joel Beasley at 00:30:39) Okay. I suggest it.

(Brian Powell at 00:30:41) Okay.

(Joel Beasley at 00:30:42) Because he builds satellites and the rockets and runs like a team in NASA and a team at his private company. And they are grappling—they're building a system right now that's going to go up in a rocket, grapple with Landsat Seven, a two-ton satellite mid-orbit, and refuel it, and then, like, go bring food to the space station.

(Brian Powell at 00:31:03) Oh, wow. Okay. Good luck with that, right?

(Joel Beasley at 00:31:06) Yeah. So he told us about kind of how they do that and robotics. And it's because he's curious. It's like, alright, well, you know, we write code, and it's important that the code runs or, like, whatever it may be. And, obviously, we do. Like, in our world, people consider tests optional. Like, if you go ahead and talk to a hundred people, fifty of them say, "Oh, tests are optional." I mean, talk to a hundred experts, tests are not optional. But the general consensus—but, like, when you put something into space, there's, like, test models, like everything you have for small replica models, life-size models at NASA's plant, and you run it over and over and over with the brightest people on Earth and run everything. And then it's like an autonomous mission. It's insane.

(Brian Powell at 00:31:45) Yeah. And then lo and behold, like, there's still something that's minutely messed up because, you know, you just don't know until you're there, right, doing it. Because Opportunity on Mars ran into something like that.

(Joel Beasley at 00:31:58) Yeah. So we're wishing the best for Mike Anderson's two-ton refuel of Landsat Seven. He also does robotics. His company donates some of their profit to FIRST Robotics, which is this program that teaches kids in school about robotics and how to be roboticists. Really cool. And he goes, "I feel like it's my duty because when I'm laying, like, on my deathbed, I might be on one of those respirators. And I don't want their embedded systems to, like, dump memory or crash."

(Brian Powell at 00:32:31) Well, I'm glad his motivations are in the right spot then, I guess.

(Joel Beasley at 00:32:34) I know. It's hilarious. It's like, I consider myself pretty nerdy, but I don't build embedded systems. So I wouldn't have gone there, but it's just so interesting how much we rely on technology. Those are systems—there's, like, this whole study. Have you ever come across human factors engineering?

(Brian Powell at 00:32:52) Yep.

(Joel Beasley at 00:32:53) Oh, that stuff is so interesting, man. It's like you use technology, but then you use it in high-pressure, life-and-death situations. And then you get these marketing people that are like, "I'm a usability expert." It's just such an interesting spectrum of the different roles that exist. There's so much technology compared to twenty years ago when I was growing up. I'm thirty now, but, I mean, no one had phones in school, and there was barely Internet except for at my dad's office, really. You know? It's insane now. Everyone's in this life cycle, and their business is a part of it.

(Brian Powell at 00:33:31) Yeah. The whole IoT stuff that's coming out is just, you know, it's crazy to watch some of that stuff because there hasn't been sort of that major acquisition yet inside of that market, but, you know, you're starting to see some of your major players sort of come out in that space both from—some of them are focused on medical, some of them on light manufacturing or manufacturing and just asset tracking. It's interesting the amount of data and how dependent we'll be coming on all of the networks and just connectivity of individual things.

(Joel Beasley at 00:34:00) The future. Like, I'm really excited for twenty years in the future. Like, it's gonna be crazy. Your company is gonna be, like, revolutionizing the software programming world with your building codes or whatnot. So if Elon Musk, he's super excited, does his rocket launch, and then he calls you up, and he's like, "Brian, you have to come over to my house. I built a time machine. You get to jump in it and go back ten years." What would you tell your previous self ten years ago?

(Brian Powell at 00:34:33) You know, I don't know if I would go back. You know, I mean, it's such a ridiculous answer, but I don't know if I'd go back and change anything because a lot of the stuff that I've learned has been through, you know, an amazing mentor network that, you know, I just continue to rely on. And, you know, some of those mentors have come, and I've gotten really close with them simply out of some of the missteps that I've made in sort of searching for help. And so, you know, that need to go back and sort of redo things, I feel like, would change where I'm at and the opportunities that I have in front of me so much that, you know, you can end up in a completely different spot, right? You could end up with, you know, things just not being right in life, I guess.

(Joel Beasley at 00:35:20) So Elon Musk was not happy with that answer, and he has now pulled out a ray gun. Okay. You have to go in. You don't have to change anything. And this is not me. This is Musk, dude. So take it out on him.

(Brian Powell at 00:35:31) Alright. It's fine.

(Joel Beasley at 00:35:32) You don't have to change anything, right? And, actually, nothing that you would say to yourself could change anything. We're protected here in this loop. Okay? Just a piece of advice. Just a little something you'd say to yourself, like, "Buy Bitcoin" or "Don't step on that trash can" or, like, "Read Martin Fowler's book sooner," or, you know, "Go invent Golang." Like, anything. What would you tell yourself ten years ago?

(Brian Powell at 00:35:59) Yeah. I probably would have told myself ten years ago that, you know, it took me a while to rely on my mentor network. And so, you know, if I could have pushed myself a little bit more as I was younger to say, you know, there's a lot of people out there who have—if you're the smartest person in the room, you're probably in the wrong room, right? And so make sure that you're surrounding yourself with people that constantly push you and can help you and to just be willing to ask for help because, you know, a lot of times—I was, you know, when I was really young, it was like, "Oh, well, I can do this. Not a problem." And then when I failed, I was, like, irritated with myself. And really what I should have done is I should have just included more people in the process of tackling a problem and surrounding myself with the right people to sort of increase my chances of success very early on in my career, I'd say.

(Joel Beasley at 00:36:53) Excellent. So you'd say mentor network.

(Brian Powell at 00:36:56) Mentor network. Big time.

(Joel Beasley at 00:36:57) Mentor network. Elon Musk put the gun away. He's now giving me a free Tesla.

(Brian Powell at 00:37:03) He's hugging me now. He wants to be my mentor.

(Joel Beasley at 00:37:07) As soon as you sign the nondisclosure about the gun thing. Oh, thank you so much, Brian, for coming on the call today. It was super exciting.

(Brian Powell at 00:37:16) Yep. I enjoyed it. Thank you so much.

(Joel Beasley at 00:37:23) Thank you so much for listening to the Modern CTO Podcast. Share this. Get the word out. Thank you guys so much. I couldn't do it without you. I appreciate it. You guys are the absolute best.