This is the third and final of my ruminations on this topic. Some years ago, about halfway through my UChicago CIOship, I wrote this:

…it is bad news when a dean at my university not only knows who I am and what I do, but doesn’t like it. Suppose the dean wants to buy nonstandard equipment through a nonstandard channel. On the university’s behalf, I object to those choices; I also believe that the entire purchase is unnecessary because the equipment would allow the dean’s school to duplicate existing services that the university provides centrally. The dean responds by arguing that the interests of individual schools should outweigh collective university interests, and that having a chief information officer — that’s me — serves no useful purpose. To the dean, my job seems to consist entirely of interfering in school affairs.

I quoted this passage from “A CIO’s Question: Will You Still Need Me When I’m 64?, a 2002 opinion piece in the Chronicle, in an EDUCAUSE presentation because it had gotten me in trouble. Although it was based on a particular dean in one institution, a different dean at a different institution thought it was about him, and wasn’t happy. The lesson I drew from that — that specificity is sometimes better than generality, and that readers identify with abstracted characters — remains important.

But that’s not my theme today. Rather, I want to revisit the arguments I made in “A CIO’s Question…”, and see how their validity has evolved. My core argument was that it remains important for colleges and universities to have a Chief Information Officer or CIO. By “CIO” I meant not necessarily someone with that exact title, but rather someone providing central, comprehensive leadership for the institution’s information-technology activities and policies.

Technologies have a lifecycle. Initial implementation often requires central initiative and guidance. In due course, however, many technologies mature sufficiently to no longer require central oversight. For example, “most colleges and universities now have pervasive networks,” I wrote, “accessible to everyone everywhere. Users interact directly with administrative and academic systems. E-mail, instant messaging, and cellphones are everyday tools. Information technology is a utility like electric power, available consistently and pervasively across most of higher education” — and therefore requiring crisp operational management rather than high-level leadership. I cited other examples of areas no longer requiring central attention: the promotion of instructional technologies, and the support of local computer users (more on that in my recent post “Help! I need somebody.“)

Yet there remain at least four good, interlinked reasons for colleges and universities to have CIOs, I wrote: properly integrating central systems, securing economies of scale in operations and procurement, promulgating and accepting standards to enable those first two, and advocating for strategic applications of IT across the institution’s academic and administrative domains.

These seem valid justifications for the CIO role today. Yet one hears challenges to traditional CIOship: distributing responsibility for IT across diverse separate entities, downgrading the role and importance of the CIO, and managing what remains of central IT as merely one utility among many.

It’s important to parse these trends carefully. What appears to be coherent movement in the wrong direction may actually be discrete movement in several right directions. Moreover, although it remains important that there be central leadership for institutional IT, it may no longer be important — or even feasible — that there be central control. (More on the demise of control in an upcoming post.)

As technologies mature, they enable decentralization. As the strategic importance of IT increases, it becomes dangerous for an institution to entrust it to a single individual, especially if that individual speaks the language of technology rather than the language of higher education, or if that individual is organizationally and geographically isolated. And a large fraction of IT is indeed a critical utility, one whose failure can jeopardize the institution, and so much of IT must be managed as such.

What appears to be the downgrading of IT may instead be an evolving recognition — however imperfect — of its increasing importance. Then again, it may be the downgrading of IT, or the political dilution of a CIO’s perceived power. We need to understand which is which: to think about the evolving CIO role thoughtfully rather than simplistically, rather than focus on its scope of authority, its precise location in organization charts, or its title and reporting line.

The challenge for a CIO is to ensure that his or her institution uses IT to its maximum long-term benefit. To achieve that, it’s important to hold onto what’s important in one’s particular institutional and technological context, while letting go of what isn’t.

This post, in somewhat modified and expanded form, appears as “Shrinking CIO?” in EDUCAUSE Review, vol. 46, no. 1 (January/February 2011)

My mother called a couple of weeks ago to say she was unable to use the Internet. She doesn’t make calls like this lightly – she’s a regular email user, does extensive research online about things ranging from food to politics to textiles, and learned to use instant messaging so she could stay in touch with her grandchildren. And she understands that her HP computer is connected to RoadRunner and thereby to the Internet. So this wasn’t just her being new to technology.

I figured that she must have somehow lost her network connection, and began walking her through some experiments (“Are the lights blinking on the modem?”, and so on). But I was over-analyzing the problem. To my mother, as to many users, the Internet isn’t a network. Rather, it’s the collection of sites and services she can reach through her web browser. The problem, it turned out, was that my mother had accidentally moved the Firefox shortcut off her desktop. No icon, no browser. No browser, no Internet. No Internet, get help.

