How Agentic SDLC Turned a 5-month Project Into 5 Days with Brian Elliott, CEO at Blitzy and Tom Jackson, CTO at RSM US LLP

(Tom Jackson at 00:00:00) You have

(Brian at 00:00:00) a tool like Blitzy, which will ingest and understand large-scale code bases and then do large swaths of development. Think weeks or months of work autonomously over several hours or several days if you can self-compute.

(Joel Beasley at 00:00:13) I don't think many people listening will have trouble understanding the concept. I think the trouble is, is it really there today? So, Tom, you're one of the customers, right?

(Tom Jackson at 00:00:24) Yes, I am. We've had probably six or 700 developers. That project took five months of time for the team to build. And, well, let's see, in that early test, I think total time to not just mock, but actually running, including back-end infrastructure usable product, was something along five or six days.

(Joel Beasley at 00:00:47) Wow. So I am particularly excited about this conversation because I got to meet Brian a couple weeks ago, I think it was, and you described this technology and what you were doing. And Tom is a customer of the technology. So I'd like you to both introduce yourself. I'd like to start with Brian.

(Joel Beasley at 00:01:07) Brian, could you please introduce yourself?

(Brian at 00:01:09) Yeah. I'm the co-founder and CEO of Blitzy, which is an autonomous enterprise software development platform. And we'll get into it more, but I'll pass it to Tom for a quick intro.

(Tom Jackson at 00:01:18) Yeah, I'm Tom Jackson. I'm the Chief Technology Officer for RSM US LLP and recently a Blitzy customer.

(Joel Beasley at 00:01:26) And could you just give me, RSM, that's a lot of letters.

(Tom Jackson at 00:01:30) We love acronyms in this industry. I mean, everything's an acronym. Though, technically, that one's not. It's just RSM. But we are the fifth-largest professional services accounting, assurance, and consulting firm in the United States, and we serve primarily—our passion focuses on the middle market specifically—and we have 19,000 professionals with all sorts of expertise across technology, business, tax, audit, and a lot of as many different needs as we have customers. So that's a big part of what we've spent our time trying to solve.

(Brian at 00:02:10) And to give Tom a little credit, he's still a technologist, not just an executive. And he keeps a foot in both worlds, the business side, but he is quite technical.

(Tom Jackson at 00:02:21) I try to bridge that gap.

(Joel Beasley at 00:02:24) So you're not just a sales CTO. You've got the technical experience as well.

(Tom Jackson at 00:02:29) Yeah, I'm a nerd. I really enjoy technology as my job and my hobbies. So I spend my time dabbling in anything I can.

(Joel Beasley at 00:02:36) You're my people. I'm such a nerd.

(Tom Jackson at 00:02:37) I have to—

(Joel Beasley at 00:02:38) I go with a beard. It's like camouflage.

(Tom Jackson at 00:02:39) I'm jealous. I'm very jealous.

(Joel Beasley at 00:02:41) It's like, no, I'm cool, trust me. Take the beard off, it's like, he's an engineer.

(Joel Beasley at 00:02:46) Brian, what is this amazing technology that you are building?

(Brian at 00:02:51) Yeah, so Blitzy is a rapidly scaling autonomous software development platform that is uniquely built for the enterprise. So if you think about this spectrum of code generation, which is the most salient AI use case that exists right now, code generation, you have all of these amazing tools on one end of the spectrum, which, you know, Tom is a user of some of these tools. You have Cursor, you have Copilot, you have these tools that help developers develop 40% faster when fully utilized within the IDE. So we love these tools. We use them. These are a perfect complement to Blitzy, but it helps set the stage for what we do. So on the other end of this spectrum, you have a tool like Blitzy, which will ingest and understand large-scale code bases and then do large swaths of development. Think weeks or months of work autonomously over several hours or several days of inferencing compute, ultimately giving highly reliable, highly quality code at scale, and calling out where it needs the human developer to come in and finish out the work. So we do, on average, about 80% of the quantum of work autonomously for these multi-week or multi-month work streams and then pass off that final 20% in a very clear guided document for the developer to come in, pick up those tools with Cursor or Copilot or those tasks, and finish it out. And so what we're really bringing is this platform that allows enterprise to have an agentic SDLC driving every sprint, major project, with Blitzy and then finishing that work out with the developers. We're seeing a five x order magnitude engineering velocity difference. So this is really bringing in the full power of generative AI throughout the SDLC.

