Beware of Geeks Bearing Gifts - Part 1
Posted by Bill Anderton
I just have to share this story. For the last couple of days I have been in a running dialog with the pastor of moderate-sized 500-member church in an affluent suburb of large urban city in the southwest. I have known this pastor for a number of years and we just renewed our acquaintanceship this week when he joined the Online Ministries Community.
This pastor joined the community to start building at least an executive-level understanding of Internet presences so he can get a true online ministry established at his church. Since we have known each other in the past, he called and we have had a series of interesting discussions over the last couple of days.
Out of those discussions, I learned of a story that just needs to be shared.
My friend agreed to let me talk about his case if I kept the details confidential in order to “protect the guilty.” You will understand as the story unfolds neither of us want to embarrass the people involved. However, this is an important story to discuss because I run across almost identical situations in churches regularly. It provides a teachable moment.
When my friend and I last spoke, last year, his church had a fairly nice website; not great, but certainly serviceable. It was nicely designed, beautiful in fact, but it was very thin on content and not updated very often. In other words, it was a better website than most but not what is should or could be considering this church’s position in its parish and the resources available to it.
My friend asked me to have a look at the current state of his website and give him my feedback.
My first look at his URL was a shock. It had been about a year since I last visited the site and as I typed the URL into my browser, I was anticipating something bigger and better that what I last saw.
Instead, I was shocked by what I saw. His website had not improved over the last year; instead, it had taken several giant steps backward!
My friend heard my audible gasp over the phone and he started chuckling. I didn’t have to ask, “What the heck happened?” He began with, “I know, I know. Let me tell you my story.”
My friend’s parish is located in an area of the southwest known for its high-tech community. Within his congregation are the CEO’s of about ten software companies, numerous computer engineers and IT people; generally, one of those churches with a high level of computer and Internet culture among the flock. He called it, “An embarrassment of riches.”
Although my friend isn’t all that technical himself, he and his small church staff are fairly typical computer users themselves. Certainly not afraid of using computers, but browsing, using Facebook and doing his own e-mail are about his limits. To run his church’s website and do the church’s social media, he depends on a small group of volunteers pulled from his more high-tech congregants.
You are probably thinking the same thing I was, “With these human resources, this church should have a great website!”
Here is where the story gets interesting.
The previous website that I saw last year was beautifully designed. Although thin on content and a lot of it static brochure-type material that was long in the tooth, this site was probably better the majority of church websites; not an online ministry, but a solid yeoman website.
Today’s version is obviously a simple template-based website on a low-end web-maker class web tool common to the $4-per-month web hosts. It has only about 12-16 pages all together. The graphic design of the site was typical of this class of free web template and all of the images we low-grade stock photography, perhaps what was included in the template when the hosting account was set up.
As it turns out, for the site I saw last year, my friend had a couple of volunteers doing the church website. One was professional Internet consultant and the other was an IT manager of a large corporation headquartered in the community. The Internet consultant had donated his time to design the site and acted as its webmaster. The IT manager had donated her time to manage the web server and do updates if the Internet consultant was out of town on business or otherwise unavailable.
Both of these volunteers were very successful in their businesses. One of the reasons that the legacy content was old and/or slow to be updated was that both volunteers were busy people and started devoting less and less time to the church website as their careers took more and more of their time. Also, the technology foundation on which the website was based was too sophisticated and complex for anyone but these professionals to maintain.
The church website was based on a popular open-source content management system (CMS) that was very Linux centric. Since the two people operating it were pros, they never developed the friendly user interfaces needed to make content updates easy for the church staff to do themselves; everything had to go through the two volunteers. The staff developed new content and then sent the resulting text and pictures to these two volunteers to post. It typically took a couple of weeks for the volunteers to make updates because of their schedules.
The webmastering and updating process became a roadblock to keeping the site fresh and current. Content updates started taking longer and longer to do.
Then disaster struck. The volunteer who was the IT manager lost her job and move to another city to start a new one. Then, within weeks, the IT consultant landed a new very-nice contract and had to leave to go to another part of the country for the next two years, only returning home on the weekends, once every two or three weeks.
The problem was that the church staff couldn’t operate the systems that were left behind. Also, the systems weren’t well documented so even other volunteers had difficulty taking over.
It was a mess.
Finally, after struggling to cope for months, the church simply started over with a simple web hosting account with its basic template and loaded a small amount of content into it to at least have a function website. As it turns out, while the legacy site was much prettier, Advent material was still on the home page through Easter. At that time, the pastor threw up his hands and got a simple web hosting account through GoDaddy.
The church is now rebooting their entire Internet presence.
The backstory was that the volunteer who was the Internet consultant had donated all of his time to develop the site, including providing the open-source CMS. Since he used this CMS all of the time and was an expert in its use, he put all of his time in the site design rather than the backend user interfaces. As an expert, he didn’t need the easy-to-use interfaces; he built a system that he could use but nobody else in the church could. The volunteer who was the IT manager could keep the servers running but didn’t have many web or content skills. She could get something done in a pinch covering for the webmaster, but changing and managing content wasn’t her thing.
When the project got started, a typical church-style committee was constituted to oversee the project. All of the stakeholders, except the two technology professionals, were other volunteer ministry leaders who ran the various ministries of the church and could provide content. All could write but had limited technical culture or skills, so the two technology professions were a God-send.
The problem was that in the exuberance of getting a nice site built, they became totally dependent on one person, the Internet consultant. While there was still a lot of passion for the project in its early days, things went well. However, as time went by and this critical resource became busier with his professional career, things started to slow down and the bottleneck became apparent. When it started taking a long time to get updates posted, the others on the committee who made the content started to lose interest; what good does it do to make new content if it was going to take weeks to get it posted? "Events" became "past events" before the first content about the event was posted.
The plot does thicken some more, but I will pause here and say that so far, this is a very common story. It happens all of the time on things other than church websites too.
But, the plot does thicken ... big time!
This pastor has been at this church for more than 10 years. In his tenure, his has been through three almost-identical cycles of this. Because he has so many technical people in the congregation, a couple of knowledge volunteers will get involved for a while but then lose interest or move.
Each cycle looks something like this: (1) things will be great while the knowledgeable people are still passionate about the project; (2) but ardor eventually cools; (3) the knowledgeable people leave the project or the church; (4) the staff and the remaining volunteers can’t cope with what the knowledgeable people built; (5) website falls into disarray; (6) website becomes an embarrassment until knowledgeable get involved to fix the embarrassment; (7) cycle starts again.
While I’ve seen this cycle happen once (in many different churches), this was the first time I heard of it happening three times back to back to back; the three-peat from hell.
One definition of insanity is to do the same thing over and over and expecting a different outcome each time. This was a textbook case
My friend wants to finally fix this problem and ask for help.
In my assessment, and I only dug into details of the very last cycle, one of the empirical causes of problem was giving the Internet consultant free rein and letting him use his favorite tool. This was tactical thinking. I know the CMS that was used, it is not for the faint-hearted. If you are a hardcore Linux server person, you can cope; civilians don’t have a chance. The tactical thinking was easy to fall into because the consultant knew this tool and, since it was open source, the server software was free.
My guess is that the committee didn’t give it a second thought and thus planted the seeds of their own ruination.
Ruination was then almost guaranteed when, for expediencies, proper user interfaces weren’t developed in the CMS that would allow the church staff and other volunteers to make content updates without going through the bottleneck. Such user interfaces could have isolated (abstracted) civilian content authors from all of the linux stuff. Therefore, all updates single-threaded through one person. If that person’s commitment slowed down, everything slowed down. The bottleneck became the weak link in the system.
I have seen this happen before. So much so, I have a name for it, “Beware of geeks bearing gifts!”
The involvement of “geeks” (trained and knowledgeable technical people) are blessings for churches. I am geek myself and wear the badge proudly. However, geeks do have to be used correctly and sometimes, need adult supervision.
Don’t assume that just because geeks have technical skills (even great skills) that they will always make the correct strategic decisions. Many professionals are specialists working only in narrow disciplines. They may be totally isolated from strategic planning and project management in their professional life. They are often given strategic plans to execute rather than making these plans themselves. It is therefore natural that many geeks may only focus on the short-term tactical goals such as, “Let’s get something better up and running right away” rather than longer-term strategic goals such as “And let’s also make sure we build something that can be operated by non-geek personnel over the long haul.”
Geeks also like their toys. Unless otherwise coached, they may use tools that others, without their level of skill and experience, can’t use.
In today posting, I’m only setting the stage for this situation; telling the tale of woo. In Part 2, on Monday, I will use this teachable moment to make some suggestions about how to channel this situation into a far more positive outcome.
Category: (04-13) April 2013 Tag:
This is only the blog's abstract. To read the full text and participate in all of the interactive features of the community, please register. It's FREE!