I have a background in enterprise application development, which is a fancy way of saying that I often have to build software that can handle many thousands of users at a time. During the “.com bubble”, the consulting company I work for was often asked to build massively scalable applications along the same requirements – even before they had their first customer! Now, most of this was to prevent a fiasco like Toys ‘R’ Us in Christmas of ‘98. But, what most of them didn’t take into consideration is that Toys ‘R’ Us had a built-in customer base from their brick-n-mortar stores to start from, whereas most of these crazed maniacs didn’t have a single customer!
What’s my point? To remind you, as a ministry or church leader, that sometimes you need to address only what is necessary first. This sounds a little like a previous post I made, doesn’t it? Well, I think this is a very important concept and grounded in real-life experience that I see over and over as I read other blogs and talk with ministry leaders. I learned this lesson the hard way, when I spent over 6 months researching a Content Management System (CMS) for my church. In the end, I discovered a few things that I want to share:
Most problems must be solved with the end-user in mind (i.e. Don’t assume you know your customer) – Take away: “Determine your goals up front”
The CMS vendors, free or the most expensive, see the users as Computer Science majors, not as an average-joe Christian with a heart to serve and no technology expertise (”I can write a Word Document, but what is content meta-data?”). Take away: “Focus on the necessary, not the cool factor”
Big solutions often miss the small problem. Take away: “Review and adjust as required”
I am still an enterprise Java developer, and the unfortunate part of this is that the Java community has lost its way. They are, thanks to Sun, all caught up in writing many layers of abstraction, frameworks and tools galore, and documenting specifications with companies that all want to gain the advantage over their competitors rather than solving a problem. This is where languages like Ruby and its web counterpart, Ruby on Rails, really shines – get out of my way and let me solve the problem first. Like the PHP community, the Ruby community often writes small little libraries that accomplish a task or integrate data. They then let the programmer decide if they want to a) write a small script to do what they need, b) write an application on top that is ugly but works, or c) write a full-blown end-user centeric solution.
God’s Word teaches us that difficulties will arise in our leadership. Paul is the most memorable example, as he struggled with imprisonment, beatings, shipwrecks, and even near-death to take the gospel to other parts of the world.
Guy Kawasaki put together a set of guidelines for using PowerPoint several years ago. While focused mostly toward startups doing pitches to venture capitalists, I think these rules can be used for leaders that cannot …
Often, leaders get so focused on leading their team that they can sometimes get confused on who they are competing against to recruit new volunteers or launch a new event. Don’t let yourself get confused on who you are competing against when trying to find volunteers.