My mother’s missing icon may seem a triviality, but it certainly wasn’t trivial to her, and I think the problem and how she handled it are instructive. Lots of services we take for granted these days don’t come from a single provider or involve a single application or technology. In fact, sometimes it’s not clear what’s a service, what’s an application, and what’s a technology. Mostly that works out okay. When it doesn’t, though, it’s very hard to figure out where the chain broke down. Even when we figure that out, it’s hard to get the provider that broke the chain to fess up and make things right.

Perhaps as a consequence, we IT folks get lots of calls like my mother’s from friends and relatives: “My printer stopped working. Can you tell me what to do?”, or “How come Aunt Jane didn’t receive my email?”, or “I just clicked on something in a website, and now my screen is full of pornography ads”, or “Is it safe to buy something from eBay?”, or “Can I get my email on my phone?”. Why, we wonder, are they calling us, and not whom they’re supposed to call?

That’s the text today’s rumination: What’s the right way to think about help desks?

I started typing this using Windows Live Writer (Microsoft) on the Windows 7 (Microsoft, but a different part) computer (Dell) that is connected to the network (Comcast, Motorola, Cisco) in my home office, and it’ll be stored on my network hard drive (Seagate) and eventually be posted using the blog service (WordPress) on the hosting service (HostMonster) where my website and blog reside. I’ll keep track of blog readers using an analytic service (Google), and when I’m traveling I might correct typos in the post using another blog editor (BlogPress) on my iPhone (Apple) communicating over cellular (AT&T) or WiFi (could be anyone) circuits.

Much of today’s IT is like this: it involves user-owned technologies like computers and phones combined in complicated ways with cloud-based services from outside providers. We’re always partly in the cloud, and partly on the ground, partly in control and partly at the mercy of providers. That’s great when it works. But when something doesn’t work, diagnosis can be fiendishly difficult – especially if one is 2,000 miles away and can’t see one’s mother’s screen.

My mother has a solution to this: she has a local kid on retainer, her “guru”. She calls him when something doesn’t work, and he comes over to diagnose and fix the problem. She called me because her guru was on vacation.

Why doesn’t my mother call the RoadRunner or HP help desks? She’s not alone in this: vendor help desks seem to be users’ last resort, rather than their first. Most of us would explain this in two words: “Silos” and “India”. Help desks grew up around specific technologies or applications. Users dealt with one help desk if their wired phone wasn’t working, another to straighten out a cellphone problem, another if their email was over quota, another to figure out how to do online journal transfers from their desks, another to tighten up computer security, and so on — hence, “Silos”. On the other end of the phone, service providers developed highly specialized help desks comprising inexpensive staff working from very specific databases of known problems and stock solutions (“India”).

This worked so long as technologies were actually separate. But in this age of everything connected to everything else, it doesn’t. Far too many help-desk interactions comprise a distant help-desk technician not finding the problem in the database, usually because the problem involves inter-application pathology. As a last but frequent resort, the help desk has the user reboot (or restore to factory specs, or whatever). Once users realize that help desks solve all problems with reboots, they don’t bother calling help desks. They reboot. When reboots don’t work, they call their friends and relatives.

We know how to fix this, right? Consolidate help desks, cross-train staff, and all will be well.

That hasn’t worked either. Cross-training staff to deal with complex inter-technology problems means we need really clever technology folks as help-desk staff, or even to divert developers and integrators to that task. Staff who rely on knowledge bases simply can’t cope with the typical cross-technology problem, as we know from the India silos. But hiring or diverting experts is expensive. To solve that problem, we implement first-tier triage, so that expensive staff only deal with expensive problems. But none of this works: there’s still too much rebooting, and users remain dissatisfied.

My mother has the right idea. Today’s help desks typically work for providers — be they commercial or internal to colleges and universities — and not for users. Help desks’ incentives are aligned with the providers’ bottom lines, not with understanding how their provider’s service fits into the user’s environment.

The solution, I propose, may be to have users own help desks.

What would that mean? In the typical college or university, there are help desks operated by service providers (both central and departmental), and there are help desks operated by non-provider departments. Users typically find the latter helpful and worthwhile, and complain extensively about the unresponsiveness of the former. The result is structural tension at the senior level between the overseers of non-provider help desks (typically deans) and overseers of provider help desks (typically a CIO, or whoever’s in charge of central IT). Usually the tension either goes unresolved or, especially when corporate-style consultants are involved, provider-based centralization wins.

