Over the last several months, I have been involved in several critical customer escalations (what we refer to as critsits) for Exchange 2010 and Exchange 2013. As a result of my involvement, I ha...
Updated Apr 27, 2020
Version 4.0
Blog Post
I'll usually ignore recommendations that I disagree with. If your recommendation makes something more complicated, more expensive, or is just abnormal (e.g. the ongoing narrative regarding SSL certificate naming, which eventually made it to a fairly logical
place after the CAs put their foot down), I need to know exactly why the simpler, cheaper, or industry-standard method won't work. If I don't get that information, I'll try it my way first. If there's a problem, then I get my answer. (And when the customer
asks me why we didn't do it the cheaper way, now I can actually tell them why.) If there's no problem, great! Sometimes the vendor will eventually acknowledge that the simpler way is fine.
But I've also never had a critical issue caused by my antics. I take full responsibility for anything I do, and I don't recommend others do things my way. But my point is, I think people would follow recommendations more closely if the repercussions were explained
in more concrete terms. Saying "trust us, we have data" or "trust us, we're Microsoft" isn't quite enough for me. :)