Robert Benchley’s core premise, in his funny but oh-so-true article “How To Get Things Done“, is that being productive requires deceiving oneself about priorities. My premise today, closely related, is that what we say isn’t what we should say, and that what we actually do isn’t either of those.

That’s obviously an issue in higher-education information technology, my usual focus, but today I’m writing about Chicago restaurants, and specifically about discrepancies among expertise, preferences, and behavior. Such discrepancies are clearly important in higher-education IT practice. The reader will have to deduce that relevance since I’m going to stick to the matter at hand and hope I finish before I get hungry.

Chicago’s a great restaurant town, no matter whether one is interested in the latest molecular gastronomy, regional cheeses and salume, appropriate garnishes for hot dogs or Italian beefs, or nuanced differences among the seven moles of Oaxaca. So it was wholly appropriate that Michelin would choose Chicago to be its third American Red Guide city. Following a year’s worth of visits, Michelin critics awarded stars to 23 restaurants, and Bib Gourmand recognition to an additional 46. Presumably, since they’re chosen by the experts, Michelin-rated restaurants are where one should prefer to eat.

Years ago I needed a nested list of something to teach myself how to use <li> tags in hand-coded Web pages. I arbitrarily chose to draft a list of  restaurants where I’d eaten and might eat again, and over time that list has grown steadily. When I became a Quicken addict, as a byproduct of record-keeping I began tracking how frequently we ate at various restaurants.

Since we’ve lived in Chicago for almost fourteen years (and still spend most of our time there), we’ve developed preferences that guide both what we recommend to visitors and presumably guide where we actually eat. So I have data on where we should eat (that’s the Michelin ratings) and where we do eat (my Quicken data), and since our recommendations to friends over the years have been pretty consistent, I can also say what our preferences are.

I thought it might be interesting to compare those. I’m curious what one might deduce about why restaurant-choice behavior differs from stated preferences, and why personal preferences differ from those of experts. I munged together a list of restaurants comprising the union of

• the Michelin starred and Bib Gourmand lists and
• Quicken data on where we’d dined (arbitrarily defined as an expense of at least $20) at least once in 2008-2010.

Without looking at frequencies, I then rated the restaurants we’ve ever dined at based on how we characterize them to others. I reduced the ratings to five categories: Not Rated (which usually means I don’t remember the place), Okay, Good, Favorite, and Event.

There are 172 restaurants on the combined list. Of those,

• Michelin awards 69 at least one star or a Bib Gourmand rating,
• we dined at least once in 2008-2010 at 103 restaurants that remain open,
• 9 places we dined have closed (none of those is on the Michelin list), and
• we rate 105 of them Okay or better (we rate more places than we dined at because we have opinions about places we haven’t visited since 2007).

First, let’s look at should versus say.

• There were 26 restaurants that both Michelin rated Bib Gourmand or Starred and we rated Good, Favorite, or Event.
• Our Event restaurants (definition: places definitely worth going to once, or if someone else is paying) all received stars from Michelin.
• However, four of their one-star restaurants we rated merely Good.
• Conversely, of our 13 Favorite restaurants in the jointly-rated set, Michelin awarded one star to 5 and Bib Gourmand to 8.
• If we expand the set to include restaurants Michelin didn’t rate and our Okay ratings — that’s a total of 105 restaurants — we learn that Michelin didn’t rate 9 of our Favorite restaurants, and we thought 3 of their Bib Gourmand restaurants were merely Okay.

It’s interesting to look at the discrepancies.

Our 9 Favorites not rated by Michelin are Avec, Café des Architectes, Coco Pazzo Café, Gioco, La Sardine, mk, Pelago, Rosebud Steakhouse, and Shaw’s Crab House. Three of the Favorites omissions from Michelin’s list are curious: Avec, Café des Architectes, and mk are clearly good as or better than many restaurants Michelin rated. The same is true of Pelago, but it may be too new for the Michelin people to have rated it. Some of the others make our list and not Michelin’s because part of their appeal to us is location (that is, they’re near where we live: Coco Pazzo Café, Pelago, and Rosebud Steakhouse), and Michelin does not include that in its judging. And some we find to be consistently good for the money or to be especially welcoming places, which are judgment calls.

