Lunch with an old friend, beautiful day in Washington, seated outdoors enjoying surprisingly excellent hamburgers. We’re going to talk about our kids, and what we’re doing this summer, and maybe even about working together on a project some day (as we did decades ago).

But as is so often the case for those of us who work in IT, first there’s a technical question about calendars on his iPhone. He’s not clear on the distinction between the iCloud calendar and the one installed by his campus IT group.

I clarify that one is personal and the other enterprise. That segues into a discussion of calendar/email/contacts services (somewhat inexplicably, his campus still uses Notes), and then into IT services and help desks.

My friend observes that his campus provides an excellent array of IT equipment, software (Notes excepted),  and services. But it also has one of those “your call will be handled by the next available representative” queuing systems on its IT help desk.

“I really hate that,” my friend says, as I swipe some of his sweet-potato fries. Because he so dislikes the queuing system, he says, he can’t think positively about his campus’s IT, no matter how good the rest of it is. The evil that men do lives after them; the good is oft interred with their bones. (Why is the Bard on my mind? Because at home we’ve been watching the excellent BBC/PBS Shakespeare Uncovered series on Netflix.)

It’s a familiar refrain. I’ve just been rereading a 1999 article with advice for new CIOs, where I had this to say:

Information technology most often succeeds when it is invisible–when people do not realize they are using it and focus on larger goals. When you and your staff do things right, even spectacularly, no one will notice. This is immensely frustrating. The only comments you are ever going to hear–from the big bosses, from faculty, from staff, from the student newspaper–will be negative, sometimes vitriolically so. This will drive you crazy. No one outside IT at the institution will sympathize.

We like to think this is peculiar to IT. It isn’t.

Case in point: Registrars. During my tenure at the University of Chicago, we replaced an old terminal-based student system for staff only with a highly flexible, modern web-based system directly accessible by students, faculty, and staff. Students used to wait in line to give their class choices to Registrar clerks, who would then set class lists and enter data in the system manually. Grading, transcripts, and other processes were similar. No one was happy except the Registrar, whose staff and budget necessarily remained large.

The new system (now-defunct SCT‘s now-defunct Matrix product) changed everything: no more waiting in line, simpler scheduling, later deadlines for grades, online transcript requests, you name it. Asked about specifics, almost everyone described almost everything as better.

But no one seemed to feel any better about the University than they had before.

At lunch, my friend pointed to this apparent conundrum as an interesting parallel to “two-factor theory,” the suggestion by Frederick Herzberg that job satisfaction and job dissatisfaction are independent of each other. The Registrar’s customers were less dissatisfied, but that did not mean they were more satisfied.

Messier case in point: Business travel. Time was, one made business-travel arrangements by calling (or having one’s assistant call) a travel agency or travel office to make reservations and get a travel advance, and one accounted for the advance and/or got reimbursed for out-of-pocket expense by filling out (or having one’s assistant fill out) a form, attaching paper receipts to it, mailing it somewhere, and eventually receiving a check.

Today it’s much more typical to make one’s own reservations through an employer-provided website, to pay expenses with a credit card that charges the employer directly, to account for expenses through the same dedicated website, and to have any reimbursement deposited directly. This all goes much faster, and is much more cost-effective for the employer.

For those of us who like rolling our own, it’s also much more appealing. But for those who don’t, and who don’t have assistants, it’s more awkward and burdensome.

We implemented a modern travel system (Concur) while I was at UChicago. I know anecdotally that most users liked its speed and convenience, but the public reaction consisted largely of complaints (most of which really weren’t about the travel system, but rather about the loss of departmental secretaries as the University did away with them in favor of centralized clerical support).

Coincidentally, my current employer switched to Concur from a paper-based system shortly before I arrived, and I observe the same pattern: widespread private appreciation completely overwhelmed by isolated objection (much of which is actually about changes in policy, such as having to justify non-preferred hotels, rather than the system itself).

What to do? For the most part we can’t use Mark Antony’s technique: through sarcasm (“Brutus is an honourable man“–imagine the air quotes), he discredits assertions of Caesar’s evil. However, it’s unwise for us to treat our customers’ complaints sarcastically.

Rather, a principal strategy for those of us in domains where dissatisfaction automatically overwhelms satisfaction must be to minimize the former. For example, I wrote,

One way to gain unproductive visibility is by unnecessarily constraining choice. To avoid this, wherever possible use carrots rather than sticks to encourage standardization, so that homogeneity is the product of aggregated free choice rather than central mandate… Try to keep institutional options open. Avoid strategies, vendors, architectures, and technologies that constrain choice. Seek interoperability. Wherever possible, have spillover vendors… Think carefully ahead about likely small disasters, many of which are caused by backhoes doing minor excavation, contractors oblivious to wiring closets, incompetent hacking, vandalism, or broken pipes.

But although minimizing unproductive visibility is important, it’s not enough. Mark Antony didn’t rely entirely on discrediting Brutus; he also cited Caesar’s good:

He was my friend, faithful and just to me… He hath brought many captives home to Rome, whose ransoms did the general coffers fill… When that the poor have cried, Caesar hath wept…

Mark Antony understood that discrediting Brutus and extolling Caesar aren’t the same thing. But it was necessary for him to do the former in order to succeed at the latter.

So let it be with IT. We need to recognize more explicitly that maximizing the good things we in IT do to satisfy our customers and campuses (or other organizations) is important, but those good things are different from and do not counterbalance the unproductively visible ways we dissatisfy them.

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.

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