As IT managers and CIOs, our businesses charge us to
identify new technical trends and IT tools we can use to achieve a competitive
advantage. At the same time, many of our organizations resist the introduction of
these new tools with ferocity. Sometimes this resistance springs from
budgetary, interpersonal, or political concerns. Other times, though, we come
face to face with a kind of resistance we are ill-equipped to deal with: the
deep seated belief that computers, “technology,” and everything that
goes with them are nothing more than foolish fads that will, in time, pass
along with all of the rest of the business gimmicks in the last fifty years.

As agents of technology, we in IT rarely sympathize with
this point of view. We engage in malicious gossip about executives who refuse
to read their e-mail, call decision-makers who cancel new technology products
“Luddites,” and say those who want to fund their projects over ours
“are stuck in the past.” This contempt, born from our culture and our
beliefs, further exacerbates an already complicated situation. However, as my
mentor once pointed out to me, a bit of listening and a dose of understanding
goes a long way toward defusing fear and even hate.

Why people say “no” reflexively

Assuming that budgets exist and we have a clear business
case, conventional wisdom claims we can move forward with whatever technology
plans we dream up. Yet in reality, non-technical decision-makers often stop us
short without even hearing our case. Why? More importantly, how can knowing why
help us break though these barriers in order to bring the benefits we dream of
to the business?

Over the years I’ve encountered, to varying degrees, the
following non-political reasons for people to resist projects: lack of trust in
the outcome, resistance to uncontrolled change, and a feeling of powerlessness
in other areas.

Although we think mostly about IT, since it forms the core
of our business activity, managers and decision-makers outside of IT confront a
world where computers form a relatively small part of the overall business
equation. In that world, fads come and go with regularity the tides would envy.
Each of these fads promises to make the manager’s life easier by somehow
magically transforming their people, process, and technology into a newer, more
effective configuration.

Unfortunately, most of these fads fail to deliver on their
promises. Why this is, and indeed how to solve it, dominates academic debates
worldwide. On a practical level, it means that any manager with a modicum of common
sense develops an instinctive distrust of anyone or anything claiming to
provide them with an easy solution.

Similarly, most managers with any level of experience have long
since lost their tolerance for the seemingly random changes inflicted on them
by today’s “fast paced” business environment. Change, usually thought
out in some unrelated part of the business, bombards them from every side. Nine
times out of ten these changes do nothing to help any individual manager’s
business unit. Instead, they appear, inflict some amount of stress, then vanish
in another cycle of change.

Together, these cycles of change contribute to a feeling of
powerlessness we try to change with—yes—yet another cycle of fad-based
“process and empowerment” changes. Many of these fads stem from valid
management and psychological theories that we simply never invest enough time
in to make them work. Others really are just pop-psychology wrapped in a fad’s
wrapper and foisted off onto us by people trying to make a quick buck. These
later “methodologies” might have a handful of good ideas in them that
will reappear sometime later in a stronger methodology.

Older managers, who have suffered through dozens, if not
hundreds, of these cycles, tend to feel this distrust the most strongly. One
particularly articulate manager I know explained his feelings this way: “Shannon,
what you just proposed sounds great. I’ve heard it before, though, in the 1970s.
You people failed to deliver on it then too. Why should I think it’ll be
different this time?”

Listen and learn

That last question—how will it be different?—provides us
with both our greatest opportunity and our most common point of failure. Most
IT managers I know launch into a detailed explanation of the new project plans
and cool new technologies, hoping that both will somehow answer the question.

As “different” as the project plans and technology
may be, though, they don’t really tell the questioner what he wants to know. His
question is not “how are the tools different” or “how will you
do the implementation for less money and in a shorter period of time,” but
rather “how will you deliver the promised business improvements despite
the track record of failure?”

As tempting as it would be to launch into a long, detailed
explanation of business process change enabled by new technologies, the
situation provides us with an even more powerful opportunity. That opportunity,
to shut our mouths and listen to what our customer has to say, can slip by if
we try to display our knowledge.

Instead of engaging in ritual display, I’ve started to ask
the following questions:

  • Why
    do you think this project is the same as all of the others to come through?
  • What,
    in your opinion, caused the other projects to fail?
  • Does
    anything about this project strike you as being unique or interesting?

These questions usually start off a conversation that can
last for hours, if not days. During this conversation your new information
source can give you unique insights into his aspect of the business, the
leadership style of people completely unassociated with your department, and a
history of the business’s evolution you can’t find anywhere else. More
importantly, so long as you listen, you can continue building a rapport with
the speaker. Even if you can’t get him to come around to your “point of
view,” that rapport may give him enough trust for him to lift his

Often, as you listen, it becomes obvious that the
“innovations” promised by your project really were promised in the 70s
and not delivered. Worse, the things preventing the original project from
succeeding (e.g., business process or management failures, lack of clear
understanding about actionable information vs. meaningless data, etc.) continue
to exist in the environment. What you do then depends on your situation, your
own experience, and the environment in which you operate.

Sometimes, though, after listening, we discover something in
our own projects we never realized was there: a clear value proving beyond a
shadow of a doubt we want to deliver a real innovation, not just a gimmick. However,
that value, for our clients and users, will not be what we think it is. It will
likely come from some seemingly trivial innovation in interface or system
design that opens up an entirely new way for our client to approach a problem
we did not even know existed.