Conversely, we rated 4 of Michelin’s one-star restaurants Good, and 3 of their Bib Gourmand places merely Okay. The 4 in that first group are Naha, NoMI, Spiaggia (one of Barack and Michelle Obama’s favorites), and Takashi, and in each case it’s because what we ate, although fine, didn’t live up to billing or price. The 3 in the second group are Bistro 110, Green Zebra, and The Purple Pig, the first of which just hasn’t impressed us that much, and the latter two of which we found disappointing especially given the hype that attaches to them.

All in all, though, we’re not too bad on should versus say. That is, what we recommend and what experts tell us we should be recommending are reasonably well aligned. Yet it’s clear that exactly what criteria one uses becomes very important as one approaches the edge of Should or Say. The general point is that understanding experts’ or one’s own preferences is important. Small differences in criteria can produce substantial differences in what one seeks.

Now the more Benchley-like issue: How does what we say correspond to what we do? Let’s start with an interesting extreme observation: Of the ten restaurants we visited most in 2008-2010, only 1 — Perennial — is on Michelin’s lists, and only 5 — Rosebud Steakhouse, Coco Pazzo Café, Pelago, Perennial, and Avec — are on our own Favorites list.

So what we say and what we do most frequently clearly aren’t quite the same (although at least our top 10 don’t include any restaurants we rate below Good). That is, if we constructed our recommendations based on our behavior, our list might be quite different.

Fortunately, the overall comparison between our ratings and our visits is less discrepant. Across the 105 restaurants we rated, 6 are in the Event class, and we ate at half of those once in 2008-2010 — not a bad number, given that these can cost upwards of $100 per person before wine, tax, and tip. Another 22 we rated Favorite, and we ate at 17 of those at least three times — but two of them went unvisited.

There are 56 restaurants in our Good category, and we ate more than once at almost half of them. Looking at those 25 places, it’s clear that some of them we should rate a bit higher, since they’re at the border and we clearly like them: for example, Branch27, Mercat, Quartino, Rhapsody, Taxim, and The Gage.That list may be the most interesting of all: It clearly suggests that accumulated behavior should figure explicitly in recommendations. That is something the Michelin ratings don’t do.

But this list also illustrates how location can bias behavior-based ratings. Frankie’s Scaloppine is a perfectly good restaurant, albeit one located on the fifth floor of an indoor shopping mall. We visited it 17 times not because it warrants a Favorite rating, but because’s it’s inexpensive, fast, and a block from our home. Several other frequently-visited restaurants on our Good list have that same attribute: even though they’re only Good, they nevertheless have attractive features.

So what should we make of all this? The point, I think, is that we have to be very careful to understand why experts tell us what they tell us, we have to be very careful to understand why we state our preferences as we do, and most of all we need to pay close attention to our behavior. That’s not to say that data should drive preferences — if we do that, nothing will ever change — but rather that divergence between what we say and what we do tells us something, and that something requires attention lest we confuse mythology with fact.

Okay, I can hear at least one of you asking: Where’s that list of Favorites? Here they are. They’re labeled with * for Michelin stars and + for Bib Gourmand, and are in italics if we dined on them at least thrice in 2008-2010:

Bon appétit! ¡Buen provecho! Time to eat!

A few nights ago, at a meeting of IT people from a subset of research universities, dinner conversation turned to why IT people work in higher education. If you do IT in higher education, everyone pretty much agreed, it’s not to get rich. Rather, you’re driven by some combination of four reasons.

1. IT jobs in higher education have tended to entail a complicated, challenging, and rewarding set of challenges. IT organizations in colleges and universities tend to be relatively small, and tend to involve teamwork across domains that might otherwise be separate. There’s not the neat division between, say, technical and support staff that one might find elsewhere, and so there has been ample opportunity to grow along various dimensions.
2. IT jobs in higher education have generally involved a certain amount of flexibility. One spends most of one’s time on one’s job, but it’s been commonplace for a certain fraction of time – perhaps as much as 20% — to be essentially the staffer’s to allocate. Much of that time has gone to experimenting with new technologies, or ways to use old technologies, or even to thinking about things not strictly technological. In the aggregate, much of that “uncommitted” time has gone to innovation, some successful and some not. But the opportunity to spend time on activities that are not strictly part of job descriptions, with part of that involving experimentation and innovation, has enabled IT organizations in higher education to be sources of administrative, educational, research, and technological progress.
3. IT in higher education has usually provided good job security. Absent failure to produce or malfeasance, IT staff in education could reasonably assume that they would have jobs so long as they continued to perform well.
4. This one’s somewhat different from the other three reasons. IT jobs in higher education have been an interesting and useful way station for recent graduates with abundant energy and skill but little sense of career or personal-development paths. For many IT staff, the job is not an end in itself, but rather a reasonable way to work for a few years while figuring out what to do next – be that graduate school, marriage and family, relocation, a more remunerative job, or whatever. That is, part of what appeals is working where one recently got – or is soon getting – a degree.

