The Dirty Dozen #1: Lack of Communication

As promised, here is the first part of the series based on the MARSS posters — The Dirty Dozen — concerning the importance of clear communication between DBAs.

The best DBAs have great communication skills. I don’t mean that they write books, present at conferences, or can order a meal in six languages. DBAs do need to be able to communicate in different tones and at different levels of detail because they’re likely to be communicating with diverse interest groups such as end users, hardware vendors, system administrators, business leaders, Oracle Support analysts — well, it’s a long list. However, like the MARSS poster, I’m going to focus on communication with our peers — other DBAs. That demands the ability to communicate a small but sufficient subset of relevant information as clearly as possible.

That’s even more important when you are working in a geographically-distributed team of DBAs within a 24-hour “follow-the-sun” model. Pythian is the second organisation where I’ve worked this way, and, although the two companies take slightly different approaches, the challenges are similar and particular communication techniques are fundamental to the smooth working of both.

Use a Logbook

Both use a service request or trouble ticket handling system (much as Oracle Support use Metalink and many companies use Remedy) or, as the poster describes it – use a log-book. Pythian has an internally-developed system called Support Track where we record all of our actions while working on a request. Note that I said “request” because this includes all of our project work and isn’t limited to “problems”.

I don’t think there can be much argument against a logbook of some kind. Let me give you an example straight from my day-to-day work at the moment. Alex Gorbachev and I are sharing the work of building a couple of RAC/ASM clusters. We work five hours apart so, when I’m sitting watching Eastenders at ten past eight in the evening, I don’t want him to phone me to ask me what I did and why. I want him to be able to read it and not be stuck waiting for a response from me. And let’s face it, at my age, a log can be a useful reminder to myself of what I did and why!

However, I’m sure that most DBAs have experienced the frustration of working on a Priority 1 Service Request via Metalink being handed over between different shifts. A new Support Analyst picks up your case and, despite your best efforts, starts to request the same information that you supplied two hours ago, or information that previous work proved to be irrelevant. How can that be when everything is on the SR?

Well, I’m going to take what I think is a minority position amongst the DBAs that I’ve met and say that I think DBAs are a little harsh in their judgement of Oracle Support Analysts. I’ve worked on quite a few tricky SRs (or TARs) over the years when everyone started to lose track of what had happened and what was relevant. When the problem history becomes long, it becomes difficult to follow (if it’s sufficiently detailed). In fact, I’ve worried about this when working with Alex on the clusters. Five hours of work history is a lot to wade through each morning. I want the detail to be there so it’s not lost, but does he really need to read all of it?

What’s required is a summary. So, as the MARSS poster would have it, Alex needs to know…

What’s Been Done and What Remains

If something isn’t working properly, detail becomes useful because I (or Alex) can read through it and see if we can track down the problem. But if, for example, a broken ASM instance is fixed now, it would be nice to know that I can forget about that and move on to the next task. That’s why, in addition to all of the history in Support Track, I normally drop Alex an email saying something like, “A is fixed, there’s still something wrong with B and I haven’t even started work on C.” That’s a deliberate simplification, but it makes life so much easier for others if we can give them a high-level map of where we are at the moment. Rest assured, if there are problems, the logbook is always there.

As the poster says, it’s OK for me to say, “I guess the day-shift can finish screwing on the panel,” but only if the day-shift actually knows that! Otherwise, are they supposed to just guess? Alternatively, are they supposed to review the entire system to see what’s missing?

Which brings me to the final point on the poster.

Never Assume Anything

This is a pet hate of mine, as many would tell you. To me, the whole point of communication is to get the necessary information from my brain cells into the receiver’s brain cells. If that doesn’t happen, for any reason, I have failed because I haven’t achieved my objective. It doesn’t help for me to say, “What do you mean you don’t know what I mean, you’re a DBA aren’t you?”, because it doesn’t get any of us towards the end goal. I know I can’t regurgitate the vendor’s entire documentation set (that would be inefficient and silly), and I can’t write a DBA training course for every task. However, if it takes 20 minutes instead of 10 minutes to write a hand-over email and maybe you include too much information, isn’t that better than omitting something crucial that seemed obvious to you?

As I’ve said before (and I’m sure I’ll say it again), I would hope that your primary motivation for communicating clearly is not just the professional desire to make sure the job is done properly, but the simple fact that clear communication with your colleagues has a wonderful effect. It shows that you care about their situation and want to make it as comfortable as possible. Refusing to at least try to communicate effectively with your colleagues and business partners is ultimately selfish. That people here put a lot of effort into communicating effectively is a sign that I’m working around good DBAs at Pythian.