From its simplest definition, empathy is the awareness of the feelings and emotions of other people. While it feels really good when friends and family understand what we are going thru, this is very rare in our line of work. When the DBAs (Default Blame Acceptor) get blamed when an application runs really slow, when the project manager rushes to complete a task even when the engineers haven’t had a good night sleep, when the sales people promise the customer that anything and everything can be done, empathy seems to be a lost art in the IT world.

 
 

While doing some Always On Availability Group design work for a global travel company, I asked a very simple question that drove our entire conversation: “what’s your most challenging issue at the moment?” When I asked that question in a room full of smart engineers who read SQL Server memory dumps for lunch, I anticipated a somehow technical response. At the back of my mind, I was thinking “could it be the quorum configuration?” “Maybe the shared storage that their SQL Server FCIs used?” “Could it be the network connectivity between their production and DR data centers that affected their DR strategy?“

 
 

One of the engineers whispered loud enough for me to hear, “work-life balance.” Now, I didn’t expect a non-technical response in a room full of highly technical people. But I knew exactly what he meant. I jokingly responded, “you’re not alone; I’m a recovering workaholic.“

  
 

I shared stories about being called at 3 AM after having worked the prior weekend to fix a database availability issue. I told the story about asking one of my customers for a cold relief medicine on the second day of my 3-day onsite engagement because I had a SharePoint farm upgrade go-live scheduled immediately after. The sleepless weekends because I was the only scheduled on-call DBA, the missed family holidays because I’ve been on a 7-hour conference call with a customer to fix an issue, and many others that I know you can relate to. I can imagine you smirking just thinking about your own experiences.

  
 

I further asked for their personal stories. We spent our lunch breaks with the engineers sharing their experiences.

  
 

Guess what the main theme was of our Always On Availability Group design discussions?

  
 

  
 

I sketched a high-level design of the proposed infrastructure – a stretched, multi-site Always On Availability Group that will leverage Distributed Availability Groups in SQL Server 2016. Every design component circled back to the main theme: work-life balance. We wanted to design and implement the solution to minimize downtime – so we could avoid getting called at 3 AM to fix an availability issue. We tried our best to simplify the solution so that the operations engineers can quickly take over the care and feeding of the infrastructure after go-live. From quorum configuration to multiple network adapters, the availability and resiliency of the design architecture focused on what mattered to them: work-life balance.

  
 

 

The database engineering team listened not because I was the expert. They listened because they knew I cared. The fact that one of my good friends is their lead database engineer was a plus. They knew I understood their pain, they felt that I cared. Because I did.

  
 

  
 

I’ve made it a standard practice to find the human aspect behind every technical issue. It’s hard because, truth be told, we geeks would rather work with machines than humans. Isn’t this why we’re in this field in the first place? Computers are logical and rational; humans often times are not. Computers can be fixed; humans don’t want to be. But instead of being logical and rational, why not start with just being curious. Ask a lot of questions. Listen. Ask follow-up questions. As the late Dr. Stephen Covey once said, “seek first to understand, then to be understood.” You’ll be surprised at what you’ll find out and how easy it is to understand someone when you are curious.