subscribe for Updates


Bryon Kroger leads a captivating panel discussion with Lauren Knausenberger, Kim Crider, and Meagan Metzger, exploring the profound impact of software development on mission outcomes. The discussion delves into personal experiences, strategic approaches, and the critical role of budgeting in government tech and digital transformation.


Bryon Kroger (00:18):

I am curious to hear from each of you, just an example of when you realized, "oh, the software is that bad?" Maybe I'll start with you, Lauren.

Lauren Knausenberger (00:28):

Sure. So I, of course, before jumping into the Air Force, quite accidentally, about 2017, I saw much more of the slow acquisition process and the now 30-year period of acquisition reform, something like that, which actually between that, and just seeing how slowly we were delivering warfighter capabilities, and how much we had such incredible innovators that really knew their craft and could solve problems - that's what kind of pulled me in. I think there were probably two that I would call out the most. One was really with you, and I actually asked Bryon, have you told the Kessel run story today? And he said, actually, we haven't really, so I'm going to give you just a little tiny, tiny story. Because it was so big. It was just...Eric Schmidt was visiting the CAOC out at AI Udeid and Qatar and the mission commander had said, Hey, if you erase my whiteboard, the world as we know it will crumble. And of course, Eric Schmidt is like, what do you mean? Well, we're planning all of the in air refueling ops for our most critical missions right in the middle of all of our operations, heavy in the Middle East. And yeah, they're on the whiteboard, and we don't really have a backup, so if you erase it, we're not going to really know who to go and meet to refuel mid-operation. And Eric Schmidt goes, "oh crap, there should be an app for that."


And that's times so many different use cases where people were doing manual things or using really, really old software, when an algorithm, A: could probably do the math a little bit more efficiently, and B: it would probably be good to have more people collaborating and in the loop and able to see the picture of what's happening. And backups are also a good idea when you're trying to fuel an airplane that is flying at 400 miles an hour on its way to an operation because if you don't refuel it, it's going to have to either land or crash. We prefer land early. And so that was a major revelation that even for some of the most important things, we weren't writing good software. And so, I was so thankful that Kessel Run was kind of the big place that we really made software just a known thing that was in our daily conversation in the Department of the Air Force, and that it was such a...just a tip of the edge mission use case.


The other one was during my time as CIO, and this was a time when you don't want to make policy by meme, but we had some software that was so terrible that literally someone sent me a meme and I sent it to, well, I think General Brown and Chief Bass might've also gotten the same meme. And that software got fixed within like 30 days. It was great, but it was our fitness app. There was a meme where it said, my medical school interview, I have the hands of a surgeon, because I'm able to go through seven nested tables without falling outside of them so that I can enter my fitness scores, so that I can continue to be an Airman and serve in the United States Air Force. And that was one of those things where it's so bad that you have to immediately respond. And once again, we did it, and we did it fast and we showed that we could do it, but it...there were probably a hundred other things that we could have pointed to at that time that were that bad that it just came down to the focus and the resourcing to do it.

Bryon Kroger (04:09):

Yeah, that last one was, I remember that meme. It was all over Reddit too. If you ever want to know what's really wrong, military sub-Reddits are incredible in govtech writ large, it's surprising. If you don't know, check it out. Kim, I'm curious, do you have any stories that were turning points for you or really galvanized your why to do what you've done in this space? Caught you mid-drink?

Kim Crider (04:37):

Thanks. Yeah, I mean, I would agree that Kessel Run definitely opened a lot of eyes. I will tell you that I started my career in the Air Force. Of course, I grew up in the Air Force before we had a Space Force. I grew up in the Air Force, so I saw a lot of the ugly too. But when I got into the Space community, my eyes got opened up really wide when I went to our premier National Security Space Defense Center, and we realized that none of these systems talk to each other. Every single system is very stovepiped, and you have a lot of people in this operation center that are running around from system to system trying to connect the dots about what's happening to these satellites in space and what the potential risks are to them, or if these satellites are on track with where we' we're tracking them through their orbits or as they're calling for their commands to the specific satellites and they're initiating their tasking orders.


All of this stuff was done in very individual stovepiped activities. And it was really concerning because if everybody wasn't fully up in terms of their training or wasn't fully engaged in what was going on, we were going to be losing a lot of potential understanding of what was going on in the domain, and our ability to actively control it. So that was a big "aha" moment for me. And this happened a lot actually in a lot of our command centers, as you would see just solid, at that time, Airmen, now Guardians, just really flustered and overwhelmed with the amount of things that they had to keep track of as they were connecting the dots in this value chain, if you will, of a mission activity.

