"Trust" is a very strong -- even loaded -- word when it's applied to working relationships. It takes us beyond issues of competence and confidence into the realm of ethics. I may think a colleague is not very good at his job, or I may lack confidence in his ability to predict when something will be done, but that is not the same as feeling he could simply be lying to me. Trust does not take root immediately, and once lost, regaining it can take much longer.

"Trust" and "partnership" are words that go together. Without trust, there is no real partnership. That we can, going on 60 years into the computer age, still feel the need for an article on this topic tells us how difficult and intractable the problem has proven to be. Anybody who purports to have a general "solution" is a charlatan. But we can't just give up. Every case of mistrust and failed partnership is different and requires a tailored approach, even if the causes seem similar on the surface. As Tolstoy wrote, "Happy families are all alike; every unhappy family is unhappy in its own way."

Many years have passed since CIOs despaired of CEOs ever viewing IT as strategic, but that has not meant that existing IT organizations easily transitioned into being strategic partners. The sometimes spoken, sometimes tacit message of CEOs was, "You don't have to convince me that IT can have strategic value for our business, but I'm not convinced that our IT folks could deliver it." Unfortunately, they were too often right.

More and more, enterprises have cut back or even cut out their IT organizations' roles in the provision of IT. The trend started many years ago when the mainframe lost its monopoly on computing power, first to the departmental minicomputer, then to the personal computer, and now to tablets and smartphones. And it's not only hardware. Potent software packages are more and more handling routine IT needs when IT provides no opportunity for proprietary competitive advantage. Inhouse IT people frequently play a secondary role, with the heavy work of implementation done by consultants from the vendor or a third party.

Outsourcing was, in its initial vogue a quarter-century ago, thought to be a pain-free way around the annoying and frustrating task of directing and managing IT, but it has not been a magic wand. Success depends on a flexible partnership, but too often the partnership talked about so enthusiastically in the negotiation phase degenerated after the contract was signed into finger-pointing and nickel-and-diming from both sides.

WHY THE TRUST ISSUE PERSISTS

Causes of Mistrust

How did this happen? There are many historical reasons, some familiar and some not talked about so much:

• Technical specialists and credentialed professionals tend to be more challenging to manage and work with than people in the more traditional business roles of administration and selling, and they are frequently open to the accusation of "not being very businesslike." They may identify more with their specialty than their organization. This is true of doctors, lawyers, engineers, scientists, professors, and, yes, IT people. But all of these folks, with the exception of IT people, lie at the core of their enterprise. What's a hospital without doctors or a university without professors? Unless they become truly dysfunctional, one puts up with their foibles.

  IT people are a different story. They started in a support role to overhead functions like accounting and production management. They didn't, and for the most part still don't, have formal credentials attesting to their professional training and standards. Like comedian Rodney Dangerfield, they "don't get no respect." (Yes, I know they get plenty of respect in so-called new economy enterprises that are built on IT, but such companies that survive do not typically have trust issues.)

• IT is difficult. There is no way around that basic fact. Whether it's getting a crashed system back online or designing and debugging a new application, the level of detail and concentration needed is extraordinary. As the field moved from batch processing to online to the Internet to mobile, the complexity increased as fast or faster than the effectiveness of techniques to manage it. Complexity plagues even the IT product powerhouses, as the steady stream of updates and bug fixes attests.

• IT software isn't just soft, it's intangible. Progress in development and implementation is extremely hard to gauge. There's no clear physical evidence. Predictions can prove wildly optimistic, even when made honestly with the best information at hand. Murphy has a field day.

• Nothing diminishes trust like overpromising and underdelivering, and few fields have "excelled" at this like IT. Yet without overpromising benefits, much of value would never have happened. Strategic lying (or more politely, shading the truth or mental reservation) has not been unknown. Many IT heads, particularly in the early days, knew that if they were candid about the likely cost of a worthwhile project, particularly if the risks and uncertainties were factored in, the project would never happen. So following the maxim that it's easier to ask forgiveness than get permission, IT leaders would give overoptimistic estimates, betting that the results would be good enough that the suits would not go ballistic about the overrun incurred to get them. Sometimes these bets worked out, and sometimes they didn't.

• IT has been beaten up so much for real and perceived failings -- not focusing on what's most important for the enterprise, unpredictable delivery and performance of what they undertake, a lack of measurable business results -- that IT managers and their people often go into a defensive crouch. In their eagerness to please, or at least stem the day's criticisms, they only reduce their credibility further.

• IT "thinking" is almost contrary to human nature. We evolved in an analog world where ambiguity was everywhere, and we learned to cope with it. But IT has no tolerance for ambiguity; it's zero or one -- everything must be spelled out and thought through. Not surprisingly, most people who are good at IT have a very different skill set and approach from most of their non-IT counterparts. (Legal work comes closest. Getting the details right is critical, and the legendary unreadability of legal documents comes from their need to dispel ambiguity.) The two worlds don't quite understand one another and don't naturally play well together or even much like one another. (Yes, the preceding does a lot of stereotyping, but isn't stereotyping really just an informal application of statistical theory?)

