SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

4 Attitudes I Wish I Had Earlier as a DBA

I was tagged by Mike Walsh (blog | twitter) in his post 4 Attitudes I Wish I Had Earlier As a DBA.

I Don’t Have to Do It Alone

I’ve always worked hard in my IT career to be knowledgeable in my field. I don’t like not knowing how to do something, and I’ll spend the time and research to figure out how to make something work or how to fix a problem. Early on in my career, whenever my team would encounter an issue, I took it as a personal challenge to solve every issue. At first this sounds great. Brian is being a real go-getter. But there’s a catch.

It hurts the team. When one person is solving all the problems, especially when that one person isn’t giving anyone else a chance, the rest of the team starts to become apathetic about new problems coming in. After all, Brian will solve it. This means one person, me, gets stuck with all the new problems. It destroys my work life balance. It means I don’t have a life. I get stressed out. I miss work. Suddenly there are problems that need solving and Brian is out. Or, two big problems hit at the same time. Brian can only work on one.

Now there’s a big problem. Since others stopped solving problems, the team isn’t prepared to solve the one Brian isn’t working on. As a result, Brian, the team, and the organization suffers. It’s one thing to be a high performer. It’s quite another to try and do it all alone. What I have learned is to be a high performer and to try and bring people along with me to also be high performers. Let’s solve the problems together, so others grow.

The Technical Solution Isn’t Always the Right Solution

This one took a long time for me to get. I like processes. I like solving technical problems. Often times I could see a technical solution to a problem, albeit a complex one. It took my last manager to get through my head this simple concept: sometimes the best solution is a people solution and not a technical one.

There isn’t a standard rule when this is true. However, when you start weighing a technical solution versus a people solution and the people solution looks less complex, it’s time to start seriously considering the people solution. This is especially true when you don’t need 100% adherence or when you have time to offer a few reminders.

People Skills Are Important

One of the reasons I received promotions early in my IT career is that I was able to talk with key business folks. I interacted well with HR when we were putting in a new software package. I could understand the PMs (probably because I was one in the USAF) and could give them estimates in their terms as well as explain variances due to issues being faced. However, I sometimes struggled with developers. Don’t all DBAs? Maybe, but most of the struggles were my own creation. Rather than asking the question, “What are you trying to solve?” and then working with the developer to find the answer, I was quick on the “No, you’re wrong,” stamp. That doesn’t do anyone any good. I have found that when I can remember to engage my people skills and not my rubber stamp, I am more effective at my job.

Remember Who Is the Boss

At the end of the day, I may feel a solution is not the best. I may not like it at all. However, unless I feel that a solution or an instruction causes me to compromise my morality or my integrity, if my management decides to go a certain direction, I’m supposed to execute. I can offer my objection to my management, but if they say, “This is the way it is,” then it’s time to stop fighting and go to it.

I knew this before becoming a DBA. After all, this is the way things work in the military. You can object, if there’s time, to your immediate chain-of-command and if that person says, “This is the way it is,” you are supposed to make the command your own. However, when I got into the civilian workplace, I somehow forgot this way of thinking. I know a few situations earlier in my career would have gone a lot better if, having voiced my objections, I hunkered down and got the work done.

 

Nothing earth-shattering, but hopefully it’ll help someone else.


Databases – Infrastructure – Security

Brian Kelley is an author, columnist, and Microsoft SQL Server MVP focusing primarily on SQL Server security. He is a contributing author for How to Cheat at Securing SQL Server 2005 (Syngress), Professional SQL Server 2008 Administration (Wrox), and Introduction to SQL Server (Texas Publishing). Brian currently serves as an infrastructure and security architect. He has also served as a senior Microsoft SQL Server DBA, database architect, developer, and incident response team lead.

Comments

Leave a comment on the original post [truthsolutions.wordpress.com, opens in a new window]

Loading comments...