The Holistic DBA -- Number Five - Communication - Part Four

** Note: As I have posted this my poor Doctor has informed me I have three kidney stones…. Ugh! So…. It might be a while before I post Part five… Sorry…. I'm afraid surgery awaits me. Gads....**

If you will recall in my last post I provided you with a list of what I consider to be the priorities of a holistic DBA. These were:

1. Be able to reliably, consistently and efficiently backup and recover the databases and all database in accordance with SLA, RPO and RTO’s.
2. Ensure database uptime with respect to all SLA, RPO and RTO’s.
3. Ensure all databases are secure.
4. Monitor all databases in a consistent and reliable manner.
5. Communicate in an effective manner.
6. Help users to help themselves.
7. Work to understand and correct bad behaviors with respect to the organizations data policies.
8. Work to understand and correct bad behaviors with respect to the organizations data designs.
9. Work to understand and correct bad behaviors with respect to the organizations application designs.
10. As befits the organization, your abilities, and time keep up with current data related technologies.

I have already discussed numbers 1-4 previously and now I want to move onto number 5…

Communication. When we went to college or high school, more than a few of us laughed at the notion that we needed a class in communication. I mean, we knew how to talk, didn’t we? We took it for the “easy A” and sighed our way through the instructor as he dolled on. You may have skipped class often, relying on your memory and textbook to get you through, and it did…. Oh how wrong you were my friends. While the academic side of communication may be a lot for us to muster (and just like 10046 tracing, most of us really don’t need to master the academic side) our ability to communicate is critical. It is, in the end, what leads to our failure or our success.

Case in point….

I once knew a DBA who shall remain anonymous. A critical system went down, boom, crash with all the accompanying bells and whistles. Now, because of the date and time and that some month end processing had just occurred, the business needed the database restored to July, 1, 2011 (all names, times and places are changed to protect the innocent). The business communicated the date, the DBA communicated the date back and started the restore. All seemingly went well, the database was up and restored to 6/1/2011. However the users began to report inconsistencies in the data. Yes, most certainly some data was not restored and was missing. Panic ensued, some reason or other was conjured up for the failure and another restore commenced. Again the restore was successful and we though happy day, who let the dogs out, woot! Until the call came that the data was again, completely wrong. Now, I’ve given you just enough information to figure out why we were wrong. Can you see it? I was called in because it was becoming a panic situation. I looked at the restore code, called the DBA doing the restore and pointed out the mistake.

So, what was the communication failure here? Was there one? The customer communicated the right date to restore, and the DBA communicated the date back to the customer. It was all seemingly well communicated. However, there was a failure in communication here (as opposed to a DBA failure in my mind) and a failure of process. What were those?

First the failure to communicate was in not cross checking the date that he read back to the customer (in one format) with the date he used in the actual restore and recover command (in a different format). Note that the customer said July, 1 and our poor DBA (using scripts, again the bane of existence) entered 6/1/2011 instead of 7/1/2011. A simple mistake to make, a hard mistake to catch sometimes when the pressure is on and the customer is like “HEY, GET THIS THING BACK UP!”.

The communication failure here was also a process failure. I’m not going to dive into the dynamics of stress under fire, but our poor DBA was under duress to get this database back up and running. To his credit (he really is a good communicator) he reported the problem down the line. In the end, I think the failure was MY failure as his direct manager (who was technically capable) I did not double check his restore script. I didn’t assign someone to work with him during this crisis. I don’t see this as a failure of the DBA but rather a failure of what should be a mandatory oversight process during a critical outage. The failure to communicate was mine. The failure to get the database restored on time was mine. The buck stops here, with me. I know, it’s cliché, but it’s the way I feel. How do you feel when a mistake is made? Do you try to understand it, do you take ownership of it or in your mind is it just one of those things that happens? In my mind, the latter choice is an utter failure to communicate, with yourself.

Let’s dig deeper into this communication thing. Look at the remaining priorities #6 through #10. Is it not obvious that each of these require that you communicate effectively? Don’t each of those priorities (which I think become critical enterprise wide priorities) require effective communication? What is required to be an effective communicator? There are many websites and books that will walk you through the basics of communication but let me tell you what I think makes for an effective communicator:

One note – this list applies to both public, meeting and private speaking – Some items may have more importance depending on the audience you are talking too.

Your speech - You have got to learn how to speak correctly. This does not mean you need to sound like a snot nosed Harvard law professor. It does mean you need to know how to properly conjugate verbs, how to avoid double negatives and other such things. I don’t claim to be the expert in this area (in fact I’m not) but I think it’s profoundly important to higher levels of success. Don’t use your point-of-birth-origin as an excuse to not speak the tongue correctly. You’re not the Larry the Cable Guy, you are a professional DBA. Be that.

