The Seven Habits of Highly Effective DBA's

I was just reading my usual daily digest from SQLServerCentral and it included an article on an interview with a scary DBA.

Now I've worked in IT long enough to have crossed swords with many a DBA. I even had the pleasure once of firing one, (and whilst no-one wants to see someone out of a job, I really do mean pleasure, what a ******* **** that guy was, and I hope he gets all that's coming to him.)

The interview rambles a bit, a one point asking which historical figures would have made good DBA's (!!!), but Grant Fritchey sums up very well the characteristics of a highly effective DBA. You can read the article here, but I quote Grant below;

The first one that comes to mind is grace under pressure. At some point in your career, you'll have a substantial number of managers, probably going very high up the chain of command, standing inside your cubicle. Typing will be difficult because they'll be jostling your elbows to get close enough to read what you're typing, even though they don't understand a word of it. It's all because, for some reason, one of the most important databases in the company is offline or inaccessible, or in an unknown state. You need to fix it quickly and competently, all the while explaining what you're doing in plain English, no techno-babble allowed, and suggesting ways to prevent the problem, whatever it is, recurring in the future. If you can do all this at the same time with those managers in your cube, then you're on your way to becoming an exceptional DBA.

I think in addition to grace under fire, Grant is also explaining several other traits;
Communication - they key to doing well in IT is to be able to communicate simply to non-IT people. So many people get this wrong, but I would almost put my entire success down to this one skill
Humble - Being a DBA involves power, Sysadmin, sysdba etc. People who get off on power make poor dba's. Senior managers are in your cubicle to get the problem fixed. It's your job, your not the worlds greatest man, your just a man who knows a password and some syntax. Remember that and you'll do well!

Next is a willingness to learn. Picking up the new TSQL syntax is only a small, although important part of that. The larger part is an understanding that things change, and a willingness to adapt as necessary. You might need to learn how to work with an agile development team, or implement a third party software package that requires 'sa' privileges, or move your database out into the cloud. It's a willingness to embrace the change, to learn, not just new processes, but new paradigms that will make you more successful as a DBA.

Flexibility is key. Standards, for example, are a means to an end, not the end in itself. If your standards say that apps cannot have 'sa' priviledges, then your business colleagues buy a product that requires them, then remember that they bought it for a reason. To make money for the company that pays your wages, so find a way of dealing with it!


Finally, I think a good DBA has to have a strong backbone. You need to be able to say no. You need to be able to say that the choice made on this database, if implemented, will cause problems, explain why the problems are going to occur, and offer a more-suitable alternative. You will often be under pressure to accept the solution "as is", but if you simply roll over, you're going to pay the price. It won't just be you though; it'll be your database and possibly your company.
There are certain issues on which a DBA must never compromise. For example, there's a good reason why you should do backups before a major modification of the database, and just because someone within the organization thinks it's a silly waste of time to run one, and doesn't want to wait the extra 45 minutes, tough. It's your charge as a DBA to ensure the integrity and protection of the databases under your control.
If someone asks for something silly, say no. You may have to do it anyway but get out there and make sure people understand why you said no. And it shouldn't just be because you want to be able to say "I told you so." If that's why you're doing it, stop being a DBA. You do it so that maybe, the next time, they'll listen.

SUITABLE ALTERNATIVE!! As one of my best colleagues once said, good design is the result of furious debate. If you don't like something, suggest an alternative THAT WORKS. I couldn't count on both hands the number of times I've wanted to physically hurt DBA's because of their 'veto everything that different' attitude that contributes nothing.

If your a DBA, and people hate you, then perhaps you should try incorporating some of these ways of working into your day. Start adding value to the business, and above all, remember that your just a someone who knows a password and some syntax!