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.

Advertisements

6 Comments (+add yours?)

  1. Doug
    Sep 05, 2014 @ 08:20:15

    Thanks for your post. I’ve recently run into a technical solution versus a people solution. It’s clearly a balancing act. Part of the balancing act is knowing the cutoff point for the selection of one over the other. Yes, our people solution is simpler but it is also much less efficient and, frankly, prone to human error and arguably not replicable. Costs of errors are high yet management somehow still feels more confident about the people solution.

    Reply

  2. Michael
    Sep 05, 2014 @ 09:10:06

    Brian, thank you for your Four Attitudes posting. Regarding the Technical / People solution, like Doug, I also worry about the human intervention, error and, more importantly, putting the burden upon the end-user’s shoulders. Perhaps you could provide an example or two

    Reply

  3. Phil
    Sep 05, 2014 @ 22:41:36

    I have seen examples when a people solution is far simpler than the technical solution, less efficient or not. In my business I often troubleshoot applications within applications, and sometimes a new application surfaces that behaves differently than the users are used to, and trouble tickets are raised. So yes, there is a technical solution to rework it to the way the users expect all the other applications to behave, or there is a people solution to include these differences in their training for this new application.

    Reply

  4. visualsi
    Sep 08, 2014 @ 09:02:02

    Hi,

    Thanks for the post. One of the best articles I’ve read in a long while. I would add a couple of things that may be implied but left out. On the other hand, I may be completely out on my own.

    1) You may not know everything there is to know concerning the problem. For example, your database fix may break parts of the application you don’t know about or may destroy the ability to migrate the application in the future inline with the long-term goals of the organization. Sometimes, what looks like a simple fix to one person ends up being an invisible design constraint to another part of the enterprise application.

    2) Your fix to the part of the application you are concentrating on might help it run better at the expense of destroying the performance of another application that depends on the same data. Simplest case would involve locking and/or deadlock priorities. More involved cases might involve advanced choreographies where your improved efficiency could cause someone else’s delayed data, which, in turn, could cause a reduction in overall throughput.

    Don’t always assume that your boss is stupid – they might not know all the details about the rows, columns and execution plans you work with every day, but they may just have a wider breadth of knowledge about how changes in one place impact other, perhaps more important, places.

    I think if everyone were to follow Brian’s advice, management-DBA-developer interactions would be MUCH more productive on average.

    Thanks,
    Rob

    “It’s very crowded at the center of the universe…” – Pat – a customer

    Reply

  5. Trackback: - Straight Path Solutions, a SQL Server Consultancy
  6. Trackback: Four Things We Wish We Knew - SQL Server - SQL Server - Toad World

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: