Back in the fifth grade, I was in a school musical, The GIGO Effect, in which the evil Glitches attempted to corrupt a computer named Mabel with "dirty power." The point of the show was that technology is unable to produce intelligent results without intelligent direction, a truism encapsulated in the formerly popular computer acronym GIGO, "garbage in, garbage out."
I don't think any business leaders are inclined to get their insights on running IT from a bunch of singing fifth-graders, but they could do worse (and generally do, to tell the truth). Intelligent direction is a product of competence. Among IT ranks, competence comprises an advanced knowledge of possibilities, the creativity to derive or invent solutions with that knowledge, and the (un)common sense to assess the implications of such solutions. If you expect to use IT to save money, create capability and reduce work, all at the same time, then you must bring competence to the table, and keep it there.
That's no great leap of logic. Everyone prefers competence. Everyone claims to value competence. And yet your IT still, for lack of a better term, sucks. It's just that simple. What goes unspoken, or at least unheard, is that the way the typical organisation positions and utilises its IT resources sucks.
In fact, it's sucking more as time goes on. Don't take my word for it, ask your own IT pros or someone else's. But why does it suck?
The reality is that, on equal cost, expedience always bests competence. In IT, it is the fallacy that expedience has no cost that fuels its dominance. Read any IT or CIO survey over the past couple of decades and you'll find that the same problems reported this year have been reported every year. Do a little more research and you'll find that with respect to most occupations, IT morale is disturbingly low, stress is ridiculously high and the best people are lost to burnout while the worst are inexplicably rewarded. Project success rates are as comically low as the average term of a CIO is conveniently short. Weakened by inconsistency and misdirection, IT is a perpetual target for interlopers selling snake oil and extremists from the reorganisational churches of IT outsourcing, insourcing or whatever sourcing who promise the converts that their latest buzzword will save them in tidy, graphable, expedient ways.
It's sad, but predictable. Just as the era of quasi- and non-technical IT management hits full swing, the practical applications of computing technology are expanding faster than they can be absorbed, as is the degree to which they impact and integrate with other technical and organisational processes. As the dollar signs increase, decisions that smart money would hedge on more detailed technical and business process scrutiny are shifted up the chain, where sober rationality is represented, but poorly defended from the forces of faith, assumption and truthiness.
Even great IT leaders have been taught to fear the invisibility and guaranteed criticism that come with IT done well far more than the accountability that rarely arises from IT done poorly. Chasing visible contribution at the expense of strategic leadership puts IT under the gun for responsibilities it shouldn't have, while ensuring it will never have the influence necessary to address the responsibilities only IT can.
There is a bright side. As far as I can tell, organisations that do IT well are no different than those lost in the sucking vacuum of the GIGOsphere. The leadership need not be particularly tech savvy, the IT spending need not be high, and in most cases, organisations need no restructuring to become effective. Be it subconscious or by epiphany, they have stumbled upon a valuable tool: A definition.
You're skeptical. Good, but stick with me.
"Engineering," like "information technology," is a term that is thrown around in "advoun" form, not quite adjective, verb or noun, and meaningless out of context. This is why people differentiate engineers vs technologists, mechanical vs electrical, even train vs sanitation. They even use the term "interdisciplinary" so everyone knows when the line isn't clear. The all encompassing IT industry, however, can't even decide what to call itself decade to decade, much less what to call many of its unique disciplines. So, you can't really blame the executives for misusing the term and failing to identify IT's mission, direct its efforts, calculate its expenses, measure its performance and address its leadership needs, much less move it forward with purpose. They can, however, be blamed for not listening.
I have observed that where IT is done well, it is referred to in very narrow organisational terms. I have done my best to reduce these to a definition:
Information technology is the art of managing an organisation's processes by establishing and maintaining computing frameworks.
I am aware that this is not the Wikipedia definition (feel free to add this one if you are so moved). The Wikipedia definition doesn't distinguish IT's ultimate role in an organisation from the many highly computer dependent tasks an organisation may undertake. There is a difference, and those who recognise it have an advantage.
You're still skeptical. Good, hang in there with me.
Picture, if you will, a CPA firm with five staff accountants handling the finances, and 100 CPAs who work with customers. They are all accountants, all doing "accounting work," but with respect to the organisation, only the five staff accountants are the company's accountants, because that's the role they fill. Pretty obvious, right?
Yet few think twice about counting everyone whose work primarily involves a computer as an IT person, no matter what role they fill, and even fewer recognize the consequences. Hiring a person to design a public website for your company, for example, is an advertising job. Having a group of people develop an iPhone app is production work. Having your DBA pull financial reports because he's a whizz at writing SQL queries simply means a portion of his FTE now belongs to the business office rather than IT.
Lumping clearly divergent roles into IT is a real problem, whether done naively or intentionally (perhaps to hide expenses and bypass organisational deficits). Regardless of the reason, this occurs in so many organisations that I believe it has had worldwide consequences, artificially deflating the job roles of other industries, artificially increasing the ranks of IT and logically causing executives to make truly costly IT decisions.
Any MBA can tell me what the unit of production is for a CFO. They can tell me the difference between FA, AR, etc. with pretty certain terminology. Not because they are accountants, nor because accounting is easy, but because there are definitions to guide them.
Can anyone tell me what the unit of production for a CIO is?
In the absence of fact, we supply dogma. On the surface, IT can look like a customer service organisation, so that is the typical analogue. Customer service is measured on several fronts: customer satisfaction, number of incidents, time of completion, etc. Satisfaction is a measure of whether a person got what he wanted, as opposed to what he needed. But to truly satisfy the role of IT, the duty is to the organisational needs, not to the individual wants. Satisfaction is important, but there is no direct correlation between satisfaction and IT success. Low satisfaction numbers may mean the system sucks, or simply that the IT group is doing a good job sticking to policies. High satisfaction numbers may mean the system is great, or the group is bleeding time and money by trying to satisfy everyone in valueless ways.
It gets worse: The more efficient, effective and pure of purpose IT is, the more invisible it becomes. The more invisible it is, the less people recognise its impact, and the more they question why it exists at all. If the organisation's leadership is uncertain about what IT is supposed to do, then anyone with an opinion, something to sell or an axe to grind becomes an instant expert with serious sway. In order to give the appearance of value in a manner people can comprehend, IT leaders are compelled to divert IT resources to non-IT work and ill conceived projects. Over time, the random tasks IT performs become confused for IT itself, and the actual IT group ends up being measured on the basis of a pool of unrelated tasks that are simply more visible and simple to quantify, and being judged with respect to failed projects it had no control over.
False measurement is the process by which we ignore relevant intangibles like knowledge, creativity and judgment in deference to irrelevant certainties. The message sent to aspiring CIOs is: An absolute lie trumps truthful uncertainty.
Faith, assumption, truthiness
Should IT reorganise? Centralise? Decentralise? Outsource? Insource? Is IT too big? Too small? Do we need ITIL? Should we provide service X? Why are we doing Y?
These are business questions whose answers often break down along what can seem like religious lines, in that everyone has an opinion and selects only the data that appears to validate it. The bigger the organisation, the more militant the debates become as we introduce radical elements of power, ambition and greed to otherwise dispassionate pragmatism.
For example, ITIL is a self described set of "best practices for IT Service Management." Many companies have spent many millions implementing ITIL-based processes, despite the lack of any science confirming its efficacy. I certainly cannot dispute the major tenets that underpin ITIL. But while each new faithful implementation shows short term promise, I have yet to see a mature ITIL-based organisation that isn't oversized, misshapen and grossly inefficient.
It's not that ITIL doesn't work, in fact it works exactly as one should expect. ITIL groups are acutely aware of their costs and processes, which is a primary goal of following the ITIL program. But ITIL organisations develop a resistance to pragmatic, incremental innovations that others quickly, if sometimes recklessly, adopt. This not only frustrates existing innovators, it makes hiring innovators a contrary act. Over time, that leads to an overall shift in staffing, with deficiencies in key roles that further deteriorate the group's ability to keep up, much less lead. While others race by on an uncertain diet of cheaper, faster, better, stumbling every so often with a mutable strategy, ITIL groups are typically forced by the weight of their own bureaucracies to stagnate, then belch changes in massive eruptions.
That's not the fault of ITIL, it's just the logical implication of wholehearted ITIL adoption, one that IT pros often predict but can't communicate in the face of a foregone conclusion. It is sufficient to say that when an organisation reviews its IT processes, it does so from the pulpit of one or another faith, and nothing anyone can say will change it. In 20 years, I have yet to see the results of an IT review contradict the opinion that spurred it. Whether it was the review that outsourced IT or the review that re-insourced it, the review always makes perfect sense. In the absence of a definition, anything makes sense.
It isn't stupidity that drives this cycle. There is a legitimate desire to get a handle on IT that leaves people vulnerable to deceptive simplicity. The truth is, executives make decisions exactly as I would if no one could tell me what IT was supposed to do and I was being presented with data out of context, barraged by the promises of some prominent voices and the deceptions of others.
What an organisation values in those circumstances becomes general and unfocused, a trend made all too clear when I saw a survey of CIOs. Asked to select all the skills pivotal to their success, 70% checked "ability to communicate effectively" and 58% marked "strategic planning," while only 22% ticked "thorough knowledge of technology options" and just 12% chose "technical proficiency." I can forgive a lack of technical proficiency. No one expects the CIO to be at the top of his troubleshooting game. But what could a CIO possibly be communicating or planning without a thorough knowledge of technology options? Those numbers should horrify executives, who make the assumption that their CIOs are supplying competent advice on a singular topic, technology.
It comes down to this: Even if you don't know how to turn on a computer, having a useful definition will help you count IT. It will help you measure IT. It will help you avoid the prophets who say they can solve your IT woes with numeric simplicity. It can even change the qualities you look for when hiring, and how you cope with uncertainty.
It's that uncertainty that underscores the value of having competent IT pros at all levels. Competence produces intelligent direction, and as any fifth grader can tell you, intelligent direction prevents the evil glitches from corrupting the system with dirty power.