Microsoft, Ex-Presidents and Trust: Page 2

Posted January 8, 2007

Rob Enderle

Rob Enderle

(Page 2 of 2)

Why Trust is Important

I could argue that Open Source as a concept was created largely due to the distrust that surrounds Microsoft and UNIX vendors. Given that it was UNIX that was most hard hit by Linux, it is hard to argue that if folks were satisfied with where they were they wouldn’t have changed. And the UNIX vendors as a group didn’t cooperate with each other soon enough nor did they respond to the move to x86 hardware fast enough to protect their own base, and a long list of empty promises just made things worse.

Related Articles
Are You (And Your Apps) Ready For Vista?

SOA Software Pushes Workbench Governance

Get a Life: Enterprises Eye Potential For Second Life

IBM Signs on For Small Business

FREE IT Management Newsletters

Microsoft should have been the beneficiary of this problem but trust actually appeared weaker with Microsoft, and the Linux wave was fueled and grew to near tidal proportions. At the core of this wave is a sense of distrust that forms the need to actually look at source code because vendors are not trusted to do what they say they are doing. This is true even though few IT departments have the time or the skill-set to analyze complex products to the level of detail required for a true operating system review (most seem to think someone else must have done it).

The fact that these proponents often seem to trust strangers more than they trust vendors is telling. And it creates, at best, an uneven trust standard when it comes to Linux and Open Source. Both Novell and Red Hat, as smaller service-oriented companies, tend to do more to engender trust but I often wonder if they truly understand its importance.

The reason trust is important is that when you trust someone you are confident they have your best interest at heart. The reason it is important to assure trust is to, on one hand, make sure they don’t take advantage of you (blind trust is stupid) and also, to make sure you don’t waste substantial time and effort making sure a vendor is, in fact, behaving in a trustworthy fashion.

My overall sense is that you have two choices when faced with a loss of trust with a critical vendor. You can attempt to fix the relationship through escalation and staffing changes, or you can extract the product and switch to another vendor. However, if the problem was largely or partially related to how you handled the relationship the experience with the new vendor may turn out to be worse. In fact it often is, in my experience, suggesting the first path should come first, and only if you are sure you can’t repair the relationship should the second be taken.

This is as true with Novell as it is with Microsoft, with Oracle as it is with IBM, and with both Sun and HP. Saving a relationship with a vendor is virtually always vastly cheaper and less painful than extracting that vendor because the dependencies are almost never known.

One of my first IT experiences as I transitioned between Finance and IT was the removal of a national payroll vendor who wasn’t meeting our expectations. We got a call after the new contract was begun from our CEO, who informed us that the vendor we had just moved from was also our largest national customer. A lot of career blood was spilt on that deal and we didn’t even see it coming (there were a lot of Finance and IT executives that signed off on the change). We ended up retaining the problem vendor and working harder on the relationship, and the result was actually better than anyone expected.

So my advice is, if you have a vendor you don’t trust, try to analyze and fix the relationship first. If you can’t, then find a way to replace them because it makes no sense to retain someone in any capacity you don’t trust. Oh, and you may want to watch the vendor gifts. I saw a number of folks get new careers because they accepted things they shouldn’t have over the last 5 or 6 years and auditors are looking.

Page 2 of 2

Previous Page
1 2

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.