ahead of what's next
An interview-style podcast that keeps you at the cutting edge of enterprise software!
In each episode, we dive deep into the world of technology and innovation, bringing you insightful interviews with industry experts, thought leaders, and trailblazers who are shaping the future of enterprise solutions.
Tune in for lively discussions, as we navigate the ever-evolving landscape of enterprise software.
ahead of what's next
AI, Technical Debt, And Star Trek...?
We chat with the Chief Product Officer and Chief Operating Officer of Nextworld about how much technical debt can REALLY effect your business, the challenges companies face with aging technology, and best Halloween costumes? Don't miss out as Q and Emily pick the brains of Konrad Rogers (COO) and Axel Allgeier (CPO) in this surprise episode of ahead of what's next A Nextworld Podcast.
of the Ahead of What's Next podcast. We're joined today with two very special guests, which we're excited to get into. Today, we're gonna be going over a topic that is very near and dear to, not only our guests, but the industry in regards to enterprise software.
Emily:Said,
Quinton:yes, it is also it's October. Spooky season is here. Emily, would you like to introduce who is joining us today on the podcast?
Emily:We are joined today by two of the next world founders, Conrad Rogers and Axel Allgaier. Thank you for being here. Both of these guys have spent the majority of their career in the enterprise software space and a large portion of that at JD Edwards. So we're excited to have them here.
Quinton:They'll forget more about the software space than I'll ever learn,
Emily:and what are we talking about?
Quinton:So today we're going to be talking about something incredibly spooky technical debt. What is it? How's it impacting the global economy? What is its role with AI in the playing terms of creation of technical debt? And finally, how you can address it. that being said, should we dive into our first question? The very, Important question, which is my favorite, in regards to the spooky season, what is your favorite Halloween costume of all time? Or, if you were to dress up as a character, which character would you want to dress up as? The floor is open, whoever wants to take it first.
Speaker 2:I think Axel should go.
Axel:I didn't grow up here, so we're really celebrating. I do have a ranch and I have a couple cows, so I dress them up instead.
Emily:Maybe a cow with a princess hat or something. That's sheep. Okay. There you go.
Quinton:Cause that's something that I'm definitely getting to see.
Emily:Conrad, how
Speaker 2:about you? I did actually. I guess a favorite costume, I don't know, Spider Man, Batman. So be one of those.
Emily:Love that. Since this is going to be Axl's first Halloween, I hear he's a big Star Trek fan. Not to ostracize any Star Wars fans out there, but I do want to ask if you could be any Star Trek character for Halloween, which would it be?
Axel:I'd have to go with Captain Kirk. The original.
Quinton:Okay.
Axel:Why? Because there's only one. Star Trek, and that's the original.
No one:Okay.
Axel:Captain Kirk gets all the action
Quinton:But we do appreciate the newer renditions of Star Trek, the newer movies. Correct.
Speaker 2:Yeah. Absolutely.
Quinton:Yeah. Okay.
Emily:What about you, Conrad?
Speaker 2:For me it's hands down, it's Spock.
Emily:Warm and sociable as ever, Mr. Spock.
Speaker 2:Yeah. I mean, even when I was a kid watching the original I was asked a similar question and the thing that appealed to me about Spock was the lack of emotion. It always appealed to me because usually when there's emotional outbursts or there's emotion, Bad things happen. At least that was my experience. So I always appealed to me, never be too happy, never be too sad or angry and good things will happen. Plus Spock is always dealing with data, right?
Axel:I want to be data. That's what I would have pegged you. I forgot about data.
Speaker 2:Yeah.
No one:I've completely forgot about that. He's an interesting character.
Speaker 2:And so with Spock, it was data, the other data, like real data and facts, and always being logical, just that always just really appealed to me. It's hands down at Spock.
Quinton:Mine's also easy for that answer because apparently they're Q. It's just synonymous. I have to be Q from Star Trek because that is who I'm, my whole world revolves around a single letter nowadays. And I learned that growing up because my mom's name, her name is Kay and I have Q and we just have the alphabet. We're starting to round up. So when it comes to dressing up as Star Trek character. It's gotta be cute.
No one:Love that.
Quinton:Yep. Has to be. I've accepted my role. And that's it. Fantastic. Yes. Um,
Emily:One other question before we dive in here rumor has it, and it's rare that I get both of you in the same room, so I have to ask, that Conrad was almost trampled to death. On Axel's property. Is this the truth? And can you tell us more?
Axel:This was right before Halloween. We were trying to put the costumes on. It just didn't go well. The steers were not cooperating.
Emily:So you have steers, you have sheep.
Axel:No sheep. Only on Halloween. Ah, they just
Emily:come right in for one day. They wear their uniform.
Axel:The steers are dressed as sheep? No, they're, what actually happened is every Once a year we have to load the steers onto the trailer for cattle, they're not cows. And that's I don't quite have the right chutes and equipment. So it's a multi person effort to herd the cows onto the trailer. And sometimes they want to turn around. And if they do stress levels increase. A person is not going to do much to prevent a cow from coming the wrong way. Right.
Emily:That's terrifying. The running
Quinton:The running of the bulls?
Axel:Which in front.
Quinton:There you go.
Axel:With a red flag and maybe they'll follow you in.
Emily:You hold it out to the side. Yeah,
Quinton:Over the trailer and you're standing next to the trailer. They don't come at
Emily:you. You. They come to the side.
Quinton:All of the above.
Emily:All right. Let's get into the meat of the matter here. Cattle had to
Quinton:catch it.
Emily:So today we're talking about technical debt. And I think for our listeners, we just want to start by giving a simple definition. What even is technical debt? And Axel, we'll start with you.
Axel:I'd categorize technical debt into two groupings. One is self imposed, I guess, and it's a result of taking shortcuts, for whatever reason. You take shortcuts, you don't write test code, you just don't structure your code properly, for whatever reason you end up with technical debt. And the second grouping is imposed on you and that would be aging code, things change. Industry changes architectures change, and your code is just sitting there as legacy code, and if you don't keep it up to date, it becomes legacy and technical debt,
Emily:right? And this can be what you've inherited from a vendor or something that you have built in house,
Axel:come from any source.
Emily:Conrad, anything to add?
Speaker 2:I mean, one thing I'd add is that. Sometimes with all the best intention and all the best practices, right? You'll write code, you'll deliver a software product and there won't be any technical debt because you did a really good job. But invariably over time that can change, right?
No one:Right.
Speaker 2:The state of the art operating system today if it's a point in time you don't update it to Axel's point or you don't keep up with it or you don't upgrade it or move along, eventually that is going to become technical debt. And if you don't keep up with it then you're really going to have problems down the road. And it's just inevitable. I mean, you look at some of the recent examples with Southwest and Even the traffic controllers network, I think something happened last year and it all came down to, they were running on components deep in their architecture that all of a sudden, or maybe not all of a sudden became unsupported.
Axel:The cloud strike example of what happened a few weeks ago is an example of. Aging architectures and components, not on cloud strikes side, but the fact that it was so impactful to companies like Delta. To me, that tells me that Delta has an aging infrastructure. They have servers, static servers that are sitting around and when they got this bad code deployed onto them from cloud strike. They had to reboot each server. You have a modern architecture, like ours, that just can't happen. Our servers come and go, they spin up and spin down, they get completely replaced. If we were using CloudStrike, it would have gotten on the servers we used at that time, and we could have just pressed a button, replaced them all, nobody would have noticed, and the new ones wouldn't have the CloudStrike code. And clearly Dell wasn't able to do that.
Emily:I think I told Quinton in an earlier episode that impacted eight and a half million devices.
Axel:For those devices that are on aging platforms, the only fix was to get out to reboot each one physically.
Quinton:And it was, what, four to five days of recovery time? Yeah.
Speaker 2:Or longer, right? Or
Quinton:longer. Wow. You mentioned, Conrad, earlier in regards to the Southwest Airlines example. I know there's a Forbes article that cited that the Southwest system failures culminated in over 825 million in loss. What do you think is technical debt a big contribution to what happened with Southwest or you want to go a little more in depth about?
Speaker 2:Yeah. I mean, the way I understand it, and that's reading all the same thing that's available to anybody else. Right. Was it was about crew scheduling, right? And it was about a system that probably did a great job when it was deployed initially, but then the business outgrew it. And so when the business outgrew it, they would revert back to like plan B's or if it needed to scale, They would go to manual processes. That works fine when you're within, the boundaries of quote unquote normal, right? But I think what happened in that time period was there were, there was weather, there were things that affected a large swath of the United States. Which is primarily where they operated. And so now the demands of what you needed from that crew scheduling system, even with the manual augmentation just could not keep up. And so it collapses and all the other airlines were in that particular instance, we're able to recover. They had some disruptions, but 90 percent of the flight cancellation, I think it was over 16, 000 flights that were canceled. 90 percent of them was one airline because of that one thing. Now, if. If you took a very proactive approach of, Hey, I'm going to keep up with this particular piece of functionality, right? Let's just, I think it was crew scheduling and we initially deploy it. But then as we see the system start to strain under the load that we're putting it under, as the business grows and you keep up with it, it doesn't become technical debt, you're investing incrementally over time. And I'm going to date myself, but there was a commercial for an oil filter is called frame, right? Frame oil filters. And I think it was something along the lines of, pay us now or pay us later.
No one:Yeah.
Speaker 2:Cause if you don't replace the oil filter, eventually you're going to have a bigger thing to replace. And I don't think I ever saw the art. I saw the commercial myself, but the way the article described it was a mechanic saying you can pay me now for an incremental cost of replacing the soil filter or. You can pay me a lot later to rebuild your engine. And it to me, that's analogous to what you need to be doing. You need to be continually investing and paying attention to how you keep the system healthy, clean, and up to date.
Emily:Yeah.
Speaker 2:Oh yeah. I mean, my son was trying to fly back to college on that day. It was a pretty stressful day. I will say that I really admired the way that Southwest reacted. It doesn't absolve you of, as a business of the sin, so to speak. But he was at the airport all day. They reimbursed him for everything he spent at the airport. We ended up having to buy him a one way ticket on another airline because he had to be back for his own reasons by the next day. They reimbursed us for that ticket as well. I don't remember, we don't fly Southwest that often, but I think they actually gave him some of their equivalent of points and things like that. So I did appreciate that. That being said, he hasn't been on a Southwest Airlines flight since,
Quinton:right? Yeah. It impacts their business, losing people that experienced that personally or ran into an issue.
Speaker 2:Was no answer. It was, you just wait and we don't know when, and that's, that has an impact. on you as a consumer.
Quinton:Right,
Emily:that can definitely hurt. There's one question that's burning in my mind that we wanted to ask you guys today. And I think we'll get an interesting take from both of you. But of course, AI, it's been around and everybody is talking about it. There's all sorts of haste that companies are taking to adopt these, adopt AI, and there's all sorts of generative AI systems out there that are doing things like writing code. My question for you is, how do you see AI potentially accelerating the creation of technical debt?
Speaker 2:well, I don't know that I'll answer it in a different way, and I probably, you've probably heard me talk about this before, but from a cloud ops background we always talk about processes and automating processes to make them go, faster, more predictably all that. But one thing we talk about is the sin that you can make when you can't do something consistently Transcribed by https: otter. ai And dependently at high quality and say a manual fashion and you go ahead and rush to automation. All you're doing is creating a bunch of crap really fast,
No one:right?
Speaker 2:And it just exacerbates the problem. And so when I port that over to this conversation about AI, there's a lot of potential in AI. Don't get me wrong, but right now it's more potential than it is reality. We're not seeing a lot of examples of really hardcore business results in a positive way from AI, but there's a lot of potential there. We know we'll come. It's not quite here yet, but I feel like in our rush to implement AI, there's this risk of what you're going to do is you're going to create a lot of, code in this instance and a large volume of it, but it might not be exactly on point. And therefore, there's probably a good chance what you are going to either have in the short term or have in the long term is a bunch of technical debt that you're going to have to deal with later via AI or otherwise.
Axel:I mean, AI doesn't always get things right. And if you don't really know the subject matter yourself really well, how do you know if it's right or not. Mm hmm. That's where it comes down to.
Emily:Technical debt pretty much is inevitable when you're dealing with technology. But maybe we can shed some light to how might companies address technical debt? You're never going to eliminate it, but how can you begin to alleviate it? We'll start with Axel for this one.
Axel:I mean, I'll stick to the two general groupings of technical debt, right? Self imposed by taking shortcuts and imposed on you as technology changes, right? If I look at what a no code platform such as ours can offer, It really protects you from both types of technical debt on the self imposed kind, it's the platform creates guardrails. It doesn't completely eliminate all self imposed technical debt, but there's enough guardrails there that they are dramatically reduced. The platform won't let you do certain things, it'll force you to create a table. There's enough validations. On the other side of the equation, the technical debt, where things, the technology changes, the industry changes on you, et cetera, no code platform, such as ours really protects you completely from those changes from that impact. And that's because you're not writing code. You're creating your applications and a higher level construct. You're creating blueprints. And the platform takes care of generating those or rendering them in whatever technology is best at the time.
Speaker 2:And inherent in that what Axel is talking about in terms of our architecture is that you're not stuck at that point in time when you initially create that application, right? Cause the platform inherently is going to keep you up to date because we're always staying up to date and we're controlling that technical implementation in this case, the actual code that's written. And I think that's really important to note because most platforms or coding languages that you use to develop an application. When you actually deploy that application, you're stuck at a point in time. It's that day. And it might be cutting edge today, but most of the time you want that to last a while and 10 years from now it's technical debt, whether you wanted it to be or not. And with a platform such as ours, that can't happen. It doesn't happen and you don't have to worry about it. Another way that the platform
Axel:protects you from technical debt is every time you touch code, you somewhat create a little bit of technical debt, when there's new capabilities that we want to leverage or offer to our applications, you have to go and touch each application, each component constantly. Oh, I wanna offer them an advanced search or some new capability. I gotta go touch each application without platform. We embed that capability in the platform and all applications have that enabled without having to go touch them, crack them open, modify them, et cetera.
Speaker 2:And you're, you were actually right though when you said low-code. Because local platforms have that same problem, right?
Axel:As soon as there's no such thing as local, you're either no code or you're not right? I've heard Vito say percentage of code is meaningful and impactful.
Emily:I've heard Vito say low code is mo code and we should make that a shirt. I think do you have a good example of this? Maybe a new technology decision is made and how that might propagate to every application as opposed to what would happen with other more traditional platforms where you have to go modify every single application at that point.
Axel:Sure. I have two that hit home for me because it's just an area that I'm passionate about. And one is database. When we first came out with the product, we ran on a specific database, MongoDB. And a couple years in, we decided we really wanted to switch to a relational database that had more data. Better transaction processing support, et cetera. In a code platform, that'd be a major undertaking. You'd have to change your schemas, your data access layer, you name it. For us, it was a very low level change and no application logic was impact. Rolled out a patch, next release, everything was running on the new database.
Emily:And there were lots of financial applications already built. It was still early. Yeah, it was
Axel:early on in our life cycle,
Speaker 2:and the entire application development community using the platform literally didn't even have to know or do anything. I mean, think about that. That's, pretty dramatic, right? And we're talking about a major component of the architecture. And so you port that thought to everything else that's within the technology stack, right? Because we're passionate and we're watching the technology arena with our entire careers have been spent in enterprise software. This is what we do. This is what we love. So us making those prudent decisions on behalf of our development community via our platform, without them being impacted. I just think that's immensely powerful. Mm hmm.
Emily:I kind of want to really drill this home, though, and I'm wondering, Conrad, you and I spoke yesterday about the power of a rewrite. Can you just really spell out how powerful that is? Next world is essentially rewriting all of our applications over and over again.
Speaker 2:And Axel alluded to this as in terms of that blueprint, and so with our architecture, with that blueprint, you as an applications developer, a user of our platform, regardless of what you're writing at the end of the day, what you're really doing is giving us a blueprint and telling us what you want to do, but not how you want to do it. We abstract you away from that, right? We have a layer within our architecture where we can codify what you've told us you want to do, and then we'll decide the technical implementation. And we'll implement that based on the blueprint for your presentation layers. And then on the server side, that's, might be an open source technology, such as plain old Java objects, but we control that. You don't need to know what POJO stands for, as a customer, all you want to know is that you want a header detail application. Okay. And we control that technical implementation. And the way we do that is at the end of the day, you have to have code. You have to have a technical implementation that is actually running right on your infrastructure. And so there's steps within our life cycle where we're actually taking your blueprint and we're converting it down to code. We're building it and we're deploying it all, with this automagically.
Axel:That's my second example. Logic blocks. Which is the way you define the most complex logic in our applications. It used to be a generated step. We used to generate Java code, compile it and then execute that so we switched to a completely interpretive approach. No more generation of Java code. No more anything. We just run that logic in memory. It actually performed better, but that's a change we did. That was completely seamless. Nobody had to change or touch anything. That blueprint of that logic block was what drove the platform.
Emily:I think what a lot of people will say when they hear, declarative development, no co development, is that all sounds well and good. It's sustainable. It can adopt new technologies, but it's really not powerful to accomplish the most comprehensive and sophisticated types of business processes I'm looking to do. What would you say to them?
Axel:I'd say if we were a platform, hard time answering that question. But we're building the most complex applications with the platform ourselves.
Emily:Like what?
Axel:You name it. Financials Order processing, manufacturing, advanced commitment, pricing, et cetera. So we're building all that with the platform. Now, early on, we had gaps and the apps teams drove requirements to the platform. But right now, today it's pretty rare that there's any dependencies from on the platform
Speaker 2:For an application.
Axel:It's pretty rare.
Speaker 2:But we went into this right to build a platform for the enterprise. So from day one, we were building a platform first approach. But what that meant was. We were shooting for the fences from day one. We stepped in the batter's box to not just hit a single and do simple Websites or glorified websites or whatever. We were building a platform to build the most complex enterprise applications And that is the goal line and that it was always our goal and that's what we've accomplished
Emily:So we've obviously talked a fair amount. And you've described to me about in the past when you were at JD Edwards, you saw the beginnings of this idea of no code. Can you talk a little bit about what the vision was back then and maybe how far you guys got?
Speaker 2:Yeah, I mean, I'll start and then Axel has even more history than I do on this topic. But when I started at J. D. Edwards, we used a case, we called it the case tool. And for the world, for the J. D. Edwards world, Product. It was an RPG based product, and we'd use the case tool to frame out the beginnings of our application. It was a one and done utility that would, we would use, but it would frame out and create a lot of the main program presentation layer data access layer pretty much everything.
Axel:Jumpstart.
Speaker 2:Yeah, it was a, yeah, jumpstart. That's a good way of putting it. To me, that was the beginning, right? Was, Hey let's start generating this code. A lot of it's the same. The structure can be the same. Why do we have to have each person rolling their own every single time with Everest, which became one world, which is now enterprise one. It was a platform first approach building on that kind of concept where the app developers were armed with event rules. They were armed with ways that they could define logic and templates for the presentation that they wanted to present based on, a library of different options. And so it took a huge step forward. However with the JD Edwards tool set, there was the complex logic ended up in business functions and business functions were encapsulated in Chunks of NCC code that were run within the platform to do things like, hardcore purchase order receipts or purchase order entry calculations and things like that. There were literally thousands of those business functions. And that was the archetype. There was a market window that had to be hit by all the ERP vendors and with Y2K coming that may have played a role in why we probably didn't push that a little bit further.
Axel:The vision though, the vision back then was not truly to be
Emily:was it mainly just let's go faster?
Axel:Yeah. I mean, we wanted to deliver the apps. Parody with world quickly, but I don't know that anybody perceived it as making a cause back then, right? No code was not a vision,
Emily:right? a little bit of revisionist history like and I think that maybe goes to something that we Already spoke with Kylie and Conrad and Vito about was the origin story when you and Ed Talked and said what would we do if we could do it all over again?
Speaker 2:Yeah, I mean, looking back pretty much the pin in that time scale that makes it legacy, a lot of that comes down to business functions and a lot of the issues and a lot of the customizations and all the things that you're doing within the platform. It's almost invariable that you end up in ANSI C code and business functions
Axel:later on as the web client came out Those C business functions. They just never they were always a challenge.
Speaker 2:Always a challenge
Axel:Rewriting them was just never a choice just because the huge investment in
Speaker 2:them probably millions of lines of code
Quinton:millions, the number I can't fathom millions is I've never seen a million of anything at one to get all together in my life. So fathom that number and lines of code is, like I said, it's unfathomable for me at least I have yet to dive into that. But in regards to kind of going back to a topic we were talking about earlier, what would you say for those who are listening, how you'd recommend people to implement the Uh, artificial intelligence in a sustainable way
Axel:go back to what you said, right? If you've got well defined processes, exactly what you want to automate or leverage AI for start there.
Speaker 2:Yeah. And I would just, try and cut through the hype and really get down to very specific use cases. What is the real return? And if you can't quantify the real return, maybe, take a breath, really think about that. And it's probably not going to be as cheap or easy or as quick as you originally think.
Emily:A lot of our listeners are JD Edwards users, customers or just people in the ecosystem. What would you recommend some of these folks start with when they're trying to address this at their organization?
Speaker 2:I think there's a myriad of things. I think sometimes organizations need to be very careful about shadow it. From a centralized it perspective, I'm not saying there's no place for decentralized, but I think you need to be careful when you don't have control over what's going on. And you may not even know. And just because you don't know that something's being implemented in some Division within your company doesn't mean that it isn't going to come back to bite you Because when it will come back to IT is when things go sideways and they need help, right? So one way I think Organizations they should partner And make sure they have very healthy relationships with The business, right? So I'm speaking from an it perspective to make sure that if a particular team is going to go off and do something, you at least know about it and you can advise them and partner with them on that. And sometimes the answer might be, you really shouldn't do that. And really we should keep that under the auspices of our formal it. Infrastructure and scope and authority. And other times let's partner together. The risk is manageable. Let's do that. You have to know what is your enterprise landscape, because if you don't know how can you keep something up to date that you're not aware of, right? And making sure that you are staying up to date and the things that you own on premise systems, legacy systems, that you're aware of How do you get support for them? How do you keep them up to date? And that you actually do that and track that. And then for your cloud vendors, you do the same thing. You make sure that they are doing their part. To maintain and keep those systems up to date and that they're paying attention to the things that you should be caring about as well. And if you want to have verification of that through a SOC 2 or something along those lines, I would encourage you to do especially for anything that's even close to mission critical.
Emily:You know, If you have aged technology installed and you really can't get budget or a project for something as big as a complete rip out and replace your ERP system, what would you tell an IT organization or just an organization in general to focus on?
Speaker 2:I would focus on one with those legacy systems. What have you done and what can you do to make sure you shore it up? And if you continue to stack cards on that house of cards, if you want to refer to it that way that you do that very carefully. Sure. And if that means you have to go slower, then go slower. If it means that you need to bring something alongside that system, to allow you to continue to innovate without adding additional risk to a legacy system that you already have, but you don't want to rip or replace it. You have it in a good place. You have a good strategy for it, but you don't want to change that. Then I would encourage you to look at those other kinds of offerings that are out there in the market to see how you can stay competitive, to see how you can continue to innovate and moving your business forward without opening any doors of risk.
Emily:anything you want to add to that, Axel?
Axel:Conrad leaves it open to other platforms out there. I would just say if you're looking for other platforms out there, stick with no code. Otherwise, you're really not necessarily solving anything and really make sure it has all the enterprise grade capabilities you need, whether it's auditing security. Can I build an app? Can I deploy to a test, to a production environment? Can I test it effectively? Can I document it? Can I have help text? Can I audit every change a user does?
Speaker 2:Is there a documented support policy for how you're going to fail over, where you're going to fail over? How resilient is that? And what are the options that the vendor can give you for that?
Quinton:Fantastic. before we close and Before we let you go today we always end up with a question for this October date that we're in today. What's next for Conrad and Axel? What's next on your guys schedules or coming up in life? What's next for you?
Axel:I'm going to be picking up next two steers. For a set of cattle.
Quinton:Love that.
Axel:Sometime in November, probably. And then I just had two surgeries, back surgery and hip surgery. And so I'm looking forward to getting back in shape after six months of doing very little.
Emily:Oh,
Axel:that will feel good.
Quinton:Love it.
Emily:When are you going to invite Conrad out to meet your steers?
Quinton:Or if ever.
Emily:Oh,
Axel:he'll meet. Nice Halloween. Good.
Speaker 2:I mean, I don't really have anything dramatic planned after Halloween.
Axel:Your son graduating?
Speaker 2:In the spring my son will be graduating from college. Nice. Football seasons now in full swing and college football is a passion for our family. So I will be definitely there's some upcoming games I'm looking forward to one in particular around Thanksgiving with against a new sec entrance in Oklahoma. Okay. So I will be attending that game
Quinton:What college fan base are you a member of?
Speaker 2:Both my kids go to LSU and my wife's family's from Louisiana. So might as well go along with it.
Quinton:Absolutely. Emily, what's going on? What's next for you?
Emily:Let's see. My sister in law, she always throws a murder mystery party that she writes herself. And so she'll write the characters and you can see her process. It looks very beautiful. Mine with like sticky notes and string everywhere. And number one, I hope I get to be the murderer. Cause that's the most fun. And number two, I'm just looking forward to having everybody over and celebrating in style.
Quinton:Surrounded by family. Yep. It's always a good place to be. Yep. Fantastic. What about you? I'm gonna piggyback off of Conrad with this one as a uh, grow, growing up in Topeka, 30 minutes from Lawrence. I think it's fun to say that KU is, or Kansas is not just a basketball school this year in regards to our program, it's gonna be fun to attend the games at Arrowhead Stadium'cause they're totally revamping their booth in Lawrence. So then there'll be no home games true in Lawrence this year, but attending at Arrowhead, which is just a fun state to be in, whether you like pro football or not. But yeah, Kansas football. just being in the fall environment with the flannels and the pumpkins. It's my favorite time of year, mainly because of football, but also for the whole October vibe.
Emily:Pumpkin spice, lattes, pumpkin
Quinton:spice, everything.
Emily:There you go.
Quinton:Yeah. Fantastic. Thank you both for joining us today. I know taking time out of your busy schedules. We greatly appreciate it. Um, In regards to all topics we talked about today, we're excited to have you back on hopefully again, someday axle. Love it. You see that? We got it. We got it in recording. Thank you guys for listening. We appreciate it. Don't forget to, to like, and subscribe to the podcast on all of our platforms. Follow us on LinkedIn. And we look forward to seeing you guys and talking to you in the next one until next time.
.jpeg)
.jpeg)