One Piece of Advice For the Aspiring DBA #DBAJumpStart

Unicorn DBA Advice

When you are an aspiring DBA, there are many things that come with that job role that you’ll have to consider as part of the job.  You will need to look at disaster recovery, high availability, platform performance, security and a variety of other areas that are critical to the keeping the platform up and running.  As you look into all of these different areas, they are tied closely with the tasks you are assigned with whatever environment you work in.  In some cases you’ll need to know more or less in area or another depending completely on the environment.

Given the variety of tasks and the skills needed for DBAs is there a single piece of advice that can be given to all DBAs that has the same value to all DBAs?  Yes, there is.  That piece of advice is to track what you work on with daily status reports.

Daily status reports are a list of the activities that you accomplish for each day.  These accomplishments are just the work that you did in a day’s work and some details about that work.  For instances, your accomplishments could be the following:

  • Resolved corruption on production database.  Issue was tied to storage drivers.  Infrastructure team will deploy fix this evening with emergency patch.
  • Provided performance tuning assistance to development team.  Explained and demonstrated impact of implicit conversions on database performance.
  • Reviewed white paper on in-memory OLTP.  Technology may provide assistance with current tier 1 application INSERT bottlenecks.
  • Meeting with business team to re-design reporting platform.  Conversations were focused on style of report headers, no need to include me in discussion.  Required meeting / 4 hours.

This list easily provides a list of what was accomplished in the day, but also provides a lot more.  Consider the corruption issue, if this shows up on another server or continues to happen after the planned patch, then you have a history of that item to review and consider.  With implicit conversions, if this has been an ongoing performance issue, you’ve shown value in not just fixing performance in production but also in preventing a reoccurrence.  Also, by showing the impact of certain technologies, you can show justification to read white papers and use time during the business day to expand what you know about SQL Server.  Lastly, including information on meetings attended can help provide a track record of useless meetings that are eating your time and help your manager get you out of those meetings.

The other thing that daily status report should include are tasks that you plan to work on in the following day or week and roadblocks that are preventing work from being accomplished.  Forward looking tasks are critical to being productive.  If you don’t know what you will need to work on tomorrow, then tomorrow, you will start the day trying to figure out what that list of tasks should be.  It is much better to write that list at the end of the day while you are still thinking about what did not get accomplished on that day.  Starting the day without a task list too easily allows the morning to slip by without getting anything accomplished.

Likewise, if you don’t lay out what your roadblocks are, when they come up, and communicate them, then your lack of progress on a project looks to be an issue with your ability to do work.  In a recent project, I had a due date that was months in the future.  Provided that a couple of tasks for others was done on time, there would be plenty of time to complete the delivery and finish the project ahead of schedule.  Unfortunately, roadblocks from others became an issue early on and continued until well past the delivery date.  Continuously reporting on those roadblocks is the only thing that saved me from getting the brunt of the complaints when the project didn’t deliver as expected.

When considering reporting on roadblocks, it may sometimes appear that they are just being done to cover your own self in the event of failures.  In this case, that is exactly what is going on.  It is critical to the success of any DBA to be able to clearly identify why something can’t be done.  Because your most important project may not be important to the person you are depending on.  Reporting on roadblocks helps your manager manage the roadblocks and reach out to reprioritize either your project or the task that you are relying on.  Your success depends on how you complete the tasks that you have the ability to complete.

While it seems there’s a lot that goes into a daily status report, there effort really doesn’t need to take more than 5 minutes a day.  Just jot down what you’ve done, what you plan to do, and what you can’t do in an e-mail and shoot it off to your manager.  Your manager may not read the status reports every day, but when it matters and when the information is needed, both you and your manager will appreciate that you do this.

There is, of course, one other time when all of this information is useful that hasn’t been discussed yet.  That is during performance reviews.  We all have to go through these and one of the hardest parts is looking back a year and figuring out what we worked on and accomplished.  If you have a year’s worth of status reports this becomes a fairly easy task.  In fact, it should be easy to lay out exactly the value that was provided over the course of a year and provide the basis for your negotiations on salary and benefits for the upcoming year.

Now having discussed daily status reports up to this point, you may be wondering that these really have nothing to do with SQL Server or with things typically associated with being a Database Administrator.  That is indeed correct, because this skill is much bigger than that.  The skills required to be a DBA are generally fairly easy to learn.  Often in any position, you’ll get a list of the tasks that are a priority – when to perform backups, indexing, or performance tuning.  What you won’t always get is the mandate to deliver a status report.  Whether you are a database administrator today or a solutions architect in the future, this one skill, and advice, will transcend your career.

To conclude, the most important skill you can learn and the advice that I’ll give any DBA, or any other type of professional, is to learn to provide daily status reports.  They’ll be your insurance when things go wrong and your praise when things are going right.  They’ll help prevent listless Monday mornings while you figure out what to do and help when you need to renegotiate the priority of your roadblocked tasks.  Overall, they’ll provide the basis for your career success.

This post is part of the SQL Community Project #DBAJumpStart by John Sansom (Blog | @JohnSansom).  John asked 20 successful and experienced SQL Server professionals one question:

“If you could give a DBA just one piece of advice, what would it be?”

My answer to this question was above, you can find all our answers together inside DBA JumpStart, a unique collection of inspiring content just for SQL Server DBAs. Be sure to get your free copy of DBA JumpStart.

2 thoughts on “One Piece of Advice For the Aspiring DBA #DBAJumpStart

  1. Writing down your daily accomplishments does more than just this. It also helps you update your resume down the line, and build some talking points for interviews 😀

    But I keep a personal log for protection. I have been put in situations where management has asked why I’m doing so little when I’m actually working full-tilt on ad-hoc work provided by the rest of the organization. It is only when I’ve pulled out the log to show I’ve literally completed 100 individual requests that week which has saved my bacon, and shifted the onus for lack of prioritization and involvement back onto the inattentive managers where it belongs.

    As for what realsqlguy said about micromanaging, the key for me is not to put times against the tasks. I feel that time tracking of full-time workers (even by the hour) is too invasive and reticent of being treated like a teenage burger-flipper rather than a database professional with a decade of experience.

    I prefer to leave them out as Jason suggests, or to use a non-committal fuzzy approach of labeling each task short, medium or long; approximating not how just much time something took but how taxing it was.

    For example a “short” data import might be one command that takes a few hours to process, but it becomes “long” when it mysteriously failed and you spent 7 hours of the day tracing and fixing the error. To me that summarizes what you did and also gives management enough information to focus on repetitive processes that perform poorly, but without making me justify the last hour of the day was wasted because I was wiped out and too unstable with debug rage, that it was better to defer further work to the morning.

    That might sound like laziness to some managers, but I find that most high-tier professionals know what I’m talking about. Sometimes the creativity sponge gets squeezed out. It happens.


  2. This is something I’m trying to implement in my team right now, with mixed results. Some are on board, others are resisting, viewing it as me “micromanaging”. I’m sharing this article with them all so that they can see some of the benefits that you’ve spelled out.


Comments are closed.