The Importance of Being Social

I'm not a very social person.  In my day job as a DBA, I used to think this didn't matter too much.  I was able to configure replication; create clustered SQL Server installations; diagnose performance issues; fix failed backup jobs and perform most of the other miscellany that comprises the daily tasks of a typical DBA.  Hard at work outside the office, I was writing steadily for websites like http://www.mssqltips.com, passing Microsoft certifications and generally doing the database thing.  These activities aren't noted for their levels of social interaction.


One part of my job that I couldn't stand, however, was ... The Meeting.  For some reason, everyone in my organisation seemed to believe that every meeting required a DBA.  Whether that meeting was technical, or not.  As a result, I spent as many as 4 hours of *every day* sat in a meeting room, listening to mostly non-technical people carry on about issues ranging from new project launches to 'elf and safety initiatives.  It was very tiresome, and my typical response to that rage-inducing disclaimer that certain people use when they engage me in conversation ('I'm not technical!', they say sheepishly, raising their hands in a defensive posture) is to respond, 'It's okay - I'm no good with people!'.


Personally, I hate the format of the meeting.  I subscribe to the Pratchettism which I'll paraphrase as ' the IQ of a mob is the IQ of the stupidest member of that mob, divided by the number of persons within it.'  I find the most productive way of working is alone, with access to reference information.  Meetings provide a forum for many people to communicate, but the efficiency of that communication is low and leaves (IMHO) a lot to be desired.


I've always had time for those who *don't* understand - but never time for those who *won't* understand.  You know the type I mean.  The type who ask you for a technical report on some issue - perhaps a root cause analysis for some recent downtime - and when you present your short(-ish) document detailing uptime statistics, log analyses, cross-references to Microsoft white papers, they either don't read it or decorate their bin with it.  Or ask - infuriatingly - for an 'executive summary'.  My typical riposte to this was, 'I would, but I've run out of crayons'.  Those who make zero effort to understand underlying technical concepts.


And yet.  As I've matured as a DBA over the last decade, and grown as a person, I've found my attitude changing.  I've awoken to the realisation - obvious perhaps - that many folks have very different skill sets.  Some have no skills at all.  But, they're all employed at the same firm (for better or worse) and that means one has to take a more relaxed attitude to conveying information. 
 
Everyone's just people, and people are all different.  Some people have the same aversion to reading a technical report or looking through a log file as I do to examining business flowcharts.  And it's taken me a very long time to realise this.  I've found that to get the best out of the team I'm working with, I do have to modify my behaviour and expectations to match the abilities of the team - and this is a lesson that, for me at least, has been a long time coming. 


There's plenty of IT guys out there (perhaps some reading this) who will identify with my technological roots, espouse all things Tech and profess hatred for all things User.  But what we all seem to forget is that the reason an IT department (or a DBA team) exists is to serve the business.  Without the business, there is no need for a database estate.  And sometimes, this means we have to engage with the people who run that business.


So next time you're in a meeting, be strategic about how you handle it.  Set some clear expectations early on about the desired outcomes of the meeting - this will help focus people and keep conversation on-track.  Use an agenda to help you do this.  Make sure everyone in the room is aware of the names and responsibilities of other attendees. 


When asked to explain technical concepts, there's a technique, which in the world of journalism is called pyramid writing.  Start with a high-level sentence that explains the outcome - 'We performed a root-cause analysis, and found the server malfunctioned due to a faulty hard drive.'  Then assuming interest doesn't wane, expand.  'During our investigation it came to light that the drive had been warning-flagged by the software management system a month ago.  This was missed as we don't use automatic alerting.'  Then further.  'We found that another drive in the RAID 5 cluster had failed two months ago, and hadn't been replaced.  This second drive failure meant data loss, since three-member RAID 5 clusters aren't tolerant to more than one drive loss.'


Remember that there are those in your organisation who are more receptive to different communication styles, too.  For example, I like dense technical material such as books, white papers, academic papers even.  I don't particularly like learning from video, nor looking at diagrams, to the extent that I prefer the XML version of an execution plan.  But others will 'grok' your points if you explain them visually.  Occasionally, then, illustrate your explanations with pen and paper.  Pick up Visio and put together some flowcharts.  In e-mails, use visual aids to classify and characterise your information - from bullet points to different size and colour fonts.  I find using the highlighting tool to highlight specific points within my text to be very effective with non-technical people.


In conclusion - think about, respond to, and care about, your audience.  Examine your attitude to communication, and see if you can make any improvements.  And remember that without business people - we're all out of a job!