Microsoft, Ex-Presidents and Trust

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

I just finished watching the funeral for our 38th President Gerald Ford and was struck by how often those eulogizing him used the word “trust.” Here was a guy who never sought the office of the presidency and yet was brought in time and again because he was the most trustworthy person anyone seemed to know. I was particularly struck by the number of things he accomplished but never really got credit for until the end. And how, now that his life is over, it was his integrity that will be remembered above all.

In our IT world there are two vendors who have traditionally stood out when the question of “trust” is raised. IBM, who has historically ranked number one as the most trusted, and Microsoft, who traditionally ranks in the least bracket in the range of vendors I’ve studied.

IBM sold that trust cheaply in the ‘80s, and the result was the firing of their CEO and the loss of much of what made IBM the powerhouse it once was. IBM has recovered somewhat. And while not nearly as powerful as it once was, I believe that were I to survey people on the company today, only one firm might challenge it for the “most trusted” ranking: HP, who might actually win now.

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

Microsoft has been a conundrum, because it is the only company that actually splits the base. When I used to survey on the company it came in as a strong No. 3 in terms of trust, but had a massive lead when it came to distrust, and was the only company that had strong positions at each extreme. Today I believe Open Source wouldn’t be the power it is if it wasn’t for this high level of distrust for Microsoft. Yet conversely, the fact that Microsoft didn’t follow IBM’s catastrophic slide is because a significant number of companies still trust it highly.

As we begin the New Year I think the value of trust should be discussed – specifically, why maintaining it has as much to do with the IT executive as with the vendor.

Who Owns Trust?

For Microsoft, when I looked at the root cause of IT distrust, it generally came down to two things. One was that Microsoft simply didn’t treat senior IT managers as they expected to be treated. Typically if you met with an enterprise level vendor as a CIO you would be wined and dined often given lavish gifts and maybe even get free travel in the corporate jet. Microsoft generally made folks pay their own travel and the “gift” was a trip to the Microsoft employee store where they would be offered the employee discount on anything they wanted to buy. As an ex-Internal Auditor I have mixed feelings about this part of the problem.

The other cause seemed to be directly connected to how closely the firm actually worked with Microsoft. For those that had purchased heavily and stayed closely connected to the firm through deployment and service, the relationships were generally strong and this was reflected in a high IBM/HP-like score. For those that used third parties (who often generically blamed problems on Microsoft) and systematically treated the company like a packaged product company (which it does kind of look like) the result typically was low trust. It was almost as if, when you were doing the surveys, you were talking about two different companies and – through the eyes of the buyer – in a way, it was.

In the Microsoft example, while the loss of trust clearly damaged the vendor, the problem should have been jointly owned by IT but clearly wasn’t. Much like any relationship, if it isn’t nurtured, protected, and prioritized it will likely degrade regardless of which side is at fault.

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

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.