Database Administration as a Service

A DBA should provide two things, a service and leadership. For Grant Fritchey, it was whilst serving a role in the Scouts of America that he had his epiphany. Creative chaos and energy, if tactfully harnessed and directed, led to effective ways to perform team-based tasks. Then he wondered why these skills couldn't be applied to the workplace. Are we DBAs doing it wrong in the way we interact with our co-workers?

Database Administrators are, by our nature and the requirements of our job, control-oriented. We are like commissars in that we must maintain and enforce security mechanisms on the data from a business and regulatory standpoint. We prepare for disaster, outages and deletions of the information that defines and supports the businesses that pay us. We get up at 2:30AM on a Sunday to put out figurative, or even literal, fires. All of this reinforces that controlling nature and leads to us to become, for want of a better term, jerks. This is a problem for the DBA profession. We need to stop. I think that we, as DBAs, can be better by embracing the ideas of “leadership through service”.

Why DBAs Become Control Freaks

As DBAs, we want to have as clean a production environment as possible. We want to know, as far as we can, exactly what is going into it, and when, so that we can manage backups, disaster recovery, downtime and all the rest. We want these things, in fact, we’re required to provide these things on production, so when we look over our shoulder at what is coming towards us from development, we instinctively cringe. This is the moment where the control over development starts, in order to tame the beast, and it’s at this moment that we’ve gone wrong.

Our responsibilities as DBAs require us to set some direction on how to manage information within our databases and the organization. The organization has tasked us with those responsibilities, but they didn’t tell us to become little martinet’s, jealously guarding our territory, privileges and access. They didn’t require us to force developers to become supplicants who must kowtow in order to get the database they need to start developing. No. The business expects us to provide a service, and deliver it like any other well-run service.

Some time ago, I called up my cable company to arrange a new installation. They gave me a day, two weeks out, and a time, sometime between the hours of 7AM and 1PM (there goes half a day). I waited on the appointed morning, only for them to show up at 4PM (the rest of the day wasted), only, oops, they didn’t have all the parts they needed for they install, so said they’d need to come back the next day…sometime between the hours of 7AM and 1PM.

Great service, right? No. Well, if you make the development team jump through hoops in order to get a new database into development, implement continuous integration, try out an Object Relational Mapping tool, or experiment with a new development paradigm, then you’re making them feel like they’re working with the cable company. As soon as a viable alternative to cable presented itself, I jumped at it. When your developers find a viable alternative to working through you, even if it’s not actually viable, what do you think will happen?

Instead of barking at the developers the next time they come up with a hair-brained scheme to only ever do inserts and deletes in order to avoid waits caused by updates (and yeah, I had this discussion with a development team), we need to try working with them, and we need to start working towards leadership through service.

Leadership through Service

Leadership skills aren’t part of the average DBA’s training. My first insight of the way to learn, and teach, these skills came from my long-time role in Scouting. The Scouts of America do a great job of turning out leaders. You can do your own searches on the internet to find the number of presidents or astronauts or other business leaders that were either Eagle Scouts, or were just involved with the Scouts for some period. Scouting teaches, among many other things, the concept of leadership through service.

A campout with the Scouts looks chaotic, with people running in circles shouting, gathering sticks for fires, some tents getting set up, and so on. You soon start to realize, however, that despite the apparent pandemonium, there is progress, and organization. Look harder and you start to see how it’s happening. On the side, experienced scouts are talking new scouts, scout masters are talking to scouts, pointing out what has to happen, suggesting how something should get done, stepping in to do things where absolutely necessary, teaching and then walking away, where possible. It’s leadership through service.

The concept is not to have someone standing tall and barking out commands. Believe me, it would be so much easier for me to walk out into a campsite, point at each scout, assign a task, and ensure each one does it exactly as I would do it, but then they’re not doing it themselves, and more importantly, they’re not learning to lead.

No, instead, the unit leaders, scouts and adults, are quietly getting things done that need to get done in order to support the young men and women (look up Venturing, women are in Scouting too) in their efforts to become better people and the leaders of tomorrow.