(Joel Beasley at 00:04:29) It's so cool because I don't think many people listening will have trouble understanding the concept. I think the trouble is, is it really there today? I think that's what people are gonna have a hard time grasping when they first hear about it. Because for me, that's what I thought. I was like, oh, of course, that's the future. Of course, that's where we're going. Makes complete and total sense. Are we there yet today? I would say no. Then I met you and I'm like, okay. At first it sounded real great. And then I was like, do you have customers? And you're like, yeah, we have huge customers. And they're using this? Yes, they are using this. And so I said, I've got to talk to them for myself. So, Tom, you're one of the customers, right?

(Tom Jackson at 00:05:06) Yes, I am.

(Joel Beasley at 00:05:07) And what Brian just described, that's something that's actually happening within your organization.

(Tom Jackson at 00:05:13) It is. And it's—I won't say, you know, Brian eloquently put what the vision is. And if it was just that push-button easy, I'd be out of a job. But the use cases that we found where we'll be able to apply this, where it works really well, we are seeing massive increases to the—or massive reduction, I should say, to the time to deliver, or the increases to velocity of those teams. And I think our biggest challenge now is, now that you see something like that, how do we adapt the business, adapt the working teams, adapt the human processes around what used to be the bottleneck in time shifting.

(Joel Beasley at 00:06:01) So this has definitely improved you guys' speed. This is making things move faster over there?

(Tom Jackson at 00:06:06) It's making things move faster in the teams that we've deployed in. We are still in—we have probably six or 700 developers and it has probably gone across four or five teams of maybe 20 or 30 of the developers currently using this platform. And we're still in the midst of deployments and trying to figure out how to adapt our SDLC best to match this. And there's been some really heavy work from our teams to adapt how we even think about starting a project in order to really take advantage. So no one should underestimate what that type of change means.

(Joel Beasley at 00:06:43) Yeah. And, of course, nothing's ever perfect right off the bat. This is an industry-changing, world-changing piece of technology, right? And there's gonna be steps and layers to it like the Tesla full self-driving. You know, it's gonna get consistently better, but the base is there and the base is better than doing it manually. Brian, am I on track or am I in left field here?

(Brian at 00:07:03) You're spot on in that. The technology is incredibly powerful, and so then it really becomes a people problem, right? This is a change or a shift to how software is developed. So, and, you know, in all of these—I think we've done 22 projects with Tom and team to date. And in every one of them, if you look at the baseline and the reality, it's somewhere between three and five x faster than what they were planning on doing it with. Now how do you get a thousand people to adopt that well? You put them through a deliberate process. And as we said when we got started, you don't do it all at once, right? You actually build it deliberately with three to five core teams. You get very successful over the first six months. You understand specifically inside of that SDLC what's gonna change, and then you start to scale from there. So we look at a crawl, walk, run methodology of getting folks brought on, and it's—the proliferation of net new technology is really gapped by the ability for the organization to adopt it, which is honestly a leadership challenge and opportunity. And I've been very impressed that Tom actually recognized that. We went through a pretty extensive validation process upfront, and he said, my biggest challenge ahead of me is going to be changing the SDLC across, you know, hundreds of people. And so we're gonna do that stepwise.

(Joel Beasley at 00:08:24) Yeah. And even to start, there's no—I mean, Tom, I'm sure you're great, but there's no way the SDLC was super, super solid across a multi-thousand person organization. There's always little give and take across teams, right?

(Tom Jackson at 00:08:36) Oh, absolutely. I think if you were to ask people to list out the major SDLC milestones in five different teams, you'd get 10 different answers. So I think it's, you know, pretty common that people adapt, which as it should be, adapt their approach to what works best based on the technology stack that they are working in, based upon the clients they're working with, etc. So getting people to shift away and trust in a technology that approaches things the way that Brian and Blitzy do is—it's as much of a challenge as getting somebody to trust an outsource provider for the most part because that's probably the best analog I can think of for how you have to think about a system at this scale.

(Joel Beasley at 00:09:27) And when you're going to implement this at the organization, do you think it helps that we just had this big wave of these cursors and copilots come through? I mean, that kinda shook everybody up with, hey, we've got to adopt this new technology and then a slightly different way of working. Does it make it a little bit easier that that wave came and now we've got this new tool because people are in the mindset of changing and improving and growing? Or am I—