Maybe that’s precisely the wrong answer. Perhaps campus IT service providers should not own help desks. Instead, colleges and universities might rely on entities close to users — administrative units, academic departments, centers, building management — to provide first-level support. Realigning help desks this way wouldn’t be easy. It would raise budgetary issues, governance issues, local-control issues, centralization issues. It would entail diseconomies of scale.

But help-desk staff would understand users’ circumstances holistically — much as my mother’s guru understands her environment . This would make them better IT diagnosticians and therapists. If users got better diagnosis and therapy for their IT problems, they’d be more productive. And those productivity gains might amply offset the increased costs of localized, realigned help desks.

Old news from the buzzword-bingo front: “Cloud” is giving way to “Mobility” as the word to work into every presentation.

To many people, “mobile computing” means a small device interacting with a massively interconnected set of cloud-based databases and computational engines. From that perspective, mobile computing isn’t an emerging technology in its own right, but rather a window into a maturing one, and so not very interesting technologically.

Delve deeper, and “mobile computing” becomes very interesting — not as a technology, but rather as an aggregation of several technologies whose evolutionary paths overlap in a particularly fertile way. Understanding the emergence of mobile technology thus requires parsing it into its components — and the same goes for guessing about the future.

In no particular order, what follow are the technologies I think underlie the current transformation of our lives through mobile computing, and how they’re likely to evolve. Please add to and/or comment on the list!

• Pervasive, transparent wireless. What we need, and what’s likely to emerge, is a combination of technology and business practices that enable people simply to stop thinking about how their devices are connected. Right now connectivity might be by 802.11 WiFi, and the WiFi might use any of several authentication and security technologies, or it might be cellular, where how you connect depends on which carrier your device likes, or it might be one of the emerging non-cellular, non-WiFi technologies like WiMax. The key technology that has yet to emerge is a mechanism for reconciling and federating the diverse identities people already use to get wireless access.
• Federated identity and attribution. I have somewhere north of 20 email addresses, plus almost as many phone numbers, some bank accounts, a wallet full of credit cards, and several membership IDs. Eventually there needs to be some way to communicate the relevant dimensions of these identity icons from mobile devices into the cloud or vice versa — and to do so without communicating the irrelevant dimensions or exposing us to identity thieves. Moreover, the sources that identify me may be different from the sources that identify others, and these different sources need some kind of interlinking trust chain. Without these kinds of federated, limited, focused mechanisms for sharing attributes, it will remain awkward to integrate mobile devices into the commercial fabric.
• Haptic interfaces. The touch screen is rapidly complementing and in many cases supplanting the keyboard and pointing device on small devices, and it is beginning to do so on larger ones (eg, iPad, Kindle, etc). Touch isn’t the only haptic technology that’s emerging rapidly, though — there are also three-dimensional technologies like the field sensors used in Wii controllers. We’re going to see rapid progress here.
• Solid-state storage. It’s interesting to remember that the original iPod actually had a spinning hard drive in it — that would be unthinkable in a small device today, where flash memory reigns supreme, and it’s becoming unthinkable in light laptops (eg, the small Dells like mine, and the new MacBook Air), and we’ll see that progression continue.
• Low-power processors. Without these and the next item, devices really aren’t “mobile”; rather, they’re temporarily detachable. Getting processors to consume less energy and put off less heat is critical to both run time and miniaturization. We’ll see immense progress here, I think, and that will gradually erase the difference between the flexibility of “portable computers” and the long run-times of “mobile devices”.
• Power. Mobile computing would be infeasible without compact lithium-ion batteries, but they’re only one step along a continuum that eventually yields some combination of wireless energy supplies (presumably solar, but some based on body heat and kinetics might re-emerge — if you’re as old as me, you’ll remember so-called “self-winding” watches, whose springs were wound by a delicately balanced internal swing arm that spun around as we walked). New battery types or capabilities are also possibilities.
• Displays. We’re still pretty much confined to displays that require some kind of rigid (or rigidly supported) surface, be it a liquid-crystal mechanism of some kind (many laptop displays, plus Kindles and other “electronic ink” devices) or some kind of charged-glass mechanism (such as iPhones and iPads, also some laptops and plasma screens). Cheap little projectors are another technology that’s playing in this space, but they only work in the dark, and then not very well. Eventually someone is going to figure out how to produce displays that are flexible, even rollable or foldable, while still being capable of detailed rendering and some kind of haptic input.
• Encryption. As outsiders seek access to individual data and communications and individuals become worried about that, we’ll see demand for simple yet secure encryption mechanisms. The problem is how to balance simplicity of use, security level, and recoverability. It’s easy to develop encryption that’s easy to use, but often that makes it less secure and/or makes it hard to recover data if one forgets one’s password. Solving either of the latter problems typically reduces simplicity, and so on around the circle.
• Sensors. Many mobile devices already have some kind of location sensor (GPS or cell-tower triangulation), often accompanied by a compass and an accelerometer. Pressure sensors, thermometers, magnetic-field detectors, bar-code readers, weather-radio receivers, speech parsers, fingerprint readers, and other sensors are also becoming common — and some of them, like Shazam, are quite astonishing. Gradually our mobile devices will need less and less information from us.

