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.