For reasons good and bad, the reasons to work in higher-education IT work have eroded, without commensurate offsets such as better pay. This has had little effect on those who work in higher-education IT for reason #4. So long as economic downturns have affected the corporate and .com worlds more than colleges and universities, it also has had little effect on those who work for #1-3. Since the economy has been on a bit of a roller coaster for some years, we’ve thus seen little erosion of IT staffing in higher education.

But as financial strictures settle firmly into higher education, this is changing. There have been greater compartmentalization of tasks, tighter accounting for time and effort, and layoffs unrelated to performance. These directly undercut reasons #1 through #3 for working in higher-education IT, and they’re beginning to have effects on staffing.

What many perceive is a key shift in the higher-education IT workforce: fewer young staff stick around to rise through the ranks, and loss rates do not reverse with age as they once did. The staff-by-age distribution is becoming bimodal, and whereas the left-hand mode is staying put or moving left – that is, staff who leave are leaving sooner – the right-hand mode, starved for replenishment from the middle, is moving right. As a result, higher-education IT organizations are increasingly starved for middle management, and as a second-order consequence they are decreasingly able to fill leadership positions from within. We therefore see more middle-management and leadership hires from the corporate sector.

Those new hires, unaccustomed to reasons #1-4, are likely to magnify rather than counteract the changes that underlay their hiring. The result, if we can avoid a vicious circle, is that non-pecuniary reasons for working in higher-education IT will give way to pecuniary ones. IT staff in colleges and universities will have more focused, less flexible, and less secure jobs, but they will be paid more to do them. If productivity under the new regime grows sufficiently to offset higher IT payrolls (which may mean that staffing levels decline), then the evolution can succeed. If it doesn’t, then increased spending will fail to yield commensurate progress.

Let’s assume, for the moment, that the evolution is both desirable and successful. What issues might we need to address? Here are five for starters:

1. Whether we like it or not, colleges and universities operate with cultures that are very different from corporate cultures. If staff are hired from the latter, then we need to find effective ways to quickly give them an understanding of the former. This doesn’t mean that outside hires must go native, accepting their new culture as gospel, but rather than they must understand the status quo if they are to change it.
2. If pay does become a dominant reason for people to work in higher-education IT, then colleges and universities must adopt modern approaches to compensation: bonuses for effective work, putting some compensation formally at risk, direct connections between performance reviews and compensation, benefits suited to staff needs, and most important compensation levels that truly compare favorably with the outside market.
3. Even if we successfully integrate and compensate staff from outside higher education, inevitably staff turnover will be higher than it has been in the past: that’s another attribute of corporate IT cultures. This means that college and university IT organizations can no longer rely on long-term employees as the repositories of accumulated experience. Rather, they must adopt formal mechanisms for reaching, making, and recording decisions, for documenting implementation and change, and generally for ensuring that wisdom survives turnover.
4. Idiosyncrasy, long the hallmark of higher-education IT and in many cases the guarantor of continued employment, will give way to standardization. The default for decisions whether to outsource will no longer be “no”. The burden of proof will shift to those opposing outsourcing, and there will be increased scrutiny of “we’ve always done it this way” arguments.
5. Partly as a result of #4, possibilities for inter-institutional collaboration and joint procurement should expand. In some cases this will lead logically to joint-development efforts, especially where higher education has unique needs (for example, student systems, learning-management systems, and many research applications). In other cases it will lead logically to demand aggregation, especially where higher-education needs are consistent, they resemble those outside the academy, and they yield no competitive advantage (for example, email systems or cloud-based storage).

