Podcast Episode 51: Minting New Talent

We just started a second round of alpha testing for version 8.5. Round 1 was really quick; we found a few issues and fixed them immediately. Round 2 will end on Friday, so we expect it to go to Beta on Monday. Version 8.5 is mostly a collection of bugfixes for issues we found in version 8.4.

On the topic of Alpha testing; it used to be a simple test of "did it install sucessfully?", but since our releases don't change once they hit beta, we are now asking for real, solid testing to be done in the Alpha phase, where we can still fix any bugs which are identified in time to include them in the next release. Because of that, we are looking for people and churches who are interested in helping us test Alpha releases in this way - maybe some churches who are already helping us test beta releases are interested, for instance.

If you're interested, let Nick know using the form at rockrms.com/getinvolved

And please remember that we're looking for really quality testing- in previous releases there were some things which should have been easy to test, but weren't tested, resulting in bugs getting through. Since everyone can't test every release to this depth, we need a good group of people who are testing so we can be sure that good tests are getting done, one place or another. The main thing we're looking for in alpha testers is attention to detail. You don't need to be super technically proficient, and certainly you don't need to be a developer. We just want people who have an eye for detail, and some time to invest in testing when the releases come out.

Even though the Core team is in Rock and uses Rock every day, we're not using all of the functions every day (check-in, for instance), and certainly we're not using it in all the same ways that your church might be. So we are looking for you to contribute your breadth of experience in really making sure that our initial releases are solid when they come out. This is part of our saying that "Rock supports churches, and churches support Rock" - as you get deeper into Rock for your organization, look for the ways you can support the community and the product too; alpha testing might be one of those ways.

All that being said, let us give you an update on our development work. We're working on version 9, fighting the same (good) issue we always fight; feature creep. There are some great features that churches are willing to fund which are getting added - some (like registration in the check-in system) even sneaked into version 8.5. But version 9 also adds some capabilities around registrations, conditional fields within registrations, in addition to the volunteer scheduling feature we've talked about and we know you're looking forward to.

As we move on toward version 9ʼs release, itʼs a good time to talk about some tweaks we are making to the Early Access program as well. After the conference where we'd discussed our funding and how there was a trend of churches making a small one-time donation to get access to the Early Access program, the community as a whole really encouraged us to make some changes to ensure the ongoing stability of Rock, including changing the Early Access requirement. Starting with version 9, instead of pretty much any donation unlocking Early Access, the requirement for the Early Access program will be that the organization is contributing at or above our suggested level of $1.50 per year, per average weekend attendee. Remember that Early Access is not only a real benefit that you can use to talk to your leadership about the funding needs to keep Rock viable, but itʼs also so that the earliest users of new major releases are churches who are already invested and usually already engaged in the community, so that by the time the releases hit general access they are fully onboarded and ready to answer questions when they arise in the community.

We talked about the Rock Cloud hosting service that we're working on at the conference, so we want to update you on that as well. This is a project that we thought would be a lot of work but maybe not all that tricky, but which has turned out to be really tricky as well. We've found a lot of limitations around creating an environment thatʼs simple while keeping all of the power of Rock available. One example of this is the lack of IPv4 addresses; itʼs hard to get a lot of those, but there are a lot of features in Rock that work best with distinct addresses. We've gotten through that, analyzed a lot of hosting providers, and thought we were through most of the issues. Then we realized that a basic assumption we'd made at the beginning that we'd be able to use SQL Server Web Edition turned out not to be true. The terms and conditions for that otherwise very cost-effective option have some clauses which disqualify it from being used for Rock.

We bring that up because we think some churches might need to know that; if you're using Web Edition to host your own Rock instance you might be in a fairly "dark gray" zone. Nothing in licensing ever seems to be black and white, but the terms and conditions say that it can't be used for a line of business application like a CRM or ERP. So itʼs a gray zone, but it seems to be a pretty dark gray zone. Unfortunately, that adjusted our pricing model so we're trying to architect so that we can keep the cost down, while keeping the speed and the power up. We're now working on a monitoring solution, and we think we've turned the corner on some things and we're getting some traction again, but this is still in development and we'll let you know when we have more to share.