(Tom Jackson at 00:09:54) I think it definitely makes it easier from the fact that if those hadn't come about and this, you know, showed up, it would sound magical. But what people are able to see from Cursors and Copilot and Codexes and the rest of those five coding tools is their own experience of, yeah, it gets me part of the way down the track, and I just have to tweak what happens. So it's not a far leap from that to say, okay, if this technology were improved or modified or approached differently, it could get farther. And so I think that was kind of the, I don't know if I believe you, but I think it makes sense, you know, type of response I would get, you know, initially when we're talking to Blitzy.

(Joel Beasley at 00:10:42) Are people pretty receptive? Did you just go find the leaders in your organization that you knew are receptive to new things? Is that how you gathered the first teams for this?

(Tom Jackson at 00:10:53) Yeah. There were a few people internally. So we have one arm of our business is, you know, consulting, including technology consulting and custom software development. So we reached out internally to the leader of that organization to come take a look at this because it was like, hey, I think I'm looking at something that seems to be real, but I don't know if it's real. Can you come take a look with me? And then they asked somebody else, and then we invited a few other people and all sort of looked around saying, okay, we can see that this looks real enough that we want to actually put some intentional time, effort, and money into seeing how real we can make it.

(Joel Beasley at 00:11:32) Brian's like Santa Claus.

(Brian at 00:11:35) Tom did not take it easy on us during the eval phase before this deployment, which is wonderful, by the way.

(Tom Jackson at 00:11:44) I'm still not taking it easy on you. I mean, we can talk about things I need in one. We could go down that for the next hour.

(Joel Beasley at 00:11:50) Publicly. Yes. No, I'm kidding. We'll do a behind-the-scenes episode.

(Brian at 00:11:56) One thing that, you know, when you're working with an audit firm is they know exactly how many hours went into every single project they've done, you know, down to the 15-minute interval. And so when we did a couple of baseline projects for them when they're in the evaluation phase, they said, okay, this was 316.25 hours, you know. And so if we're gonna be five times faster, we have to be able to do this in 40 hours. And we were able to be successful across the first two kind of proof-of-concept projects and prove out the technology. But I think it was because they were that diligent and had the baseline that they were able to say, okay, well, we're willing to go deeper here. We're willing to partner deeper and start working together.

(Joel Beasley at 00:12:33) That is awesome. And so can you explain—so my background, twenty years software engineer, then I haven't been hands-on on a day-to-day basis in about five years. But can you just give me the 30,000-foot view of how these AI agents actually work and cooperate in order to build the software?

(Brian at 00:12:53) Totally. So first, it starts with understanding context, right? So when Blitzy starts working with a new code base, it'll ingest and create a knowledge graph of the underlying code base. So this is a core part of our technology. It can take a couple of days depending on the size of the underlying code base. We do 20, 30, 40 million line code bases. I think with Tom, we're in millions, but not tens of millions with you all, but really scale is where we are uniquely valuable inside of the marketplace. So we'll ingest that. We'll create a knowledge graph, and then we'll provide a spec to that end enterprise to say, hey, here's a human-readable version of what is going on inside of your code base, a few hundred pages that you might otherwise have Accenture build if you give them, you know, six months and some time to come back with a large architecture diagram. That is your home base for working with Blitzy. And then from there, you provide your development intent. It could be new feature development, which Tom and team have done a bunch of where you're providing user stories, hey, this is what we wanna build. It could be large-scale refactors. But the system at that point is gonna be more similar to a Deep Research or a managed type experience where it's gonna take an hour. It's gonna be referencing the knowledge graph. Multiple different LLMs are gonna be working together to create a plan, keeping the architect, the human, in the loop there. That plan can be edited or approved. But once it's approved, that's where the deep inference compute starts, where we're going to be writing, testing, and validating the code hundreds of times agentically ahead of it getting back to the human. So there's extensive validation that happens agentically so that the human can spend the least amount of time on whatever is possible while having a separate team of agents come in and understand what is left, right? And so this process really happens iteratively across all of the LLM providers so that at the end, you get a pull request of code that's been precompiled and pretested to match the functional correctness of what you're requesting and then a guide that says, hey, these files, this 15% needs to be human-completed to come in. And so it's really this intensive validation that's happening underneath the hood using a combination of all the LLMs together, different agents, different personas, different tools to drive up the quality of the code and doing that, you know, at massive scale.

(Joel Beasley at 00:15:08) When you're doing that, is the UI making it pretty? Is that the last mile? Something that humans are doing? How do they make that experience magical?

(Brian at 00:15:19) Yeah. You can think the humans—configuration, last mile UI, something that was underspecified in the spec, which when you're doing months of work, you'll sometimes say, oh, we didn't consider—