That chaotic period in the Scouts is creative chaos, it is group thought. You’d kill it stone dead by clumsy intervention. Instead, the leaders harness the creative energy gradually, and use their influence to give it focus and purpose. The same is true of our professional lives. Development should be chaotic. Production shouldn’t be. I like to describe it by analogy. Production is an old Eastern city, like Boston. It’s sedate, stodgy, boring, but safe and relatively controlled. Development is a cow town in the Old West on a Saturday night after payday at the end of a long cattle drive. It’s nothing short of absolute insanity. Each of these environments is exactly as it should be.

Our job is to take what Dodge City produces and gentrify it to the point that we can let it loose in Boston without causing mass chaos. The very best way we can do this is not to try to make Dodge City into Boston. It won’t work. Instead, we need to reach out and offer ourselves as a service, even as servants, to make Dodge City work as much like Dodge City as we possibly can. Our service should be to enable the developers to be developers, to develop.

Leadership through service teaches us that we can best set direction if we best serve, best help, best provide an environment through which people can get what they need, but do it within a paradigm that also moves in a good direction. In short, DBAs can act as a roadblock or as a pathway. I’m here to tell you that acting as a pathway will absolutely give you more control over what goes into your production system than acting as a roadblock.


Here are my suggestions for how to get this done:

  • Define a process
  • Work backwards from production
  • Integrate tightly with development team
  • Automate as much as possible

You’ll need to have a process to get code from development to production, but you don’t want to control development. You just want to control production. So, work backwards from there. Figure out what you need in order to establish a safe production environment that will support the business, then layout a pathway and a process that enables the developers to get there. Provide this as a service for them.

This means talking to them, getting to know their development paradigm and supporting it. Be a service. Be a servant. Never be a roadblock. Help them get things done, but always keeping in sight your end goal of a safe production landing. To make this work, automate everything you can. The more manual your processes, the more pain you’re going to feel.

A word of caution, though, and a bit of a brush back for any developers who are rubbing their hands thinking, “Oh boy, the DBA has to do anything I say.” Nothing I’ve suggested here should changes the fact that the DBA’s job is to keep the production environment online and secure. Yes, we want to provide a service, but we need to provide leadership as well. Combining the two is the important point. So when developers have that crazy idea, support it, but guide it. Find out why they want to do it. Is it a good idea? Do you have viable alternatives? Is there a better way? Working with them and help guide their efforts, where necessary, without setting the absolute direction, or doggedly imposing your own ideas.

I understand that some organizations just won’t be able to adapt this approach. Organizations where, for example, developers have been ill-treated for so long that they have completely bypassed the DBA team in every regard; IT departments where management won’t support tighter coupling between DBAs and developers; places where DBAs just can’t surrender any level of control. Just because this is difficult doesn’t mean it’s wrong. In fact, as with many things, the more difficult approach is the right approach. Doing things the way we’ve always done them may be easy, but it doesn’t mean it’s right.


To make this happen, you’re going to have to bring some different tools to the job. No, I don’t mean PowerShell, and this isn’t a long softball sales pitch either. I’m talking internal tools, those soft skills of the world of work, namely people skills, leadership skills, communication.

After years of been treated like mushrooms, kept in the dark and fed, well, you know what, DBAs let that aspect of their workplace skills slide. Funnily enough, this isolation was often a positive choice by the DBA. I know that I was frequently happiest when I was invisible. I remember reading an article, a long time ago, suggesting that the best DBA was the one that no one in the company knew because everything “just worked”. Those days are gone. In fact, those days are part of the problem.

As DBAs, we need to engage. We need to talk to the business in order to understand their needs, so we know what services we need to provide. We can’t even set up a simple backup scheme without first understanding the recovery time objectives and recovery point objectives. We can’t even meet those requirements without communicating to the business some level of the technology that might be required to meet those times, if they’re seriously difficult. That’s a heck of a lot of talking to the business.

We need to talk to the developers for the same reasons. We need to understand their development paradigm, negotiate deployment windows and all the rest. Then, of course, we have system administrators and SAN administrators. All these people need to know who you are and what you look like. Communication is as much part of your job as knowing the difference between a clustered index and a non-clustered index.