Also following the conference we know that there is a lot of interest in Avalanche. We've been talking with Southeast Christian Church, and we have some plans. The goal is to really hit that as a project first thing in January. Right now we're doing a lot of planning; what features should go into it, coordinating some schedules to have a big strategy meeting. Avalanche is a great project and is really well thought-out. There are a few features architecturally that we would like to see go a little differently to tie into some larger structures and even some specific block development, so thatʼs why we want to work with them on it. We would be a little hesitant to advise you to get started with Avalanche right now, because some things will change and you'd need to go back and correct those items if you started now. But itʼs going to be a big deal for us in January.

Some of our limitations right now on projects like that are staffing; Emily has been working really hard on interviewing countless people and trying to find the right fits for several positions, but we have some pretty unique requirements if we're to uphold our core values around community and craftsmanship; we need someone on board with the mission and the vision of Spark while being highly technical.

A related initiative is the University program we've been talking about and working on- taking more resumes and matching them with positions we're aware of in your churches. It sounds like there are some matches already that are going to work out, so thatʼs a great start. If you've got a position you're looking to fill at your church, reach out to Emily directly on Slack and let her know about it and we'll see if we can find a match for you.

We're also in a "rotation" year in the non-profit, so there are some people rotating off of our board and some people coming in - we'll announce those names once we get our confirmations.

Other behind-the-scenes items we're looking at include possibly some additional training options next year - we have heard from churches that there are subjects they would value a deeper dive into.

As you can see, many of these initiatives are things we're hearing from the community, and many of them (like the board members) are just a reality we need to give effort to to ensure that the foundation of Rock stays solid.

Another item that fits in to the category of keeping our foundation solid, is the idea we're developing of an Advisory Council. We're looking at this for two reasons. The first is that we know that we could use the input and advice from the churches which are our biggest supporters. They have needs, connections, and some great insights that would really benefit the Spark community if they were organized and put together. The other reason is that we need to communicate things succinctly to them as well, so that these bits of information are flowing both ways. We're looking at how to put all of this together, and we'll be contacting some of these churches in the next month or so.

We want to take a moment to put an idea out here, from a book that Emily has been reading recently. The concept is blitzscaling - basically the concept of lightning fast growth in organizations. They're finding that the most successful companies in todayʼs economy, and definitely moving forward, are the organizations who choose fast growth and market saturation over efficiency. Itʼs kind of the opposite of the traditional approach of developing something, perfecting it, making it reproducible and then moving on to the next item. What occurred to Emily as sheʼs going through this book, is that our community is (and has been) blitzscaling. What we see as we watch the community interactions, is that the community is really getting legs and can be very different from one encounter to another. Thatʼs very exciting because it means that Rock as an Ecosystem is being able to meet the needs of a lot of churches. Itʼs doing it well, itʼs scaling quickly, and itʼs meeting needs very rapidly. Itʼs meeting needs because itʼs not focused on just one organization.

But at the same time as thatʼs going on, Spark Development Network (the "Core Team") can't blitzscale. We are a nonprofit. We can't go out and get venture capital, hire big names to put together big teams and projects. But we also don't blitzscale, as a protection for the product. An organization that scales that quickly is going to make mistakes, and can't uphold our Core Values of Accessibility, Community, Craftsmanship, and Innovation. We refuse to sacrifice these values, so as an organization we can't blitzscale, even as we desire the community itself to blitzscale.

If you consider the dichotomy of these two approaches, you can start to understand why our team so frequently feels so overwhelmed with everything we need to do, how quickly it needs to be done, and whose needs have to be met. We see the needs, we feel them, we empathize with them, and we want nothing more than to meet them immediately. But we can't scale as quickly as the community does.

Additionally, even if we were given a Venture Capital type of investment today, we are unwilling to sacrifice our core values- we think that character in the people we hire is absolutely critical. We're really looking for those one-in-a-million people on our team. And this is why we rely to an extent on learning about people from people already the community. What we do NOT want, is for people to vacate their positions at their churches and come to work for us- that type of a pattern would be the worst thing that could happen. But we rely on you to reach out to your friends working in secular fields or sometimes inside your volunteer teams who have the heart and are looking for a way to make more impact, and who would be a good fit for our team. If they're interested, tell us about them! This is the best way a member of a blitzscaling community can help a core team that can't scale like that; leverage your connections and help connect us with people you already know that aren't yet in our community but would fit in our team.

This episode of RockCast is brought to you by Rock Partner SmartyStreets, providers of address standardization and validation services.

Rock Partners provide crucial support for Spark Development Network, and important services for the community - please be sure to visit them and say thank you for supporting Rock!