Many of those currently preparing to become leaders within higher-education IT are ill prepared to address issues like these. Many of those who come from outside to take leadership positions in higher-education IT do not understand why issues like these are hard to address in higher education. The solution, as with many of the changes we face, is serious, deep-thinking professional development: places where those rising or jumping into college or university IT leadership can learn what the future is bringing and how to address it. These can be didactic, like EDUCAUSE’s management and leadership institutes, or collaborative, like the Common Solutions Group, the Council of Liberal Arts Colleges, the League for Innovation, and other entities where peers gather to share experiences and best practices.

In the past we’ve built leaders informally, by drawing them from those who have been with us for a long time. As that pool dries up, we need to think differently.

Remember Attack Plan R? That’s the one that enabled Brigadier General Ripper to bypass General Turgidson and the rest of the Air Force chain of command, sending his bombers on an unauthorized mission to attack the Soviet Union. As a result of Plan R and two missed communications – the Soviets’ failure to announce the Doomsday Device and an encrypted radio’s failure to recall Major Kong’s B-52 – General Ripper ended the world and protected our precious bodily fluids, Colonel Mandrake’s best efforts notwithstanding.

Fortunately, we’re talking about Sterling Hayden, George C. Scott, Slim Pickens, and Peter Sellers in Stanley Kubrick’s Dr. Strangelove, or How I Learned to Stop Worrying and Love the Bomb, and not an actual event. But it’s a classic illustration why control of key technologies is important, and it’s the introduction to my theme for today: we’re losing control of key technologies, which is important and has implications for how campus IT leaders do their jobs. We can afford to lose control; we can’t afford to lose influence.

Here’s how IT was on most campuses until about ten years ago:

• There were a bunch of central applications: a financial system, a student-registration system, some web servers, maybe an instructional-management system, and then some more basic central facilities such as email and shared file storage.
• Those applications and services were all managed by college or university employees – usually in the central IT shop, but sometimes in academic or administrative units – and they ran on mainframes or servers owned and operated likewise.
• Students, faculty, and staff used the central applications from desktop and laptop computers. Amazing as it seems today, students often obtained their computers from the campus computer reseller or bookstore, or at least followed the institution’s advice if they bought them elsewhere. Faculty and staff computers were very typically purchased by the college or university and assigned to users. In all three cases, a great deal of the software on users’ computers was procured, configured, and/or installed by college or university staff.
• Personal computers and workstations connected to central applications and services over the campus network. The campus network, mostly wired but increasingly wireless, was provided and managed by the central IT organization, or in some cases by academic units.
• Campus telephony consisted primarily of office, dormitory, and “public” telephone sets connected to a campus telephone exchange, which was either operated by campus staff or operated by an outside vendor under contract to the campus.

Notice the dominant feature of that list: all the key elements of campus information technology were provided, controlled, or at least strongly guided by the college or university, either through its central IT organization or through academic or administrative units.

There were exceptions to campus control over information technology, to be sure. The World Wide Web was already a major source of academic information. Although some academic material on the web came from campus servers, most of it didn’t. There were also many services available over the web, but most campus use of these was for personal rather than campus purposes (banking, for example, and travel planning). Most campus libraries relied heavily on outside services, some accessible through the Web and some through other client/server mechanisms. And many researchers, especially in physics and other computationally-intensive disciplines, routinely used shared computational resources located in research centers or on other campuses. Regardless,  a decade ago central or departmental campus IT organizations controlled most campus IT.

Now fast forward to the present, when things are quite different. The first difference is complexity. For example, I described my own IT environment in a post a few weeks ago:

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.

Mélanges like this are pretty much the norm these days. And not just when people are working from home as I often do: the same is increasingly true at the office, for faculty and staff, and in class and dorms, for students. It’s true even of the facilities and services we might still think of as institutional: administrative systems and core services, for example.

The mélanges are complex, as I already pointed out, but their complexity goes beyond technical integration. That’s the second difference between the past and the present: not only does IT involve a lot of interrelated yet distinct pieces, but the pieces typically come from outside providers – the cloud, in the current usage. Those outside providers operate outside campus control.

Group the items I listed in my ten-years-ago list above into four categories: servers and data centers, central services and applications, personal computers and workstations, and the networks that interconnect them. Now consider how IT is on today’s campus:

• Instead of buying new servers and housing them in campus buildings, campuses increasingly create servers within virtualization environments, house those environments in off-campus facilities perhaps provided by commercial hosting firms, and use the hosting firm’s infrastructure rather than their own.
• A rapidly growing fraction of central services is outsourced, which means not only that servers are off campus and proprietary, but that the applications and services are being administered by outside firms.
• Although most campuses still operate wired and wireless networks, users increasingly reach “campus” services through smartphones, tablets, web-enabled televisions, and portable computers whose default connectivity is provided by telephone companies or by commercial network providers.
• Those smartphones, tablets, and televisions, and even many of the portable computers, are chosen, procured, configured, and maintained individual users, not by the institution.

This migration from institutional to external or personal control is what we mean by “cloud services”. That is, the key change is not the location of servers, the architecture of applications, the management of networks, or the procurement of personal computers. Rather, it is our willingness to give up authority over IT resources, to trade control for economy of scale and cost containment. It’s Attack Plan R.

The tradeoff has at least four important consequences. Three of these have received widespread attention, and I won’t delve into them here: ceding control to the cloud

• can introduce very real security, privacy, and legal risks,
• can undercut long-established mechanisms designed to produce effective user support at minimal cost, and
• can restructure IT costs and funding mechanisms.

I want to focus here on the fourth consequence. Ceding control to the cloud necessarily entails a fundamental shift in the role of central and departmental IT organizations. This shift requires CIOs and IT staff to change their ways if they are to continue being effective – being Rippers, Kongs, or Turgidsons won’t work any more.

Most important, cloud-driven loss of campus control over the IT environment means that organizational and management models based on ownership, faith, authority, and hierarchy – however benevolent, inclusive, and open – will give way to models based on persuasion, negotiation, contracting, and assessment. It will become relatively less important for CIOs to be skilled at managing large organizations, and more important for them to know how to define, specify, and measure costs and results and to negotiate intramural agreements and extramural contracts consistently. Cost-effective use of cloud services also requires standardization, since nothing drives costs up and vendors away quite so quickly as idiosyncrasy. Migration to the cloud thus requires that CIOs understand emerging standards, especially for database schemas, security models, virtualization, system interfaces, and on and on. It requires that CIOs understand that strength lies in numbers – especially in campuses banding together to procure services rather than in departures from the norm, however innovative.

Almost as important, much of what campuses now achieve through regulation they will need to achieve through persuasion – policy will give way to pedagogy as the dominant mechanism for guiding users and units. I serve on the operations advisory committee for a federal agency. To ensure data and program integrity, the agency’s IT organization wanted to revise policies to regulate staff use of personal computers and small mobile devices to do their work from home or while traveling. It became rapidly clear, as the advisory committee reacted to this, that although it was perfectly possible to write policies governing the use of personal and mobile devices, most of those policies would be ignored unless the agency mounted a major educational campaign. Then it became clear that if there were a major educational campaign, this would minimize the need for policy changes. This is the kind of transition we can imagine in higher education: we need to help users to do the right thing, not just tell them.

On occasion I’ve described my core management approaches as “bribery” and “conspiracy”. This meant that as CIO my job was was to make what was best for the university also be what was most appealing to individuals (that’s “bribery”), and that figuring out what was best for the university required discussion, collaboration, and agreement among a broad array of IT and non-IT campus leaders (“conspiracy”). As control gives way to the cloud for campus IT, these two approaches become equally relevant to vendor relations and inter-institutional joint action. We who provide information technology to higher education need to work together to ensure that as we lose control over IT resources we don’t also lose influence.

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.

Having not been a CIO  for over a year, I’ve been thinking about the evolution of that role — whatever its associated title — in colleges and universities.

As some of you know, I’ve thought and written about CIOship before. In the spirit of Ruminations, I figured the right way to rethink about CIOship was to revisit how I’d thought about it before.

So in this and the next two posts I’ll revisit those earlier pieces, see whether they still make sense. Ignoring chronology, I start with a short piece from a collection in EDUCAUSE Review three years ago. My part was short, so I’ll just quote it in full.

The U.S. Military Academy is a highly centralized organization: an end-of-career superintendent manages a largely transient faculty and a hierarchical administration. Harvard, in contrast, is a highly decentralized organization: a president nudges and coaxes deans, who control most of the resources and who in turn nudge and coax department heads and faculty, who enjoy substantial autonomy.

Like most other colleges and universities, the University of Chicago operates between these extremes—or, more typically and problematically, tries to combine the two. The budget process is centralized, for example, but its product is a set of formulas outlining boundaries within which deans and vice presidents have great freedom. Similarly, the university claims to have centralized telecommunications procurement, but somehow cell phones aren’t included.

