What’s Your Point?

As a DBA you are getting pinched between developers, project managers, budget conscious managers and server teams. When a critical issue with no one easy answer for those people pops up, what do you do? You can panic or try and point the blame someplace else or you can rise to the situation and help get the problem resolved, even if it isn’t a database caused issue.

How can you become a part of the solution? How can you guide others to want to do the same thing? There are many steps but let’s talk about the communication step.

Read these 3 fictitious statements or e-mails (with only a bit of hyperbole added) about a serious production problem in the financial system for your company from the desk of the DBA…

Option 1

“The server is slow, the infrastructure is messed up and the code is horrible!!! We are doomed, you guys need to make changes and get this worked on right now. Clean this up and fix it, what kind of a shop is this anyway? What kind of a database did I inherit?! This is not how I am used to working! SAN Team – fix your disk performance. Dev team – fix your stinking code!”

vs. Option 2

“The finance team recently asked me to look at their environment. I was working on a few other things but I managed to make the time to check out the server. I used various tools to conduct some research and based on my analysis, I have found a few causes for the recent performance slow-downs.Through applying the best practices and principles found on such and such a site combined with my experience, I have a list of recommendations. Based on my expertise, we must make these changes or we face continued performance problems. I would like to propose that we move to a better server that can handle the future load we throw at it. To get to that future load, we must increase memory and disk performance primarily. The disks, not just for capacity but for performance as well, something that we have not been doing around here to date. I know that I will be able to improve performance if you give me the hardware that I need.

vs. Option 3

“The finance application users and upper management have reported several performance related outages lately. The most recent was during their closing of last quarter, the reports were 2 days late to compliance. They report it has been getting worse  over the past year. After some research, it seems that there are some quick hits to be made with infrastructure and development. We can also talk about some longer term solutions both teams can work on.

I have a few options I would like to discuss the pros and cons of and I would like to hear your thoughts on the best approach. Do you have some time to review the summary of research, some key performance graphs and discuss some steps we can take before it grows to an escalation issue?”

A rhetorical question: which of those options are more likely to lead to resolution?

My vote? Option 3.

Why Option 3?

What does option 3 contain that the others don’t? Allow me to borrow from my history as a volunteer EMT,  borrow from a book I am currently reading, and steal from common sense to explore why I like Option 3.

“What is Your Chief Complaint?”

If you are a nurse, doctor, EMT, Paramedic, PA, etc. you know the frustration of trying to get such simple information. When interviewing a patient, especially in an emergency, pre-hospital scenario you want to get to the heart (no pun intended) of the matter, and quickly. Early on I would show up to a patient’s side and (stupidly) say, “Good evening, how are you?” (took awhile to break that everyday habit.. the responses back were humorous at times… “I’m great, that’s why I called you guys!”) and then drive at, “what’s going on tonight? Can you tell me about your pain, illness, issue, etc?” You want to ask open ended questions so you aren’t suggesting words (patients are like kids in that regard) and feelings. At the same time you cringe knowing the dialog that is likely to happen for some of the less severe medical patients:

Patient (PT): “Well, sonny, you see I’ve been taking all of these pills for all of these situations I got from what the Doctor tells me. But today I was walking around and just felt kind of off. A little while ago I had a headache but I couldn’t really eat, so I didn’t take two of those pills that I’m supposed to take when I eat. You know, I was going to have a meat loaf but they forgot to bring me the onion soup packet and”

EMT: “So you are having a headache and just feeling off? today? Is that why you called 911?”

PT: “Oh no, I feel like that some days and the headaches come and go with me. You see when I didn’t eat I forgot to take those pills, you see, and well I just have had this pain in my side and my stomach. Oh, I also haven’t gone to the, you know, bathroom in 2 days. I think it’s because the pharmacist was telling me to stop taking one of the vitamins and maybe take one of those pills more often.. Yeah that one, the pink one”

EMT: “So is that pain what prompted you to call 911?”

And so on and so forth. We won’t get into the conversations around patient history (“My father-in-law had the sugar diabetes, but my father didn’t, he died at 50 of a heart attack..” “Okay, what about you, do you have a history of x?”). We want to drive at the chief complaint as soon as possible. It becomes a tool in ruling conditions, situations and priorities in or out. Our job in the field isn’t to diagnose but we do have to form a differential diagnosis and act according to a protocol for that.

