Every once in a while I run into a customer with a very specific request: Please do “this” down to the very last detail. I might take a look at the request and think, “Hmmm… I don’t know what they’re trying to do, but this doesn’t look like a good idea on the surface. I wonder what’s up.”
For example, I once had an Oracle customer log a ticket asking me to run the SQL statement: “alter database character set…” If you know anything about Oracle you know that changing the database character set isn’t a SQL statement, it’s a huge, nasty project.
So I’ll ask, “What are you trying to do here?” The responses range from an actual explanation to a grumpy, “Just get it done”
If we engage in a dialogue either I’ll get the picture and we’ll all move forward; the customer will see that their request may not get them where they want to go and we’ll figure out something else; or something in the middle. Point is, we’re moving forward and the customer gets what they want. I presume most of the time that this is why I’ve been hired.
If I’m told to shut up and just do what I’m told, we may have several problems:
First, if something goes wrong as a direct result of the request, I’m sort of involved now. If I make a mistake, I’ll own up to is, but if I’ve just been the IT monkey, it’s hard to accept much responsibility, which leads to bad feelings all the way around.
Even if nothing goes wrong, I’m not really adding a lot of value here. If all I’m doing is typing a request into the keyboard, did the customer really need to pay my fees?
Third, I don’t know what’s going on. That may not seem important, but if your IT service provider, DBA, or whoever you depend on to get things done for you doesn’t have any insight into the big picture, they can’t watch out for you in the future. I hope the reason I was hired is because I know a few things and provide value. I need information to provide said value, so my questions are never questioning the intelligence of the requester, I just want to know.
Some thoughts for both customers and their service providers:
You (hopefully) hired a service provider because they are smart and maybe because they know a bit more about a subject than you. Let them ask questions. You’re not going to get their A-game if you don’t let them in on the plan.
Try not to tell them how to do their job. Different shops have different requirements and regulations, but that’s not what I mean. A remote DBA firm deals with nothing but databases – part of their value is derived form repetition and efficiencies of scale. If they’ve applied the same patch 100 times, there’s no need to question every keystroke. Focus on clearly communicating your requirements and expected results.
For service providers:
Your customer isn’t an idiot, so don’t treat them like one. They know their business waaaay better than you, so assume they are trying to do the right thing even if you don’t agree with the tactics. If you receive a request that doesn’t make sense, always assume it’s you who don’t know what’s going on, not your customer.
Don’t be afraid to educate. If your customer doesn’t know anything about MySQL replication, for example, teach them; tell them why you want to take the approach you’re taking. Most people like to learn and they like to know what’s going on. If you expect to be kept in their loop, don’t leave them out of yours.
In my character set example, we went through a little friction when I first asked what they wanted to do; however, when I explained that changing the character set is certainly possible but requires a lot of effort, they were ready to talk. Turns out they had an application displaying garbage ACSCII in Internet Explorer. The ultimate solution had nothing to do with the database, but was a big problem nonetheless. We both recognized poor communication was where our friction started, and after a discussion we’ve never had that problem again.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
It’s 2015 and you can now establish totally respectable MS SQL DBA credibility just by mentioning you have been in the game since SQL Server version 9. You may even get the same gasps of shock from some colleagues that used to be reserved for the version 6 veterans.