Even faculty hiring has both centralized and decentralized components, causing occasional tension between department heads and the provost’s office. Confusion results, especially regarding the processes for setting priorities, resolving conflicts, and negotiating trade-offs.

Senior leadership groups—an officers group, a deans group, and an executive budget committee—exist to resolve these tensions between decentralized and centralized goals and actions. To the extent that these groups evolve into collaborative teams, they work well for issues of general institutional importance. They work less well for issues that involve only a subset of units: IT and Facilities, with overlapping responsibilities for design and installation; intellectual and administrative units, with divergent goals for student life; or pairs of academic departments, with a need to exploit synergies. So I—like other vice presidents, as well as deans and colleagues—have lots of lunches at the Quadrangle Club, the standard place for University of Chicago administrators and faculty to conduct lunch meetings.

For those of us with sedentary habits and no willpower, lunch can be a problem. That’s especially true for me, since the Quad Club makes a delicious BLT wrap, which is in effect a handful of garnished bacon only minimally buffered by a thin wrapper—and I love bacon. Ordinarily, mindful of my waistline, I’d try to avoid Quad Club lunches. But who has lunch with whom—and, sometimes more important, who sees whom having lunch with whom and stops by the table—is very important to the university’s functioning.

An aggregation of dyadic administrative lunches helps us behave as though we are centralized, even as each of us jealously guards his or her decentralized authority. Our lunches don’t turn into negotiating sessions, and only rarely do concrete decisions emerge from them. Rather, lunches give us the opportunity to share thoughts, experiences, perspectives, enthusiasm, paranoia, gossip—the informal information about one another that enables us to negotiate, collaborate, complain, and respond appropriately when our domains do or should engage one another.

This coming year promises to be challenging at the university: an ambitious president, lots of new vice presidents, currents of organizational and cultural change, and many trade-offs to be negotiated. Some of these challenges will call for more centralization and others for more decentralization. Some will necessitate a lunch. In this, I think, we are typical. Bacon is good.

In addition to celebrating bacon, I proposed that  formal processes don’t suffice to manage colleges and universities, especially in times of change. A year later, the national economy fell apart as the credit bubble burst, and most institutions found themselves managing two kinds of change at once: the intellectual and programmatic expansion required by technological and social progress, plus the unwelcome shrinkage required to operate within drastically smaller and uncertain resources.

Some institutions have managed to adapt to these challenging circumstances without major dislocation. Others haven’t. It seems to me, based on lots of conversations with IT leaders from diverse institutions, that the existence of established, effective backchannel relationships is even more important in times of shrinkage than in times of growth.

Competition often dominates in times of growth. Competition really doesn’t require backchannels, in fact, backchannels can undercut competitive will. Shrinkage requires collaboration and negotiation, however, rather than competition. And collaboration and negotiation most definitely benefit from backchannels.

In other words, bacon is even more important today than it was in 2007. In the next episode: does it still make sense to follow the money?

A not-very-secret: cash “taxi” items on expense reports sometimes don’t quite correspond to actual taxi fares.

Sometimes the  traveler didn’t remember exactly what the fare was, little more than an oversight or an honest mistake. But sometimes the traveler bought, say, a drink for someone, and whereas the expense-reporting policy allows and requires no receipts for taxi fares under $25 or so, it doesn’t allow buying drinks.

Another not-very-secret: Sometimes IT help-desk or computer-repair staff actually notice things that appear on the screens of users’ computers in the course of assistance or repairs. Most policies within help desks and computer-repair groups state clearly that staff are not to read messages or look at documents on users’ computers, and that if they happen to do so accidentally they are not to disclose what they’ve seen to anyone else.

And so to a scenario. A repair technician,  A, is fixing a faculty member’s computer. The repair succeeds, the computer comes back to life, and on the screen is a message the faculty member had received from a colleague: “Had a great time drinking with my friends last night, and better still, I wrote it all off to the University as taxi fares”.

A is unintentionally aware of a faculty member’s claim to have violated University policy. Does A tell, or not? If A tells, that’s a violation of the don’t-disclose-content rule. If A doesn’t tell, that’s concealing, and therefore abetting, an apparent violation of University policy.

