Optimism, resilience, stamina: the make-up of the CTO/CIO

Here’s a disquieting little secret that few of us ever really acknowledge, maybe because it’s rather painful and also an unavoidable part of the fabric of our existence in IT. I don’t know how to say it more eloquently (or less bluntly), so here goes: being in information technology is hard. In our day-to-day dealings with stakeholders, with end users, with management, even within our own ranks, it’s common to hear some pretty discouraging and recurring things, voiced either explicitly or implicitly. For example,

• “what have you (IT) done for us lately?”;
• “what do you (IT as a whole) do all day?”;
• “we’ve been asking for that system for years now and not gotten it”;
• “how can that be so hard? Why can’t you just …”;
• “at my last company we did that in just [names an absurdly short amount of time] and it worked really well.”

A major role of IT management, in my view, consists of steadfastly, repeatedly, and quietly combating these discouraging statements, of raising people’s consciousness of complexities and risk and levels of effort, of building ongoing trust, of establishing a clear and public record of excellence and collaboration. And it necessitates frequently reminding our staff not to get disheartened when we hear indications that we haven’t fully succeeded in that.

It’s normal that business expectations are high. Yet, those expectations are significantly and often unduly heightened by one of today’s realities: lots of non-IT people do “IT in the small”, working with spreadsheets, surfing countless applications on the web, even administering their home networks. But of course, this IT-like work “in the small” comes not even close to having the issues and complexity of enterprise-level systems. We in IT know this, but it’s anything but obvious to others. In essence, we’re in the position of constantly and actively having to fight some very basic resulting assumptions and myths about what we do. Those myths are often held widely throughout a company, including by senior management and boards of directors.

Here are just a few of the myths we combat:

• Software is like a toaster: you get it (or make it), plug it in, and you’re ready to roll.
• Maintenance shouldn’t take much of anyone’s time.
• Most changes to systems (e.g., to accommodate new business rules) are simple.
• Stakeholders’ role is to say what they need; IT simply has to deliver (all of it). Collaboration and careful prioritization isn’t all that necessary and boy, it consumes a lot of time.
• We should keep all data forever; disk space is cheap.
• Industry best practices don’t matter, especially if it means things will take longer. We can ignore best practices and we’ll be successful anyway.

I could (and probably will in future posts) write in detail on each of the above myths, but for now I’ll tell just one illustrative anecdote that demonstrates the kind of world view I’m discussing here.

Quite some years ago, I worked for a company that was bought by a much larger entity. At the time, we were pushing hard to finish the construction and deployment of a revolutionary (for its time) CRM-like system for use in the company’s call centers. One of our stakeholder meetings featured the following statement from a newly hired VP of Marketing: “Well, we just got bought by company X–they have call centers. Hey, why don’t we just snag some of their code?”

Everyone needs to be wary of any systems-related statement that includes words like “just” and “only”. Of course, the notion of reusing other companies’ software, when possible, isn’t something to dismiss out of hand (hence the subsequent rise of ERP packages). But the word “just”, combined with the artful word “snag,” revealed an amazingly dismissive world view about the complexities of building and integrating systems. We had a long discussion with that executive about how the word “snag” pretty much didn’t apply to the level of systems we were discussing.

So again, it’s hard being in IT, and it’s hard being the leader of IT. You need a large dollop of resilience, optimism, and stamina as your psychological armor. It’s definitely possible (indeed, necessary) to break these myths down, but it takes coming in fresh every day, ready to work hard and ready to face the same kinds of misunderstandings of the basics.

As is my frequent practice, I’m going to follow up on this post with another that talks about the flip side: the ways that IT itself can unfortunately perpetuate some of the myths I’ve been discussing.