(Joel Beasley at 00:15:31) Of course.

(Brian at 00:15:32) This ahead of time. And so you had to come in, and we have a refinement workflow where you can say, refine this and run this portion again that's shorter in length than the day or multi-day run that you did. So there's really this new way of thinking that Tom's getting at. The core is you used to be able to sort of catch things in stride, right, and say, we're on a three-month project. On month 2.5, we realized we actually want to do something differently, and so we'll do that. Where Blitzy will do a huge chunk of that work for you.

(Brian at 00:16:01) And if you know what you want ahead of time, you're in a really good spot. But you'll realize very quickly, like, two days later when you get it back, I did not consider this portion. I know it was in the spec that was presented to me, but we need to have a chat about this. And so we, by default, had to make the platform both large-scale generative, but also iterative in nature so folks can have that moment, go back in, and refine their approach.

(Joel Beasley at 00:16:24) What's the interface that I'm doing this in? Is it a Blitzy app, a Blitzy website?

(Brian at 00:16:28) It's a Blitzy web application here. We're going to show you a spec visually. You'll log in. You'll be able to see your spec, come in, do plain text prompting experience where you're explaining what you want, and then Blitzy is going to come back in the web app and show you a future state technical specification document saying, here's everything that we're going to change. Right? So it's just a web application driving you through a spec-driven development process.

(Tom Jackson at 00:16:52) Yeah. But I would say also that the other side of the interface that really is where we tend to put a lot of the further context is actually the GitHub repo that is being used for the conversation between Blitzy and the developers. Because since Blitzy is pulling in all that context and actually integrated into a branch that we've created for it, we tend to populate a lot of back-end context and markdown files and other things in our code repos such that the agents can understand it. So that tends to be the other side of the interface that's been extremely useful to leverage.

(Brian at 00:17:35) Why do you think that team, which was one of the first teams that started picking this up and using it right out the gate—I remember some of the other teams have come on after those folks—but what do you think about that team has made them so successful?

(Tom Jackson at 00:17:47) So I think that they, first of all, they knew their product, they knew their customer, and they knew the problems they had on their list. Right? We weren't trying to find new problems to solve. They already had the list that they wanted to accomplish and prioritization done from the customer. So they were able to, they'd already had that context ready to go.

(Tom Jackson at 00:18:05) And then they were also the ones that worked, there's a gentleman that's in our organization, Craig, Craig Ramsey. He has been the one that spent a lot of time trying to figure out how to take what we constructed in how we lay out our repos, how we separate infrastructure as code from the primary code source, from the front-end UI, and put it together in a way that can be consumed by the platform and, therefore, give the platform enough information to build and adapt all those elements and get useful deployable feature releases back. So they had spent the time to understand a little bit of the nuances working on solving those problems. And so because of that, I think they just had a better appreciation for what they were getting into when they started.

(Brian at 00:18:56) And there's an actually important nuance there, Joel, that'll bring this to light to you. You're a technologist even though you're not hands-on every day. Generating code is very different from building enterprise software. Right? And so Blitzy is going to be using your internal packages, your internal libraries, your internal APIs and services to actually build that software.

(Brian at 00:19:18) That's how it's one of the ways that it gets faster. And so if you want to do feature X and you just generate net new code for all of that, that's not helpful for enterprise because that's not how they build. That's not how they operate. That's not how they maintain. So this kind of configuration setup is all about giving the platform the ability to see and index and understand your core set of services as an enterprise so that when you build something that touches that or uses that or leverages that, it's going to be built in the same way that the enterprise would want the humans to build it.

(Brian at 00:19:48) And so that was the, I think, initial investment that Craig and team put in. But that nuance, if you're developing in the enterprise, I think is kind of the moment where this is leveraging all the years of work that I built, leveraging my services and components when they're available as opposed to trying to reinvent the wheel every time, which is what you'll get with, call it quick-fire AI code gen tools.

(Joel Beasley at 00:20:12) So, like, for payment systems. Right? If you do quick-fire, it's going to go integrate with Stripe or something. But we have our own internal payments that you can expose it to your internal services, and it can use those.

(Brian at 00:20:23) Exactly. Yeah. That's the system design.

