Tuesday, May 31, 2011

What makes a great database manager? (Part 1)

I have been fortunate to have worked with some great Database Managers at some of the charities I have consulted for. At least, I think they were great. But I have often wondered what it is which makes a great database manager. Why is it that some people have really stood out when I worked with them? Can we actually define what makes a database manager "great"?

Here’s my thoughts on that - and it's a 2 part post because (as usual!) I have quite a lot to say...

My Definition of a Database Manager

First off, for the purpose of this post, I thought I should try to define the sort of role/person I am writing about. This is because the job role of “Database Manager” can mean a number of different things depending on the type of database, size of organisation and database team, the specific tasks they are expected to do and so on. So here's what/who I am thinking of:
  • I am presuming that the role is not purely for a “techie” who would only look after the “back end” of the database and who would rarely come into contact with end-users, application users, business users et al. As such, for the sort of Database Manager I am considering, it shouldn’t matter too much if your database uses SQL Server, Oracle, MySQL, Access or whatever.
  • They are someone who is more likely to be working with the “application” than the back-end; e.g. they would know (or could learn) The Raiser's Edge, an IRIS system, Salesforce, DonorPerfect, ThankQ etc. 
  • They are therefore highly likely to be someone who would have regular interaction with end-users and business users, so they need more than just technical skills. They need some technical skills, but how much depends on each specific organisation.
  • It is likely that they would not be part of the IT department in a charity – although that isn’t critical.
I do recognise that when it comes to a Database Manager, the size of an organisation can have a significant impact on their role and responsibilities. For smaller charities, they could well be looking after the fundraising database package, trying to write a temporary Access system and do the daily backups, whereas in a larger organisation there might even be a team of people who “manage” the database, which could mean that each individual could have different roles (e.g. data loading, support desk) and the head of that team might be far more of a “classic manager” than simply a database person.

And there are more ways of defining such posts too; I’m absolutely sure that for every person who agrees with one of my statements above, there will be someone else who disagrees! And that’s fine! All the above is not to try to enforce a structure on you or your charity, but to help you understand the sort of person/role I am considering when writing this post.


Okay, let’s start with the most obvious of statements but one which we should never ignore: experience is great! You can read lots of books, go on a training course and even get a degree but experience and learning and using software every day and working with end-users of all sorts and presenting to Trustees and doing things right and making huge mistakes… is all the sort of stuff which really means someone can become a great Database Manager.

Of course, having experience alone does not make someone a great Database Manager. If someone has 10 years of experience in one product but can’t hold a conversation with a business manager then they may not be right for you.

But let’s not forget how important experience is throughout every topic I list below.

Technical Skills

Clearly, a Database Manager would have some technical skills. (I detail below what I mean by technical). To what degree does depend on the system, the users, the size of the database team, even the type of fundraising etc. I know quite a few arts organisations who have a part-time database manager for their development database, and whilst I don’t think that is the best idea, they do get by, and in many such instances I am sure that the database manager does not describe themselves as technical!
  • Application skills. If your organisation uses The Raiser's Edge, Salesforce, DonorPerfect etc, then your Database Manager should have a solid understanding of that system. And if they are the sole individual looking after that system then they will need to know or be able to learn in-depth knowledge. My only caveat is where the Database Manager is actually a manager of other people in their team, in which case, if such people are the “do-ers” then as long as the Database Manager knows what is possible, understands the implications, can discuss it at a good level and so on, then even if they can’t do it themselves that may not be so critical.
  • Other technical skills. All the following could come in useful:
    • Excel and Access. For the sole Database Manager who might have to import data, clean data, extract data for mailing houses, review data outside their database, present data differently for managers etc etc, Excel and Access are great tools.
    • SQL. Whilst many packages do not require a Database Manager to have SQL skills, there are increasingly more systems where if they do have SQL skills, it can add an extra dimension to their data extraction/reporting capabilities. And for some systems which don’t have built-in query tools (or weak query tools), it is almost essential.
    • PC/Windows skills, Network-savvy. It’s always useful to for a Database Manager to have at least a fundamental knowledge of Windows and at least the benefits of what a network brings (!) as they will no doubt get involved at some time with installation issues, security rights etc. I wouldn’t expect them to be able to resolve such problems but to understand the implications is a good thing.
    • “Web skills”. As above, most Database Managers wouldn’t be expected to have to program in HTML or JavaScript, but again a solid appreciation of web knowledge, database/web connectivity issues and so on can help.
    • Report Writer skills; e.g. Crystal Reports, SQL Server Reporting Services, Access report writer. Important if your database system uses such packages to create reports and you are expecting the Database Manager to be able to design or upkeep reports.
  • You don’t need a degree in IT. It will give you a good base of understanding but I would never worry about employing anyone because they didn’t have one!

Data Skills

I have separated Data Skills from Technical Skills, but some data skills are no doubt a sub-set of Technical skills.
  • Data Quality. It’s vital that a Database Manager understands and appreciates Data Quality needs and issues and why it is so important: data accuracy and data integrity (and everything that infers), data cleanliness and consistency, up-to-date data and trust in the data; how to encourage and improve data quality, what can be achieved and what can’t be enforced, business issues and requirements, legal implications, financial implications and so on and so on.
  • The specific ability to consider and understand impact and dependency. It is quite a skill when someone can consider and understand what the impact would be if a user asks for a change or addition to a database. How would it impact existing data? Could it affect reports? Would other users find it useful as well? Could it be ambiguous? Are there security issues? And so on. It’s a key thing for a great Database Manager.
  • Data Models/Data Structure. I think it is important that a Database Manager understands the basics of data models and definitely “gets” data structures. For example, they must know why different data types are important and relevant (i.e. free text, look-up tables, currency fields etc) and the difference, relevance and importance of “one to one” and “one to many” data structures, even if they don’t think of them in those terms. i.e. a “one to one” data item is something like a First Name or Date of Birth, where each person only has one of each, whereas a “one to many” are entities such as donations, communication records, hobbies and interests, where each supporter could have multiple such records.
  • Entity Relationship (ER) Diagrams. Going a step further, should a Database Manager understand ER diagrams? Possibly if they are using a database where they will be regularly running SQL queries or if they are going to be involved in designing a system.
  • Data transfer skills. If your Database Manager is going to be involved with transferring data into, and to a slightly lesser extent, out of the database, then having good knowledge of Data Transfer issues can be a real benefit. Not just on a pure technical level but understanding how data files “link together” when importing them, the issues and implications of updating one-to-one and one-to-many fields, auditing, why URNs (Unique Reference Numbers) are so important, data integrity (again!), testing… and more. Larger organisations may have a dedicated resource to do this, but if you just have one person managing your database then they need to understand Data transfer – there’s no easier way to ruin your data than import thousands of records incorrectly!

In Part 2 of this post, I will look at a how a great database manager needs Subject/Business Knowledge, Soft Skills and the X Factor...

(This post is an extract from my free, downloadable eBook, "How to Interview and Employ a Great Database Manager").

No comments: