The Importance of Properly Documenting Job Responsibilities and Expectations

I recently received an email asking whether I had a formal listing of roles and responsibilities for what a DBA does in a larger data center. (In the end the person asking for this information was really just looking for a general overview—but I somehow assumed they were looking for specifics.)

Below is a slightly modified version of the email response I provided—where I’ve added in some ‘section headings’ to make this a bit more readable and to call out some key concepts or concerns that anyone working in IT or with databases should keep in mind:

I don’t have anything like that—simply because the roles and responsibilities for a DBA will vary from one company to another (i.e., are you in charge of the hardware on your SQL Server or are the Windows Sys-Admins? ) and even from one department to another (if you’re a ‘dev DBA’ and not a production DBA then your permissions, roles, and responsibilities will be vastly different). For example, take a look at the job description that I, and my managers, defined for my job role at Coldwater Creek—where I my specific job involved being BOTH a production DBA and a senior web developer:
http://www.sqlserveraudits.com/experience/job-descriptions/

That, of course, is just a job description—so it’s not even as concise and detailed as it needs to be. But it does show that ‘requirements’ and roles and specifics can and DO change from one organization to the next and even from one person to the next. (Prior to the creation of this ‘role’ for me such a job description had NEVER existed at Coldwater Creek – and I don’t believe that it did after I left either.)

The Importance of Clearly Delineating your Job Description and Responsibilities

That said, you are, however, 100% on the right path in looking to DOCUMENT these details for yourself.

If you don’t have something like this documented and have been handed ‘control’ (or more importantly: responsibility) of specific servers and their security, availability, and up-time, then you WILL want to work with management (your supervisor) to document these specifics in full detail.

Otherwise, you risk being accountable (in the eyes of management) for something you patently didn’t know was your responsibility. Likewise, a key part of clearly defining your responsibilities is the need to try and not just delimit, or list, things you’re responsible but to also try and quantify as much as possible. In other words, if management tells you that you’re responsible to keep Server XYZ up during business hours (or all the time), that’s fine and well—but also impossible. As such, you’ll need to quantify what kinds of down-time are acceptable—and how much data loss is acceptable. And, if those windows of down-time and loss are too small for the hardware and solutions you’ve got in place, then you need to work with management to either ‘budge’ on those expectations or give you the hardware, software/licenses, and training/guidance that you NEED to meet their expectations. Which, in turn, is really the basis of RPOs, RTOs, and how SLAs are born – which I spoke about here:
http://sqlmag.com/blog/sql-server-recovery-time-objectives-and-recovery-point-objectives

So, in short: do keep working on getting this information detailed—concretely. Just be aware that specifics FULLY depend upon your position and the needs of your organization—and then ‘customize’ and quantify as needed.

Regards,

--Mike