Podcast Episode 17: Episode 201: Systems Thinking Can Change Your Digital Ministry

Description

Learn seven mindsets for building smarter, simpler solutions with Rock and discover how systems thinking can change the course of your digital ministry.

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome to this episode of Rockcast. I'm Emily Forman. With me today are Jon Edmiston and Nick Airdo, and we are excited to talk to you about all things Rock. Hang with us for this episode. We're gonna run through the latest version update. We're gonna talk again a little bit more about systems thinking, this time with an engineering mindset and how we can apply it to that. This is a critical thing for our community to continue focusing on. Then we're gonna give you an r x 26 update. That's right. We're not talking Rx 25 anymore. We are already on the move and then a few community announcements to wrap up. So let's do it. Nick, fill us in. Well, we had a fun start of our week and we released version sixteen thirteen and version seventeen six simultaneously, basically security improvements. And there's one bug fix in seventeen six that was introduced. The bug was introduced in '22. So we wanted to get that out right away. And those went through rapid testing, alpha, we got a church to help us out installing it on their test system and it's live as of last night in fact. A few late nights and a lot of team efforts, but that's good. Yeah, was an all day event yesterday for part of the team to help make that happen so quickly. And then, so then on the other front of V18 is in alpha. It's been in alpha for a week plus and it's got a probably a week or two at least to go. We're gonna be adding some things and repackaging shortly I think. So V18 though is looking really good. That's great. And by the time the podcast publishes, we're probably a few days past the immediate release, but you should see that if you haven't seen an announcement yet. It'd be a great thing to update to. All right, John, systems thinking is on the mind. Yeah. So systems thinking is a huge topic. I know we've talked about it before on the podcast, this is Briefly. Yeah. This is something you could literally get a college degree in. So we wanna keep coming back to it, coming at it from different angles and trying to help maybe change some the we think about it. And I would highly recommend though, get on YouTube, do some more research on systems thinking. I think systems thinking and first principles are probably the two things that could change the course of your ministry more than anything else. They're very difficult. Wow. It's very difficult, because it doesn't always intuitively make sense. You can teach someone one plus one equals two, but this is much more abstract. This is something you have to really think through, and it doesn't always make sense in the beginning. But anyways, let's just jump in. So today, I want to think about it, helping us think about sustainability and building elegant solutions with Rock by using systems thinking. So the first thing is, when we think about it, is making sure that we use features as intended. And sometimes within Rock, features can be used in a lot of different ways, but it's always really good to understand why was this made and what was it supposed to be used for? So honor the design intent before extending or customizing. And it doesn't mean that you can't use it in a new novel and creative way, but if you first start with , okay, what was this made to do? Then you can kind of go from there. So understand the why behind every feature. Also too, when you when you see this feature, I think it's really tempting just to jump in and and just start, , using it. Now we talk a lot about being the the Ready Aim Fire concept. It seems very obvious, but our life and our world does not really operate on Ready, Aim, Fire. In fact, many people are just fire, fire, fire. And then sometimes we're all a little bit that. So I would change Ready, Aim, Fire in this intent to be read prototype implement. So make sure you first read. I know, you look at the UI, you see those features and you're just, Okay, I get it. It's intuitive. Sure, but go read the documentation. So many times there's little nuggets in there that tell you about a little block setting, or what this can and should do. And so invest the time in reading. Abraham Lincoln was famous for saying, if he was given an hour to chop down a tree, he'd spent forty five minutes sharpening his axe. And that's what that is. Read. You're gonna save yourself so much time if you read. Then prototype, make something with the intent of throwing it away and starting over, and then implement. So I hear a lot of times when people do check-in or workflows, especially check-in though, I can't tell how many people I bump into at conferences or just in every day, they're , Oh man, if I could redo my check-in. When I was first getting into Rockets, usually check-in's one of first things, don't really understand it, and they're just using the UI to make something and it kind of works, but it's , if I could redo it, man, it'd be so much better. And then workflows is another one you can quickly get into trouble on if you don't understand things the concept of skeleton versus muscles. And if you don't know what that means, there's a video, , go watch that video. So the systems insight, you want to make sure that you're working with the grain of the system. , in woodworking, you want to make sure you're working with the grain, then that way you gain momentum, and when you start to feel that you're fighting against it, you're probably doing something wrong, you're burning energy. Pay attention to that feeling. And so especially the concept of going downstream. If you're going downstream with a feature, you're , Okay, this feels good. But when you're fighting upstream, stop. You probably don't understand something. I know I I see that a lot in in technologies I work with. I I find myself fighting against it. I'm , I must be doing something wrong. So the takeaway here, great engineering starts with great observation. And so just make sure you understand the lay of the land. Number point two here, strive for simple elegance. So those are words that I always to have in my head. Simple elegance. And they're very hard to define. Simple is not simplistic. Those two things are very different. And I think sometimes we get confused in our heads that simple has to be simplistic. I would say simple, better definition of simple is something that's complex under the covers, but feels inside the box is complexity, but on the surface, the interface to it is very simple and elegant. It just has to feel right. When things don't feel right, they're not elegant. So simplicity is not the absence of complexity, but the art of managing it well, and also too of hiding it well. Sometimes, again, if you're not feeling you're swimming downstream, if you're swimming upstream, there's something wrong. When you're done, it should just feel right. For example, a couple years ago, was gonna build a big shed in the backyard, and I'm , Okay, well, I got this. I used to do construction when I was a kid, working with my grandfather for his contracting business. I So was , I can do this, I don't need plans. But I'm , I should probably look at some plans. So I invest in the research, and I found this set of plans online that was great. I'm , Oh, this is kind of what I want, a couple of changes maybe, but And then I thought, what? I'm just gonna make it a little bigger. I'm make gonna it a little taller, I'm gonna make it a little bigger, and everything's gonna go right. And I decided, , at the last minute I decided not to do that. Boy, I glad, because whoever designed that shed had thought through everything, and it almost building Legos, because everything was built for the sheet of plywood. I was making very little cuts. Everything was just aligned right. I even started thinking, what I'm gonna do? I'm gonna actually put more studs in more often than normal. Well, guess what? I knew this, but I didn't really recognize how much this has been pre thought, but the length of plywood and that standard practice, everything aligns well if you just go with it. So again, but as I was building the shed, I felt this is just going super smooth and super well. It's the same thing. If you get that alignment, if you use it as intended, everything is so much easier. And it was literally building Legos, and it was pretty easy build till I shot my hand with a nail gun. We can have a different podcast about that. Yeah, but that had nothing to do with the size of the building. I kind of sometimes to use the metaphor of the mole and the meerkat. As you're building your solution, you're moling underground, and eventually that's good, but eventually you have to meerkat. You have to pop back up, get above ground, look which structure you're going in, and then go, yes, this is good, and then go back down and dig. If you're just moling, you're gonna end up where you don't wanna be, and with a lot of effort expended, and if you're only meerkatting, you're kind of a waste, no one just needs to be looking around. So you have to do both. And so you wanna make sure too that you backtrack early and you iterate. And often when I'm trying to find a solution to something, I come up with a solution. I'm , okay, think that's a pretty good solution. Then I take that solution, I put it aside and I come up with the next solution. So I'll say, Okay, let's just pretend I can't do that. What else would I do? And so often that second solution is actually better, or a combination of the two will, a fusion of the two will be often the best one. But never just take your first option, that's just usually not gonna be your best. So the takeaway here, elegant solutions are discovered, not forced. They are felt more than calculated, and you're recognized by harmony, not just their logic. So sometimes when someone says, well, how do it's an elegant solution? I don't know. I can't tell you. It just feels elegant. It's just everything's simple, everything's smooth. Okay. Number three, under this was this one's a big one. I'm actually gonna I'm actually thinking about doing a whole video on just this one. Understand the performance characteristics of the feature or the product that you're working on. Every system has limits. Work within them, not against them. So know the performance profiles of your Rock tools. So what is the performance profile? I get what you want to do. Can this feature support that level of performance? And that doesn't always mean that you can't achieve what you want. So sometimes you're , well, but then I can't do what I want. Well, no. Maybe you can't use it the exact way you want. It does mean though that you might have to engineer a solution to work within the boundaries. So let me give you some examples. You might be wanting to do something that performantly you can't do at scale because of the number of records and the fact that they have attributes that you have to go then hydrate and get the friendly values. Although we've done some really cool things in the data model to make that much faster. But for reason, you just can't get it to perform. Well, you're not. Not all things are lost, you could use persistent datasets. So you could then bring that heaviness into a persistent dataset that gets hydrated, and then you can use that persistent dataset. So again, it's not , Oh, I can't do this, so now , Rock stinks. It's , No, you're engineering it. You have to say, Okay, now I can't do it this way, but I could do it this way. Another good example where maybe there's some concerns is matrix attributes. They're okay for certain use cases, a certain occasional use cases, but you can't use them as a a data store for for data and then expect a report off it performantly. So just know what what is the performance profile of a of matrix attributes? Use them when they match what you're trying to do. So you have to engineer for scale and reporting, not just functionality. I think sometimes we just think we just take this hammer, we're just gonna start, , destroying the whole building with a hammer. It's , well, maybe that's not the best tool for the job. And so you have to think an architect, and this allows you to scale things 10 x, a 100 x, a thousand x beyond what your initial approach might have been. So you have to make sure that you're doing things to make them more efficient. And then so the takeaway here, respect the boundaries of your tools, they exist for a reason. But often the tool is not gonna be the limitator, you can get them to do better. And that brings us to number four, know your tools. Mastery comes from exploration, not just need. So if you wanna master your tools, you have to explore your tools, not just when you need them, but at all times. So again, I kinda mentioned that I grew up doing construction with my grandfather, who's a general contractor, and the lesson I learned there is a craftsman knows his tools, and a craftsman never blames his tools. I to say that was always true on our job site, but it wasn't always that way. But that is true. And so sometimes we blame our tools when we don't know our tools. That's not to say that tools are always perfect, right? We're always back here trying to make them more performant, but a lot of times when I see something not performing well, it's , Oh, well that's because you're kind of doing it wrong. And so we have to understand that Rock is very deep. You have to get and understand every single tool. It doesn't mean you have to know everything about it, it just means that that tool exists in the toolbox and what is its rough purpose. And I feel a lot of people don't do that. They only reach for a tool or reach for understanding when it's needed, but then you're only reaching for the thing that you knew about. So I would, at least at the surface, skim through all the documentation so what's there. Let me ask you a question too, who goes to a buffet, all you can eat buffet, and only nibbles? no one does. If you're sitting on all you eat buffet, and you're not walking out about ready to puke, you're not doing something right, right? Rolling out. Yeah. So when you get early access to Rock and you donate to Rock, you get everything. It's not every feature is metered and you have to understand it Right. That's going to the buffet and saying, , I'm just gonna have a little bit of salad. I just offended myself in many ways. That's not what we want. Make sure you understand your tools. So many individuals don't know about persistent datasets or persisting your your your data views, and when you should and shouldn't do that, because it's not always you should. Here's another analogy. You are a superhero. You're a ministry superhero and you're not reading your powers manual. Imagine you're a superhero and you have lots of powers and you'd refuse to even understand the powers. Oh, I can fly? Can you imagine that? I knew I had super speed, but I didn't know I could fly. Oh, I can be invisible? That's great. So just at least understand they're there. It does not need that you have to master every one of these superhero powers, but you should at least know that they exist so that when you need them, that they're there. The more , the less you have to build, and the more often you're gonna get it right the first time. Okay. So that moves us on to think sustainability. And it's not the sustainability you're thinking about. Build for the church, not your ego. Oh, that's sustainability. That hits, right? I think, and again, it sounds very controversial, but come on, at the end of the day, we all have an ego we all do. Yeah. The only problem is if you don't think you have an ego, that's a problem. That's the only problem. So we had to make sure that as we go through this, we have to be thinking about the church and not our ego. So does your solution make you feel good or does it make your team more effective? I mean, as a technologist, we have to have to question ourselves on that. Because it's very easy to say, I can't wait to show this because it's gonna be so impressive that I did this. But is it good for your team? Can they support it? Can it last be on you? Do here's another question you could ask. Do my selection solutions reflect my love for the church or myself? I remember a time when I was starting to volunteer at CCV, and we got together with this little volunteer team, and we're trying to talk about tools that we could write to help the church. So we had the first thing we had to do is have to pick which programming language are we gonna pick, right? So there's just a couple of us who could program, right? So I was kinda wanting to use Java server pages. That was a technology way back then because I knew it and it's something I wanted to learn more about. The the other other person who's gonna probably have time to to to volunteer wanted to do ASP, active server pages. And I was , I don't wanna learn that. But it was pretty obvious he was not gonna move off of that. And so I was , okay, we'll do active server pages. So again, trying to think through what's best for the church versus what's just best for me. That way we'd have two people who would know it is also pretty approachable. You could get easy cheap hosting on ASP. It was very hard to find hosting for Java back then. So again, it was it was definitely the best choice for CCV for a lot of reasons. Story update, he never programmed one line of code. But I did learn ASP, which wasn't bad. So ask yourself too, if you disappeared tomorrow, would your team thank you or curse your name? Did you leave something that they can maintain? Is it documented? Documented, that's a big one. Documentation is so important. We spend a lot of time on documentation because the community needs it to do things well. It's slightly frustrating to see the level of documentation that others might provide. I get that you don't have a community that needs to know this, but you kind of do, you have a team. And if you're a one man band, someone's coming behind you, you're not the last So we always say documentation is a love letter, It's to your church, but it's also to yourself, because you'll need it too. Yep. Ministry longevity demands technical humility. So ministry longevity demands technical humility. And again, I know you might be thinking, gosh, this sounds really negative. It's not, I'm speaking to the ego that's in all of us, we all have to check ourselves on this. I have to check myself on this, when I'm writing something that, , will be the coolest thing in world, I wanna use this new thing. It's , okay, but this isn't what's best for the organization. It's not what's best for the community. Because sometimes I wanna go do something new too, right? But if I do it in a technology that works with Rock, I can share it as a recipe for the community of Rock. And so sometimes I definitely have to stay within guardrails. Okay, next one, the harder path often unlocks the greater win. Trade short term ease for long term gain. So a lot of times when we're thinking about how to implement something, we're , Oh, but if I do it that way, it's gonna make it really hard on me. But it might be the better solution, not just for you, but for the whole church. it might be better for your staff. But if I put that out, that means I have to do all this work. It's gonna take me two hours to do that. It's gonna make me two days to do that. Yeah, I remember once in college, typed in the whole course catalog for the business college, so I could put it online. This was 1994. So there was nothing online. Literally the College of Business had no website, I made it. But I thought it would be really great to put the course catalog online, and you could just read the whole thing and get all the the, , CIS one twenty or marketing four twenty. So I typed the whole thing in. No one had a digital copy. I mean, I'm sure someone some at the commercial printer had it, but I wasn't getting access to it. It wasn't that hard. Improved my typing a little bit. But it's the same thing when we're doing something. Sometimes we think about, well, that's gonna be hard for me, and we need to check that. Sometimes if we're not careful, we think too much about the effort required by us versus the total benefit to the solution. So better better stewardship of staff time. So be thinking about the full staff time versus just your setup. So the cost of doing it right is usually less than the cost of complexity or having to fix it later. So, , just tell yourself, buck up, get it done. Okay. So last one, additional things that we can talk about here, some small things. Make sure you think about feedback loops. Always be thinking about how you're gonna measure and adjust, how do you I got this new process I'm putting, okay, how are you gonna measure that? How are gonna show it's gonna work? How are gonna show the benefits of that? You wanna optimize too for individual experiences. It's not always about the features, it's about the outcomes. So we kinda talked about at conference, make sure you're measuring the right stuff, ministry impact versus just random data. And avoid avoid at all costs, and we talked about this last time, customization addiction. So custom code is not bad, but it should be the last resort. There's so many huge churches that we work with that have no custom code. Mhmm. And they're able to do it Mhmm. Because they know their tools, because they they go through the engineering. There's there's a couple churches right now that are basically saying, can't update because of customizations. And oftentimes, unfortunately, they weren't even customizations they did. It's customizations they paid someone else to do, and now they're stuck. And that is trading short term gain for long term issues, huge long term issues. And that's just a really a place you don't want to be. So those are some some thoughts on systems thinking as we, , roll out specific features, especially in the engineering mindset. And we'll be doing more. I wanna do a video again on that performance thing because I think that's a key one, understanding the performance characteristics of Rock and how you can scale it. But you have to just think about it. You can't just brute force your way in. Wow. Those are some really incredible tips. And depending on where you are and what you're doing, what you're experienced with, good different starting places for for anyone. There's something there. Alright. We just wrapped up Rx twenty five if anyone's counting. But Rx twenty six is already in full swing. So here is a quick update on where we're at. We did a site tour last week that we think is going to potentially be what we're looking for. We are hoping to have more information, including even registration dates and all of that coming before too long. So stay tuned. Know that we're putting a lot of effort into that, and we should have it coming soon. Additionally, this next year, we're looking to have probably fewer sessions that are really well tailored to the audience with very high quality content and speaking. If you've spoken in the past or you're a Rock star, we're in the process of sending out communications asking for speaker pitches this year. So what we're looking for is a short video that demonstrates your speaking ability and potentially a content pitch as well. Although this year we'd to, a core team, provide some topics and some angles that we think that we have a need for in the community as far as content goes. So those are some options. If you've not spoken before and you're interested in it, please send us an email at infosparkdevnetwork dot org, and we will we'll be paying attention to that as well, and and we'll, in return, ask you for that pitch. So contents in full swing, location, dates, those are in full swing. And then one other thing, we're going to be opening up the gold circle award submission process soon. So you don't have to hang on to the projects that you're working on all year. You'll be able to put those in as you complete them, which will hopefully take a little bit of pressure off the the end of the year or end of season rush for that as well. So exciting things happening. Lots happening behind the scenes, , that image of the duck sitting on the water but paddling furiously beneath the surface. We never really stop the conference motion. Right? So one year completes, the next starts, and we're still paddling as we go. So really excited about that and hope to have more information coming soon. A couple of announcements before we sign off for this podcast. As we've mentioned before, in 2026, we're updating our commitment level to $4.45 per average weekend attendee per year. If you haven't had a chance to update your commitment yet, you can do that on your community profile. Please go ahead and put that in. You can add in the start date so that does not mean you're updating it for today. Tell us your start date on that. If you need to adjust your start date away from January 26 to a different time in the year based on a budget, reason, just put a little note in there and let us know. Put that date in and put your commitment update. If for some reason this is going to leave your church behind, maybe you've had a leadership change or maybe you're a really small organization or someone who's having a scale problem right now, we definitely don't wanna leave you in that position. Please reach out to us. Again, same email address, infosparkdevnetwork dot org, and we'll do everything we can to work with you. So thank you so much for your support in that area. We have two ways you can continue to get involved right now. You can sign up for one of, three class sessions we have coming soon, our virtual master class coming up in November. We only have one to two virtual classes a year. It's a great way to save on travel costs if you need. We have a check-in class coming up soon, and a little bit after that, we have a sequel for Rock class. So those are three good options for you. And, additionally, we are looking for roadshow hosts for next year. A roadshow is an opportunity for you to introduce the people at churches in your area, to Rock and how you use it. We provide the presentation, you provide the location, and give that presentation as well as some FAQs. And your region of Rock Churches is welcome to join you in that as well. So reach out, let us know if that's something you'd be interested in. We'd love to hear from you. We are starting to get those coordinated now. Well, this has been another Rockcast full of good content that you may want to put on repeat, and we're excited to be able to bring that to you. Thanks for your support. Thanks for your engagement. This Rock project is only better because of you. Make sure you subscribe wherever you get your podcasts so you'll stay up to date with everything that's happening here at Spark Development Network. Thank you. This episode of Rockcast is brought to you by Rock sponsor IT OneSource. Any IT products and services solutions can be acquired through IT OneSource. Connect with them today at rockrms.com/sponsors.