Bryon Kroger (06:51):

Yeah, I was in those ops centers. I spent the first seven years of my career mostly in air operations, but pretty much every JOC you go into, you see the same activities. We'll get to the positive stuff in a minute. I know we're just kind of like beating up. But Megan, do you have any good stories?

Meagan Metzger (07:07):

I've got some great stories. So if any of you have ever heard me tell the story of the reason I founded Dcode, I always use these points of inception. My first point of inception...I've always been in the private sector helping the government, and I was working for a large systems integrator. I will not say who, at the time, but we were building software, financial management software for Army and Army Reserves, and, I kid you not, we would get error messages in this software that would say "immediately shut down your computer." And I'm like, "or what? The world's going to explode?" It was the worst software I had ever seen in my life, and we could have bought the same thing off the shelf for about a hundred thousand dollars. Instead of the $30 million we were getting a year to build a really shitty [sic] software.


Sorry, I did not work there...yeah, I decided that was not for me, but that was my first point of inception was there's got to be a better way. We need better capabilities. Because the software was so bad, people would just log what they were spending money on, the budget of the US military, incorrectly because it was too hard to categorize it so that we spent $50 million on this base on toilets. I'm like, "no," it's just no one wanted to actually use the software. So that was one. After that, I worked...I was a Chief Strategy Officer for a firm and we were doing IT strategy and acquisition support. And this is where again, we were supporting the government trying to develop strategies to buy the tech that we needed, like the software, and we couldn't get out of our own way. And so we were spending a fortune on things that we knew weren't right was dead on arrival...before we even finished the acquisition. So, when people ask why I started Dcode, and our whole mission is how do we get better tech capabilities into the missions that need it? We do a lot of the stuff that Adam was talking about, but I was just a really concerned taxpayer, sitting here going, "wow, we're losing out as citizens, as a country, because we're spending a fortune. We just won't get out of our own way to get to the tech we actually need. So yeah, I've got lots of great stories, but we'll do that at happy hour.

Lauren Knausenberger (09:22):


Bryon Kroger (09:23):

Plug for happy hour. So, the next talk that we had after General Groen was Nathan Harvey from Google. He's on the state of DevOps report. He's done the last three years. I think y'all are pretty familiar with DORA. And he talked about the connection between software delivery performance and mission outcomes. And I'm curious to hear, we've beat up on government a little bit now, but there are real cool mission outcomes. And I'm not talking about like, "oh yeah, they shipped software and they did it fast and they did it every week or every day," but real mission outcomes. What are some really encouraging things that you've seen in terms of mission outcomes from improving software delivery? Anybody can answer.

Lauren Knausenberger (10:05):

So I'll start, and I'm going to also go back to Kessel Run, because it was kind of the beginning for truly understanding how hard hitting software was in the Department of Defense, and it was just so clear that you could not ignore it. So very quickly, on the speed side, going from five years, to deploy 14 times in a day, and that was a long time ago, 14 times in a day, which at the time was mind-blowing. Now I'm sure it's hundreds, maybe more, but the immediate metrics...almost immediately, we were saving about a hundred thousand dollars a week in fuel because of just a better algorithm. Just the machine was more efficient in the way it did the math. By the end of about the first year, it was about half a million a week in fuel, and then by the end of the second year, I think it was somewhere around the lines of half a billion dollars a year in maintenance and wear and tear on air platforms.


And so, those numbers were just so mind-boggling that you could not ignore, oh my goodness, the way that we developed software here...this paid for the software operation, it paid for the upskilling, it paid for everything. And so, from there, even just understanding that solving problems in a different way, starting with the outcomes, starting with the users, starting with what we were trying to accomplish with the mission and solving problems in different ways, that almost became more important than the process of writing software itself. But that was probably the biggest example. There have been a gazillion since then, but that was where the revolution started. What do you ladies see?

Kim Crider (11:43):



I'll pick up on the user-centered kind of idea. I mean, in the Space Force, in the Space community, I think we've seen a lot of success on user-centered design. Users really being in the driver's seat, and in many cases, actually some hands-on role in developing software. You may have heard of this initiative that we started in the Space Force called Delta Innovation and Supra Coders, right? Well, this whole idea was driven by the fact that, if you put users in the forefront, and you talk to them about what it is that...the problems that they're trying to solve...and going back to my NSDC, National Space Defense Center problem...what are the challenges that you need to solve that is going to make your mission more effective? And let them actually drive that, let them drive that with their developer teams. We saw this going on in... the space version of Kessel Run was recreated with a lot of help from Bryon and the Rise8 team under a group called Section 31, part of Kobayashi Maru out in L.A.,


