We don't have a "database guy"

In fact, I'm totally against having a "database guy". [sound of screeching brakes] Yes, I know my current and former boss authored a whole chapter about this in Simply Strategy Stuff. [Page 58.] "Somebody has to live and die for the database". I agree with the strategy. But, success is dependent on how you execute it.

And, here's why. Your database isn't about technology. It's a piece of technology that supports your church mission and systems for ministry which is all about people, relationships, care and spiritual growth.

To make it even more complex, ministry is fast-paced and in constant change. As you work towards goals in the pace of growth, teams and projects proliferate—as does confusion. It takes a team of people to help manage this across multiple departments and establish trust for team success and church health.

So, what doesn't work? Assign one guy to be in charge of the database and call it a day.

So, then, what does work? We hand-picked a group of people from various departments and assembled a SuperTeam.

What do they do?

• champion the technology solution
• clarify intentions
• articulate benefits
• learn functionality
• empower others

How do they do it?

• Stimulate conversation. They establish context for data decisions through organized and impromptu discussions. They provide opportunities for information exchange between teams.
• Keep an eye out. They watch for and address inconsistencies; in data and systems. With a "shared ownership" mindset, they help discover how the pieces fit together and determine next steps to maximize ministry.
• Provide resources. They anticipate people needs and address system concerns by gathering and distributing information horizontally and vertically.

The benefits?

• Training tools that replicates learnings for shared success.
• Reports that bring all the data together to create a single version of the truth.
• Reliability and flow that allows people to focus on their ministry strengths.
• Individuals and teams that make smart decisions for the church as a whole.

• Breakthrough thinking and new insights—from everyone.

The rest of the story? There aren't any techie data geeks that love database administration on our SuperTeam. Not a single one. The work is challenging. Discussions are complicated and navigating around a database obstacle course isn't always fun. No, our SuperTeam members don't love databases, but they do love people. And, that's why they don't shrink back (and why they're hand-picked for the team). They bring their area of expertise to the table to cast vision, change perceptions, raise morale and make a big impact.

So who lives and dies for our database? Technically, it's the SuperTeam. They are the ones who make the ministry. I just cheer them on and clear the hurdles.

"The successful company is not the one with the most brains, but the most brains acting in concert." Peter Drucker, Management guru

Comments

[jhook]

Kem,

I think the idea of a Super Team is right on! I believe most of the nay-sayers are referring to the technical side of systems development. Since I know you are an F1 user, I believe you are referring to the data integrity side of the database; some people refer to that as a "data administrator" versus a "database administrator." In the church industry, bot hare referred to as database guys. Some refer to your super team as a team of super users.

Whatever you call them, there is a real need for data coordination within the church. Each church needs a data strategy - what is the first time and what is the minimal level of information you are willing to track for a person or family; what are the subsequent opportunities to capture additional information and when and how often do you cleanse (update, revitalize) the data. Since data is a church asset, not any one ministry's, this has to be coordinated and communicated across ministries. Too often, the different ministries are silos with their own way of conducting "church." In this manner, the ministries tend to pass a person or family off from one primary ministry to the next. In a family centric church, the family is viewed as in the middle and all ministries are their to service the primary customer - the people.

The more people who are focused on the data the better the quality of information. When only one person is in charge of the data, they can rationalize all its shortcomings and inconsistencies. The more people who "own" the quality of data, the better able the leaders can depend on the reporting results. There is no need to rationalize, everyone is vested in maintaining the quality.

Good post!

Grace to you,

jhook
Fellowship Technologies

[Greg Atkinson]

Very interesting. Thanks for sharing that.

[Peter]

Let me revise my opinion slightly here. I still argue that you need someone who is well versed in databases. One of the biggest problems with a lot of developers is failure to understand what makes just about any database platform perform well. That leads to poor choices and no ability to refactor the design later because it's too ingrained.

Case in point, one company I worked for designed an app that had a bunch of checkboxes, notes, and dates on the screen. Rather than designing this properly, they figured that there were just a few fields so why not put everything in one table. Over time, some fields got removed from the UI (but stayed in the table) and more were added. If we'd designed this properly from a DB standpoint, that whole area could have been driven by the database with no code changes necessary. Instead, we had to do new releases and add new columns to this table every time we needed new functionality. (Even worse, they re-purposed some columns so we had to know what they were used for as of a certain date!)

Yes, that example focuses on some poor programmer choices, but if they understood working in sets and some basic OLTP database theory, they could have done much better.