The same holds true in our offices – Our colleagues want to know what the problem is. What is the concise problem statement we are gathered here to discuss? An exercise that works with Patients is, “Can you tell me what one issue you are experiencing tonight is bothering you the most? If you had to pick only one, why did you need an ambulance?” (said with a nice tone to all Patients, even if it is 2AM and there are two cars in the driveway and no sign of an emergency, but I digress).

I actually extended the analogy between being an EMT and a DBA in an article on troubleshooting over at SQL Server Central. Beyond communication.

Principle 1 (From the EMT Life)- Determine a problem statement (and cut to the chase). Make it free of exaggeration (in either direction) and extra adjectives. Describe the problem you are working to solve.

“Don’t Bury The Lead”

I ordered “Made to Stick: Why Some Ideas Stick and Others Die” after it was recommended by a friend with a lot of experience in the Professional Development and social networking world (Domesticating IT Blog|Jon DiPietro on Twitter). I am not done reading yet and will likely do my first book review when done but it is a great book so far. I want to use the principles found in the book to help present SQL materials better, blog in a more useful way and get my ideas across at work more efficiently.

In the first chapter the authors talk about a common trait among ideas that succeed: Simplicity and sticking to the core of the idea.

They use the analogy of newspaper journalists. I didn’t realize this, but most journalists spend the vast majority of their time writing the first line in the story – the lead. They want to get the main idea out clearly and concisely and leave the reader with as much info in that line as they can. If you only read that first line, they want you to have an idea, they hope to draw you in to read more but they cover the important stuff first. In fact a good newspaper article, from what I am reading, is an inverted pyramid. The most important ideas up front and continuing in descending order.

Principle #2 (From the Book) – In that problem statement, remember the impact and reason behind what you are doing. Still keep it simple but keep that core thought pattern alive and vibrant in the beginning and throughout your message.

“The Most Beautiful Sound”

I forget who said it and how but I have heard many variations. To most people, even those who won’t admit it, the most beautiful sound to them is them. People want to be validated and respected and they want their voices to want to be heard. Option 3 was the only option that didn’t put the requester on a pedestal or tear other people off of one.

Principle #3 (Common Sense?) – Honestly seek and consider feedback. Other people have other points of view. Perhaps one of those points of view is the winner. Who cares, the problem gets solved and people always remember the one who stopped a resolution, not the individual member of the team who came up with the winning idea. Enlist assistance and understand it. This will also disarm people to hearing your ideas.

“Just the facts m’am”

Opinions are quite common and you know the sayings about them. Everyone prefers their own opinion in most cases. Opinions can be argued forever. Facts stand up. Yeah some stubborn folk will try and argue them but the rest of the team and management should (hopefully) see them for what they are – facts. In Option 3, research was done and offered to be summarized and presented.

Principle #4 (More Common Sense?) – Present Factual data and give facts more weight – You have your opinions on the issue. We always do and you should present those, eventually. Weigh the facts higher, your manager and team mates will, and present those first and foremost. Perhaps your assumptions about the data were incorrect and a second set of eyes will help.

“Know Your Audience”

Alright, so maybe this one is trickery? I don’t think it is but I could see why one could say that. I don’t mean make-up data or mince the tough conclusions. What I mean is know who you are speaking to and what motivates them.

The issue in this situation is an application with rotten performance and some important users who are ticked off. You are the DBA. You are an advocate for your organizations data (As I posted when talking about where to start, performance is availability and users need available data). Much like I was a patient advocate when I was an EMT gathering facts to present to the Emergency Department triage team, you need to care about that database and the data in it and work hard to have it “fixed up”.

As a volunteer EMT who did, at most one year, about 75-125 ambulance calls, I wasn’t as jaded as some of the emergency room staff grows to be. Knowing where the staff was coming from, I could properly present the most important facts that would help them prioritize my patient and get them the care they deserve.

Principle #5 (From the EMT life and Common Sense?) The Right Message for the Right People. Perhaps for one team mate the message can be even more blunt. Perhaps your managers style is, “No charts and data points please, I trust you, lay 3 options with pros and cons on me”. Tailor the problem statement and it’s delivery to the listener you know (which means you have to be a good listener well before an issue arises so you can actually know that audience) .

With That…

I will leave you to ponder on the principles I found in Option 3. Did you find any others? Do you have a different take? I am sure the readers here would love to read it. Leave a comment and let us know.

Standard Disclaimer on Content Like This: This can fall under the practice what I preach category. It’s something I work on and realize I mess up with from time to time. The principles seem easy as I digest them and write them out. The actualization of their use, not so easy. I’m a work in progress, what else can I say? 😉