If everything is important then nothing is

Patrick Lencioni’s quote is excellent. I see a lot of database managers, no, a lot of people in the industry struggle with this.

But I believe it is true. There is a lot of discussion about multitasking or task switching and how women are better at it than men. However, I believe that making a list of everything you’re doing and then attempting to figure out how to make that list more manageable will only help you get things done.

The difficulty in managing multiple tasks is usually due to the number of moving parts and interdependencies. As previously stated, I would make a list of the projects, going old school if necessary and writing it down on a piece of paper with a pen! Then you can figure out when things need to happen.

The key to all of this is managing expectations; whether you’re a consultant or an employee, you just have to be honest and tell people what you’re thinking. To be fair, I write this from a position of frequently getting myself into hot water over this. Anyone who has worked with me knows that I try to do too much, and I recently found myself in front of a client and friend, anxious and concerned about their project due to time constraints, the work that is required, and letting them down.

As obvious as it is, burning the candle at both ends cannot be sustained indefinitely. I’ve seen people working a frightening number of hours during lockdown just to keep things running while all the extra work, not business as usual, was being added. If this continues for an extended period of time, two things are likely to occur: people will become disinterested in their jobs, or they will be forced to take time off.

My suggestion would be as follows:

  1. Return to pen and paper and make a list of everything that needs to happen.
  2. Communicate this effectively to the team working on it as well as the larger stakeholder who is requesting more work. Sometimes stakeholders will come to an agreement and re-prioritize.
  3. Make a list of at least three things you’ll accomplish that day. Also, make sure that no single day has more than three tasks to complete. I don’t mean trivial tasks like making tea or doing the dishes; I mean tasks that require your full attention.

If your list cannot be broken down into three things that you can accomplish in a day, then your list-making process needs to be reviewed. Here’s an example of how to break down the list.

Problem: My database needs to be cleaned; this will take months, and I’m not sure where to begin.

This could be divided into the following areas of my database that have the greatest impact on users:

  1. Contact Types / Constituent Codes – Who are my stakeholders
  2. Action Types / Communication Types – What do I talk to them about
  3. Attributes / Profiles – Do some of these options need turning off

With those three things in place, many of your users will notice an improvement fairly quickly.

It’s the same with website or integration projects: break them down into something manageable or achievable so that something gets done, and if it can’t be done on time, explain it as soon as you know you won’t meet a deadline so stakeholders can make alternative plans.

Finally, why three? There’s a great piece here about how we are taught and given three options at a young age, read more about the power of three –

If you have a different approach to dealing with the day-to-day challenges of managing a team and multiple people wanting multiple things at the same time, I’d like to hear about it.

General Training

Database Team Structures

I’ve been involved in analysing database team arrangements across organisations as a follow-up to my article on database personnel. When building fundraising teams, one element that is frequently overlooked is the infrastructure required to support the expansion. So I decided to discuss how I attempt to determine what is necessary.

Understanding the team’s requirements, both present and future, should be your first priority. Hopefully, your company has a list of routine duties, such as: Weekly or monthly events could include processing Direct Debits or importing JustGiving data. This is what I would refer to as “business as usual” (BAU) material. Once you get the list, you must indicate how long each task takes so that you can determine how much time is spent on BAU work each month. As part of this, I would also include monthly team meetings, mailing choices (if they are regular, like once a month’s worth of Enews), training sessions, and support.

Then there is project work, whether it be an analysis, a new product, an innovation, or a study of your CRM system that requires improvements. Once more, you should keep a track of how much time the team spends on this kind of work. This is what I would consider project work, and I would also include scheduled yet sporadic mailings, such as if you send out appeal mailings on a quarterly or biennial basis. Additionally, I would advise you to regularly check in with system users to make sure everything is still going well. I advise creating a super user group that can discuss how their respective teams use the database. and anything that irritates them or prevents them from doing their job.

You now have a rough idea of how long projects that you are aware of are taking.

Last but not least, there is Emergency Response work. Either something has gone wrong and needs to be fixed, or Blackbaud is withdrawing the office integration, in which case a patch needs to be found. The organisation won’t be aware of this kind of situation, but there is no way around the need to have a response. You’ll need to be aware of how much time you spend on this kind of work, just like you would with the other kinds.

In an ideal world, it should look something like this:

BAU – 50-60%

Project work – 25-30%

Emergencies -5-10%

The amount of real days that people can work must then be taken into consideration, along with any holidays. I assume there are 200 working days in a year because I am a consultant.

With these estimates, you ought to now have a better idea of what the team’s requirements are.

Most organisations with fundraising revenues exceeding £5 million should require more than one individual to work on their database team, in my opinion (So long as the database team is just responsible for the database and not the whole IT infrastructure stuff) Just to be clear, I’ve worked with several organisations that rely on one or two superusers to fill the role of database management because they don’t have one. With the information above, hopefully it was clear why having a database person was necessary.

So, let’s go back to business. You’ll have a better idea of the activities that are necessary and, consequently, what you’ll need in a team, based on the time split required between BAU and projects. I’m assuming you’ll need someone to handle imports, mailing selections, insight and report production, as well as project-related deliverables. Now, just as you don’t want knowledge silos in your database, you also don’t want them in your teams, as this can cause issues with things like succession planning.According to the size of your organisation, you may need project managers who collaborate with the database team or business analysts who can translate user needs into briefs for the database team to implement change. In an ideal world, all database teams would have at least two members so there is coverage for things like holidays and illness.

Digital strategy is one of the topics I’m hearing about increasingly frequently. I understand that many organisations are still embracing digital technology, and I believe that the impact of digital strategy on database teams appears to be broad. A new strategy of any kind should involve your database team early on so that the database can be set up in a way that allows you to report on the success of your programmes. It also appears to have different success metrics than what the majority of people are used to. Every strategy should include a list of specific success metrics. As always, start small. Consider the top 3 factors that contribute to success and grow from there.

And now that I’m just looking ahead, I would love to see more heads of data sitting on leadership teams. Although the database team’s primary responsibility is to serve its users, having a voice at the table at the beginning of strategic discussions and being aware of how data is affected by process, governance, or insight means that we are on board for the journey and have a clearer understanding of the WHY behind what we are doing.

Instead than just being a place to store things or a liability, organisations need to view their data as an asset. If you’re interested in learning more, I recently read a book called Leverage that goes into this topic in further detail.

I therefore expect that this will be helpful to individuals who are having trouble figuring out new team structures, and I anticipate seeing more database professionals on leadership teams in the industry. Reach out to other database managers in the industry as much as possible. Our industry is great at sharing information; long may it continue.

There are a variety of different types of structures that database teams in the UK charity sector may use. Some common structures include:

  1. Centralised database team: In this structure, all of the organization’s databases are managed by a single database team. This group may be in charge of data modelling, analysis, integration, and storage.
  2. Decentralized database teams: In this organisational structure, there are various database teams, each of which is in charge of managing a particular collection of databases. These teams may be set up according to location or function (such as financing, programme delivery, or fundraising).
  3. Hybrid structure: In this structure, centralised and decentralised database teams are combined; some databases are managed by a central database team, while others are managed by decentralised teams.
  4. Database team is provided by an external vendor or service provider rather than being handled internally in this arrangement.

The appropriate structure for a database team in the UK charity sector will be determined by the organization’s size and complexity, as well as its specific needs and goals. Depending on their changing needs and priorities, organisations may choose to adopt different structures at different times.


Database Person 101

One of the things I do is assist with interviewing database people for roles. It’s usually where I already have a relationship and have worked on a project for a client. I recently hired a database person at a charity where I’d been assisting with Raiser’s Edge database support for the past few years.

The pandemic has made conducting interviews quite different. Zoom or Microsoft Teams interviews can be difficult to conduct, but they can also be beneficial since, in my opinion, interviewees are less anxious when they are not present and are not dealing with the pressures of travel. Some people experience the opposite, where they become more anxious when they cannot meet in person. Keep in mind that the interviewee wants to perform at their best for all parties.

However, I digress. The purpose of this piece is to discuss the onboarding process for new hires, what it’s like to join a team, and what you should try to consider. But before that, I would note that it has been challenging to find candidates during the pandemic. If you’re trying to hire, all I would advise is to persevere because the right person will come along. You should also be realistic about what you can offer, as I believe that remote working is here to stay and that database professionals do need some time away from the office to focus and do some of the “doing.”

