On the second Tuesday of each month, the SQL Server universe all comes together to blog about a topic. Known as T-SQL Tuesday and started by Adam Machanic (Blog | @AdamMachanic), this month’s T-SQL Tuesday topic is hosted by friend and fellow MCM Jason Brimhall (@sqlrnnr) and he wants us to blog about bets. Specifically, “I want to know about the gambles within your databases or not within your databases that you have seen over the years. When has somebody (a CTO, Developer, Business User) placed a bet that was far too risky in your opinion?”

A friend of mine, someone that is a regular speaker at SQL Saturdays, was recently approached from an attendee of one of his sessions. This attendee was looking for help in setting up a cluster. But this would all have to be done by screen sharing and passing control over to my friend – directly being able to connect to the servers wasn’t an option. Further discussion revealed that the person was doing this without the company’s knowledge – and that the company wasn’t to be told. For, it seems, the person was hired as a senior DBA, but isn’t qualified to do the tasks, and doesn’t want the company to know that (s)he doesn’t have the skills necessary to do the job.

Wisely, my friend turned down this “opportunity”. However, this blog is to be about bets, so let’s look at some of the bets that were made, or were being contemplated. First off, the company placed a bet on hiring this person. I will assume that they did due diligence, doing things like performing background checks and conducting an interview. Their bet was that the person they were hiring for a senior DBA position actually has the skills necessary for a senior DBA. At this point, they have no idea of how bad of a bet they made.

What could they have done differently so that they would have had a better outcome? From my point-of-view, their interview process was not thorough enough to adequately determine whether their candidates had the required skill set. If they don’t have on-staff personnel competent to determine this, they should have spent a little bit of money to hire a competent senior DBA to evaluate and assess their candidates. (Small plug: I offer such a service – you tell me what you need, and I’ll grill the candidates (complete with a lab) to ensure that they know and can do what you need them to be able to do. Contact me for details.)

Other bets that were being contemplated:

• The attendee was willing to let someone whom they had only met at a SQL Saturday do a task that they couldn’t do.
  • How do they know whether the person can do the job and wouldn’t mess things up?
• The attendee was willing to let an unauthorized person into their companies systems.
  • How do they know that this person can be trusted while on the systems?
  • They were willing to take this risk with the potential of being fired.
• If my friend had proceeded with accessing the company’s systems, there are several bets that he would have been taking also:
  • Legal – would the company take legal actions for his unauthorized access to the company’s systems?
  • IMO, it’s a sure bet that there would be security violations occurring. What would the repercussions of those be?
  • If word of his actions were to spread, there would be a loss of reputation – potentially causing future loss of clients.
    • While the attendee might know something of my friend’s background, my friend knows nothing of the attendees. Other than that the attendee is willing to circumvent ethics to keep from looking bad. What’s to keep the attendee from telling others of what my friend did?
  • He might face the loss of insurance – this would mean that he couldn’t consult.

There were a lot of bets being placed in this situation. The company lost – even if they don’t know it yet. The attendee lost – and probably knows it. Thankfully, my friend has ethics and didn’t take this bet, so he didn’t.