(Tom Jackson at 00:20:26) Yeah. So we have a whole set of libraries that we maintain called RSM Core that we use across any application that we're building. We have a UI toolkit that we're using to give our teams and our customers a consistent UI look and feel across everything. And one of the things that has been one of the initial challenges, but something that once the time was spent paid off a lot was making it so that Blitzy could pull down from our libraries and actually use our UI toolkit instead of just generating standard React JS. And so the learning is when to instruct the system to not try to solve a problem if it's not using our UI toolkit, but just identify that we're missing something or something like that.

(Tom Jackson at 00:21:18) Guiding the agentic system has been the hard part has been that generative AI systems want to generate things. And getting it not to generate what you don't want to has been a bit of the learning as we do some of this stuff.

(Brian at 00:21:35) Yeah. Totally. And it's been great. We've, our operational deployment team, we've hired a lot of people in the past six months because we've realized education and training is the only barrier. These tools are new for everybody. Right? Even LLMs were good at writing code maybe when 3.5 was the first time. It was like, you could squint your eyes and say, okay. I think this could actually be something if used properly. So all of this is new.

(Brian at 00:22:05) And gaining the intuition for that comes down to getting your hands dirty and using these tools. We try to, as much as we can, follow spec-driven development because that's been around for a long time, and that's sort of an accepted methodology. So one of the ways that you can think about Blitzy is it's spec and test-driven development done at the time of compute. But the spec is the source of truth. Right?

(Brian at 00:22:30) And so you want to make sure that the spec is saying, hey, use these internal libraries or use internal services or sort of ask Blitzy to tell the spec to do that to sort of get the right output.

(Joel Beasley at 00:22:41) I love it. I love it because there are so many companies too that have approached me off the podcast, and they were still trying to figure out how to convince—and this is modern within the past two or three years—still trying to figure out how to convince their teams to do test-driven development. They're like, okay. One of the best ways to convince them to do it is to hook up the agentic SDLC, and it'll do it for them mostly.

(Brian at 00:23:02) Yeah. And what we started doing—a lot of folks, we set up an accelerator program. This was you guys were already on for quite some time, Tom. So you didn't get into this motion. We're happy to bring some of the new teams onto it, but we'll just ingest code.

(Brian at 00:23:17) We'll walk phase. We'll document all of it for them. Crawl phase. We'll add test coverage, add code coverage. And then what's great about doing that as step one and step two is when you get into the use cases that Tom and team have gotten great at, which is new feature development or large-scale refactors, the AI is going to use that as well as a reference point. Right? And so it's just going to increase the knowledge and the context and stride to know what to do when, including the Copilot tools that you're using. Right? And so you get the sort of auto lift by having great documentation and great local test coverage. Then you get the Blitzy lift by saying, we're going to give this entire system the best robust infrastructure.

(Brian at 00:23:58) We're only able to do this because we can do this at scale with a platform like Blitzy.

(Tom Jackson at 00:24:02) I want to—

(Joel Beasley at 00:24:03) Go back to your first interactions with Brian and the teams and actually choosing Blitzy as a vendor. What was, like, the one thing that kind of got you over the edge when you were on the fence? This is new technology. What made you make the decision to even give it a shot?

(Tom Jackson at 00:24:21) So, I mean, number one, the team that Brian has, they're very willing to just constantly work through all of the random questions and challenges that we had, first of all. But, really, with one of the tests we did, as I mentioned, RSM does a lot of, has a great team that does fantastic work for custom software development for our clients. And so the leader of the team at that time was able to take one of the specs that they'd done previously for a client and say, okay. Let's talk about removing anything that's proprietary, but let's take what we're trying to accomplish and the spec that was developed, and let's send it through and see what we get. And so that project took something along, you know, five months of time for the team to build and get ready to deploy and have it accomplish all the goals that they had in spec.

(Tom Jackson at 00:25:15) And Blitzy in that early test. We had to do it twice, I remember, because the first one came out with some oddities. But the second time they did it, I think total time to not just mock, but actually running, including back-end infrastructure usable product was something along five or six days. And when the gentleman went through it, he said, yeah. There's some decisions that they made here and here that we wouldn't have done that way, but they've also done some things here that we now would have put on our backlog anyway.

(Tom Jackson at 00:25:56) So kind of the trade-off of it was, yeah, this would have moved the timeline dramatically for building for the client. Now it wasn't like the system built the fully operational pure running system. It got it to the point that Brian's devs could finish out the back end, tweak a few things, and get the project to run state. But we would see that and have the developers say, yeah. It came out with something that it's not done yet, but it's a lot farther than we would have been in six days.

(Tom Jackson at 00:26:33) So that, because that's all what it's about is time to deliver.