and they were very focused on user-centered design, actively collaborating, even still today, with those operators that are doing command and control of space systems in those ops centers, and having those users really drive what their needs are and influence that design and be actively involved in the delivery of the software to support that. And that enhanced their ability to really understand and drive how they were going to improve their overall Space tasking process. In other cases, we saw some of these operators actually really fired up to do hands-on coding. In some cases, they would do it with developers, sitting side by side with them, in sort of paired programming. In other cases, they would just do it on their own. And I loved it because, at the time, I was the Chief Technology Innovation Officer, I was really pushing this whole approach of user-centered design and Delta innovation.


Of course, anybody that did hands-on work, they went through their own...we had an established training program that would get them skilled up on what they could do. But these young Guardians were just so fired up, right? They're up all night trying to figure out how they're going to improve this capability to enhance their mission. And we saw some really great things come out of that in the Space domain awareness arena, where they're constantly looking at what's going on in the Space domain and trying to figure there a potential for a conjunction, right - one satellite or one system in Space to hit something? And there's a lot of math that goes into that. Well, what happens, largely today still, is that there's a huge amount of information, a huge amount of data that has to be analyzed, to determine, "is there a potential for conjunction?"


Well, as you can imagine, right, 80-20 rule, 80% of that information is not really that relevant. It's not a critical conjunction. It's not something that's going to be in the area of a asset that we're worried about. So why don't we just eliminate the majority of that and focus on the conjunctions or the potential conjunctions that we're really concerned about. Well, it took a Guardian, working as a Supra Coder, but hand in hand with other programmers to identify that problem and then basically crack into the system, crack into the software, and reconfigure it, and change it so that now they're focusing on the conjunctions that matter. Saved a lot of time. And it certainly increased safety, right? Because now you're focusing on the things that you're most worried about.

Meagan Metzger (15:47):

Yeah, I think...I loved that talk. I would tell you of all the programs that we've worked on where we're working with the government stakeholders to evolve the culture and figure out how to move forward with tech and remove the bureaucratic barriers. And the ones that are very successful have that one thing in common is they knew exactly what the outcome was that they were trying to get. Not the output, but the outcome. And first, I'll tell you a bad story. I know you wanted a good story, but this was recent, where a fortune was spent to develop this really elaborate software, and they had the mentality of build it and they shall come. And no one came, right? No one came. And we were in a room and I asked the question like, "well, what would enforce the user...?" Because they're like, "we need to put...we're going to mandate it...


we're going to say, thou shall, definitely use this." I'm like, "okay, but move that aside. Why would they come here? What does it do, that makes their life better?" And they did not know. They're like, "well, they have to. It's their job." I'm like, "if there is nothing here that works for them, the people have to use it, that's different than what they have now. They're not being lazy. You just built shitty [sic] stuff," right?

Bryon Kroger (16:56):

Swear jar.

Meagan Metzger (16:58):

That's like the equivalent of living in Arizona and the car salesman selling me seat heaters. What are we doing? But on the flip of that, I've seen some really cool programs, some I've been involved with and some I haven't. The one that really stands out to me was actually on the Veteran Affairs side, and a close friend of mine was on the digital service team. And they had spent...the Veteran Affairs, had spent a fortune at this point to consolidate 1100 different websites and systems.


And they finally actually just sat down with Veterans. And I'm not talking technical people like, "Hey, you're sitting in a hospital waiting room. Can we have you look at the software?" And found out no one knew how to log on, and no one actually knew where to register in the systems. And it was just spending literally 10 minutes with these Veterans that changed their whole trajectory of what they're building. And they got stuff out in three months after that. So you see stuff like that, and I say that chasm of innovation in the DOD, it's like on one hand we're working on AI and hypersonics, on the other hand, we're getting off an aircraft, filling in a handwritten maintenance log, walking it a mile, typing it in, printing it out, faxing it, the pigeon flies... That's what's stopping us from staying competitive as a country. So outcomes for days. If you don't know why you're building something, just be a toddler and ask why until you actually figure it out.

Bryon Kroger (18:19):

