Happy New Year, everyone! Sorry I’ve been a bit lax on blogging, but it was a crazy busy last half of the year. I will be doing more blogging this year and there will be some other new things which I’ll talk about soon. All in good time …
Anyway, I’m at the car dealer this morning having my car serviced and I overheard an exchange between a tech and a customer that inspired me to write this blog post. The service person who is handling this customer’s case talks to the gentleman explain what the tech found (or didn’t, in this case). Said customer did not believe him, so he asked for the tech to come out. The tech explains things and how he does his process, including to the point of explaining how he could possibly be seeing what he is. Now, I’m not a deep car guy, but here’s this tech trying to explain how the systems are working together. The guy was having none of it and pulled the “Well, it’s a brand new car. I don’t see why this is relevant.” HE then starts asking the tech if they have a rental car or a loaner which isn’t his responsibility. At no time did I hear the tech raise his voice, and it was not a shouting match but clearly the customer felt like he was being wrong and lied to.
I’ve seen this in our end of the world in different ways. I’ve even experienced it.
I love working with customers. Heck, I’ve built a career on it and wouldn’t have survived this long if I sucked at my job. Ostensibly you’re hiring myself or Max (or someone else, if not SQLHA) because you want expertise. I certainly want to provide that, and would turn down an engagement if I felt you knew more than me or I could be of no help (or didn’t have the bandwidth). Why would I take on an engagement that would ultimately be a problem? The money isn’t worth it.
However, there have been those handful of cases over the years where no matter what you say to someone, they’re in denial. Their problem can’t possibly be the problem, right? Sometimes it is what it is, but people don’t like the answer. This devolves – like the situation I witnessed this morning – into a no win situation. Having said that, if you’re going to keep fighting me, why did you hire me? Why would you hire any expert if you’re not going to listen to them? Could we be wrong? Sure. We’re not infallible. I will admit and own my mistakes or if I am wrong. At the same time, I stand by my track record. You’re not hiring me only for my dashing good looks, you know.
Recently I was working with one of our customers who hit a problem. They sent me an e-mail and I knew immediately what their issue was – it was something I had seen a million times. So based on the little info they gave me, I replied, and lo and behold, problem solved. THAT is why you hire folks like me. Would I have dug in more to see what the issue was if it wasn’t what I suggested? You bet. They were happy and they were not blocked.
I would be lying if I said I know and retain every minutiae about Windows Server, SQL Server, Linux, storage, networking, and so on. It’s just not possible since I do not have a photographic memory. I retain a heck of a lot, and over the years, I joke but it’s probably true: I’ve forgotten more about clustering SQL Server and Windows Server than most people knew. It’s not an ego thing. I’ve just been doing it for 20 years. I still remember lots of little details – even about NT4 – but not everything. It all comes back to me when I’m hands on with the older stuff.
Some things to leave you with:
- Asking for help is not a sign of weakness, whether you are an expert or not. I’m at the car dealer because I’m not a mechanic. If I was an expert, would I be sitting here? NO! So if their customer this morning knew more than the tech, why didn’t he just fix it himself? Which leads into …
- Being a jerk is not called for in these scenarios whether you are the customer or the person working with him or her. Having been in in the tech’s shoes, I felt for the him. The service rep’s job is to handle these scenarios. The customer asked to speak to the tech, but the customer got indignant. Sometimes you get your dander up and no matter how you break things down, how nice you are, you’re attacking them. The right thing to do at that point is disengage.
- When you’re hiring someone, do your due diligence. When we get on a call before we do an engagement with a customer, it’s usually pretty clear we’ve been around the block a few times. It’s up to them at the end of the day whether or not they want to hire us. Some will just consider cost above all. We get that and always work with a customer’s budget whenever possible. But if you want the sun, moon, and stars for the price of a candy bar, chances are we may not be able to help you. The problem with putting budget above all is that often leads to bigger problems. Many times we come in after you’ve hired the wrong person and clean up an even bigger mess. Hiring the right resource up front saves you both time (and often downtime) and money. We’re mission critical guys. We get it. Time really is money – on a whole lot of levels. Work with people who understand the technical and non-technical factors and are invested in working with you.
- Good consultants don’t drain your proverbial blood like a vampire and will say no to work not in their wheelhouse. I’m not working for charity, but SQLHA isn’t going to take your money “just because”. We’ve had companies contact us who we said no to that come back later BECAUSE we said no and they liked that. We were up front and honest with them. No is not a bad word or negative in consulting, contrary to popular belief.
- Someone you hire’s job isn’t to insult your employees nor be a threat to them. Fun fact: I can tell you with 100% certainty I’m not looking to replace you as a DBA or admin, nor staff your company with my cronies. That’s not what we do at SQLHA.
Bottom line: trust your instincts. They are often right. We all need to ask for help, and we can’t know everything about everything, but be smart about where you get your advice and who you bring in to help. If you need some help, contact us and we’d be happy to see what we can do.