Let’s get back to it. Although the individual I hired had experience with databases, they hadn’t worked on the particular database at this nonprofit, so as part of the onboarding process, you need to give them time to get up to speed. Keep in mind that not everyone learns in the same way; some prefer to read, some prefer to watch videos, and some prefer to just dive in. If you’re writing handover notes, consider whether making a video of a brief passage that can be utilised as training material or to explain something a little more technical would be the best course of action. The majority of companies offer current films for system overviews, and if you’re just getting started, YouTube is your buddy.

Training: Even while you want the new employee to become acclimated as quickly as possible, try not to schedule all of your training sessions or orientations during the first few weeks. Joining new organisations can be overwhelming for database professionals because most database professionals are introverts. I don’t mean this in a negative way; I’m just saying that meeting lots of new people can be exhausting and that trying to remember names and roles on top of systems and processes takes time. Create a strategy for the information your database person needs to know and make sure there is room for it.

I chose a half-dozen things for the person to learn each month for the first three months, and then a few of the more important things for the last three months of their probationary period. Which is a good point; I would always estimate that it takes approximately 6 months to onboard and embed a multifaceted database person; obviously, if your database person is only doing imports or selections, it can be much faster, but as a guide, that is what I would suggest. Everything will be fine if they arrive sooner.

When your new hire is no longer new, the honeymoon period is over, and they must work on their own. Hopefully, the following items are in place:

Task Management – They’ve found a way to manage their day-to-day tasks, whether it’s Outlook tasks, a separate calendar, or something completely different like Todoist or Trello.

Documentation – There are notes on what you’ve gone through that are saved in a location where you can refer to them or share them with other team members. This documentation should include process notes, your personal notes, and contact information. Using a programme like OneNote or Evernote, which allows you to save links to websites as well as documents and pictures, can be useful at times. You may also be able to embed videos if you’ve decided to create your own collection of how tos.

Projects List – Before you set out to change the world or annoy colleagues with the “This is how we did it at my previous job…” I’d make a projects list and a tracker for everything that happens on a regular basis, such as imports from JustGiving or Direct Debit Processing, and then look at the bigger projects / clean up type stuff that you might want to tackle when you have the time, such as Contact Types, Communications lists, or teams that aren’t using the CRM as well as you’d like. They are not 5 minute tasks.

Again, you can keep this separate from your regular day-to-day tasks, or you can keep it all in one place. Personally, I keep them separate because I would be overwhelmed by a long task list followed by a long list of projects I need to complete.

Finally, make time for self-learning and keeping up with what’s going on in the industry. Database professionals don’t have many options for getting help, coaching, or mentoring on a daily basis. So start with the Facebook groups; there’s a fundraising database group as well as Raiser’s Edge groups for the UK and overseas. Other CRM systems are available, and there are groups for them. However, I would say that many of these groups are places where people vent about their CRM system, sometimes for good reason, but you’ll need to wade through this or add a picture of your pet to cut through the noise.

You can, of course, look for people on LinkedIn and connect with them; who knows, we might even be able to hold events where we can put like-minded people in a room for a discussion – stranger things have happened!

Finally, this isn’t my typical type of post, so if you’d like to see more of this type of thing, perhaps about specific database challenges, let me know and I’ll keep typing; if this is completely off the mark or if I’ve missed something obvious, let me know and I can amend or leave this type of thing to people much more qualified than myself.

Here are some examples of common job roles on a database team in the UK charity sector:

  1. Database Administrator (DBA): A DBA is in charge of managing and maintaining the organization’s databases, which includes tasks like data modelling, storage, integration, and security.
  2. A data analyst is in charge of analysing data in order to extract insights and inform decision-making. Data cleaning, data visualisation, and statistical analysis are examples of such tasks.
  3. A data engineer is in charge of designing, constructing, and maintaining the infrastructure and systems that support the organization’s data needs. Data pipelines, data lakes, and data warehouses are examples of such tasks.
  4. A data scientist is responsible for analysing data and extracting insights using advanced statistical and machine learning techniques. Predictive modelling, natural language processing, and image recognition are examples of such tasks.
  5. Data Manager: A data manager is in charge of overseeing the overall management and governance of an organization’s data, which includes tasks like data quality, data security, and data privacy.

A database team may include one or more people in each of these roles, depending on the size and complexity of the organisation, or it may have a more specialised structure with additional job roles.