Steve Jones is in the control room for this month’s T-SQL Tuesday challenge. His topic is a good one. I won’t repeat it here, just look at his post announcing this month’s topic. His topic is discussing challenges we’ve faced when dealing with “customers” (I use that to include clients, managers, colleagues, the business, etc.). I decided to remind myself of some advice to follow here and maybe it will help you as well:
Huh?
How good of a listener are you? How good of a listener are you? Hey.. The post is right here. We have distractions. The other 50 requests our manager has made top priority, remembering that we were supposed to remember something important for our spouse, #sqlhelp tweets coming up, e-mails that people expect to be handled like a phone call, etc. We have a lot of excuses but they all stink. Actually listen to what your customer is asking. Listen to what they are not asking. Ask follow up questions. A lot of chicken little syndrome can be cured by realizing what the real request was and not what you assumed it to be by reading in between the lines. Listen to your customers.
Huh!?!?!?!?!?!!!!!
So the listening skills net catches a lot of problems. Sometimes, though, you are just being asked to do something, well, stupid. Something dangerous, wrong or that costs way too much (now or later). Sometimes the request is harebrained – But the perceived need is not. That’s right, you can get a whacky order but the problem the customer is facing is a real problem. It causes real issues and they really want it resolved. I’m almost ready to accuse us of not listening the first time. Why? Because I’ve done it myself.
Consider, “Please setup replication to move data from this database on Server A, to this other database on Server A (not a typo) with a new snapshot every hour. No, there is no budget for separate disks, just put the replicated database on the same volumes. Thank you, have a good day”. You could do it and block your nose, whine and tell them person requesting how stupid they are or… You could go back and ask something innocent like, “What are you trying to accomplish?” Maybe in this case it is a reporting environment where they can offload some operational reporting queries. You could consider other options with them. Do more listening and ask fair questions.
Try on their shoes
If it is a feature or software need the above two nets catch most. If it is a disagreement over a principle or issue then before listening to that uncensored, quick to anger, slow to forgive ego, ask yourself what it looks like from their point of view. Ask yourself what you did to screw this up. Ask how you could do more to make something work out better. Basically this tip is force the pride out of the situation, give up your assumed “right” to be angry, give up the desire to make yourself right and take the first step in making the situation right.
[Muttering and Grumbling]
Well sometimes even after humbling yourself, actively listening, gently suggesting alternatives and trying to be customer focused, they still want what you think is wrong. You have two choices here, I think:
- Do it, but don’t roll over. Just do what they want. Waste that money, install that software, sacrifice performance for some feature that they don’t understand. Get ready to bill more time, work more hours and spend more money to change it later. Do the best job you can documenting concerns, mitigating risks and advocating for the right approach in the little tasks along the way. Perhaps talk about incremental changes to make in the future and maybe even get a project plan for undoing the bad aspects in the future.
- Don’t do it. How bad is it? I guess you need to ask yourself that. Is it something that you know is destined for failure or serious issues? Are you sure your pride isn’t fooling you here because someone called you wrong? Maybe it is time to end the relationship and look for new work or new clients.
I wouldn’t advise bluffing it is dishonest and your credibility and integrity are important, but I have actually been in a situation where I couldn’t go the direction a client wanted because I thought it was detrimental. I don’t even recall the specifics but it was a case with a couple players in there. Myself and a vendor provided consulting team that was providing bad advice. Contrary to best practices and advice I felt was dangerous for the client. I told them this and said I would be more than happy to direct them to other resources, even answer a quick question if they ever had any in the future but I couldn’t work in that scenario because I felt the outcome was already pinned to less than success. I ended the relationship and a short time later I received word that they wanted to work with me on their SQL Server as the exclusive resource with the vendor team not working on the database. I went back and they ended up being a longer term client with a series of successes. Before I closed that door, I needed to be sure that I wasn’t trying to be “right” or win an argument but that I was truly in a situation where I couldn’t be an advocate for the client.
The Well Informed Customer Is Always Right
In summary, I guess I am just reminding myself (and anyone reading) that there is a bridge between what a customer needs and what they want. Sometimes they don’t know what they are asking for (hence the title, borrowed from the Princess Bride sort of) but they know what their problem is really well. If we can talk through a problem and use our listening skills, humility and position of advocates for the customer (and their data) we can, more often than not, get to a common ground that works. So let’s try and operate with that goal in mind. Not being right. Not proving the customer/manager/vendor/client wrong.
Thanks for visiting. Some Related Posts
Thanks for stopping by during this T-SQL Tuesday. Feel free to subscribe to my feed to see future posts. I wrote about similar topics in posts like:
- Documentation – I hate doing it. So do you probably. But if we want to be good advocates it helps to do this.
- Worked Fine in Development – Because as DBAs, our customers are often developers. We have to get along.
- Unrelated Relationship Ramblings – An example of bad customer service and how it should be.
- Bill Clinton Wasn’t Impeached For.. – It was his failure to own a situation. How do we mess that one up?
- SQL Univeristy – Knowledge Sharing – We either do it and all succeed or don’t and all fail.
- Plan To Fail (Or Don’t plan to succeed) – Today’s post boils down to risk aversion. Part of that is planning for failures.