(Brian at 00:26:39) And then it began the process of, great. How do we get teams successful? Right? How do we bring this into the organization? And I was just very impressed that, like, you and me, great. I see this and this is great. Five months to five days is great, but all that matters is that we're able to realize this across all of these teams. And so let's now spend all of our time talking about the operational deployment.

(Tom Jackson at 00:27:03) And that's, you know, still the challenge. Not specifically for Blitzy. It's always the challenge whenever you change tooling or whenever you change processes or whenever you try something new, that doing it at scale is hard.

(Joel Beasley at 00:27:17) Five months and five days. Did I hear that right?

(Tom Jackson at 00:27:20) Yeah. I'd try to remember exactly, but I think that was, it was less than a week. I remember that.

(Joel Beasley at 00:27:24) Wow. So now it's just a human thing. We've got to get the people on board with changing, and that's pretty intense. Brian, you actually brought someone on to validate it.

(Brian at 00:27:38) Well, I mean, so if you go back to the team, the first team that started using this that got multiple successive runs very, very quickly. Something Tom mentioned is super important there is they knew what they wanted. Right? And right now, across most organizations that are operating in the, let's call it a circa 2023, 2022 development life cycle. Engineering is always the constraint. It's always been the constraint.

(Brian at 00:28:07) So there is not pressure, deep pressure on really defining exactly what you want and what the priorities are because it's always going to be constrained by this ability to deliver. Right? And the RSM team that you guys started with had a really clear vision of, here's a very deep product roadmap. Here's everything that we want to accomplish. Right?

(Brian at 00:28:28) And so when we started bringing that into our process, even before we will sell it, we'll say, like, hey. What is the roadmap across these teams? Right? Because we want to get really fast time to value and really quick deployment and success because we need our folks to realize the bottleneck is going to shift to a deep understanding of what you truly want and what you want to prioritize and what technical trade-offs you want to make.

(Joel Beasley at 00:28:52) Well, as we start to wrap up, I always like to ask because a lot of people in running engineering teams or just in technology leading people, they're always trying to grow and improve. And so one of the things I like to ask—I'll start with Tom. Tom, what's one piece of leadership advice that you got earlier on in your career that has stuck with you all the way through today?

(Tom Jackson at 00:29:17) Slow down. And when I say that, I tend to talk very quickly. So I am very much constraining myself right now in this conversation. And it was slow down, and also I had a CFO that told me, hey. Know when you made the sale and just stop.

(Tom Jackson at 00:29:39) Right? You don't have to keep talking. Let the silence let the silence talk for you. Right?

(Joel Beasley at 00:29:43) You talk through the sale a couple times. It gets painful money-wise, and then you stop it.

(Tom Jackson at 00:29:48) Yeah. Absolutely. Yeah. So that's advice I've gotten for me personally on the leadership side. This advice I give people in my organization is, if you're in a room and no one is speaking, everyone is either, everybody was just harping on what's not going right or no one is speaking to how to move forward. Be the person that speaks up.

(Tom Jackson at 00:30:11) Be the person that raises your hand and says, how about we try this? That makes you the leader in the room, and you don't have to have that title. You can just do it. So for me, it's just taking those opportunities as they come, and that's what I tell people to do.

(Joel Beasley at 00:30:26) I love that, not having the title, just do it. Just play the role. You know? Often, I have found, and I'm sure you both sell into companies. Often, the leader isn't the most influential person. The title of the leader isn't necessarily always the most influential person. So trying to figure out who's making that decision on that team is important. Brian, same question, man.

(Brian at 00:30:48) Yeah, I think the best leadership advice I ever got was hire for cultural fit and potential over direct one-to-one mapped experience. And so we have an unbelievably talented team of senior technologists, but we've turned down just as many with incredible pedigree that weren't a culture or a values fit. And for us, that comes down to operating as a team, putting the customer first, having a passion for invention, and moving fast. And if you can display those values and you bring people in that display those values here as a company, then we will be successful, and our customers will feel that we really, really care about them, and we're gonna put in the work to make them successful, both from the technology and the people side.

(Brian at 00:31:34) So hiring and enforcing a really, really team-based culture has been the best advice I've ever gotten.

(Joel Beasley at 00:31:43) Well, we did it. Brian, Tom, we made a podcast. How do you feel?

(Brian at 00:31:47) It's fun.

(Tom Jackson at 00:31:48) Yeah. Thanks for the invite.

(Joel Beasley at 00:31:50) 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.