The point is, the emergence of mobile technology isn’t unidimensional — it’s not Dick Tracy’s wrist radio becoming a wrist TV. Rather, it comprises the simultaneous emergence and confluence of several otherwise distinct technologies.

It’s inevitable that both the emergence and the confluence will continue in ways we can scarcely imagine. This yet another example of the maxim we always need to remember: everything, even technological progress, is connected to everything else!

Larry Kohlberg’s work, which I mentioned a couple of posts ago, was an example of what graduate students in my time called “Stage Quest”: the effort, following Jean Piaget’s work on cognitive development, to find and document inexorable stage sequences in all kinds of development, including political, organizational, and occupational. In due course it became clear that not all development occurs through an invariant succession of stages. Yet Stage Quest keeps creeping into all kinds of organizational thinking and advice, not least the piece I’m ruminating on today: “Follow the Money'” and Other Unsolicited Advice for CIOs, from 1999.

Over a recent weekend I learned how to drive this 1952 Ford tractor. It’s fun to drive vehicles other than one’s car — in high school, for example, I briefly drove a Greyhound bus around a parking lot (well, okay, it wasn’t actually Greyhound, since it was in Mexico, but it was the same kind of bus — and this was when diesel intercity buses still had manual transmissions) and a friend’s TR-3 with a gearshift one could pull out of the transmission. Later I drove small trucks across the country a few times, and a motorcycle maybe twice, and those little Disney cars, which, truth be told, seemed much faster and more exciting in Anaheim when I was a kid than our son found them when he tried them years later in Orlando.

But I digress. Driving a tractor turns out to be very different from all those other vehicles in one key respect: you pick your gear before you start out, and then you stick with it. If you want to change gears, you stop the tractor completely first, and start over. For a tractor to work without unexpected interruptions, you need to understand what the job is before you set out. If you stick with the wrong gear, the tractor stalls, and you fail.

Here’s my summary reflection on “Follow the Money…”: It’s too much based on Stage Quest, and not enough on a 1952 tractor. The article arose from a conversation with a longstanding CIO from another institution. “What advice,” he asked me, “would you give a new CIO?” We came up with a dozen categories:

• Ends justify means,
• Who’s the boss?,
• Blood is thicker than water,
• Round up the usual suspects,
• Espouse the party line,
• What’s the difference?,
• Silence is golden,
• Follow the money,
• Timing is everything,
• Consort with the enemy,
• Practice what you preach, and
• Be where you are, not where you were

The relative importance of voice and data networking has changed, and I was unduly optimistic about desktop support becoming simpler, but much of the advice remains sound — especially, as I wrote in Part I of CIOship, the advice to avoid hierarchical approaches to IT organization and its relationships with other campus entities, and to collaborate actively across institutional boundaries.

But, as I said above, the article seems in retrospect to be excessively based, albeit implicitly, on the Stage Quest assumption that CIOs face similar series of challenges in different institutions. This, in turn, implies that CIOs at early stages in the series can learn from those who have progressed to later stages. Yet it has become quite clear, especially over the past few years,  that higher-education CIOships come in distinct forms. Like the various jobs a tractor driver might tackle, each form of the job entails a different series of stages, and requires a different gear. Some CIOs are hired to clean up a mess, for example, some are hired to encourage IT-based innovation, some are hired to consolidate past gains, and some are hired to focus on a particular problem. What one might do to Consolidate will fail miserably if one’s job is Cleanup.

The advice missing from “Follow the money…” is this: it’s very important to know which CIO job one has, and therefore which suite of skills and actions — which gear, that is — the job requires. A CIO hired into a Cleanup job will succeed by doing different things than one hired into an Innovate job. Those require different approaches than Consolidate or Focus jobs. Advice, in short, must be taken only in context.

This may help explain the discomfort with CIOship evident in “A CIO’s Question: Will You Still Need Me When I’m 64?“, which I wrote five years later. I’ll revisit that in the next Reflections on CIOship post.