I love that. I love it. I want to switch gears a little bit and talk about, I'll do, actually, I'll do cATO since I have Lauren here so...But those of you who don't know the first CATO, which again was a made up term at Kessel Run, but it was really ongoing authorization. A lot of people don't realize that. Lauren signed the ongoing authorization memo for Kessel Run, which we dubbed cATO. And I mean you were just an incredible champion for it. But I'm curious now, being able to reflect on that, everything that's happened since, where organizations have gone with it, some good, some bad, what do you think is, what would you do differently and what would you keep the same?

Lauren Knausenberger (19:02):

So, I think the way we started was really good because I think I said earlier, "hey, there are these guys that can deploy 14 times a day," but that wasn't the end of the story at the time. It was, we can deploy 14 times a day, but the fastest authorization official in the Air Force can get us our latest deployment in two months, and everybody else, it'll probably be a year before I can just push an update to my software. And so that really called me to action. And I really wanted to get involved with this incredibly passionate team. And I think we crafted some pretty solid policy together at the time, and just really automated a lot of it and got the right buy-in for people to say, look, we can prove, and we did prove, through a lot of testing that the way that we are accrediting, the way that we were testing, the way that we were automating that pipeline, and even educating the developers and the security personnel ,was inherently more secure than the previous process.


And we continue to prove that. I think that, and at the time we put out a bar, it was just like, "hey, everybody's going to want a continuous ATO." It sounds like Christmas. You just develop code, and it's done, and it magically appears in production. And occasionally some guys will come in and hack you and you fix it and it's cool. And that sounded amazing. Everybody did want a continuous ATO. And then I would explain to them, alright, but you have to be this good to get it. There is going to be a very high bar. And so there were very few teams that had the discipline that could prove that they could fix things really quickly, that they had the basic cybersecurity skills, that they understood how to automate the pipeline. And so there were some standardization things in there that I think were largely good.


Where I think we sucked was kind of the governance and reframing how we accredited because there were only a couple of authorizing officials that really understood the new methodologies. And so, it still became a little bit personality dependent. It kind of got pulled back to DOD CIO because at some point people just started saying, "king of the north, I have a continuous ATO." And it's like, "wait, who actually checked your system? Did they actually audit your processes? Did somebody come and make sure that you weren't pushing crap code? How did you actually accredit this?" And so, there was some natural pendulum swinging there that I think was healthy. I think we've maybe swung a little bit too far the other way now. I think that...I hope that we don't take for granted that we can deploy code quickly...that we can, and that we've shown that we have.


It's still very powerful. It's still a valuable litmus test, but we have way too few people in the Department that understand the methodology, and can help enable teams to go through. And I think that the pendulum will swing back to a healthier place now that we've been very, very focused on enablement and then, "hey, well only a few people can do this." I think we're headed to a good place. But, I think that it's going to take a lot of cooperation largely from DOD CIO partnering with the Services directly and being radically transparent about what works and what doesn't. And I think that will then flow to being a little bit easier with what at this point is pretty proven process. But I think we are going to have to bring in, I mean it's been too long since we brought in some of those mechanisms. We're going to have evolve faster and bring in new tools and leverage AI at an increasing pace.

Bryon Kroger (22:41):

We talked a lot about strategy at the end of the day and digital operating models, how to reorganize, very strategic big picture stuff. And it's's great! You all came into your roles with grand strategies, and I mean that, they were good strategies. I read both of them. And then, you help people write grand strategies across the government. And then there's this thing that always gets in the way, which is the budget. My favorite was when you showed up, I was like, "Lauren is going to be the CIO. This is going to be great!" And she published this amazing strategy and then I heard her give this talk where she was like, and I showed up, and we were hundreds of millions of dollars underfunded to do even the base level IT that we were supposed to be doing, let alone the innovative things that you wanted to do. So, it's not something we got to talk about a lot today. I'd love to hear from each of you, how are you addressing those budgetary challenges? How did you get after it, and what would you recommend to folks out in the audience?

Lauren Knausenberger (23:40):

I'm happy to go, but I know you guys have ideas on this too.

Meagan Metzger (23:44):

I have so many ideas. Some are good, some are bad. Well, one, you see this a lot. One of the biggest things I hear constantly when I'm in conversations about how do we evolve the department and what's the biggest challenge? And it always comes back to money. So I'm of two minds. One, a lot of times, yes, we are budget constrained. Yes, we need PPBE reform. That's a long way away. What do we have today that we can deal with and what can we do? A lot of it comes down to some creative writing. If we're going to be hamstrung, we get the budgets we have, there's some control we have. But if we're going to be hamstrung, how do we actually start evolving even our budget line items to match more outcomes-based requirements that fit? So for example, I was working with a gentleman, a general officer in the Air Force.


