My personal calendar for the past few weeks have been filled with visits to hospitals, clinics and other medical professionals after what happened to my wife last March. Growing up, I hated visits to hospitals. It’s probably because of all the medications I have had to take to treat primary complex. Show me a syringe used for vaccine and you’ll see me having goose bumps in an instant. I’ll be the last one to visit a medical facility unless it really is that critical, like what happened to my wife. It’s like the classic story of the hero conquering all odds for his princess – except that “all odds” in this case is a simple fear of hospitals, doctors included.

To conquer this fear, I used the time I spent accompanying my wife to observe how medical professionals work. Here are a couple of things I observed that helped me become a better SQL Server DBA. I realized that I’ve already been doing some of these but it’s interesting to see it from a different point of view.

1. Master the art of the triage. By definition, triage in the medical field is the process of deciding which patients should be treated first based on how sick or seriously injured they are. Interestingly, triage is considered one of the most challenging job of a registered nurse. That’s because it requires certain skills that have not been taught in nursing and/or medical schools: organizational skills, critical thinking, customer expectation management, communication skills and quick decision-making skills. I remember hearing the non-stop, sometimes irritating sound of the call buzzer from my wife’s hospital bed. My wife further explained that this is for the patients to call the nurses in case they need anything. No wonder it kept ringing. The nurses need to quickly assess how important the call is and whether or not they should immediately address it. Better yet, maybe assign it to an intern. As SQL Server DBAs, we are constantly bombarded with numerous requests from business stakeholders – from queries running slow to joining in on a conference call. Before immediately jumping in on the task, ask yourself these questions: “Does this require my immediate attention? Will this task take me away from something that only I can do? Is this a business show stopper?” We SQL Server DBAs need to train ourselves to solve problems that have the biggest impact to the organization.
2. The term Service Level Agreement is really a five-letter word. No, this isn’t an attempt to test your vocabulary. It’s an attempt to show you what service level agreement (SLA) is from the point of view of your customers. Let me explain. When we had to take our youngest son to the ER because of an accident – he hit his head hard on the edge of the bed – we immediately drove to the nearest hospital. When we got to the ER, we were asked to fill up some forms – while they applied an ice pack – and wait. And we waited. The five-minute wait became fifty. And then some. After waiting for two hundred seventy minutes, the doctor came to see our son – for less than fifteen minutes. As we were walking out of the ER, our son jokingly said, “I think I already feel better because of the wait.” Guess who’s going back to that hospital even if it’s the last one available? Certainly not us. Now, as SQL Server DBAs, we don’t get to decide what the SLAs are for the different databases that we manage. But we can communicate the need to clearly define an SLA to business stakeholders. Because if we don’t define SLAs, customers and stakeholders assume that everything will be attended to immediately. It’s called expectation management. Which is why I said that SLA is really just a five-letter word spelled as TRUST.
3. Communicate, don’t regurgitate. As the cardiologist explained the results of my wife’s ECG test, we can’t help but wonder about how what he’s saying resonates with other patients that he has to deal with. Sure, my wife understood everything he said because she has a medical background. He didn’t even have to explain everything – it’s all in the report. But what about for those who don’t have a medical background? We humans tend to be afraid of what we don’t understand. Imagine what it feels like to be on a hospital bed after a stroke and hearing words that you don’t understand. “Is he reading my death sentence?” Similarly, we SQL Server DBAs talk to business stakeholders about the DBCC CHECKDB job that should be running on our databases to detect corruption on the global allocation map (GAM) pages. Or the SELECT * statement running on the database that retrieves all of the columns and does a table scan instead of an index scan. No wonder the business stakeholders think that we’re not doing a great job. We need to properly communicate what we do in ways that our listener will understand. Instead of talking about DBCC CHECKDB, why not refer to taking your database to the doctor (a.k.a. you, the DBA) to see if something is wrong so you can fix it before it gets worse. When your listener asks why you need to do so, tell a story instead of regurgitating SQL Server Books Online. They will remember you more when you do so.
4. Care more about the people, not just the job. As I was reading the whiteboard containing the notes about my wife’s status, one of the nurses came in. The nurse started asking questions – how my wife was doing, how the kids were doing, whether or not she was expecting more visitors, was the hospital menu good enough, etc. You can see how she was really passionate about her job and how it is reflected in what she does. The nurse even said that she treats her patients like how she would serve her family. Contrast this with another nurse who came in to check my wife’s vital signs and immediately left afterwards. I guess my wife was just another item in the checklist of patients that she has to visit. As technical professionals, we tend to forget that there’s an individual behind that storage area network. The SAN administrator is not intentionally trying to make your life harder by thin provisioning the LUNs on your database storage. Nor is the network engineer trying to make your life harder by implementing seemingly complicated firewall rules.  Maybe they have a reason why they do so. By understanding the individual behind the job, we may be able to figure out why they do what they do. Unfortunately, they didn’t teach empathy in computer science courses which is why it is a challenge for us technology professionals to do this intentionally. As former US president Theodore Roosevelt once said, “People don’t care how much you know until they know how much you care.”

While I still don’t look forward to another visit to a hospital, it was a fun experience seeing and learning how medical professionals can teach us SQL Server DBAs a thing or two about becoming better at what we do.