Podcast Episode 20: Episode 198: The Skill that Protects Your Credibility and Speeds Up Your Performance

Description

This episode takes you behind the scenes of what's happening in Rock, starting with a version update and a look at what’s coming in v17.3. The team explores integration best practices and systems thinking to help church digital teams work smarter and more effectively. You’ll also get a first look at RX25—registration is open, the schedule is live, and there’s plenty to get excited about! Plus, hear insights from the latest partner survey, a projected donation increase in 2026, and upcoming training opportunities, including new Lava and Check-In classes.

Transcribed Content

Whether you're learning the basics or you want to be a Rock Master, we have a class for you from high level overviews to specific features. Find the training class that fits your needs this year at community.rockrms.com/classes. Welcome to this episode of RockCast. We are going to take you behind the scenes with Rock and show you what's happening when it comes to the latest code being written on the platform, talk about some of the strategies and ideas behind what our team is doing and would to share with you, and discuss a little bit about the community. So we're going to kick off with a version update from Nick, then we're going to discuss some integration best practices, systems thinking for church digital teams, and then we're going to talk a little bit about the conference, a recent survey that we released and have some info on. And you may have seen our recent blog post about the donation increase coming next year, so we'll give you all the details on that, and then a quick notification about some upcoming classes. So we're ready to kick this off. I'm Emily Forman. I have Jon Edmiston and Nick Airdo here with me today, and let's just dive right in. Nick, tell us about the latest bits being written on Rock and what's coming in the next version updates. Sure thing. The the thing we're working on, , this moment is seventeen three, and that's likely to go out the door pretty soon. So we're gonna, I think, start alpha testing that has 38, maybe 39, depending on if John assigns me this task we just got, bug fixes. So they're pretty self contained. It's probably a a really good simple patch, but talking beyond 17.3, let's peer into the future a little bit. Feels it's coming very soon. We started looking at blocks that we were potentially going to convert to Obsidian. And we said, is anyone even using these blocks? So the, a set came up, it was called the self-service kiosk blocks. There's three of them, three blocks kind of in this self-service site that we've previewed in version four. They are called the let's see my notes here. The transaction entry kiosk block, the prayer request kiosk block, and the person update kiosk block. That was intended to basically sit in your lobby and have people walk up and, , enter a prayer request or update their personal information. The problem is that the transaction entry block on that block, that one is not PCI compliant. And the reality is, is it looks nobody's really using them. So we're going to do away with those. And in version 18, they will wipe themselves out. We do some investigation right before we wipe them out to make sure that you're really not using them as best as we can tell. Those will be gone. And there's a this is all highlighted in the tech bulletin. Mhmm. So I know we haven't really talked about the tech bulletin much, but it's kind of a place to get some expanded information that you really don't wanna put in a in a three sentence release note. So although there's a release note, it will point to a tech bulletin, and you'll be able to read about more details on things there. So I could go on, I could talk about one other cool lava filter that was recently added in V18. I believe it's in V18. It's called the update persisted dataset. And I guess that was requested by somebody in the community and it was simple to write. So one of our top guys did it, John. He What it does is you pass it a key of the persistent dataset and it updates it. So if you haven't a persistent dataset that is maybe only getting persisted monthly but you just need it to happen right now, you can now do that through Lava. I think the use case the person was requesting is with the update commands that we have now where Lava can update data. They know they just updated something that was in a persistent data set and they'd the persistent data set to be To kick it. Renewed and I was , well, that's a good idea. So a quick adaptation. Very cool. Sometimes it was it's some of these, , you look at them, they're easier just to go do than to push it to the next version. in in our planning tool, I'm , oh, this couldn't take that long. Or to even write it up for somebody else to do. They just jumped on it. Yeah. Well, the exception is you have to write the documentation. I felt in this case the documentation was just as hard as a code. Because it literally was only a couple lines of code. Yeah. Because that was already in another place that we have and the guts was already written. And Nick, to clarify, where can someone find the tech bulletin if they haven't yet run across that? Yeah. Now there will be links in the release notes to tech bulletin. In fact, on the release notes page, you'll see a link that says Tech Bulletin. But you could also get to it by going straight to rockrms.com/techbulletin. Great. Thank you so much. So either look for the link at the top of the Release Notes page or use that very specific URL. Thanks, Nick. John, let's talk about some integration best practices. Yes. So I to occasionally just read about what's going on in a product or technology that I'm interested in. And of course, Rock is one of those. So occasionally I'll read through Rock Shop stuff just to know what kind of plugins are out there so we can make good recommendations and just understand, what is this ecosystem built with? Now, I got to say the truth, don't know all of them. So sometimes people ask me about a plugin, I literally know nothing about it. But I try to just peruse them. And I noticed one plugin had mentioned that the integration steps in the documentation that they wrote was create an API key within Rock. And then the next step was give it Rock administrator access, give it access to RSR Rock administrator. And I was , Woah, that's aggressive. That is a aggressive take. Now come to find out, I think there's a lot of integrations doing that. So why is that a bad idea? You're basically just literally giving You're going to the Home Depot, you're having a master key made for your house and you're giving it out. You probably don't want to give out too many keys to your house. This key has access to everything. It can read everything, it can delete everything, it can do everything. This is not a best practice. So there's a lot of integrations that I work with that have to integrate with things maybe Office three sixty five or my Microsoft environment. So when you provision them, a lot of them auto provision and you don't have to know what they just did. They just super easy and they do it right. Occasionally you have to set it up yourself. When you do, you have to go into your tenant and you have to grant specific little access points for them to do. And there's literally in Microsoft, thousands of these access points, but they usually just tell you which ones you need to give it. So you're basically just putting little teeny pinholes for just the things they need. It's tedious, it's not very fun, and that's why most vendors don't make you do that. They write an integration that says, hey, just grant me access and then inside there kind of hints at what you're going to give them access to and it takes care of it for you. That's the kind of integration you want to be looking for as you go into the Rock Shop. That's very doable for them to do to create a migration that you just installed it on the Rock Shop and it automatically sets all that. A lot of the Rockshop plugins will actually show you what your API key is. You don't have to make it. They already made you the API key. They already secured it for you and that they show it right in the UI. Here's your API key. You want to be looking for things that. If you see a solution that is asking you to do that, you really, I would recommend pump the brakes and go back to them and say, hey, I really love what you're doing here, but I can't do that. I won't do that for security reasons, but it also doesn't portray the maturity of the solution. So you should probably be worried about that. I do think in some of these cases, the maturity of the solution on the other side is really good. However, they haven't invested into that integration. And that's super important. So I would highly recommend they do that. Now from their perspective, it might be , well, know, the API there's , maybe there's 20 or 40 different API calls that they have to go secure. That's okay. Doesn't take that long to write that migration. But I would say in that case, I was speaking to them, I would say that might mean that it might be better for you to create a purpose built API actions, which is totally doable on Rock. Your plugin can actually create its own API endpoints and it goes right into the UI and you can secure those. Remember, the Rock API is really cool, it's really powerful, but it's made for very basic atomic things creating a thing, updating a thing, reading a thing and deleting a thing. What they're doing is trying to do a whole bunch of those at once. And in those cases, yeah, sometimes it's better just to build your own purpose built endpoints and then secure just those. There's a lot of other good technical reasons why that's a good idea. But I wanted to throw it out because I was a little surprised, but I thought, Oh, it's just an edge case. We'll go work with that one place. But when I mentioned it on social media, kind of got the feeling that it was in more places. I started looking around it. It is, I wouldn't say it's everybody's doing it, but there are some who are and I think that just, we need to encourage that to get changed because that is a lot of risk. And we work really hard to make sure Rock is secure. And that's always going to be something we're going to have to do, because security is just something you have to worry about every day. But then when we go out creating new API keys and giving them carte blanche to everything, that's just nullifying all the effort we put in to make a secure platform to then not even lock the door, I guess in a sense, or to provide keys at will to everybody. It's not a great idea. Yeah, no reason to introduce that level of risk into the platform at all. And it might take a little extra work on the part of the vendor to build an integration that's more precise, but it's definitely worth the effort. Yeah, and as we go from this conversation forward, let's treat maybe some of those integrations that have this problem with some grace, maybe But they didn't let's politely, in the sense of how we want to be a community, encourage them in a loving way to say, Hey, get it, but we want something a little bit more secure than that. Can you work on that? And some of them, they're not Rock experts. They also may not be experts in our tech stack, which is fine, there's a literally understand out there, there's an infinite number of tech stacks. You can't know them all, but there are lots of resources to figure that out. We have documentation, but there's also a lot of partners, support partners who can help these integration partners get their integrations done. And I think that's okay. Get it and everybody knows every tech stack, but there are at least four or five partners in the Rock community who are. And you can go to any one of them and they can either point you in the right direction through consulting or actually do it for you if you need help. Great. Well thanks for those insights, and it's definitely something people should pay attention to and not make assumptions about. Great thoughts on that. While we're talking about the right way to approach problems, what can you share about some systems thinking that might be beneficial to church digital teams? Yeah, think this is a really cool topic, and it's somewhat related to what we just talked about. And you probably have experienced this. Have you ever just added one little step to your workflow, only to find out that it greatly slows down your whole system? Maybe even your check-in was impacted, or maybe it just messed up the shape of the data within Rock and now your Monday reports aren't giving you what you want, which frustrates your leadership or volunteers. It's not just bad luck when you do that, that's just kind of speaking to a system ripple, things are rippling through your system. That's just the way things are in a sense, but it kind of speaks to this concept of systems thinking. Systems thinking is probably one of the most sought after skills in the industry right now. Everybody's thinking about the systems thinking. It's not really new, but it's something that's being talked about and actually now has a name systems thinking. It isn't just a tech skill, so you don't have to be a programmer to have systems thinking. In fact, I think some of the best systems thinkers aren't developers. But it's something that your digital team definitely needs as we expand the role and importance of these tool sets. So we really want to kind of unpack, , what are we talking about when we say systems thinking and how can we level up in this area? So if we wanted to have a succinct definition of systems thinking, it's this. It's the ability to see the big picture of how all the parts of a system, the people, the processes, the technology interact, and to anticipate how a change in one area will ripple across the whole system. So think through that. I think if we think through that, we're , yeah, we can identify a lot of problems that we're having because we don't have the systems thinking. So in practice, that means we need to identify the connections, recognizing relationships between seemingly separate features or even teams. So this isn't just a technology thing, it's actually a people thing too. It's both. It's seeing the full system. It's predicting ripple effects, asking what happens if I change this before making that move. I mean, we're all guilty of this will be fine. But we need to kind of maybe slow down a little bit. Spotting feedback loops, seeing how an output in one area becomes an input for another, making sure that we can see the connectors between that. And balancing trade offs. Weighing performance, usability, cost, scalability, and knowing, and the most important thing is knowing that they're in tension with one another. In my career, both in the secular world and in church space, there can be a tendency, especially among some leaders, to say that they want it all. I got to have all of that. I'm not willing to give up on any of that. Okay, well that's not real life. The goal then is to educate that, right? Right. Most of the education works really well. However, in a few key areas, I've seen that where the person just didn't want to hear it, And that's a very dangerous leader in my mind, because they're not willing to deal with the real world and the trade offs within the real world, which wants me to go off onto a rabbit trail of a whole another topic I'm thinking about on constraint. How do you communicate constraints? But we'll talk about that some other day. Now this is really important, this topic of systems thinking, because what we're doing inside the churches that we work in is very complex, we have to recognize that. And I don't think it's just a large church thing, I think it's a church innovation thing, whether you're a big church or a small church, you're probably using Rock because you want extensibility, because you want to be able to empower ministry in ways that you just can't in other ways. And there's just a lot of complexity there. There's attendance, there's giving, there's volunteer onboarding, there's event registrations, security, we just talked about that. It's kind of high stakes too, when these things break, the ministry is so reliant upon the systems that we're building that it can really change and impact the momentum of the church. Both mostly in the short term, Oh, I just wrecked that person's day or maybe they're weak, but also in the long term, because we have to think beyond ourselves. At a certain point, you will not work for the church you work for right now, whether that's through retirement, death, or some other thing Very true. You're all not going to be there for eternity. So we have to make sure that through good systems thinking now is it help us, but it should be helping the organization have a long term. There's also compliance risks. Now we don't have the same compliances as a financial institution or a bank, but we do have compliance, even if it's not forced in Us. For example, most churches don't have compliance in terms of background checks. it's just a best practice. Now sometimes there's an insurance compliance that some churches may have, but that's not what most churches have. Most churches do background checks because they want to be good stewards of the protection and the kids that are provided to us on the weekend. And also sometimes data retention is a compliance thing that we need to have, not so much in The United States, but definitely in other areas. But another one is system performance. With Rock, yeah, it's a very, very powerful tool. But most powerful tools, a chainsaw, you can hurt yourself if you're not doing the right thing with the chainsaw. If you're throwing the chainsaw around, especially if you taped the throttle. Oh my goodness. Yeah. Which is, I mean, to be honest, that's what some people do, we give them a tool and they tape the throttle, there's some security features in Rock that often the first thing people do is undo them. Okay, and that's fine, I'm not saying it's always a bad idea, but just realize you tape the throttle and now don't throw that chainsaw. Well, that's a good one to think before you execute. Might be good, but check it out first. I'd say that's one the biggest problems with Rock today, is that the extensibility will always be in conflict with performance, and innovation will also be in conflict with quality. Those two things are two sides of a magnet, they just repel each other. But the big one here is extensibility will always be at war with performance. And so you have to know from a systems thinking perspective, that little change you're about to make, what's its impact on system performance? So all of this is a blend of some technical ability, but also with strategic foresight. And if you have those, a little bit of technical knowledge, again, you don't have to be a programmer, but more so with strategic foresight, you become an indispensable part of your digital ministry. So, what does that mean within Rock and within a church? That's kind of high level system thinking. But when we come into the Rock space we have to make sure that we don't see these isolated features groups and data views and workflows as isolated features. No, they're always interconnected. That usually makes sense when there's a problem, right? When something's not going right we can see the interconnections, but on a day to day basis sometimes we don't see them that way. In hindsight we see them as an interconnected ecosystem, but day to day sometimes we forget that and that that's what causes our problems. So our core questions have to be , what's connected? What causes what? And where are the feedback loops? Where does one thing start and impact another thing? So a good analogy is just in the rainforest, weather, soil and animals are all linked, your Rock features are all interconnected. Change one, others will be impacted. So understanding that the impact could be breaking, it just doesn't work, it could be bad data, or it could be system performance. So for example, you might fix or add something to your data view that just makes it go completely slow and that is going to definitely impact a lot of your dashboards, your connection requests, a lot the connection requests are looking at these data views for badges or certain things, it could slow down your check-in, as we've seen that happen a lot. So you really have to understand that and you have to understand what tools do I have in play with data views? Persisted, right? Do I persist it? Do I not persist it? If I persist it, well there's other impacts for that. Persistence isn't always just the right answer by persisting it. Now they're not up to date except on the schedule. So again, systems thinking, have to think through all that. You also have to have configuration management. That is the worst word. That's saying you have to have vegetables, especially bad ones. Everybody I haven't met some well, have. I actually worked with someone at Honeywell who love configuration management and no one liked him. Because it's so difficult to put. Yeah. I picture, , the most stereotypical, , accountant. That's that's what made him good at his job, to be gonna say, it sounds he might have been hired for the right spot. Yeah. But no one liked him. Okay. Yes. Sorry. Now I'm thinking about him. We're on a tangent now. So you but you really want to think through, okay, , what are you changing? your group structures? How does that shift your data views? , if change your group structures, that could change how your data views are working because they were configured a certain way which alters your Monday reporting or your weekend check-in. So you really got to document that. Change management is basically a documentation task. You gotta think through the performance adding that little configuration changes that change performance, data movement, maybe you remove a person attribute and that silently broke your steps process. Oops. If it's not documented, you're not going to know. Or maybe there's old workflows that are brittle and don't follow the patterns that we talk about , , the bones and the muscles. if you don't know what I mean by that, there's a video on that. You should definitely understand that And I love hearing the community talk. Oh yeah, my workflows are all more muscles. I'm , yes, someone's watched the video. That's awesome. But also security. Oh gosh, you changed the security on a file type. -oh, does everybody now have access to all those files in an unsecured way? Is sensitive volunteer data or child data protected? Those are things we have to have good documentation for. Now part of you might go, Does it really have to be this complex? And kind of the answer is a little bit yes. Now we're always trying to fix things so you can have your cake and eat it too. we're back here trying our hardest on that. However, again, can A lot of times that the extensibility and the power at odds, we can dumb it down and now we can have not guaranteed performance, but almost close to guaranteed performance. And some systems do that, they don't give you a lot of options because they're trying to make sure that performance is always there. We've given you the chainsaw and , there's not a lot of safeties on that chainsaw. We continue to try to add optional safeties, but ironically, many people just turn them off. So the reality is, we're dealing with complex ministry problems. Complexity comes with a territory. There's also sometimes this talk about , well, I want to have enterprise software as if that's a magic wand. But if we want to have enterprise level software, we have to have enterprise level thought and somewhat investment. When I say investment, it's not always money, although that's a piece of it, but it's investment of time, documentation. So there's a couple options we can do here. One is keep to the basics. If you're the church who doesn't want to invest a lot in that enterprise investment, that's okay. Keep to the basics. Someone just the other day said, Oh, that church is only using Rock as a Rolodex. Cool, that's awesome. That works too. No problem. In fact, I actually think that's wise for some churches, because they've recognized what their need is, and they've also recognized where their skillset is, and staying within those things is always a wise choice. I would actually say it'd be worse for them to go do all kinds of events, stuff that perhaps gives them scalability problems or security problems. And long term they can't use it because their staff simply can't support it. Maybe a volunteer came in and just set up this magical wonderful thing and maybe even did it right, but it's not supportable. So I will never look down at a church who's using in a very basic way. In fact, we're trying to encourage more of that through our essentials stuff. But just also that I kind of hate saying it because it's so over said, with great power comes great responsibility. And that certainly is true with Rock. We gave you lava. Great power, be responsible. And again, going back to this thing, extensibility and performance will always be at war with each other, not arguing, they're at war with each other. Okay, so how do we get better at being systems mindsets? The first thing is we got to level up our mindset, which is basically, hey, we're in the big leagues. We got to hold ourselves to high standards, just our peers in the enterprise IT teams. I think a lot of times there's this tension that we want to be them. And so we want to use the tools them, we want to use the technologies them. Well, means we have to sometimes sweat them. If we want to be Mike, which is Michael Jordan, if you're an eighty's and ninety's kid you probably understand be Mike, you got to go do the practice. You can't just be Mike and just walk on the field or the court and be , Okay, let's go. It just doesn't work that way. So if we want the rewards of enterprise software we have to be willing to pay the price for that. And again, that's not necessarily monetary, that's more discipline. And as a core team just know that trust us, that we're working behind the scenes to give you as much of that with as little amount of effort as possible, but we can only do so much, especially if we want to give you the extensibility and power that you want. The thing you can do too besides your mindset is building up your hard and soft skills. So on your technical side, query optimization, workflow design, APIs integrations, understanding Lava, how many database reads I just create without Lava, A lot of that, but also soft skills documentation, change management, team communications, increasing our documentation. Do we have user flow diagrams showing how data moves through our system, dependencies between these features, where are the integration points. As we go into that, I think there's some concepts that we can do too that help do this. Within programming we have this concept that we call a separation of concerns. So that basically says don't create spaghetti. If I had to unpack that for somebody, it's don't create spaghetti. Sounds pretty obvious, but here's what it really means. It's a design principle that means breaking apart big things, big complex things into smaller, clear defined parts. And then each of these parts have an interface is what we call it. They have inputs and they have outputs. And what happens on the inside is a little bit of a black box. They shouldn't know about what happens on the inside. So have very few inputs and a very few outputs and then you interconnect them through that. So that provides clarity and it provides boundaries. So each part only has a single purpose is responsible for one thing and it does that one thing well, And it hides its internals. it does, no one else should know how it did that one thing. And if you have to figure that out, you go inside of it and you just tweak that one thing. And these parts are what we call loosely coupled, loosely connected. So again, shouldn't know about each other's internals. And that helps build a more flexible system. So when you don't do that, have spaghetti. So a good example of this might be your background checks. There's a lot of things in Rock that need to know if someone's background checked, right? So you might have a steps program, Hey, you can't volunteer until you are background checked. So what if all these interconnected places had to go figure out all the logic for background checks? No, you wouldn't want that. You want to come down and say, no, there's one person attribute. Doesn't have to be a person attribute, but in this case, I'm going say person attribute. That is a date that tells you when the background check expires. That is a single point of truth for background checking. And every other system will just look at that one date. Now the background check system probably has a whole bunch of other things when was the request submitted? When was it reviewed? Who's reviewed it? What kind of background? all that other stuff is internal to the background check process. The only thing it's going to output, which will be the input for every other system is what is the date that it expires. Now, that's a simplistic thing. Maybe you need another one possibly, but hopefully not. Don't bring in complexity that you don't need. That's an example of separation concerns. The background check process is lots of complexity there, but it's only going to output a very simple thing. You want to look for other examples of that. So trying to create a separation of concerns. That should be another concept and another saying that goes into your tool belt. So if you're in a meeting , Hey, , I think we're breaking the separation of concerns principle. let's break this into components. Let's get that documented. Obviously you want to have a flow chart for how the background check process works, but you should never look at it unless you're digging into the background check process. So just moving to close this out, what are some action steps you can take? So turn this into a practical weekly, I would say maybe daily practice. Before changes, think what's this going to affect? Am I affecting something that's an input to another system? Or is this the internals of another process? So now you can kind of scope what is it, , what's the, how big of a change is this? Run system reviews, maybe into your teams on a monthly basis, you're going to do one system review per month. Let's just review the background check process, guys. Let's just make sure we all understand that. Now that forces you to document it, which is a good thing. Test changes in a staging environment if you can. I recognize most churches maybe can't afford that investment in time and money. That's okay. You can, that's great. But try to stage your things to minimize impacts. But the big takeaway is that systems thinking protects ministry credibility, speeds up your performance and ensures accurate performing. But I think it's got also de stress your job. I think a lot of the stress that we bring to us, to ourselves is because of a lack of systems thinking. There's a lack of thinking what's this gonna impact that discipline and having that level of thought. So again, I'd probably sum it up by saying, hey, there's this thing called systems thinking, it's thinking about the whole system and its parts. We should try to chop our systems, our complex systems into components that have basic inputs and outputs and keep their gory details inside themselves. And then we should start saying things separation of concerns, think through these concepts, internalize them to our ministries. And one more thing I just had to the end, realize that your church is bigger than you and you need to be doing this, not for yourself, although there's a God, good reasons to do it for yourself, but you need to be doing it for the church as a whole, and for your love of that church and for its long term success. Those are some really great points, John. And I think it's great that you pointed out several times about how extensibility and performance are at odds. At war. They're at war. We have to use that word. You can't have maximum on both. So you have to figure out where it is that your team can afford to be, wants to be, and can sustain. And that's just a really important thing to understand, especially in the Rock world. And the way I kind of visualize it, because I strangely have these visuals in my head. So I picture , it's the eighties and it's wrestling. Okay. Before WWF even, this is the old school wrestling. And they used to have these team tap ins, and so it was two guys, only one of them would wrestle at a time, but they would tap in. So on team A you have extensibility and innovation, and on team B you have performance and quality, and these guys are going to battle. They have big feathered hair they're Yes, bright have to have that hair. And they're just wrestling and there's nothing you can do, they're never gonna each other. They're wrestling with each other all the time. And that's kind of the tension in the world that we live in. Extensibility and performance, innovation and quality are always gonna hate each other. And that's just reality we live in. Yeah. So when it comes to digital ministry, there's a lot of innovative new things that we can do and that we can lean into. We just have to understand the dynamics of the world that we live in. But John, if somebody wants to really dive into what's new and what's possible on the digital ministry front, it feels there's so much changing there right now. How could they What could they do? What's one action they could take? Very soon. That's easy. Go to Rx. That's it. Because the more I keep preparing for Rx, the more I keep going through and thinking about what we're working on as a church, not as Rock, but as a church. I believe digital ministry doesn't exist today. I mean, there's a few small hints of it, right? And there are some projects out there that, that are just hinting at digital ministry. But I feel what we're doing is not expanding something that we're already doing, it's literally changing the church in exciting ways, and in ways that will always deliver physical community. Every time I'm talking about digital ministry, I'm always going to say that. If your digital ministry is not increasing your physical community, I believe you're not doing it right. So we extend at an exciting time in the church. we have the ability to greatly impact and magnify the capabilities and the reach of the church. And I think the biggest topic at RX is this topic. And I think this RX is not just a regular RX, this is an RX for the ages in my mind. Because we're gonna be talking about these concepts and we're gonna have all these churches around, some of them who are pioneering in that space, legit pioneering in that space and there's a lot we can learn from them. In fact, there's a few data points I'm going share from some of those churches that are going to blow your mind. It blew my mind. I mean, I've worked with them and the pure data points just blew my mind. So we're going be sharing that and I feel you're going to want to be there. It's just not don't come because it's RX, come because we're talking about an exciting transformative time. And I feel we have this opportunity to reach a lot more people before Jesus comes. So let's get to it. Let's get to it indeed. And it's time we've heard from several people, still quite a few people that are planning to come but haven't yet purchased tickets. So the time is growing near. Make sure that you get those last details in, especially now because our team does need those head counts to start really locking things in well. But look around you for a minute. You may be someone that attends Rx regularly. Are you thinking about who can benefit from what you're used to, what you're taking in at Rx every year? Who else on your team? Who of your leaders could really benefit from understanding this RX of the Ages, the vision of what's possible, rubbing shoulders with churches that are innovating in these spaces? Who else should be there from your team? And then look around your church community and the ministries that you partner with nearby, and why not share those same opportunities with them? So make those invites, schedule your registration, and don't forget, we just released the Rx schedule. So if you are registered, you probably got an email from us yesterday that points you directly to that. It's also linked in the main menu of our Rx site, rx.rockrms.com. Check out that schedule. Now you can see for yourself who's speaking, what some of the topics and trends are, and it's going to be a really powerful time with a little something for everyone. So don't miss it. Speaking of things that have been just released, after we finished the Integrated Services Survey, we had such a great response from the community saying, Hey, thanks for helping us better understand who has services of various types in the community, and kind of what the experience of the community has been, various churches, and working with them. So we decided to roll out a Rock Partner survey. And we did a very similar survey concept where we asked a simple question for a score rating and then a why, and then summarized with AI and average scores. And that's now available on our site as well. We'll put a link in the show notes. It's on our Rock RMS sitepartners, and there's a link to the survey at the top of the page. And we're hoping that's something that the community can use as well. We've had just great responses from that data point. So thank you to everyone who participated in sending that information back. Now, we may have also been able to notify you, but if you haven't seen yet, we've been talking for just over a year about the upcoming 2026 donation level. And when we rolled out originally the move to 4.1 we had said, Potentially plan on an increase in 2026 to the amount of $4.6 per attendee per year. We're trying to just help make sure that our funding doesn't lag behind the economic factors and team growth that allow us to continue building the exciting tools that we are. However, great news, we're able to actually reduce that after looking at our numbers. We're going to be able to make the donation increase to only $4.45 So we do still need to move up a little bit, but it is about half of what we thought we might have to do, so that's great news. Now you may have a few questions about this. How does this apply to you? I'll answer some of those here, but we'll have a link in the show notes as well for you to check out additional FAQs. Officially, this is going to be starting in January 2026, But don't worry, if your fiscal year is slightly off from the calendar year, that's not a problem. Just reach out and let us know. You'll get some communications from us. Let us know what your plans are, and go ahead and update your commitment on the Community page to indicate that new commitment level and the date that you can start anytime in the calendar year 2026 to align with your fiscal year. Our goal is not to create problems, but just to work with every church and the funding cycles that they have. So as we've done in the past, we'll work with you on this too. Why are we increasing the donation amount? I mentioned earlier, there are always increasing costs due to inflation and shifts in the economy, and this donation amount helps us deliver high quality innovation and support. It also helps our team grow just as the community continues to grow. So we are a small, nimble team that gets a lot of work done, and so we definitely are maximizing those dollars. And thank you so much for your support. If you have any other questions, check the show notes for a link to that blog with some additional information. Yeah, I'd add maybe one more why too. The why I worry about is that every time we add a new feature, it's a new feature we have to maintain. So for instance, I'm just going to top of mind, LMS, chat, there's some cool features I can't say from They're coming in '18. Those are great features, it costs money to make them. But guess what? It costs money to keep them going. That's true. LMS especially, a lot of people are really excited and they're doing some really cool stuff in it. But it's another whole set of code that we have to keep bugs from coming into. But we've already even added a whole bunch of features to LMS. 18 has new features in LMS. I worry personally, are we going to maintain all of this at our current resourcing level? And I would say too, it's not a linear, resourcing is not linear. So as you add more people, you actually get less productive a little bit. A lot. Because now those people need managers. Some point, you need another layer of managers. We've been really pushing that off. We don't want that. But at certain point, there's just gonna be nothing we can do. Because we're very hyper productive, you mentioned. So yeah, you're getting a lot more free money too. LMS, you don't have to pay for an LMS. That's right. You got an LMS for free. And I dare say it's pretty powerful. It's pretty exciting. So yeah, that's another reason why prices go up too, the amount of stuff we're trying to create and the value that we provide goes up. Well, thanks for that note. We do work very hard to be as efficient as possible per dollar. But you're right, there are some natural inefficiencies with growth and we work to manage those as well. I think almost sometimes to a fault because especially when we were smaller, we had to be. And sometimes I've personally had to chill out on a few , We used to be able do that in a couple hours, now it's taking so long. Well, yeah, because it got harder and we have more people and it's , that's just a natural thing. It's not that anybody's working less, it's just the nature of a system that's gotten bigger and more complex. Sure, we have to bring more people the hill, not just a small number, so you've to make sure everybody's moving together. Yeah, communication takes time. That's exactly it. Alright, John, you mentioned earlier when you were talking about systems thinking that one of the things that anyone in the community could do is to build up their hard and soft skills, and so we provide opportunities through our classes that can be very helpful on that front. Coming up soon, the week before the conference in fact, is a Master Class that has just a couple of seats left. So that's right here in our headquarters in Phoenix. You can join us and then stick around for the conference afterward. Additionally, we have a lava class coming up. That's another great topic when it comes to extensibility extensibility versus performance, understanding lava well is critical there. So don't miss that class if that's next up for you. And then we also have a check-in class that could be valuable to administrators or to the teams that run check-in on-site. So check those out, we'll have a link in the show notes. And I feel we've covered a lot of ground today. Yeah. Well, we're just starting the conversation on systems thinking, and that we can all level up. And the first goal is to start thinking in that mode and we'll just get better at it. That's exactly right. And we're so excited because as of the time when this podcast publishes, we are really drawing close to the conference this year, which is both terrifying and very exciting. We love to see everyone, but it always feels there are quite a few loose ends to wrap up before we get there. So keep us in your prayers, and we're so excited to see you. Thanks for tuning into this Rockcast podcast. Be sure to follow or subscribe to our podcast wherever you get yours so you can hear us next time around and be in the know with Rock. This episode of Rockcast is brought to you by Rock sponsor, Checkr, providers of integrated background checks. Connect with Checkr today at Rock r m s dot com slash sponsors.