He's like, "I can't get approval for budget and I just need money. I'm trying to do AI initiatives." This was before you got a lot of money if you said AI, this was when you were getting no money if you said AI, on that pendulum swing, it's like, "well, that's because your line item says I need money for AI." I'm like, what if you just said "ship detection in the South China Sea?" Then you're funding a eagle, a shark with a laser beam. It doesn't matter. The outcome is still the same. And I think if we really want to future proof our budgets and our technologies, we have to actually put the outcome that we need. So as the tech and the software in that changes, we have the flexibility to be able to do that. Now, that's hard. That's easier said than done, but I think we have to put a different lens on and think of things...break the mold of what are we actually trying to do? But at the end of the day, the budgets are a big challenge. And I think the ability, if you go back to the outcomes that we're talking about, that really helps with the prioritization. If you go, this is the outcome we're going to get to, and here are the things that I need to fund, how much is it helping me accomplish that outcome? Then you can rack and stack in a different way. And I've seen these women do that with a lot of success, but it takes a lot of discipline.

Bryon Kroger (25:47):

Yeah, that racking and stacking...Paul Gaffney's talk, I thought it was really great. Two of the, I think seven leadership black holes. One was big teams, he talked a lot about, and one of the best things you can do for speed and delivery is actually reduce team size, but that also reduces budget. And there's probably a lot of cutting that we could do. And the other one he talked about was the quest for more, if y'all remember, and how, once we start delivering well and we have innovation going, we just want more, more, more. Instead of that prioritization of "here's what I actually need..." So I'm curious how that played out for you all. You had...

Meagan Metzger (26:23):

We don't always need more money.

Bryon Kroger (26:24): had these big strategies and then the budgets came. How did you handle that?

Lauren Knausenberger (26:30):

Well, I will share. I mean, I think this audience knows that the budgeting process is a little slow. And if you want to do things kind of quickly, you have to figure out ways to make trades in execution. And so, I think I remember saying like, "oh my gosh, we start the year like $350 million in the red." And Bryon's like, "well, that must be really amazing services." And I'm like, "no, no. I think the line items are Office 365 licenses so that you can answer your email, making sure that NIPR and SIPR are still turned on, having routers and switches on bases." And I'm like, "wait, how can we be 350 billion in the red on those things, and talk about software and hypersonics?" I was just like, how is this possible? And so, I actually had to spend a lot of time doing education on tying to strategy and how, if the foundation is broken, and you're kind of playing faith-based budgeting, that is the term I coined, by the way, faith-based budgeting, where you start the year 350 million in the red and you play chicken hoping that the money will fall from heaven in August, which does happen for IT sometimes.


It does happen, but it's not a way to run an efficient operation. Especially when you're talking about things that have to do with how much you consumed during the year and predicting. So that was a little bit eyeopening, but we did ultimately get there by really just having ruthless collaboration. We had to get people to agree to do things together. That was part of it. To make some trade space, but, really helping people to understand how much those technologies were enabling the mission got us to a much healthier budget picture now. But actually backstage, I shared something with Bryon that I think blew his mind a little bit, which is that Platform One actually just hit the budget like October 1. And we're in a continuing resolution, so who knows if it actually got funded yet. But if you think about that...

Bryon Kroger (28:39):

I've got a thumbs up.

Lauren Knausenberger (28:41):

So good. So good. So how long has Platform One been around? It's a while. It's finally in the budget. Something being actually in the budget in the DOD means that you can provide more robust enterprise services. You can plan. You can say, "hey, I'm going to do this," and know that you're actually going to have the funding to do it, rather than saying, "I can do this..." And holding your breath and hoping that you're not lying. But that's how a lot of some of the most innovative capabilities across the services work. And in some ways that's a good thing. In some ways, kind of being hungry, having to raise money... that's how we did everything as Chief Transformation Officer in that first role. In some ways, that's really good. But when you're talking about enterprise services for 750,000 people, that's probably not the right place.

Bryon Kroger (29:30):

No, it's not good… Well, I love it. Faith-based budgeting, by the way. I've got so many new terms. Paul Gaffney hit us with the "budget pageant." That's what he called it. That's a really fun one.

Lauren Knausenberger (29:40):

Was there a swimsuit competition?

Bryon Kroger (29:41):