So let me end by saying that a database guy may not be necessary, but I really think someone needs to have that knowledge so they can make wise decisions. Perhaps Matt has a good idea on this one - a team, perhaps a subset of the dev team where one person really has that knowledge and one or more are learning.

-Pete

[Matthew McMaster]

I love it when someone agrees with me. What I don't like is that your blog is better written. You point out many things that I missed and I think I have a few benefits that you missed. One large one that Peter who commented above should agree with is that with a database expert on staff the church has a single point of failure. I have worked with too many churches that had the perfect database champion. (Fellowship One Champion in our company lingo) Then the call of more money, the need to move, promotion, death, mission trip, you name it takes that perfect person and leaves the church in a lurch. A champion team absorbs the loss of staff across the team and trains the replacement personnel in the process.

https://experience.fellowshipone.com/blogs/deliveringchange/default.aspx

[John Stark]

nice post.
I agree ministry is best done in teams... but even great teams need a leader.

[Ian Koenig]

I so agree with this. Only in the largest of large organizations can you effectively get away with a "database team" whose only view of the universe is the database.

When the focus of the database goes from being "a unique item" to a set of relationships of data and what that data is, you suddenly gain insight into your business. In this case its the business of people. So what honestly matters and needs to be tracked about people.

My company's view is about money. Until I got involved in some of the discussions, the talk was all about SQL this and SQL that. "Oh wait we need SQL 2005 and MySQL." When I got involved I started asking the questions of "Why does this matter? Yes we need it to work and what about the data? Isn't the reason we are able to even talk about this stuff is the data this stuff holds?" Now its more focused on the data and not so much the latest toy.

[Dan Roam]

Not being a DB sort of person myself, I'll refrain from pretending to know which approach is better.

But as a connoisseur of quick sketches, I sure get the message. I *love* your drawing!

[Peter S]

Gotta disagree with this to some extent. The problem with a "Super Team" without someone who really understands databases is that you tend towards procedural code instead of code that can be better optimized for database operations. Sadly, most developers really don't understand the idea of working with Sets of data instead of row-at-a-time type processing. You also run into problems with people who don't understand why you'd want to normalize or denormalize the database during the design phase and then can't refactor the DB design easily because of everything built on top of it.

While I don't think you necessarily need a "Database Guy" all by their lonesome, you do need this knowledge in order to design apps that work well (not just work) with databases.

Now I agree with you that the team needs to love people and love what they're doing. If you don't have that, you don't have a good system or you have a user-unfriendly system that nobody wants to use. Including the DB guy so that you can write efficient code and scale your apps is an important piece of that.

Of course, putting your DB guy out all by themselves or as the sole guardian of the data/structure is a little foolish. They need to be a part of the team, interacting, helping with the queries that drive the data, documenting the model, writing stored procedures, etc. Leaving them on the outside just fosters a "me vs. them" attitude that doesn't help anyone. I will count myself quite blessed to work with a team of developers who are quite people-focused and will take the time to do things right. I'll definitely ask their opinion on data-matters prior to just designing something and forcing people to use it.

(Disclosure - yes, I'm primarily a database guy. I also offer constructive criticism on the interface and help ensure that we're not coding ourselves into a corner while trying to balance against over-engineering.)

[Joe Louthan]

Before I read this, I was so excited about going from 13 year Systems Administrator with expertise in Linux, Windows and Mac to going into Vocational Ministry as a Pastor and a Teacher.

I get to burn those 13 years in effigy. Bah hahaha!

Then I read this post and I got this amazing impression that I am going to bring those 13 years of ITness into any ministry I am going to work for. Yes, I think I am going to be a Pastor of IT.

I can marry you, bury you and analyze your Crash/Hang Dumps from Win2k3/IIS6, write some BASH scripts and upgrade your Xserves to Leopard.

[Jeremy Scheller]

I would love to have a Superteam. (or a database guy). Anything other than I'm the database guy which is the current state of affairs...

It's one of those things that I just want done, everybody agrees we need it done, and nobody wants to do it.

Here's what I want: Alakazaam Poof here's your up to date database!

[-courtenay-]

I would say we have a combination of the two approaches. We do have a database guy. Except she's a girl–not the point. But, she isn't the only person who touches the database. Several other people are involved in keeping things current and consistent. Database Girl is passionate about training other people, employees and volunteers, to use the system to its full capability (and beyond, sometimes).