Open Box DBA

There are some (maybe “alot”) of perceptions that DBA’s work in a silo, or a black box. There are a lot of folks that don’t really know what exactly we do, well, until something goes wrong that is.   Then, all of a sudden, we suddenly have the spotlight on us, and a big red X in our back.  But when we work hard to be proactive and make everything “just work” (that is really possible, you know) somehow others question what we really do on daily basis.  Yes, it is true, you have done your work, the systems will alert you before the customers call and things are so quiet, that the people around you can’t help but wonder, what does that DBA do?  Careful, because when that happens it isn’t far from: hey our numbers are down and we need to make some cuts.  That DBA, they don’t really do a lot, maybe we can afford to let them go…  it is true, it can happen just because you not only do your job, you do your job well. Well, only if you forget how to show your real value; the bonus they got when they hired you and might not have even known it.

Here are a few tips to make yourself, your team, more visible to others:

1.  Make an effort to know your customers and educate them about what you do.  Keep in mind, your customers may be more diverse than you realize at first.

Some of your obvious customers:  The folks that develop and/or install applications that use SQL servers; people that use (users) the applications that the developers have made that use SQL servers; and the members of the group that administer the core systems your SQL server runs on, including network and storage.

Some not so obvious or customer “joins”:  Your peers, your boss, your bosses boss, and anyone that knows someone/anyone in a category above that may also know your peers/boss/bosses boss.

Here’s one example.  If your DB team is involved in code reviews for the developer teams before production changes are made, especially if you have a go/no go influence, when you are sending your feedback, don’t just say – “this code is bad; go rewrite this.”  Instead, help your customer understand why you’re pushing back by making an effort to help educate them on your decision.   I know, they are developers, they are supposed to know how to write a good code but hey, they are probably under a deadline, just need to make something work, and had no idea the global impact of their individual change.  Given infinite resources and time, they could probably have written it better.  But just like you, they don’t have that luxury.  Instead, you have the opportunity to train and coach your developers by sharing your knowledge and experience.  Partner with them, the effort you make here will go a long way to show your value and as a bonus, the next time the developer is working on a similar project, they will already come to you with code you know is pretty good because you coached them. How you communicate your feedback to them and make your points also equally important.  You should not be afraid to share with them your sources including sending them a blog post or including an example on how to write said query/code.   If you give them enough information to take action on and learn from without boiling the ocean by telling them to go read a book, they will see you as a huge value as opposed to being pain-in-the-you-know-what DBA who like to just criticize their work.  Time you invest in your developers here will reward you in the future and paint you as a positive DBA.  Don’t be surprised if you try this and they first are suspicious (to cover for their shock) and then transition to acceptance and finally will start coming to you for advice.  Talk about value!

2.  Automate your repeatable processes.  Document and publish them in the place that others can access easily.

Ok, automating the repeatable processes is pretty straightforward (right?)  But once you have automated it, document it.  First so you don’t have to reinvent it when it comes up again, but as equally important, to share with others.  If you document something that your going to share with others, you will probably do it a little different (better?) than you would if your were writing notes to yourself.  And since your writing this to benefit someone else, it makes sense to put it someplace where your audience can find it.  That blog your so proud of probably is easily findable and that is a good thing, right?

Here is one example.  Say you have QA or Development environments that need data from your production environment.   You probably hear this quite often, especially if a new project is spooling up or reaching a milestone (hint, hint) ‘can you refresh my environment with prod data please?’ Because this was happening a lot, you had taken the time to exercise your crafty PowerShell or T-SQL magic and built a script that you could do this for you.  You tweaked it, tuned it, and were actually impressed by your own ability to make it work really well.  Every chance you got for a performance improvement or more automation, you took it.

Heck, it was your baby and you probably bragged about it in-between SQL Saturday sessions about how you made the thing scrub production data so only test data was transferred, the logins we synchronized and mapped to the appropriate test accounts, there was error checking and alerting built in if anything went awry.  Wow, you even realized that by running this auto-magic process, you were validating and testing you production backup, copy, restore process all while supporting the QA or Developer teams.  On the surface, your customer loves you because they have fresh data to test for every iteration they may ever need, on demand, when they need it. Maybe they can even do it themselves with the push of a button and you just get the report and put a check mark in your SarBox list that back-ups have been tested. You lean back in your chair, with a satisfied look on your face, knowing that you really are that good.

Hey, hey, before you put your feet up on the desk and wait for you nomination to the IT choice awards, your not done yet.  Why?  Because only YOU know what you did and how good it really is, no matter how many bragging sidebars you win at PASS, your not helping yourself unless your customers know what you did.  Before your feet approach the top of your desk, take the time to document what you did with the intention of showing people, who may not be as good as you, what it takes.  Your scripts and paths to them are good things, but they are not the only things.  Some of the folks that benefit from your work and what you did to make it happen are more inclined to understand a flow chart or diagram of your processes.  English may be widely spoken, but pictures still are more universally accepted and understood.  Simple flowcharts are an amazing communications mechanism to help other understand what it is that you really built for them and how it works.  Show of, but don’t became too enamored by your own work, let someone else do that for you.  Keep in mind that you should publish them on the place that your customer can access, like your team SharePoint page (if you have any), or just a simple document that you distribute that among your team and your customers.  Be open to going through it and ideas, comment, and even criticism, from those that view it.   In the end, the learning you gain and the doors that it opens will help ensure your known for not just building the button, but remembered for being open to and helping everyone understand what the button “is”.  Helping your customers know what you do is a good thing.

3.  Quarterly Report, before and after.

Before you are all thinking that I’m going bananas on you, please hear me out.   We DBA’s love performance tuning.   We like to keep making things perform better and faster, and if your shop is one of the shops that have a short iteration deployment cycle like, say, every two weeks – things are changing constantly.  This means, new code is introduced quite often and, if your data also changes a lot, you will have a never-ending performance-tuning task on your hands.   It’s fun and exciting but how do we make others see the difference?   Those 300,000 reads that now changed to 90 reads – how is that translate to the upper management?  They won’t see it the way you do, and this is why it’s important for you to do some sort of quarterly report.   Every beginning of quarter, capture a baseline of your database performance.   Erin Stellato (Blog | Twitter) has excellent resources and a strategy for how to use them here.  If you don’t have third party tools to build repository for you, I suggest you follow her suggestion and invest in building your own.   Then at the end of the next quarter, capture another baseline and so you have something to it compare with.  Bam!  You show improvement, well that is the goal, and even if you show the opposite, that can trigger actions for the next quarter with justification.  Oh, and maybe a review of the change management process, but that is a different story.  Oh, and some may think that creating a fancy graph is a waste of time, I would highly encourage you to spend to the time to learn how to turn your columns of data into a “fancy graph or pie chart.”  Why?  Take a look at an executives schedule in Outlook this week.  Do you see a lot of time open in there?  Probably not, it is far easier to quickly grasp what a graph or pie chart is trying to convey than it is to run through a laundry list of numbers and listen to you verbally explain what it means.  Again, the time you take to put a little extra effort in it will pay off.

Speak your customer’s language and you will not just be heard, you will be understood.  Speak techno gibberish to the wrong group, and you might as well offer to configure your execs VCR (iPad) while you’re at it.  It is an investment in yourself; just like reading this blog is an investment of your time in an effort to improve.  I hope that my sharing was worth your investment.

Make yourself, your team, visible; it will reward itself back to you, your career, and your customers