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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Comments
- Anonymous
January 01, 2003
I'm pretty sure I've been accused of running off the DBA before. Usually because we had to remove their access from production for some reason or the other. Management still considered that "normal". - Anonymous
January 01, 2003
Excellent list. I'm certain people get by with #3 all the time. I've seen that included in employee agreements before, yet no systems in place to actually detect/enforce it. ...and if one is copying Production data straight back to non-production systems (also a bad idea), then there's all kinds of places to snoop.
Maybe that's a corresponding item: Not sufficiently protecting your company's data. - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
A production DBA, that is. I thought you'd like that one. Do you have other examples of things DBAs do and get fired? - Anonymous
January 01, 2003
The comment has been removed - Anonymous
January 01, 2003
#7 is my favorite, I wish more people were fired for that. Great post, it is unfortunate that so many of us have lived through those scenarios. - Anonymous
January 01, 2003
Great post! I especially like the part about not being able to recover. I always point out that DBAs earn their money through performance tuning, but they keep their jobs through recovery. If you can't recover, you can't be a DBA. - Anonymous
January 01, 2003
Ouch. That's tough. I think it's find (encouraged, even) to ask others for help, as long as one isn't divulging info they should not be. But at that rate, it would be better just to have someone else do the work. - Anonymous
January 30, 2015
Great post! I especially like the part about not being able to recover. I always point out that DBAs earn their money through performance tuning, but they keep their jobs through recovery. If you can't recover, you can't be a DBA. - Anonymous
January 30, 2015
There was a 'DBA' contracted to a local public works department who got her job by spouting buzzwords to the uneducated. She got the job, then proceeded to run up a $2000+ phone bill in a month to ask someone in Oregon (who knew no more than she did) how to do things. Between the phone bill and tasks left for others to finish she was walked out the door. - Anonymous
January 30, 2015
The comment has been removed - Anonymous
January 30, 2015
Great post. Don't forget the DBA who tunes himself into a problem. You know, reads a blog post, becomes and expert, and starts tweaking on a perfectly good system. That's always a good one. Lots of objects prefaced with DBTA_ - Anonymous
January 30, 2015
These should all be common sense. Its unfortunate that they are so common. - Anonymous
February 01, 2015
I love this post. My particular favorite in this list is the sticky note syndrome. As a consultant, I get to walk into all sorts of companies and often get assigned to a desk that belongs to someone on vacation. I'm shocked how many times I see sticky notes displaying the keys to multiple kingdoms. Such a simple thing to fix.