One of the great rewards of being a scout leader, for me, is to see someone who lacks natural communication skills suddenly “get it”, and start to find a way to influence the decision process. In the same way, DBAs can learn the subtle arts of group work within an organization, as long as we get out of the cubicle and actually communicate with people, in a clear and useful way. Laughing at a database design and calling it stupid does not help make it better (trust me on this; it’s one of my big mistakes). We also have to write up requirements documents, process flow-control documents, emails, again, with clarity.

If you’re one of those DBAs who has grown to like being in a dank cubicle in the basement, this is not going to be easy. Your skills at influencing others in the workplace may be rusty, but the one constant in our universe is change, so you may as well embrace it and manage it or it’s going to manage you. Just remember that these changes are going to be iterative. You’re going to have to adjust as you gain understanding of what your organization needs.

Call to Action

As a DBA, you’re providing two things, a service and leadership. Start working on your soft skills. Provide a good service. Be a good servant. The leadership will flow naturally from this as you demonstrate your interest in being a pathway, not a roadblock.

Now is the time. Get up out of your cube. Walk down to the development team. Immediately say yes to something they need, get it set up for them, and start to build that pathway. Then you can come back and tell me what an idiot I am, in the comments.

Tags: , ,


  • Rate
    [Total: 0    Average: 0/5]
  • Atradius

    Finally a human article about DBAs …
    Very well said – as a DBA one can easily feel like a robot and becoming as robotic as a computer – it is great to see an article like this which reminds us we are alive after all …

  • wildtroutfisher

    Back to Gilwell
    It’s nice to see how Wood Badge concepts can be related to all aspects of life – despite all of the negative media attention regarding Scouting. It is still the best program for teaching our youth to be leaders and giving them the tools and confidence to be effective leaders. Great article!

  • paschott

    Good reminder
    I’m blessed to work with a DBA who embraced these philosophies for some time. In part, it made his job easier as he talked through reasons why certain things could/should be done. However, he also worked to empower users and developers as much as reasonably possible. That meant that much less problematic code went to production and there was a lot more attention paid to how the code written would affect the production servers.

    I appreciate the attention to the human side of the DBA job. It’s a good reminder to all that we don’t work in a completely isolated world.


    One Team
    This was an excellent articles. DBAs work as part of a team. Of course their top priority should be to protect production, but in development they should be working with developers on exploring a wide array of options for improvements.

  • puzsol

    More please
    As a young developer my favourite systems administrator was the guy who gave me administrative permissions on my own computer so I could do things like install gvim and modify security settings in IE. That is he removed an unnecessary roadblock to getting my job done.

    At the same time, my least favourite people were the DBA’s… that mysterious group that we never saw, and when we asked for something like an extra column on a table just got a flat "no" response. No understanding, no suggestions of alternatives, and don’t even think of adding a function or a stored procedure to the mix. So we found ways around it, horrible messy slow ways… I didn’t expand my understanding of the true power of databases, or appropriate places for getting things done… in my mind the DBA WAS the road block, and databases just a pain (why not just use a flat file?)… It’s taken years to come to love SQL and embrace it for all it can do.

    So please, if you are a DBA, listen to this article. Be the servant leader, especially to those young naive developers… the system your database supports will perform better if you do.

  • Anonymous

    No Skills and Training Tips?
    Leadership is the easy bit. Powershell is the hard bit. Why did I read this?

  • Anonymous

    Great Article
    Nicely done Grant. Easily one of the best articles I’ve read in a long time.

  • Grant Fritchey

    re: Back to Gilwell
    And how did you know I went through Wood Badge?

    But yeah, that training was worth every penny. Plus, going back and working as staff really reinforced the lessons in a major way.


  • Grant Fritchey

    re: Good Reminder
    I wish I could say I’ve always worked this way, but I’d be lying. It is a mechanism that I’ve been trying hard to apply and it’s one that I think can serve people well. I mainly wrote this up in response to a request after the SQL in the City:London event. I talk about a lot of this stuff in one of my presentations and one of the attendees said I needed an article to get the word out to more people. Here you go!

  • Grant Fritchey

    re: No Skills and Training Tips
    Sorry it wasn’t to your liking. A lot of people do find leadership hard, even harder than PowerShell.

  • martin.harrison0

    Great Thought Provoking Article
    Great article Grant. It got me thinking.
    I strongly believe that effective DBAs have to have many of the same traits required of project managers. I have been developer, project manager and I’m now a busy corporate DBA. A project manager has to influence and control without direct power, has to circumnavigate roadblocks with interpersonal skills and organizational experience. DBAs interface with many teams, System Administrators, SAN Administrators, multiple Development teams, Customer Services when issues need explanations, Change Control teams, Security and Compliance Teams, System Architects and Tiered Support for troubleshooting. When you start to jot it all down it soon becomes clear why inter-personal skills are the key to getting things done and a big part of being a great DBA.

    The way to build a positive reputation and thereby gain influence through respect is not strong arming these teams into submission but patient dialogue behind the scenes, out of the limelight, explaining the reasons for best practice and quality improvement. DBA work is a black art and in my experience the most reward and fun comes from taking someone who is negative about DBA activities and explaining the good reasons why something should be done in a certain manner.
    My company is enlightened enough to grant me some time to mentor kids having a tough time in a local school. The same principles of explanation, encouragement and listening that are essential in that environment are every bit as important when taking a Systems Administrator through the reasons why building out a server in the correct, rather than the fastest manner will deliver the best results for you, the S.A., your company and ultimately your customers.

    Go out of your way to put a metaphorical DBA arm around the un-suspecting shoulder of your team mates and reap the rewards.

    One of my favorite personal development reads is Brad McGeHee’s book (and ebook):,-2nd-edition/

  • Grant Fritchey

    Thanks Martin.

    Where were you about 15 years ago when I needed this kind of advice? Ha!

    I agree with you. When you look at all the interactions with all the different teams that it is possible for a DBA to have, if a DBA hopes to be a leader within the organization, they’re going to have to work a lot on soft skills.

    Then again, some DBAs are extremely happy to run backups, defrag indexes and then go home.

  • Anonymous

    DBA Developer relationship
    This environment of DBAs and Developers existing in separate worlds is new to me. I come from a small company background where I wore many hats including both DBA and Developer, among many others, and I wear but one now. The notion that as a developer I am being asked to provide solutions with little support and cooperation from those that have the keys to the kingdom is frustrating and debilitating. The wasted time requesting, waiting, and begging for resources is unbelievable. I sense that developers are tired of being treated as a lower class and incompetent, when all that we are requesting are the tools to do the job we are being paid to do. We understand the need for structure and consistency, and fully intend to play by the rules. The customer in the end is the one who pays the price. What I see as a result of this control is the lack of well structured systems and automation which can truly help this organization become more productive. In my former small world we were far more advanced in automation and centralized systems simply because no one was there to deny me access to tools I needed to get the job done.

  • Grant Fritchey

    re: DBA Developer Relationship

    Especially in large enterprises the DBA must act as a gatekeeper in and around production. It’s a fundamental part of their job. But far too many DBAs take that to mean that they must prevent almost everything from coming through that gate, leading to the situation you’re seeing. It shouldn’t be that way. There has to be a better approach that allows developers to build & deploy stuff while the DBA stil protects production. That’s exactly what I’m trying to advocate for.

  • DBA-Scouter

    Great article
    Thanks for a great article Grant. I too am a long-time Scouter (OA, Wood Badge, troop advancements now) and a long-time DBA. I hope my BSA training keeps me from being the jerk DBA. A little servant leadership works wonders with Scouts and with developers!

    BTW – I will be at the Atlanta SQL in the City in October. I hope to get to you meet you.

  • Dana

    Great Read!
    Grant, thank you so much for the exceptional read. I can easily relate to both sides for both DBA and Developer. Being an accidental DBA myself and coming from the development side, I definitely agree with what you’re saying. There has to be a comfortable median where DBA’s and Developers meet in order to ensure the "sanctity" of production.

  • Grant Fritchey

    re: Great Article
    Thank you very much Ken. And yes, look me up in Atlanta. I’ll be there making all sorts of noise so I won’t be easy to miss.

  • Grant Fritchey

    re: Great Read
    Thank you!

    That is the hard part, finding, and maintaining, that center path where you give as much freedom as you can to the developers without compromising the protection of the production data.

  • Dana

    Great Read!
    Grant, thank you so much for the exceptional read. I can easily relate to both sides for both DBA and Developer. Being an accidental DBA myself and coming from the development side, I definitely agree with what you’re saying. There has to be a comfortable median where DBA’s and Developers meet in order to ensure the "sanctity" of production.

  • glen

    I thought that every DBA would have this understanding to begin with
    I am not understanding how the necessity for this article comes about. Clearly it is the business the drives development in turn employing database administration. Service is a must.

  • Grant Fritchey

    re: DBA Understanding
    Thanks for the feedback Glen.

    My own personal experience and lots of anecdotal evidence observed online, in person, and in discussions suggests that there are plenty of DBAs that don’t get it. Or, rather, they think the service they’re providing is being that road block, that "sane" individual that says everything has to slow down, back off, not be a crazy speedy developer-centric process when in development.

    And sure, there are very well run, sane businesses where roles and responsibilities are clearly defined, logical, and adhered to. There are also a lot of crazy places doing crazy stuff either through a lack of knowledge and understanding or because of many past bad experiences leading to current poor choices.

    If this isn’t applicable to you & your experience, OK. But, I think, more of us have worked for the crazy places than have worked for the sane places.

    Think of it like backups. Every good DBA knows you should have tested backups in place, right? But how often do you see on Twitter or in the forums where people didn’t.

    I think there’s just a lot of education needed to turn out good DBAs and, at least in my opinion (worth no more than anyone else’s), this is part of it. Thanks again for the feedback.

  • Anonymous

    Leadership Through Service
    Leadership through service is the example set by the greatest leader of all time.

  • Anonymous

    Leadership is the easy bit?
    Anyone that says that hasn’t led! This article was well-written and well-presented and as I professional DBA I can associate with almost everything that has been said.

    That said, one of the reasons some DBAs are not taken seriously is because they seem to do a lot of talking but actually say very little. Or what is said isn’t or is said simply to ascertain said DBAs position in a group.

    Next to leadership comes subject-matter-skills. Without those skills leadership makes one nothing more than a "nice person".

  • Grant Fritchey

    re: Subject Matter

    I was the production DBA for an app that I never saw prior to the week we were supposed to put it into production. It consisted of nothing but multi-statement UDFs that joined to multi-statement UDFs that called multi-statement UDFs which joined other multi-statement UDFs. I said "OMG! This isn’t going to work" and the developers said "Why not? Microsoft let us do this, so it must be OK." At the time, I didn’t understand enough of how statistics worked to give a good answer, so we went to production with it over my protests. It failed, but more importantly, I failed because of my lack of understanding and inability to accurately communicate the issues.

  • chapunica

    Not a Developer
    Hi Grant. Great article, I read almost everything from you thanks for sharing.

    I have a question? What advice you do have for DBA’s that are not Developers or don’t have that experience on their belt.
    I only have 3 years of experience as a dba and next week I should start on a new place were they only have 1 dba- (me)


  • Grant Fritchey

    re:Not a Developer
    Thanks for the kind words.

    Tough, tough question. First, make sure you have backups in place. Above all. After that… do the right thing for the business, whatever that might be. But, be careful to take care of yourself. Make sure you’re not just getting one year of experience, multiplied. Strive and push to do more and learn more. It’s the best way to grow.

    But first, the backups.

  • paschott

    re: Not a Developer
    Congratulations on the new job. Along with Grant’s excellent suggestion about backing up the databases (and testing them), don’t forget to take an inventory of the SQL Servers sitting around. I have a friend who just started a new job and found 55 SQL Server instances, ranging from SQL 2000 to SQL 2012 w/ some SQL Express thrown in – all/most being used in some way. Now that he knows that he can look at all of them and determine how often these databases need to be backed up. And don’t forget to test your backups!

    Keep reading – subscribe to things like SQLServerCentral’s daily newsletter and MSSQLTips (off the top of my head – I’m sure there are more). I’d recommend getting some baselines of your customer-facing servers when you get a chance so you can know when something is different. I’d also recommend DDL Audit triggers if you can get approval for them. That can help you know when a code change was made to your servers.

  • chapunica

    Not a Developer
    Thanks paschott.
    Great advice
    Thanks both of you for helping people like me.:-)