• A corollary of this is that IT people tend to be less adept at office politics than most of their business counterparts. They are craftsmen in a world of organization men, jungle fighters, and gamesmen. ¹ A senior person from an outsourcer or a vendor may seem refreshingly smooth but may be dangerously so. Weiler's Law ² applies: "Nothing is impossible for the man who doesn't have to do it himself."

• The CIO role, originally defined in the mid-1980s and ballyhooed by consultants and academics, has not been uniformly successful. Finding people who have the technical chops to command the respect of IT people and the broad vision, style, and personality to command respect in the boardroom isn't easy and never will be.

• Canned methodologies can come across as time-wasting, flank-covering bureaucracy and often are exactly that. Worse, the long-used (and misused) waterfall methodology for developing applications gets in the way of collaborative problem solving. That approach isolates IT people, further exacerbating the "don't play well together" problem cited above by leaving people in their comfort zones and thinking in terms of "them vs. us."

• A lot of IT work since the beginning has been shoddy. "Building codes" governing architecture and design were decades in coming and still frequently honored only in the breach. Documentation of designs and programs has always been a problem, suffering from poor quality when it exists at all. Years of quick-and-dirty fixes have left a legacy of undocumented cat's cradle systems. In defense of IT, much of this was done under brutal time pressure, but then it was never cleaned up afterward -- dues to the past just kept accumulating. Cynics outside IT suspect a job-preservation motive when only good old Jack has the foggiest idea of what's in there.

• Many IT people tend not to want to show work in progress, preferring to wait for all the stated requirements to be met, because they expect (too often correctly) that they'll have to spend most of their time explaining why features aren't there yet. So when the result is not visible until it's born full-grown on a half-shell, it may not quite look like Venus to the business people. The "try it and fix it" approach is, unfortunately, not instinctive.

• When dealing with a request or requirement, the IT person's first thoughts are about what is really involved, so she attempts to flush out details the requestor may not have even thought of. In the meantime, the requestor, impatient with gory detail, just wants to know when it will be done and at what cost, information the IT person cannot simply conjure up on the spot. The frustration is mutual, as each sees the other as vague and mealy-mouthed.

• Governance structures that look reasonable on paper turn out to be stilted, cumbersome, and boring for non-IT executives, thus losing the support of the general business executives they were designed to bring on board.

• Technology turbulence, combined with protracted implementation, means that applications look and feel obsolete even before they're delivered, guaranteeing disappointment.

• IT managers and people have to walk a fine line between being too tech-centered and becoming technically obsolete. Now that IT innovations get a lot of general media coverage, IT people look bad if they're not up to date with the new new thing their non-IT counterparts ask about, yet they can't be seen as treating technology like the proverbial child with a hammer to whom everything is a nail.

It's Not All IT's Fault

IT people must shoulder much of the blame for a poisoned relationship but by no means all of it. Not all their wounds are self-inflicted:

• Managers of functions getting new IT have gotten away too long with treating IT as a spectator sport in which they have no accountability for achieving the promised results. If IT has delivered what the business asked for and the projected benefits are not realized, IT is not to blame. Yet they have often ended up as the fall guys, outmaneuvered by cannier office politicians.

• People who are not conversant with how IT applications are built get frustrated when they are told that what they think is a simple request is actually complex and thus will take some time to complete. When this happens, they suspect that the IT people are lazy, unresponsive, or incompetent. When the opposite happens and IT delivers something surprisingly quickly, it's taken for granted.

• Business turbulence has not helped. Even with techniques like prototyping and Agile, there is no escaping the fact that IT projects take time. While nimbleness in business is a great virtue, changes that depend on new IT need to be thought through more thoroughly than changes that can be implemented by fiat. Some turbulence can't be avoided, but gratuitously jerking the business around because of some new wheeze from a consultant or academic is a sure way to waste resources and generate ill feeling about long-lead items like IT.

• Obsession with IT's cost lies at the heart of many partnership issues. Too many CIOs have fallen into the trap of trying to be "more Catholic than the Pope" in cutting costs, as if that will be remembered favorably when the IT function is too hollowed out to take on an important effort next year.

• Negative views of the IT function, even if justified, have meant that good ideas and advice have not been solicited when business units have contracted with vendors directly (see the sidebar "How Not to Buy a Package.")

SO WHAT CAN WE DO?

This is no "Clear History" button to reset a troubled relationship. There is no fairy dust that will make stereotypical IT people and stereotypical business people suddenly understand one another and enjoy working together. But as any marriage counselor will attest, homing in on the real issues, clarifying them, and gaining agreement that they are critical is a great place to start. The more clearly and tangibly the issues can be articulated, the more likely that common ground can be found. Purging the discussion of "You always..." and "They never..." sentences is key, because they're (almost!) never literally true. There are undoubtedly many ways to do this (see, for example, the sidebar "Making Peace in Client F"), but here are a few basic principles:

• Colocate. Perhaps the most important principle is colocation. "Nothing propinks like propinquity," as an Ian Fleming ³ character said. I have been continually amazed by how organizations exacerbate the them/us divide by physically separating IT people from the people they're supposedly helping. Colocation not only humanizes the "other," it also enables collaborative problem solving instead of throwing documents over a wall. IT needs to be more than just a construction worker; a better analogy is architect, a professional who can identify and help the client evaluate possibilities and options and clarify the inevitable tradeoffs so as to achieve the optimal combination of capabilities, cost, and, in many cases, implementation timeline. (This use of the word "architect" should not be confused with specialized roles like data architect or enterprise architect; they're related but not the same.)

• Build understanding of each other's jobs. Having an IT person sit with a customer service representative or a field salesperson or an operations manager, for example, can provide more insight and stimulate more creativity than any sheaf of documents. Likewise, explaining to a non-IT person in jargon-free language why different options for fulfilling a need can create very different levels of complexity is better than demanding that she just say what she wants; it can both reduce costs and improve satisfaction. Of course, the business person must be open to this.

• Deliver faster. In terms of the substance of IT's work, there is probably no element more important to improve than speed of execution. This depends on modern techniques that work best with teams that include non-IT people at every step, fully incorporating the try-it-and-fix-it approach.

• Make implementation in the field a real team effort. Every new IT capability profits from tweaking as its actual use reveals things that could have been done better. Again, collaboration helps home in on the greatest improvement for the least cost.

• Use methodologies wisely. Methodologies serve an important purpose, but they become counterproductive when they are so arcane or jargon-laden that non-IT people (and more than a few IT people) tune them out. They need to be explained, not imposed.

• Identify and root out management controls and practices that are broadly viewed as unproductive. Managers in and out of IT need to focus less on mechanisms and more on the quality and productivity of the interactions of their people as they venture out of their comfort zones. Putting cats together in a bag does not turn them into friends.

MAKING PEACE IN CLIENT F

Client F, a multiline insurer, had engaged a boutique strategy firm to help them set direction. It soon became clear that almost any direction required a lot of new IT and that their IT situation was beset with mistrust. Teaming up with the strategy firm, which had compiled copious notes documenting strong negative feelings about the IT organizations (and vice versa), I launched a multistep process in which I:

• Interviewed a cross-section of the organization, from divisional CEOs to first-line supervisors both in and out of IT, to obtain a wide range of views of the IT situation.

• Extracted near-verbatim quotes from the interview notes, larded with a number of quotes from other clients with similar issues that I might plausibly have heard in Client F but had not. (When people don't say what they might have been expected to say, it can be as revealing as what they actually do say.)

• Circulated the quotes in a questionnaire to a larger cross-section, asking respondents to rank each quote on a 5-point Likert (strongly agree to strongly disagree) scale.

• Segmented the results according to whether the respondents were in an IT unit or not.

• Presented the results in a workshop of the interviewees, showing where the segments agreed and where they didn't. (Where they agreed about a negative statement, perceptions at least matched reality.) The real work to come concerned the areas where the perceptions did not match. The objective was to zero in on root causes of the dissatisfaction with IT.

• Circulated a deliberately incomplete -- and in some cases, a bit off the mark -- set of root cause conjectures to get the discussion going. Respondents' homework was to prioritize the consensus set of root causes.

• Held a workshop to agree on a set of actions, again presenting incomplete ideas to seed the discussion.

• Formed multidisciplinary teams to address specific actions.

• Followed up with individual teams.

Most of the proposed actions were implemented. The situation did not become nirvana, but it got a lot healthier.

.

None of this is magic. None of it is guaranteed to work if people don't want it to. Even if it helps the organization, it won't work for every individual. There are people, particularly in IT, who will not thrive outside their comfort zone, but if they're exceptionally strong contributors behind the scenes, that may not be a problem.

I don't suggest that you rule out team-building exercises, but I suspect I am not alone in finding them a bit contrived and hokey, especially if participants go right back to business as usual afterward. I also suspect IT-oriented people are more likely than most to be skeptical if not downright cynical about them. In short, nothing builds teamwork better than real work toward a real goal, done as a team.

There will be idiosyncratic factors that the general guidelines above will not address -- remember what Tolstoy said about unhappy families -- and thus having a facilitated process to identify them is vital. It need not (and should not) be a Big Deal preceded by fanfares and drumrolls. There may also need to be staff changes; some toxic history simply can't be overcome. At its heart, all of this is just common sense and management in the deepest sense of that word.

ENDNOTES

¹ I owe this useful typology to Michael Maccoby, as set forth in his book The Gamesman (Bantam Books, 1978).

² A.H. Weiler was a writer, editor, and critic at The New York Times for 50 years.

³ Yes, that Ian Fleming. In Diamonds Are Forever, Felix Leiter, a wise older spy in the game, offers this adage to James Bond. American diplomat George Ball often quoted it.