One of his black holes was the conference room, by the way. It's a leadership black hole. And in the conference room, there's a lot of pageantry that goes on. "Budget Pageant" is one of those. Absolutely. So now I have "Faith-based Funding," and I learned some new swear words from Meagan. So what do you have?

Kim Crider (29:59):

Well, I would certainly agree with what these two guys have said, but I would tell you that every job that I had in any sort of executive-level role was essentially a startup. Showed up with no people and no money and just..."go do something." So there was a lot of faith based on that, but it really is about...I know one of the things that you guys talked about today is the Flywheel Effect. And that, for me, was always I think the right answer. You can create this Flywheel Effect. The Value Flywheel is a real thing. I have numerous examples of showing up in these jobs, no people, no money, but zeroing in on what is a critical outcome, that is going to really drive a need, and satisfy a need. And then thinking through what do we need to do to get that done.


Focus on that one thing. And I would tell my team, and it was really just sort of like all of the folks that didn't have anything else to do would show up on my doorstep. And I would say to these guys, all right, we're going to be successful here. We're going to be successful. We're going to focus on this one thing that is going to be really, really important to them. So let's think through all the things that are going to drive us towards that success. And we would do that. And we had a couple of successes where we would zero in on this one thing. We would stand up in front of a large group of people and we would show them, here's how this need that we've established is going to be satisfied through this capability that we can build out. And we showed a demonstration of how that would work. And of course, that got a lot of people's attention. And before we knew it, we started to generate a lot of interest in what we were doing. We were getting a little bit more money as we were going, and we were able to continue the process along. The other thing that I wanted to highlight, and Bryon, you've said this before in some of your other talks, and I was reading about this before I came over here today, it's such a great quote...


You've quoted somebody else in saying that the performance of an organization is never greater than the consciousness of a leader. And I think that that is absolutely another piece of this. Outcomes, yes, the ability to think through the Flywheel Effect, the ability to educate folks on where they need to go, but it really is about you in your leadership role, no matter what position that you're in, in the organization, having that consciousness, having the consciousness of where is it that we need to go, and being relentless on driving towards that, and bringing others with you. That's what's going to drive performance. That's what's going to drive outcomes at the end of the day.

Meagan Metzger (32:50):

Can I add something? I know. Don't yell at me. Yes, but here's what I love about what you're saying. The biggest art, and I think what's missing if you're going and you're asking for money, and you're not getting the money, is... we talked about end users, and we know what outcome would help them. And then you have your four-star who has a very different goal, and drawing the thread between what that end user needs actually impacts the vision for what that general officer or leader has, and making that connection. So it might be that the Airman doesn't want to do manual maintenance logs, and it's very frustrating. And then their goal might be, get the aircraft turned around quickly to save billions of dollars. And that story thread is missing. So a lot of times getting that budget approval, if you're working on those programs, you're somewhere there in the middle, connecting those dots...the story that I told of "build It, and no one came," well, they also weren't getting funded for the next year because no one came, but they also didn't understand what that person really cared about. So they're just there in the middle, building a bunch of things that don't actually matter.

Bryon Kroger (33:59):

Nice. That was two Field of Dreams references. Where are my Iowans at? Woo. Yeah, I know we've got a couple of 'em in the audience. I'm from Georgia. I'm from Iowa, by the way. I think I've got three or four here.

Lauren Knausenberger (34:09):

I'm going to say one more thing along those lines, now that we're talking maybe to a room of folks that want to actually solve some of these problems, and make some good money doing it too. Definitely one of the best things that you can do to fund something that will solve a real problem is to help your customer find the trade space upfront, help them to kill something. And once upon a time, we didn't kill anything. We still don't kill many things, but people now are realizing how important that trade space is, especially at the senior levels. People will be promoted based on finding trade space and doing something amazing with it. So if you can find that, that will allow you to solve a problem, make money, and really help a leader to deliver the outcome that they want to make,

Bryon Kroger (34:57):

I love it. That's a great note to end on because you ladies have drinks, but none of these fine folks do, right? Yes. And we're standing between them and Happy Hour. So you all are staying for happy hour, right?

Lauren Knausenberger, Kim Crider (35:08):

We are. Here, here, absolutely.

Bryon Kroger (35:10):

All right. So, Happy Hour is in Coalition Hall. If you want to talk to them, ask them more questions, they'll be in the room along with myself and everyone from the team. Just want to thank everybody. It's been a really great first day. Thank you all for helping me close it out.