6 min read

It’s true for your database, too: you need the right people doing the right job. Here’s how to get “people” right on the database side of things.

Last week I described a familiar feeling at nonprofits—“my database sucks”—and laid out four factors that can cause this feeling. Let me repeat two starting points: first, this is common. If you’re frustrated by your database, you’re in good company. Second, don’t rush to just replace the database. Take the time to think through some key questions to investigate what’s really causing your problems, and then determine the best solutions.

In the first part of this series, I discussed how misguided perceptions around your database can ruin it. Today I want to look at the second major reason everyone’s database sucks: people problems.


Some databases are built better than others. Some data sets are cleaner than others. Some are user friendly. Some are intuitive. Some are fast. Countless factors might separate database from database.

But there is one, universal filter through which every piece of data at your organization flows: people. If you have the wrong people, or people doing the wrong things, it does not matter how good every other link in the chain is: your database will suck.

Some organizations have a lot of staff with defined roles. Smaller organizations will have fewer people wearing more hats. The number of staff is not as important—that will depend on the size of your organization—but what is essential is that all of the necessary roles are fulfilled.


This “database shepherd” is the single most important role that every organization must fill. In larger organizations this may be a shared role between a team of admins, but usually this is a hat that one administrator wears. In many ways, an organization’s data is its most valuable resource.

Lose your database and I don’t care how long or prestigious your run has been, you shall suffer mightily. The database admin’s role is thus to watch over your most valuable asset. When disaster strikes, questions are raised, or needs arise, you need an admin to answer the call.

What a database administrator is not: They are not petty tyrants, obsessively blockading or stonewalling changes or requests. At the end of the day your database belongs to and serves your organization first. This role is not high and mighty, but in service of other staff and department needs—to make sure needs and desires are fulfilled effectively and judiciously.


Support from leadership is essential for every database. The “executive champion” needs to have a clear idea of what they want going in and coming out of the database. Then they need to make these expectations clear and give their staff the latitude to accomplish them.

They also need to solicit feedback about the processes, the platform, and the perceptions of the database, and be willing to champion changes and requests from their staff “in the trenches” to the administrators who fulfill those requests. Executive champions need to make sure the employees they oversee have the tools, permissions, and resources they need to do their jobs effectively and efficiently.

The single biggest benefit the executive champion can provide is tearing down obstacles to help your staff do their jobs well by maintaining and using good data.

What an Executive Champion is not: They are not helicopter parents of the database. They are not admins and should not prescribe how things are done. They are not a good barometer of the state of the database. Generally, the true state of the database is so hidden from executives such that they should not trust their own experiences alone.

The executive champion should not oversee or micromanage the day-to-day use of the database. They should enable smooth workflows and open feedback loops to ensure efficient and enjoyable usage of the database.


Meet the frontline workers of your database, the brave men and women who do the essential work of getting data in the system. These need to be detail oriented employees who have processes that encourage checking their work. These people make sure donations, donors, attributes, etc. are all correctly entered. They lay the building blocks of success every day; they are functionary, but essential. No matter how large or small your organization is, someone has to get the data in.

What data entry is not: Administrators. Admins can do data entry, but do not confuse one role for the other. One person might do both jobs, but they are distinct jobs. Similarly, your parttime volunteer who puts in your data for you is not an administrator. Admins ask questions like, “why are we doing X, and how will that affect Y?” That question is not expected of data entry roles. Many organizations end up frustrated when some preventable accident happens because they expected the data entry person to ask questions they never should ask. Or, on the other hand, data entry is overlooked, because the administrator is busy chasing other issues or asking and solving other problems. These roles must be defined and staffed. 


These are the people that use the database for its intended purpose. For example, in development databases these are your major-gift officers, foundation managers, and direct mail managers, and so on—in short, fundraisers.

End users access the database on a regular basis for their work raising money and fulling their many development tasks. At the end of the day, these are the primary individuals who rely on the database being in working order. They need the data inside to do their jobs effectively. They should be consulted and included when major changes are being considered. They should be given as much freedom in the system as possible while keeping the “gutter guards” up. In short: the database is for them.

What end users are not: Children. Give them as much permission and access as you can reasonably allow. Get their buy-in when changes are made. Train them well on the system and set expectations for how they should be using the system. These people need to become as comfortable as possible with the system.

If the database does not serve these people well, they will capture their donors, actions, and tasks somewhere else . . . spreadsheets, emails, post-it notes—anything to avoid using the database. And that does not serve the organization well. This creates a huge headache for the admins, a reporting nightmare for leadership, and long-term frustration for the end users themselves. Treat them like adults who need the right tools and support to excel in their jobs and then hold them accountable.


These are people that use the database for additional purposes. Think your accountants, marketing professionals, program professionals, operations staff, and so on. These people usually interact with the development database to get some piece of data out of it for their purposes. Accountants need to audit the books, marketers need to pull mailing lists, etc. Make sure the information is stored in such a way that these folks can get what they need and get out. The database should serve their needs while causing the least amount of disturbance to the database’s primary users: development staff. As ever, we want to reduce friction for auxiliary users, while bearing in mind that it is not for them—it is for fundraisers.

What auxiliary users are not: End users. The last thing you want is for accountants or marketers to start getting their fingers in the database build. The development database serves development first and foremost. That doesn’t mean ignore the needs of auxiliary users, but position them properly. Do not let them change how or what you do if it proves detrimental to your primary goal: fundraising. You can’t acquiesce to every different department and leave your fundraisers holding the scraps. (Side note: see my point on integrations in part one of this series. Databases often become clunky because we try to integrate everything and please everyone. That’s not the purpose of the database. Or an integration.)


Not every organization has distinct people filling each of these roles. But every organization does have each of these roles that someone is filling—whether you know it or not. These tasks are being done (well or poorly, frequently or rarely) simply because they are inextricable from the fact of having a database.

If you are having an issue with your database, consider whether not attending to the people—the various roles and responsibilities playing a part in your database—is playing first fiddle in causing these problems.

Here are some questions to ask to clean things up:

  1. Who fills these roles in my organization?
  2. Are any roles being overlooked or neglected?
  3. If a role is not being filled well, can that be an internal transfer? Or do we need a new hire?

After asking those questions, make the roles—and corresponding responsibilities—explicit: “Joe is our Admin. He is the point man for our system and all questions go through him. Betty is our Executive Champion who makes sure board and leadership requirements are made clear. If you’re running into any roadblocks you go to her. David and Suzie are End Users…”

This way there is no guessing and no excuses. Get people in the right places doing the right things and your database will very quickly become more manageable.

This article is part two of a four-part series. You can read part one here and part three here

Leave a Reply

Your email address will not be published. Required fields are marked *