MVP Series: 7 Ways to Lose Your DBA Job

We are thrilled to have special guest authors from the Canadian MVP Award Program contributing posts . For the next few weeks, we will be posting a different article from one of our Canadian SQL Server MVPs each week. We hope you enjoy them, please feel free to leave a comment. Thanks to Karen Lopez for this week's article!

I typically write how-to and tips posts, not posts on how to do something wrong. But anti-patterns are just as important to study as best practices. As a project manager and architect, I get to see first-hand all the ways that data professionals choose to attack problems and live with the challenges of too little time and too much to do. In this post, I'm going to share with you the types of behaviours I've seen that will likely get you fired if you try them.

  1. Installing unlicensed or unofficial copies of software. Yes, I know you think you are saving your company time and money. Yes, BitTorrent seems so full of shiny new software. And that nifty script to downloaded off some guy's blog? It may or may not be licensed for use in your environment. Or the guy might change or add a licence later. You just don't know. These "free" things might sound cheap, but they aren't saving your company risk. You've hear of ROI? Not only does it stand for Return on Investment, it also stands for Risk of Incarceration. Keeping your boss and your CIO out of jail is also on your performance plan, even if you don't see it written down there.
  2. Use Sticky Note Security. You think you are being smart by posting the SA password on your monitor with some misleading notes like "Remember to Call Mom" (you really should call your mother, by the way) and some random letters and number underneath. We all know your trick. Oh, and hiding it under your keyboard doesn't work, either. Sticky note security isn't security at all.
  3. Being a Data Snoop. Yes, it sure would be fun to know what that celebrity did while they were visiting your hospital. Certainly it might be good to know what your co-workers are making or how many mortgages they have on their home. But querying data just because you want to know something about someone else is wrong. And in some industries and jurisdictions, it's illegal. Yes, ROI applies to you as well. You've been granted access to all the data to do your job. Abusing that trust is a ticket out the door.
  4. Failing at Restores. Yes, you know that backups are important. But RESTOREs are even more important. In fact, few people care if you do any backups at all. They just want you to get their data back. Sure, you need backups to do that, but if you've never verified that your backups work, you are likely going to fail at restores. You need to regularly, automatically test restores. Because you certainly don't want to find out that your tape backups are perfect, then sent to be destroyed one day later (true story) when your database is down.
  5. Not Answering the Phone. One of the problem with all the advances in technology we've seen over the years is higher availability of systems. But along with that comes higher expectations for DBA on-call availability. Sure, life happens and you sometimes can't answer right away, but if you consistently fail to respond to on-call requests, you aren't meeting expectations. We have SLAs to meet. Your own professional service level agreement is to be there when you are scheduled to be there. If you are moonlighting (working for someone else in the evenings) or in a band or just feel like sleeping, you aren't a good fit for being a production DBA. You should consider a career change to Data Architect. We are rarely on call and we love data.
  6. Oversharing Production Data. Yes, you know the data needs to be secure from outside viewing. But when that developer comes to you and says she needs an extract of the database to send to the developers thousands of miles away to help them debug a nasty issue with their code, just say "no" unless there is a process that protect the data appropriately. Or when the nice clerk in HR asks you for a list of all the customer data so that he can do a customer satisfaction survey, you should ask a lot of questions. Because he really just wants to sell it on the internet to help repay his gambling debts (true story). Internal employees need access to data all the time, and there should be a process for providing that. Extracting data removes the data from all that security. And likely your paycheck.
  7. Being an Expert Over Being a Team Player. Yes, you can get away for a while being the Awesome SQL Server expert for a while. But if your attitude comes at the expense of team function, you are being a negative force on productivity. If you wander the halls and your blog, ranting about how the stupidity of your co-workers burns so bad, you are being that guy that no one trusts. If you call all your female team members "missy" (true story) or you stand loudly proclaiming the ineptitude of your other DBAs, you are likely not going to be part of the team for much longer. You don't have to be friends with your team mates. You don't even have to like them. But you do have to be part of that team.


We had enough pain finding a great DBA like you. We want you to stick around and be part of the team. Plus you'll look terrible in orange prison garb. Keep your ROI high (the right meaning of that term) and keep on loving your data.


 Karen Lopez has more than twenty years of experience helping large organizations manage large, multi-project information technology programs. She's a project manager and data architect, specializing in being practical and getting stuff done over allegiances to methodologies or check lists.Most of her work has been on turnaround projects: helping teams get back to the original goals quickly, but not sacrificing security, reliability or flexibility. Karen loves her work and enjoys networking with others who have experiences to share.Karen is also available as a spokesperson for Information Technology issues. Specialties: Project Management, Information Management, IT Methods and Methodologies, Information Privacy, ARTS Data Model, Data Modeling, Process Modeling. Industries; Retail, Energy, Health, Government, Defense.