What did the developer say to the DBA? It doesn’t matter; the answer is “no.”
What does “DBA” stand for? “Don’t bother asking.”

If you work in information technology, and maybe even if you don’t, you’ve likely heard these database administrator jokes and stereotypes. As a group, DBAs get a bad rap. After all, they’re often the gatekeepers for database security, migrations, reporting and more. And the answer to a “can we” question is often “no,” and for good reasons.

But problems arise when you answer a definitive “no” to so many business inquiries. First, you’re not perceived as adding much value to the company. Second, business stakeholders are less likely to collaborate with you when you need information or assistance. Third, people might stop asking, and then we’re right back to the first point, because there’s not much value-add when no one wants to talk to or work with you, or when people think saying no is your only function.

Finding Ways to Say Yes as DBA

In the short run, it may be easiest to simply say no to an inquiry that doesn’t follow best practices. “Can I have sys admin access to this database?” “Can’t we just implement that tomorrow and skip the testing and rollback plan?” “Can we make this query run in half the time?” Uh, no …

The trick is to find ways to help without giving carte blanche access to databases and their maintenance. Remember that there’s always a business reason when people ask database-related questions. Your job as a collaborative DBA is to find out what that business reason is and how you might achieve that without breaking with best practices in database management. 

For example, you wouldn’t give sysadmin access to just anyone, but there is a lot of flexibility with permissions in SQL Server, and hopefully you can find a set of permissions that follows the “principle of least privilege” but still allows enough flexibility to get things done. You may be able to help someone write a script to gather the information they need or make a report run a bit faster so that it passes performance standards. You may offer to help develop a rollback and testing plan to mitigate risks to help get through a change approval process. 

When you have to say no to something, you need to educate your audience about the best practices behind your answer and offer a way to get it done that does follow best practices. By educating business stakeholders, you not only establish yourself as an expert, but foster a collaborative working relationship that benefits both parties in the long run.  

There’s a fine line, though, between educating and condescension. Stakeholders have to believe that you sincerely want to help, and that you’re trying to balance the company’s goals, security best practices and business group requests. If your education process doesn’t respect its audience, you will still alienate them and appear as “the bad guy” even if you’re trying to do the right thing. Here are some examples of the right and wrong way to approach a situation:

Wrong: “I see this new code you submitted uses a CURSOR construct. Those are really bad, and anyone who has used databases for more than a year should know that. Here’s a link to a blog post and some videos that will show you how to avoid using this awful construct.”

Alternative: “I see this new code you submitted uses a CURSOR construct. While it may run OK in the test environment, it can seriously impact performance in a busy environment. It’s not uncommon for someone with a programming background to try to process data this way, but there are more efficient ways for a database to approach it. I would be happy to meet with you to explain the pitfalls and how to adjust the code. I know both of our calendars are pretty full, so if you’d rather read up or watch a video, I have included some links for those as well, and then we can catch up if you have questions about them.”

Sharing the Workload

You may be thinking, “How will I ever get my real work done if I have to keep educating stakeholders about best practices?” or “I don’t have time to do extra work every time someone asks for something that’s not realistic.” 

These sentiments are true enough, and there are plenty of people who will try to take advantage of your willingness to help and try to get you to do all the work. But there are ways to maintain boundaries when you’re collaborating with stakeholders to achieve a common goal. Here are some ideas:

• Set realistic expectations. When a stakeholder asks you to do extra work, estimate the time it will take and give a timeline for completion that takes into account the rest of your workload.
• Set clear boundaries. We’ve all been victim to “just a quick question” turning into a 30-minute or 45-minute training session. Sometimes that’s fine, but other times it isn’t. It’s OK to establish boundaries up front by saying, “I can help, but I have another commitment in 15 minutes” — even if that commitment is a cup of coffee or a walk outside.
• Leverage your relationship with managers. This includes yours and the supervisors of those you’re working with. When there are conflicting projects, ask your manager for clarification of priorities or extra hands to help. Have honest conversations with the supervisors of the departments involved to ensure you’re all on the same page about the workload. Be careful to avoid doing “end runs” or things that might appear to be “tattling.”  Phrases such as “I have some discretionary time, but I also have project commitments that may be impacted, so I can’t offer a definitive timeline without consulting other departments” can help, but be open with your communication and follow up often so it doesn’t look like you’ve just given someone a brush-off.
• Keep it professional. You may not like the person you’re working with, but you still need to work toward a common goal. Keep your personal opinions to yourself so you can discuss the work objectively.
• Propose solutions, not problems. See if you can find a way to share the workload. Think outside the box to find a way to get the work done while maintaining your other responsibilities. 

SQL Tailor Consulting, Your Collaborative DBA

SQL Tailor is your collaborative DBA. SQL Tailor would love to put its 25 years of SQL Server database experience to work for you, tailoring services to meet your unique needs, whether they involve emergency support services, optimization, migrations or anything else related to SQL Server database management.

Give us a call at (248) 919-8086 or email joe@sqltailor.com for a free consultation.