I heard deafening screams of excitement in our living room. Curious, I went down to check what was happening. My wife and kids were playing Super Mario on the Wii. I haven’t played this game in a long time so I asked what they were so excited about. The three of them were trying to save Princess Peach from the evil Bowser. The excitement came from near-hit incidents where Bowser could defeat all of them before they even had a chance to save the princess. Their excitement got me to really pay attention to what was going on.
I couldn’t help myself but search for “possible cheat codes” on how to beat Bowser. I’m surprised that there are tons of resources out there specifically on defeating Bowser. I even saw references to published guides about cheat codes. I guess every player out there has one main goal regarding this game: defeat Bowser.
One specific cheat got my attention: how to save the princess without defeating Bowser?
Asking the right person instead of just asking the right questions
If I was to ask every person playing the game, their goal would be to defeat Bowser. Every trick, every cheat, every shortcut. All designed to defeat Bowser. The more efficient the player is, the faster Bowser gets defeated.
Imagine if I asked Princess Peach what the real goal is. I bet her response would be “to save me.” That’s what got me thinking about the cheat code on saving the princess without defeating Bowser.
Could it be that we’re asking the right question but to the wrong people?
I saw this post on one of the forums the other day. This is typical of any question you will see on forums and newsgroups about this topic.
Now, there is nothing wrong with the question. It is a valid question, one that every SQL Server DBA or technical professional would ask. Like searching for cheat codes on how to defeat Bowser.
Often times, I’m tempted to provide the answer that the person asking was looking for. That will be an easy way out. They get their answer, maybe implement the recommendation and become really good at it. At least, I can say I’ve provided somebody an opportunity to become an expert in implementing a SQL Server high availability and disaster recovery solution.
But this is an example of asking the right question to the wrong people.
You ask this question to a bunch of SQL Server professionals and they will tell you what you want to know. The problem here lies in the fact that you miss the opportunity to know what you really need to know.
Who’s Princess Peach?
When designing a solution, technical professionals fall into the trap of asking themselves the question: How do I do this?
Notice the emphasis on I. The solution is designed and implemented based on the one asking the question when it should be focused on the one who will benefit from it. This is where the questions should be directed to the business stakeholders. They are the ones that have a business requirement about keeping the applications or the databases online and highly available. They are the ones that will make the decisions.
So instead of asking “How do I do this?” ask “What do YOU need?” The focus shifts from I to YOU.
What does Princess Peach really want?
Most technical professionals would then respond saying, “But the business stakeholders know nothing about this. I get to be the one responsible for designing, implementing and maintaining it.”
Despite that fact, we are still responsible for asking them what they need. This is where the Alphabet Soup becomes the focus of the conversation.
- What’s YOUR recovery point and recovery time objective (RPO and RTO, respectively)?
- What’s YOUR service level agreement (SLA)?
While the business stakeholders may not know anything about implementing Availability Groups or stretched clusters or what Standard Edition features you can implement, I’m sure they have an idea about the potential revenue loss caused by application and database downtime. Your responsibility is to help the business stakeholders define and articulate what those objectives are by asking the right people the right questions.
Don’t fall into the trap of achieving technical goals like this. You may find an answer to YOUR question. But it might necessarily address the business stakeholders’ goals.