I missed T-SQL Tuesday #1, but participated in T-SQL Tuesday #2. Now it's time for #3, and I'm making my entry. I like this style of getting a series of posts from the community on a topic, and thanks to Rob Farley, we have an interesting and open-ended topic for T-SQL Tuesday #3: Relationships.

Making Friends
Some year ago I started a new job as a DBA with a large company. I was a production guy, working in the Operations group that was responsible for keeping our live systems running. That's the kind of work I enjoy.

In the company there was also an Engineering group, that was a counter-part to my group. They helped architect, design, sometimes build solutions that we would then deploy. As you might expect, there were usually bugs or issues in systems, and since my group was on-call for issues, we had to support those systems at night, often without a lot of help from Engineering after hours. The relationship between the groups was somewhat contentious, and even outright hostile at times.

Enter Steve. New DBA, and taking the place of a senior DBA that had moved on. Without the baggage of previous relationships, I wasn't aware of issues. However when I got a call one day asking if the DBA could come help Engineering on an issue, I headed over. More than a few of my co-workers told me that I should stand my ground and not let the Engineering group tell me what to do.

Walking over to the other side of the building, I couldn't help but wonder what I was in for. All the talk from my group had put me in a slightly defensive mood, but when I got there, all I found was another IT guy asking for help discovering why something wasn't working. A little SQL Server debugging and tracing, and I'd fixed his issue, gotten thanks, chatted for a few minutes, and then went back to work.

Over the next few months, I had a few more encounters with Engineering and Security people, usually being called to solve a problem. I made some friendships by helping people get their jobs done. I left my ego at the door, and just solved problems, even when they were self-inflicted by people that ought to know better.

Those relationships were handy later in my career at that company. There were times I needed to shortcut a rule to get something done, and would get the help I needed. My responsibility to comply with paperwork or regulations had to be completed, but having a good working relationship allowed me to get the work done first, and the documentation second. It also helped me to stop an Engineering deployment a few times and let them know that they had a system with issues and their group was responsible. Hearing that from someone with whom you have a good relationship is completely different than hearing that from someone you dislike. It allowed me to legitimately push-back and have someone listen to my reasons without being overly defensive from the start.

In short, the relationships helped me to get work done and problems solved in an efficient matter. Sometimes being a DBA means working on relationships outside of SQL Server in order to have those inside SQL Server work better.