Your vocabulary - If you want to sound like you know what you are talking about, improve your vocabulary. Pepper it with words that add meaning to your thoughts. Understand the current technical jargon (in concert with priority #10) that is related to the topic you are speaking about. Learn what a thesaurus is and use it when you write. Writing is a great way to improve your vocabulary, even technical writing.

Don’t communicate to death by Email – Be an explorer and get out there and meet people! Get your butt up and go find the person and talk to them. Follow-up with an email if you think it’s important. Get updates by email if you like. The point is, in the process of communication, we need to learn to be personable. We need to learn to get along with people. We need to learn that being irritable all the time makes people shy away from us. Learn to go find and meet all the people that make a difference in the organization. Make it a goal, say once a day, to meet someone new, and find out what they do. Learn their name, learn their skills and where they fit in the organization. Knowledge is a powerful thing, and putting a face to a name is important.

Be credible - Understand that if we constantly espouse ideas that are ridiculous that we will lose credibility. However, don’t be afraid to take a chance and let an idea fly. Just be prepared to defend it and to back down if you are found to be in the wrong. Don’t let pride get in your way, rather let your professionalism and a touch of humility and a dusting of persistence be your guide to when it’s time to say “I was wrong”. You will lose very little (if any) credibility if you admit you were wrong. You will lose a lot of credibility if you stomp off and refuse to accept that you were in error.

Pick your moment – Now with respect to #4, you might well be right but the moment was wrong. Perhaps something is going on that is not making the person capable of really listening to your point-of-view. Perhaps it’s your approach. Perhaps it’s any of the items on the list. The thing is, we need to pick the moments to discuss various topics. An idea that you have that is amazing, brilliant but a little risky might fly right after your group has had a great quarter. That same idea might well get summarily dismissed if your organization is struggling to meet its SLA’s. Which in fact, implies you might be skipping the priorities before the communication priority.

Your tone - Your tone is critical and you need to gauge it carefully when you speak. Use your tone to create drama, to create impressions of important with respect to a certain topic or to re-assert everyone’s attention on yourself and not the pizza that just entered the room.

Know what you are talking about - I’ve sat in so many meetings when the pro-ported professional pro-DBA espoused some obnoxious, totally wild, incorrect statement with respect to Oracle and everyone just sat there and nodded their heads. What would you do? Would you correct him? Would you take issue if his plan was wrong? If you don’t know what you are talking about, then you won’t have a clue what to say. If you are not past #1,2,3,4 and moving forward into the later priorities, you are going to have nothing much to add to the conversation. Learn your trade, and learn it well.

I’ll include one key, and I think important, but to that last statement. In fact, you don’t need to know, and cannot know everything. What you do need to know, and must learn to do is figure out how to collect information and understanding quickly, efficiently and understand if that information is reliable. You simply can’t know everything. You can know how to find out about a great many things in a few clicks. You can discover existing standards, tools and technologies quite quickly, if you have the understanding on how to do it.

Know your lines - Know what you’re going to say before you say it. This is particularly hard with respect to one on one meetings or group meetings. However death by power point is the second most common cause of Gout in the United States, only bested by an intense desire to stand-up, pull your hair out of your head and say “I’m mad as hell, and I’m not going to take it anymore”. I’ve also come to understand that the lines “It’s my money, and I need it now” are starting to cause many people to have gout flare-ups.

DO NOT come into a in person presentation with power-points and a dull dry script that you don’t know. It’s disaster waiting to happen.

Similarly don’t go talking to those up in the golden tower without having your facts at hand, without fully understanding your argument and also understanding who your enemy is. Yes, I believe that communication can be a battle area and I come prepared to go to war. You should too. (sometimes surrender is inevitable but you can always re-group for another day).

Practice - This is why priorities #1 through #4 are so important. Yes, they are important to the organization to be sure, but for you to be the best DBA for the organization you need to learn to communication. You need to be willing to communicate, you need to have time to communicate. Getting #1 through #4 in place, automated, repeatable should be the first step to improving on your communication skills. It’s those communications skills that will take you down the yellow brick road to becoming the holistic DBA.

Listen - What does listening have to do with communication? Just about everything! The key to communication is listening. There are incredible orators out there, but when you are in a one on one, or one on group discussion, it’s listening that will be the key to your success. Other people have great ideas. Sometimes those people are quiet, and often go unheard. Help them speak up when they have a good idea. Also, as you listen to the group dynamic, if you allow yourself to “step away” from it for a while and just listen to what’s being said, you might have some insight come to you that you that might not otherwise. You might find yourself being the man-in-the-middle, as it were, the un-polarized DBA with the correct solution that is obvious and defusing. Sometimes listening can lead to a successful meeting where just talking can lead to a disaster.

Does communication really belong at the #5 spot? Part of me really wants to park it in the number one slot for a lot of reasons, and maybe I should. The reason I park it in the #5 slot is that I see it as the gateway to the greater universe and the method by which we hyper-inflate our jobs and become the best damn DBA’s on the planet.

Ok… enough about communication. No, my name is not Covey. I don’t purport to be an expert on communication. I do know what I’ve seen work, and what I’ve seen fail terribly. I’m also not perfect at it, not by far…. I get frustrated way to easily, I find my tolerance levels dip into very low levels way to easily and I lose patience when I get stressed. Just saying, I’m far from perfect.

More about the last priorities on my next post…