Podcast Episode 7: Episode 213: The Vacation Test Every Rock Admin Should Run Right Now

Description

Imagine your Rock admin takes two weeks off for vacation with no handoff, no Slack notification, no "just text me if you need something" message. What breaks first? Whatever comes to mind is your starting point for what Nassim Taleb calls the fragility list.In this episode, Jon, Emily, and Nicole apply Talebʼs concept of antifragility to church systems inside Rock. Most people think the opposite of fragile is tough, but Taleb says thereʼs a third category for things that become stronger under stress. Glass breaks under tension but muscle grows, so should your systems.Jon shares an update about v19 in Beta Testing, and early AI Agent capabilities in this release. After engagement from social media on church budgets and AI pricing, he explains further how churches can prepare their budgets now while AI tools are still subsidized.Visit the show notes to find all the resources talked about in this episode. Don't forget to join the new Rock Cast Rocket Chat Channel to see what other churches are saying about this episode.

Transcribed Content

Welcome back to the ROTCast show. Thank you guys for tuning in. , we've seen some great engagement on the ROTCast Rocket Chat channel. It's been really fun reading those conversations. So if you haven't yet, make sure you join that channel, and then you can also hop in on the fun. So today, we have a great, roundup ready. John's gonna kick us off with some updates on Rock and AI, and then Emily will cover the main segment on a concept that will change the way you think about every church system. So, John, you wanna start? Yeah. So just the latest update, v 19 is in beta as of this week. And by the time you re listen to this, you will be even further in beta, but probably not out of beta. How long will beta last? That's a great question. It'll last as long as it needs to. We wanna make sure we get some really good testing. I think we had a really, really good alpha. We had some really good participation from the community. We had complete test coverage, and we found a few bugs, got those done. The team's been, , cranking those out as they come in. So I feel really good about 19. Beta has found a few other little things. Here's what I would say. The biggest finding that we found in v 19 is plugins are not being updated as quickly as they should. So in the code, we deprecate code. And then so what that means is, , hey. We don't wanna use this code path anymore. So we we kinda flag it saying, hey. Anybody who's using this code path, stop it. , here's here's another way of doing it. , the deprecation will tell you what to do. Some of those deprecations have been in Rock. Those warning flags have been in Rock for years. And we should have actually pulled them out, but we try to be very cautious when we finally start pulling some out in '19. And now we're finding out the plug ins are way behind in their updating. So we've been actively working together with those plug in developers to say, hey, we need to get these addressed. So even doing that ourselves, Spark has some some plug ins, so we're trying to be very good about that, trying to be a leader in that. But we're gonna continue to see that. So in 20, we've already pulled out some more deprecations. So if you're a plugin developer or you use a plugin, please emphasize the importance of keeping your plugins nicely maintained. But the, , the big thing in '19 is connections, and we're super excited to get that actually out there and more stuff coming in '20 and also AI. And so there'll be more discussions about AI going forward. That kind of leads into this the second news topic that I really wanna talk about, which is some updates in AI that I think the community needs to know about. The first thing is we have been talking a lot about AI, and I just wanna make make sure that we're all on the same page when we talk about AI. The goal of AI is not to take the person out of the ministry. That's a great clarification. It's actually the opposite. It's to put more people into ministry. And what keeps us from doing more ministry today, all of us, is that we have all these tasks that are very menial. They're actually holding us back. Mhmm. And if the proper use of AI is to get rid of a lot of that work and to to have AI help us see and have clarity into each individual so that we can be better responsive to them. So if you're using AI and you're not seeing more care and more discipleship, then you're we're probably doing it wrong. But I think there's a lot of people maybe who are not using it or maybe haven't caught the vision yet that this is a replacement of people. And again, that is quite the opposite. If we're doing this right, we're actually gonna be much more engaged in people's life. And it's in a sense it's saying because I think analogy helps. Right? Especially when you're dealing with new new concepts. It's a sense it's saying, hey. I'm not going to use my car. I'm just gonna walk from appointment to appointment. Mean, I imagine if you're a pastor and you have to drive from a hospital visit or you have to go visit some people at their home. You could say, what? I'm just gonna going to walk. That would be crazy. , we we we will drive, and then we will spend more time, and I can hit more appointments a day. And so we just want to be very cautious in in making sure that people understand what we mean by AI. So that said, , what what do we need to be worrying about, , this week? And it's really this whole concept that the price of AI is going up. So the price of AI has been subsidized until this point by equity capital. So what you're paying for your AI bill, you're only paying a part of your usage. The investors are paying the rest. And that's about to come due. That that's gonna start stopping. And why is that? Because adoption is up, scarcity is kicking in. So every major AI lab is out there trying to get deals to buy compute, buy data centers. They don't have enough of their own. In fact, many of them, , leverage deals to get their most of their data centers. So they're all out there making huge deals. If you've been watching that last two weeks, every single one of them is doing multibillion dollar deals, hundreds of billion dollar deals to to lock in compute because it's a scarcity. So compute is gonna become probably one of our scarcest resources. In fact, some people are thinking that it actually might be traded as a future in the futures market. So Really? Yeah. Because it's so scarce. So people will be be able to buy in and invest in that kind of stuff. Now why don't we just build more? Well, it takes a lot of time, and a lot of the components just you you just can't get. So the other limitation behind the data center is electricity. There's just not enough electricity. So right now, , the the time to buy transformers and parts in terms of the electrical infrastructure are two years out. So you used to be, , maybe a couple months out to get some of these transformers. Now it's two years because they've all been gobbled up and swallowed up. So we're gonna see scarcity in that. You're already seeing data centers going up everywhere. I mean, there's a huge one being considered in Utah. There's, I think, 40 or 50 right now being talked about just in the Phoenix Valley. So it's gonna be a major race. So this is really going to impact the price you pay. So you just need to know about that. , I'm glad we're talking about that because it we had a lot of engagement on post from x a couple weeks ago on this. But what would you say is the most important for a church that's just starting out with AI tools? Yeah. So it just kinda depends on how where are you in the maturity level of AI. If you're on the bleeding edge of it, you're probably gonna need to be talking about this in the next, , six to twelve months. You're gonna have to get that figured out. If you're a little bit on the laggard side, you probably have two years. Eventually, it's going to be a major part of all of our budgets. How long do you think churches will have to prep their budgets? Well, I think the best thing you can do right now is is we always talk about the the biggest thing in any kind of ministry or even business is communication. So even if it doesn't hit your budget for, let's say, you're on the laggard side, it's it's gonna be eighteen months. You should be talking about it to your leadership right now. , hey, guys. , this is a big thing. The world's changing. Is actually gonna hit our budget. We should be talking about that. What you don't wanna do is show up, , with a major change and there's been no planning. So I think definitely right now we need to be thought leaders in this. We need to be helping to guide our ministry staffs on what's coming. Mhmm. So again, I I think if you're on the bleeding edge, you need to be talking about right now and need to be planning. , our AI bill in April is about five x what it was in February. Oh, wow. And it's only gonna get bigger. , we're just, , we we've made a huge pivot. Everybody on our team is AI forward. But it's going to get much, much worse because we're our our usage will go up, but so will the price go up. Now the good thing is technology is just two things. , as it increases, it gets more powerful, but it also gets more efficient. Mhmm. So if you look at the CPUs of today, they're way more efficient than they were ten years ago, but they're also way more powerful. So we have both of those things happening. But because we're early in on this, , it's it's going to be a problem. I would say, , this is, , 1848. The gold rush hasn't started, but there's a few, , people who have are hearing the rumors of there's gold over there, and some people are starting across the prairie from Missouri. , hey. I hear there's gold in them hills. , let's go. , we're just leaving Missouri right now. And so it's a very interesting time to be Mhmm. , alive and working in this. Yeah. , I'd really love to hear from our listeners where you guys are in your churches with prepping for AI. , is that something that you guys are taking into account for your budgets right now? Are your senior leadership aware of it? Let us know in the ROTcast Rocket Chat channel. Thanks for those updates. Yeah. , it's always good to have those AI topics at the front of your mind. Emily, you wanna lead us into our next segment for today? Sure. I'm really excited about this. This is a segment we've been wanting to talk about for a while, And it's based on a book, actually a series of books by an author named Nassim Talib. He is a former Wall Street trader, and, he's now a philosopher and a statistician. Oh, wow. Such an interesting departure from Yes. Wall Street So I think he's a very smart guy. Would be my take on that. Now what he does is he writes and he thinks about risk and insecurity. And so he's written this book called Antifragile, which is part of his, I think, five book Encerto series. And it's a really interesting concept. So that's what we're going to talk about a little bit here today. If you think about the word, fragile, what might be the opposite of that? I think most of us would think , something fragile breaks. Something that isn't fragile, the opposite of that would be it's really tough or maybe resilient. But he actually proposes there's this third category. And there's not an English word for it. So he had to make one up. Hence the title of his book which Antifragile. It sounds a little counterintuitive, but here's the way that he, the illustration he uses to picture it. If you think of something a glass, made of glass, you pick it up, you drop it, it shatters. That's kind of the definition of fragile. If it's under stress, it breaks. You can squeeze it and it will fall apart. If something's resilient, you might think of a plastic cup. So you squeeze it, it doesn't break. And it just stays the same the plastic doesn't change, nothing, gets better about it, but nothing gets worse. Anti fragile is on the other end of it, and it's something that actually when it's under stress, it grows and it improves. So that's kind of a new concept. If you study language, anytime you have something that's critical to the way your society works, there's at least one word for it. Our language doesn't have a word for this, so it's not necessarily a concept we've put a lot of thought or time into typically. And what might make it interesting is in terms of churches, right? Every system in your church, your people systems, your data systems, your technology systems, they all fall into one of these three categories. They're either fragile and stress will break them. They're resilient and stress won't hurt them, but it won't improve them. Or they fall into this anti fragile category and stress actually improves them. So we want to talk about how to move more things into that antifragile category, even if they seem to be resilient. Do you want to start us off? Sure. Yeah. So the first one is automate that which which is important to you. Now I think, again, when you think about AI that , we think, oh, that's anti human. It's not. It's a it's a it's a way that we can help take work off our plate that we don't wanna do. I think this is the same thing. We have to look at what are humans good at and what are humans not good at. Humans are good at connection, creativity, thinking. We're not very disciplined. There's a few people who have gifts at being hyper disciplined. Usually, they come at an expense of some other thing, every gift. But for the most part, the average person is not very disciplined. I've considered myself in that category too. If it's something that's really important to you, you wanna make sure that there's an automation, that we ghost and say, hey, what? I'm not very good at to do these things, so I'm going to automate them. So if it's something that's super important or it's bound to a person, just remember people, even if they are disciplined, aren't always there. So they they get sick. That's true. They take vacation. They might find another job. They retire. You cannot bound something to a person and be antifragile. It has to the system has to be able to survive a single person. So you should really design for absence. So when you think about something that's important, you have to go, what happens if they're if that person isn't there? Now if there's no people there, then don't worry about it. But no no process can be bound to a single person. You have to be able to think of absence. So building workflows that fire automatically, there's certain AI tools that can be scheduled that they'll run on a loop, those types of things. So , take for instance, new visitors. The new visitor process is pretty important to you. Mhmm. If you rely on someone coming in and doing their work to get that process done, , that's not gonna be a good idea. E r ERA calculations can be set up to make sure that follow-up happens. Now some of these automations don't have to be completely machine based. Right? They can , when you think about ERA, it can create connection requests. Right. Well, now check the box, , that happened. And now you have another process that does have tools that can help provide accountability. So it's not taking the person completely out, but the person can't be the person the only way that this process works, especially with just one person. So the litmus test might be when your best Rock administrator takes two weeks off, do you even notice? Hopefully, no. And maybe you should even kinda practice that. , you don't actually have to take two weeks off. You can say, hey, best Rock administrator. Keep a little piece of paper next to you. Write down anything that you did this in the last two weeks. And you have to do it on a daily basis because you can't remember. We're not disciplined. Remember? Write down things that only how to do or that you're doing. If you were on vacation, we might have an oopsie. Because whatever breaks is fragile, so that's your list. If you see something that should be automated, automate it. Yeah. That's a great test. I love that idea. Unfortunately, I don't think churches are really aware what's on that list until something actually breaks. Mhmm. Yeah. I think it's on all of us. , we realize, oh gosh, so and so is not here. How does that gonna get done? Definitely. , for our listeners, I'm curious. What's one workflow or system that would break if that key person was missing for two weeks? Let us know in the channel. I think, , this also applies to our volunteers. And humans are creatures of habit. We tend to fall back on our systems, on our repeated behaviors. And for our volunteers, , might notice the same volunteers are doing the same role, sitting in the same seat every week. And while that's comfortable, it's consistent, it's stable, the other side of that is that it's also fragile. It can be. So I propose that we introduce intentional disruption into that system. And it's not just to cause chaos, okay? But when you're deliberately moving your volunteers through different roles, they get to experience disruption in small doses. Instead of, , when actually push comes to shove and something does break. So hopefully they'll be better prepared. And I think this will lead to three really powerful unforeseen benefits. The first being that your volunteers that understand multiple areas of ministry are going to feel more connected to the church overall. The second one is that it'll help you surface future leaders. So, , when people are forced to step encouraged to step out of their comfort zone, you'll get a better idea of their giftings or how they respond when they try new things. And then the last benefit is that it's so much easier to onboard a new person when that sorry. It's so much easier to onboard a new person when the previous resource is still available for cross training. Yeah. So true. And it's a really interesting concept, Nicole, because it's almost counterintuitive. Everything's working great, so make it a little unstable now to prevent chaos downstream. Exactly. And I think, , a fourth benefit is that it just makes your volunteers feel more valued. K? They might feel more invisible if they're doing the same thing and, , kind of backed up into the corner. But when you trust them with more, you're sending a message that, , you're empowering and enabling them to do more. Plus, I think they can as they move from position to position, they're gonna bring little tastes of other positions along. It's , oh, well, we used to do it over here. We had this thing. And, , they can kind of cross pollinate ideas. And I actually think I'd prefer that. If I get stuck doing the same thing for five years, I mean, I even realize I'm doing it for five years. But if I change something up, it's , oh, this feels fresh. And you feel productive. You feel you're contributing to something, making it better. Yeah. So that that's a great idea. Here's another concept that I think churches could apply. It's actually just do less, but do it right. And it's a super interesting concept because I think our instincts drive us to want to do more. Right? If we are a person who wants to make a bigger impact, we think do more. But the quantity isn't always the key. Adding something new isn't always the solution. It feels progress when you're adding more things all the time, but it creates this problem. Because now you have this whole large menu of things, you're providing a lot of opportunities for something to break. And everything that you create now has a maintenance cost. So I remember back when I was the communication director at a church, everybody at that time wanted to start a blog. That was the thing everyone wanted. And they had to come centrally and ask , here's this blog I want to start. Can I do it? And the first thing we would ask is , okay, so you have a good idea for a post. Do you have three months worth of ideas? Can you show me an archive of things you've already written? And the answer was usually that they couldn't. So they wanted to start something because they were excited about an idea or they were, , interested in adding more and contributing something else, but they really didn't have that maintenance plan worked out. And so that is a real potential liability. The other thing is that, as you're adding more, you're creating complexity because complexity thrives on having all these multiple pieces and parts. So you're just making something more fragile when you add more in quantity. So the answer here might be look for something you can remove. And that could be, , in in Rock terms specifically, we have, an indicator about the most recent time a report or a data view has been run. Are you using those? Are you looking at them? I mean, I know firsthand how easy it is to build a quick data view or a quick report without referencing , oh, does something exist for this already? Or is there a foundational data view that I can build this off of? And I certainly don't always set myself some reminder to come back and get rid of it or refine it. So when you have a whole team of people building things data views or reports, or workflows, they just accumulate over time and they start getting really messy. And that's true for a lot of processes as well. Not to mention things , excuse me, custom blocks. All those customizations you've added or maybe some hidden JavaScript somewhere that you're using to update something you need, all those things have a cost and that complexity actually creates fragility. So I would say just look for things that you can make simpler, something that won't break, that is easy to hand off. It just takes a little more effort to do that. Yeah. And the kind of tying back to, , my first point about automating something that is important, just make sure, , is this really important? , don't automate something that you don't even need. I think there is an a fallacy that things that aren't used don't have costs. So a data view that you don't use doesn't have a cost. Well, it does because if it's scheduled, it's taking up resources. It causes clutter. , people don't even know where where are the right data views. People might use an inappropriate data view because they it was named something that they were kinda looking for. These things all have costs. Mhmm. So cut. And you and you can kinda see us doing that even in the core product. Right? That's true. We're talking about blocks we're getting rid of because they're not being used. We're talking about even small whole features that we're getting rid of because we're not why do we do that? It's because of this. We want to remove that which is not needed. And it might even mean, , undoing some work that you've done. Mhmm. In fact, on that front, I'd be interested if our listeners kind of ran through their mental spring cleaning list. We all have one. And think about the thing that you've been wanting to clean up in your Rock instance and share it in our Rockcast channel. I bet you might inspire someone else to do the same. Yeah. I would bet not everybody has a screen cleaning list, though. I'm not sure I have one. Oh, is it just me? Yeah. I think it might just be me. Just just so everybody can feel a little bit they're okay. If they don't have the list? Yeah. I mean, they should. But I do to clean things up. I mean, I've cleaned up a lot of things in Asana recently, and it just feels good. , it removes tension. Yeah. I just learned about the the you can archive all your inbox notifications. I didn't know that until this week. Yeah. It's the bankruptcy button, isn't it? Yeah. Feels so good. I give up. It does. Just light and free. Does so As long as you only occasionally use it. But there's a book Getting Things Done by David Allen. He talks about the the mental tension that comes when you have all these things. If you can just get them organized and trust the system, it actually de stresses you in amazing ways. And that's it's certainly been the true in my experience. Okay. So the next one here is don't hard code your future in today's work. So now that we're automating, I have an automation. I wanna do that. That's great. We have to be very careful about how we do these automations and how we do our work. One of the questions I would ask and I do ask on everything I do, is how could I regret this in the future? Not necessarily creating the workflow. I might have convinced myself now that this is a needed workflow, but now it's in the implementation of the workflow. , what is gonna come back and bite me in the future? And Putting a little bit of proactive time into that. For things more on the technical side, it might mean don't bury your configuration deep inside these things. We have this thing called the rigging pattern. Go to our Rx sessions. There's a whole session on on the rigging pattern. And what is that what that does is it says, I'm gonna move move my configuration for a specific need or feature into this little configuration file that's up really high and it's easy to see. And then all my low end, SQL or Lava or re or workflows are all gonna reference that. So if I ever had to change what group ID this thing has to run with, it's not peppered all through all these low end things. I have to go remember the five places I've embedded that group ID, , 2467. Yikes. And I'm never going to. Right? Mhmm. So instead, I put that in one place. , the group ID is 2467, and then all my stuff just flows off of that. We have a huge amount of rigging for Rx. So every year when we create a new Rx, we basically go into one file and we change , there's there's probably 15 to 20 different things that we have to change, but it used to be, , they would be all peppered in 200 places, and it would it it was impossible for us to get it all right. Now at least we have it all there. And we even have a little script that actually runs through and checks everything to make sure that everything exists and everything. So so don't hard code things campus IDs or people. One feature that we added just for this is a feature we call campus teams. So every campus can have a list of roles or teams, and that's where you can define who does what. , who's the facility coordinator on campus a? And so therefore, in your lava and stuff, you can just refer back to those, and that gives you a nice GUI. So if those ever change, you just go, oh, I'll just change this to this person. No code changes. No nothing. Nice. So try to leverage these already created, , flexibility points so that your workflows and SQL and Lava aren't fragile. That makes sense. But what about for non developers? How does this apply to them? Well, again, think about how am I going to regret this in the future? Mhmm. What is what is limiting with this? I always the word elegant. A solution is elegant when it just feels right, and and it's non fragile. So as we're talking through this fragility concept, it really reminds me of, , a lot of things that I apply to my work. Now why do I do that? Because I've already done the fragile things. , I've broken enough things that I've created. I've created enough fragile systems that over time, you're just , ugh. I'm tired of, , I'm tired of, , making a mess. Mhmm. So you just move a little slower. So it's looking for points of failure that you can work around. So in the technical space, I think the the analogies are a little bit easier. But I would definitely say if it's if it's relying on a human heartbeat to do a thing that is not scheduled, that's a that's a risk. If there's one person there, that's a risk. So it might even be creating email addresses that are not tied to a person, but land in but are tied to a person's inbox. And a lot of churches do that. Right? We have, , accounting at my church name dot So just thinking through trying not to link things to specific people or specific configurations that could change. I think security roles fall into that too. If you've ever been in the midst of changing out a staff person in charge of something and you have to find all the places that are specifically individually secured and try to get that over to the new person who's replacing them, it's almost impossible. Yeah. This really sounds the voice of experience, this this particular example. Yeah. For definitely more mistakes you make, the more you the more regret you have in your life that you can go, I don't wanna do that again. Yep. That's true. Yeah. , I think there's a lot of application for nontechnical systems. And to bring it back to the volunteers and your operations team. When a ministry isn't hitting its goals, sometimes their default is to add more, , more programs, more initiatives, more touch points. And while that might feel adding more is being more responsible, what you're really doing is you're just accumulating more. And sometimes that just slows everything down. So your volunteers might be spread across too many initiatives. Mhmm. Your leaders might be trying to own so many programs that there's none for them to own. They can't do it well. And then your team might be at risk for more burnout and because they're spending more time operating, trying to manage the system and the machine rather than actually serving the people. So this goes back to the whole conversation on complexity. And, , our couple episodes ago, we did the complexity trap. Yep. So the solution isn't to add more, but it's to simplify. And for churches, , I think we really need to ask ourselves, , what can we cut back on so that our team can dive deeper? And remember that one, , really strong, excellent connection point is gonna be way better than three to four mediocre ones. Because the ministry that's doing less but doing it, , with full intentionality and full presence is gonna be harder to break than the ministry that's trying to do everything all at once. That's a great Yeah. So doing less yourself, but also in a team concept as well. And this ties back to John's automation point. If the team doesn't have to be maintaining these fragile processes, they can have the capacity to be present with people, which is why we hire ministry staff anyway. I think Elon has a point too where he says if you don't add back 10% of the things you cut, you didn't cut enough. So you have to tend you have to cut so much that you tend to add back a few things that you overcutted. If you're not adding things back, you you're not cutting enough, which I thought was a it's an interesting principle. Mhmm. That really is. It's tough to say that too, , can make mistakes. You can cut something and add it back. I think so much in our in our current culture, we expect perfection out of everything and everybody. And it's , well, to to to to try to achieve that then, we we play it safe. And by playing it safe, we don't recognize the efficiencies that we could have. So we have to be comfortable to saying , okay, I was wrong. , let's add that back. Yep. And that should be celebrated because that means that that person took the guts to go try to achieve efficiency. Bravery for efficiency's sake. Yeah. So I think there's just one more thing we should consider in churches about how to make their processes and systems less fragile, more antifragile, and that's actually related to the budget. So might be something that our listening audience needs to comprehend first and then maybe even take to some of their leaders. But the most churches budget , when you set your budget up, you're budgeting all of your costs for what's known. Right? So that's that middle ground. , I know what it's gonna cost. I will hit repeat. I will add my, , small percentage increase year over year from my subscription costs. A little bit of reserve, and nothing too experimental because that's risky. Right? And they're trying to be good stewards of their budget, which is totally admirable. But it feels safe. However, it locks your performance next year and your things that you accomplish and what you look to do to the same budget and therefore kind of the same outcomes as you've had this year. It doesn't give you opportunity to try new things. So there's a concept that's kind of a barbell, and it is means that it's kind of weighted on one end. Right? So you can have your operational costs on one side. And on your other side, you can have some small, intentional, maybe slightly more risky bets on what you think might help improve things in a new or exponential way. You don't have to bet the whole farm. You can try a few things in a way that's manageable and contained, but you probably are going to need some budget to try new things. This is a good time to think about it. You don't want to make a giant commitment to something you haven't tried. And that can be really tempting, especially if that thing you haven't tried looks really shiny and it's the perfect solution to everything. So a few examples of that might be if you're considering moving to a new giving platform or some other, , critical piece of your church's infrastructure, try it first. See if you can have a small scale test where you roll it out in a certain function or aligned with a certain small group and test it and see how it works before you commit completely. That's a great idea. Also, we tell people as they're implementing Rock for the first time to do things slow roll their check-in, test it first at a campus or at two campuses or test it in the smaller service. Maybe it's not just moving to a new platform, but maybe it's trying out some new equipment for check-in. You wanna do something different. Try it in a small area that you can manage. Don't buy all of that equipment for every campus and every ministry. Buy buy a, , a couple and try it out and see how it goes. You can also run an experiment about people the same way. So this may not even be budget, but you could try your people. Hey. We wanna try a new process to welcome new people on campus. Maybe go all in on one campus or with one certain volunteer team and do quick touch points to see what's learned. So when you do want to roll it out to the whole campus, if successful, you have some great points from the people that have been boots on the ground. Yeah. I think he makes a point too. , when you're budgeting, keep the barbell side for these experiments, , unallocated so that you can make the bets as they come. Right. Just super smart because, , we're all fools if we think we can understand what where things are going. As we were budgeting for for last year, , October, November, to think that we knew what was gonna happen in AI in the first quarter twenty twenty six, , I'd to think I saw that coming, but I would be lying. Yeah. So if we already create our budgets now, we're very, Locked in. Locked in rigid. Right? Fragile. But if you can keep that, , you gotta have your operational budgets, make sure you you get you got the people covered. Yes. Else, would probably unallocate. And specifically what you need in a lot of those operational areas. But it's not a lack of stewardship to have a determined pot of funding that allows you to try new things so that the whole organization can be nimble when it needs to. Mhmm. In a sense, I mean, not to over spiritualize it, but you might be saying, well, God only works in yearly time frames, he's and never gonna drop that surprise or that idea. , so in a sense, if you get too rigid with your budget, you're assuming that God's gonna come to you at November, time on the budgets too, and say, put this into the budget. ? I declare. Okay. Yes. That's good. I think that's also how startups think. Some and allows them, , to move so fast as they're known for. And, hopefully, that's, , what we're trying to do also, but they won't act on anything unproven. they'll have something to back up what they want to do. But then they're also not completely standing still and, , remaining stagnant. And John, the AI pricing that you mentioned earlier, how costs are going up, pricing is going up, you could use the same barbell approach there. So allocate right now for some things that you wanna try on the AI side and realize that this pricing is incentivized. So this is the perfect time to try your experiments. And then as you're learning and growing, you can be very targeted in what you wanna roll out. Just make sure you're budgeting for the the real costs. Yeah. And as much as we talk about the cost going up and the costs are high right now, they're still not that big of a deal. , because I came out of the IT space and communications, I always, , relate it to how many laptops is this. , it's really not that many laptops when you think about it. , the amount of laptops we go and buy, it's sometimes we kinda , okay, that person is using laptop. Okay. But some of these are , okay, that's a three laptop. , we could just not buy three laptops this year and we would have the money to do this experiment. Yep. That's good. I wonder what our listeners, if they've run any experiments, , small or big if they worked or if they didn't work. That'd be interesting to hear. Sure would. And then another thing that we just suggest as we wrap up here is one action. Right? So find that thing. Do you have a system that's dependent on a person? Do you have a workflow or a data view or a area of Rock that you need to consolidate and and remove something? Do you have something you could run a small pilot on that's been kind of in your thoughts, but you haven't made an action yet? Pick that one thing, apply some budget for it, and try it out. Yeah. I mean, you can I would just take the vacation test? Just tap somebody on the on their shoulder and be , hey, next week pretend you're on vacation, show up, you're still gonna do your work, but keep a little side list. I actually think if you're not keeping a little side list for some experiment on your own, on on yourself, you're not doing it right. I'm constantly, , trying to keep a little side list of, , things I'm working on so I can understand, oh, yeah. You work on that a lot. Maybe you could delegate that. Mhmm. Or we do time surveys sometimes with teams and , hey, do a time survey. , a lot of our time is entered into a time system. But even if it's not do a time survey. It's not to say that we wanna we don't trust you. We wanna make sure you're working. It's , I wanna see what we could take off your plate. , the things you're doing that I don't even know that if I knew, I'd probably be , why are we doing that? I know we needed to do that two years ago, but we don't need to do that anymore. That's good. Yeah. Not just to find things that you can cut back on, but, , for more visibility into what your team is working on. Well, thank you guys for joining us today. Before we go, thought the community would be interested to hear that we have hit our halfway registration point. We currently have 500 attendees signed up to come to Rx. Nice. Fantastic. Yeah. But we, , still need to keep the momentum going. So far, our listeners and our community, if you could this week, , share an invite with somebody in your network, whether that's your church staff, your leadership, , even somebody not on Rock. Conference is gonna be a great way for them to learn more about Rock and dive into critical topics AI. , that's why we have vision day for them. And so if you're not registered yet, please do go ahead and sign up. And then if you are registered this week, we wanna hear how your challenge goes and then also, , share an invite with someone. So thanks for tuning in and we'll see you next week.