A while back, I read a survey that showed that, other than directors of human resources, CIOs were considered the least influential senior executives in most organizations. That got me thinking about the lack of influence that seems to afflict IT in general. It makes me wonder whether some self-defeating assumptions might contribute to this state of affairs.
Technical folks frequently grumble about their lack of influence. They complain bitterly that management doesn't understand the importance and constraints of their work. They object to their exclusion from important decision-making. They are angered by the lack of respect paid to their opinions given the centrality of their work to the success of the enterprise .
But strangely, when given an opportunity to be influential, many demur, backing away from the conversations that result in the making of decisions and policy. This has puzzled me.
Recently, it struck me that this reticence may be related to another facet of technical culture, the idea that deliverables should speak for themselves. Think of how we deliver our products to our users and clients.
There seem to be two modes of delivery. In the first, we casually toss our work into the organizational mix without much ceremony or explanation. This approach brings to mind the image of a hunk of raw meat being thrown to a pack of hungry animals. Our apparent indifference to the reaction of the recipients to something we created with great effort is striking. The other approach is more akin to the unveiling of a statue before a crowd of spectators. We pull back a curtain that covers our breathtaking creation and wait for the adulation of the viewers.
Both of these delivery modes are based on the idea that the deliverables stand on their own -- their merits are so patently obvious, they require no explanation. And both discourage conversation. The casual meat throwers invite no comment from the recipients. After delivery, they leave the recipients to devour the meal. The artists awaiting appreciation become wounded and withdrawn when criticism rolls in. In neither case do the creators participate effectively in a follow-up conversation. Our work, we feel, speaks for itself, and no amount of talk can take the place of that eloquence.
Does the same assumption color our willingness to participate in the conversations that shape the enterprise's direction? My guess is that there is a general feeling among IT folks that the mechanics of influence are tawdry, and the merits of one's perspective and product should be self-evident. Having to explain the merits of our products or argue for our point of view feels like fighting for respect, when it should be forthcoming because of our obvious virtues. IT people are generally very smart and genuinely want to do what's best for the organization. What more is there to say?
But influence doesn't work that way. To get and maintain it requires building personal relationships based on mutual trust and respect. It takes time and effort. It is work, real work. But most of us in IT think of the production as work and all the discussion as diversion from work.
If we're going to become as influential as we deserve to be, we're going to have to start thinking more broadly about building -- not just technology, but also relationships with others in our organizations.
Paul Glen is a consultant who helps technical organizations improve productivity through leadership, and the author of the award-winning book Leading Geeks (Jossey-Bass, 2003). You can contact him at info@paulglen.com .
Read more about management and careers in Computerworld's Management and Careers Topic Center.