Today we have a guest editorial from Andy Warren as Steve is away.

Many if not most of you probably already have a good idea of what a DBA (database administrator) does, but it’s easy to forget that not everyone does. I’ve recently joined a new team and during the first few weeks of getting to know everyone a developer stopped to chat for a moment and he asked that question; what does a DBA do?

You might be thinking something along the lines of how can a developer not know what a DBA does?

I’m guessing there are two reasons; they’ve never worked on a team that had a DBA or they’ve never interacted with a DBA. The former is common in startups and small companies, the latter in big(ger) companies that are silo’d and walled off so that devs are separated from the production/operations team. There might be a third – they want to see how you see your role, are you going to be teacher or tyrant?

But putting that aside, how do you answer the question? It’s the elevator pitch challenge.

Answering “it depends” is accurate, but hardly useful. Answering “I manage SQL Server” is more specific, but not much more useful. Those of us who do it for a living know that it varies by company. Sometimes we’re pure administrators, sometimes we consult with the development teams, sometimes we’re on the development team, sometimes we’re design and coding, and often we’re hired as part insurance, part fireman to resolve and prevent database issues. We’re often stuck being the ones that have say no to requests based on security, performance, and even coding approach. It can be an interesting role and a boring one, one that sometimes adds value and one that is often relegated to care taker status.

The key is calibrating the answer to the asker. Explaining what I do to my Mom is different than explaining it to my new colleague. It seems like the answer should be reflected in the job description, but I think those are often focused externally at candidates more than describing how the role interacts with teams internally. In this particular case I’m the “first DBA” and they have only the outline of what they hope I add and how I’ll add it.

In hindsight I didn’t answer the question as cleanly as I might have.  What should I have told my new colleague that he would find useful?  I’ve been thinking something like “I am the subject matter expert for SQL Server, responsible for uptime and performance, and for reviewing data access code as far as security, performance, and best practices”.

I’m curious if you’ve found an answer to question that is useful, and ideally succinct, an answer that informs and opens the door to future collaboration? I hope you’ll post your answer (specific to your current role is fine) and we’ll see where the discussion goes!