Most of us have a pretty easy time dealing with this one: privacy trumps expense reporting, A should say nothing, and that’s what the IT organization wants. But what if A tells? Should he or she be punished for violating the don’t-disclose rule, rewarded for helping to unearth fraud, both, or neither? Most of us, I expect, would mildly rebuke A but nevertheless thank him or her, keep the whole thing quiet, and move on.

A more nuanced scenario: same story, but a different technician, B, who is known to routinely look at material on repaired computers, and to tell stories — without identifying individuals — about what he’s seen (“You should have seen some of the pictures on a computer I fixed yesterday — I’m not going to say who it is, but I wish I got that kind of action”).

If B tells about the faculty member’s alleged expense fraud, it’s likely that B will be admonished or punished publicly even if his disclosure helps redress fraud. B presumably knows this, and so is very unlikely to say anything about the expense-fraud message. Again, most of us know how to think about this one: we really don’t expect B to tell, but we also think that B’s comeuppance is nigh given his or her history of peeking. The important point is that B’s disincentives to tell are stronger than A’s, even though the policy environment is identical.

Next scenario: Same situation as before, except now the message from the faculty member C views on the repaired computer isn’t about expense fraud. Rather, it’s a detailed discussion of plans to use a recently-purchased handgun to murder the individual who blew the whistle on certain research improprieties, thus ending the faculty member’s tenure, job, and probably career.

To me, the answer to this scenario is clear: C must tell. That means C is violating policy in exactly the same way we thought A or B needn’t, but that’s what we want C to do. Why? Because threats to life morally trump threats to property. When C tells, the University will take protective, disciplinary, and legal action as appropriate. If the faculty member turns out to have been writing hypothetically rather than intentionally, there will probably be a complaint against C, and C may well lose his or her job as a result. C nevertheless must tell.

In the process of guiding A and B, we send staffers like C mixed signals. We tell IT staff that privacy is paramount, and that violations will be prosecuted. This doesn’t stop staff from seeing things they shouldn’t, but it usually keeps them from discussing what they see. In cases where the issue is privacy versus minor fraud, or even research malfeasance, that may be the result we want. In cases where the issue is life versus privacy, however, we want staff speak up. To encourage this, we probably want to hold them harmless — or at least let them know that we’ll deal with cases based on the circumstances.

Our challenge here — I’m channeling Larry Kohlberg and other moral-stage researchers, who were active at Harvard during my graduate-student years there — is to help staff understand that sometimes personal risk must give way to moral imperative — that is, for example, that trying to save someone’s life should outweigh risking one’s job. We need to hire and educate staff to understand this kind of moral hierarchy. We need to frame our policies to recognize and address the moral dilemmas that may arise. Most important, we need to behave sensibly and pragmatically when that’s the right thing to do, and make sure our staff understand that’s what we’ll do.

Cases to think about:

http://www.nytimes.com/1999/05/20/us/pornography-cited-in-ouster-at-harvard.html

http://www.nytimes.com/1998/11/13/nyregion/inquiry-on-child-pornography-prompts-a-resignation-at-yale.html

For further reading:

http://en.wikipedia.org/wiki/Kohlberg%27s_stages_of_moral_development

I don’t want to push this metaphor too far, but here’s the idea behind this series of brief essays and comments: I plan to revisit conversations that seem, in retrospect, to be incomplete (or maybe wrong). Some of those conversations will have taken place entirely within my head.

Since that’s sort of like a ruminant (cows, sheep) chewing its cud, I picked that name for this blog.

Here are some of the conversation topics I’ve been wanting to revisit:

• When should moral imperative trump IT policy?
• Does the “demotion” of the “CIO” position mean IT is more or less important to a college or university? That is, I want to revisit my “Will you still need me when I’m 64?” piece from some years back
• Why help desks must change their perspective 180°, so that they no longer work for service providers but rather for service consumers
• Why the household parts of the National Broadband Plan are just as important to higher education as US-UCAN’s network for anchor institutions
• How should someone choose a mobile phone?
• Do people today want privacy, or just the ability to choose whether they have privacy?
• Is the demise of the strategic generalist higher-education IT leader, or more specifically the vanishing supply chain for those, good or bad?

I have no idea how frequently postings will appear, but when they do I intend and hope that they provoke controversy, discussion, and therefore progress. It’s probably worth saying that posts reflect my personal views, not those of employers or friends present or past. And of course I welcome suggestions what I might write about.