"Follow the Money," and Other Unsolicited Advice for CIOs: An Update

A couple decades ago, when I'd been CIO at the University of Chicago for just under three years, Marty Ringle, then and until recently the CIO at Reed College, and still a widely respected colleague, asked me to write an article summarizing advice I'd give others starting on the same path.

"The advice," I wrote, "is old, established, general, obvious—but not enough so to be commonly followed. A few of the dozen items are peculiar to information technology. Some, truth be told, are peculiar to me. Some are relevant outside higher education. Many are not." Recently a new CIO posted a request for advice, and I sent him a link to the article ("'Follow the Money,' and Other Unsolicited Advice for CIOs," CAUSE/EFFECT 22:1, 1999). Rereading the piece, it occurred to me that although much of the advice stands the test of time, some needs updating.

With a new generation taking on responsibility for IT, I thought old advice from someone who's been there might still be useful. And so here's what I wrote back in 1999, with updates, reflections, or other notes in italics after each section.

Ends Justify Means?

Never forget this: IT itself almost never is an institutional goal in higher education. Colleges and universities carry out and disseminate research; teach undergraduate, graduate, and other students; serve their communities in other ways; and administer these activities as efficiently as possible. Expenditures on IT serve and align with these larger institutional goals. Except in the narrow sense that information technology is an area for research and curriculum, colleges and universities do not invest in information technology for its own sake. This often means that institutions need far less information technology than is available to them. It also means that certain IT failures are intolerable, since they would impede institutional progress toward core goals.?

The principal example of must-work information technology is the network, including both voice and data. Networks tie everything together, and make possible the research, instructional, and administrative communication central to college or university functioning. If an institution depends on a given service's reliability campuswide, then there must be clear lines of authority, responsibility, and resource for that service. If you lose sight of that, you lose the game. Never trade away authority over networks, and seek authority over related services.?

What best advances institutional goals? Ask what IT services are directly and indirectly most important to the core work of most students, faculty, and staff, and worry first about meeting service expectations for those. Voice service typically heads the list. Next come network services such as e-mail (which imply network "data tone"). Next, by a hair, come key administrative systems, especially those involved in spending money, collecting tuition and other funds, getting paid, and handling student registration and records (which imply machine rooms and data centers). Next comes desktop-computing support (including guidance and easy acquisition, training, and help when needed). Then comes access to technology in public instructional clusters. Get these wrong—or whatever different list fits your institution—and nothing else you do will matter.?

Update: This is still basically right, especially the centrality of networks. But voice is now much less important than data, "e-mail" should be read as a proxy for network-based services in general (although it remains curiously important in its own right: see "Stockard Channing, Extended Mind, and the Paradoxical Persistence of Email"), and "administrative systems" should be read as a proxy for databases and the myriad services that feed, build on, process, analyze, and interconnect them.

Exactly how to think about security? It's not exactly a core service—much as security guards in malls don't sell stuff—but it's an ever more important domain to which IT is central. Rules versus guidance, carrots versus sticks, who's on first; all were less important then than they are now. Some thoughts: "Seatbelts & IT Security".

Also, the gradual migration of much IT from local systems to vendor services (see "Leading an IT Organization Out of Control") complicates the picture significantly. "Never trade away authority" can be as much about who sets contract terms as about who operates what.

Who's the Boss??

Not, title to the contrary, you. "There go my people," Gandhi may have said, "I must go with them, for I am their leader." The fact is, your success will be the aggregate success of your staff. Your roles are to guide their success in the right directions and to provide them the necessary resources. Unless your organization is very small, you will need to achieve this through layers. Minimize the number of layers (I have never liked the steamroller-like tone of "flatten the organization"). There should be one clearly identifiable layer comprising leaders, formal or otherwise, of each significant area in which your organization works. This area-leaders group should promote collaboration, consistency, and efficiency across group boundaries. There should be one layer reporting directly to you and small enough to become an effective management team, in which your role is akin to that of clerk in a Quaker meeting. In small organizations, these two layers may be the same.?

Without the small team at the top around you, there is too much on your plate, and your job is lonely. Without the group comprising all activity leaders, there is no clear place for cross-activity spirit and collaboration to build, and nothing to counteract groups??? natural instincts to wall themselves off. The size and culture of your organization will determine how many layers you need, and how to constitute them.?

Update: Wouldn't change a thing, except to point out that the Gandhi attribution for the quote is questionable at best; somewhat less questionable is the common attribution to French politician Alexandre Auguste Ledru-Rollin.

Blood Is Thicker Than Water?

Everyone who works for you needs to feel comfortable talking to you, even though most of them will do this rarely. Early on you need to meet each of your staff. You need to make your way around sub-unit meetings, to walk the halls where your staff work, perhaps to have satellite offices.?

Everyone also needs to feel like a valued part of the same organization. This entails obvious things like job classifications, titles, pay, equipment, space, furnishings, training, and travel. It also entails symbols like coherent organization names, logos and other graphics, business cards, and letterhead. It entails not stinting on the summer picnic, the coffee mugs, the holiday party, or whatever other festivities and tokens are traditional.?

However skilled they are, your staff occasionally will screw something up. This is an organizational failure. You, not the perpetrator, need to take public responsibility for it. You will certainly want to figure out who screwed things up, and to take measures to prevent recurrence. However, measures short of termination are internal. So long as someone works for you, do not hang him or her out publicly to dry.?

Update: Wouldn't change a thing.

Round Up the Usual Suspects?

In any IT organization, there are a number of people upon whom everyone else relies. Everyone knows who the usual suspects are. Find out. Make sure the usual suspects know you know who they are, give them lots of support, pay them well, and give them management or technical training as necessary. Include many of them in your crosscutting organizational layers (see "Who's the boss," above), and encourage their participation in crosscutting project teams. Wherever possible, make sure they bring disciples along behind them—this always pays off, since college and university salaries are rarely high enough to attract outsiders.?

Update: Wouldn't change a thing.

Espouse the Party Line?

Be very clear in your own mind what is great about IT at your institution, what is okay, and what needs work. Collect good stories and vignettes in the first area, understand what is necessary to maintain the status quo in the second, and work with your staff to develop reasonable programs and strategies to remedy the third. Have a stump speech that summarizes all this, which you can modify slightly and deliver to diverse audiences. Seek speaking opportunities—the more who hear you be coherent and intelligent, the better. Have a written document, preferably on the Web, that replicates your stump speech. Revise all this periodically and as necessary. Be very careful not to say that A is the most important thing to one audience, and then that B is to another. Especially avoid saying that C is the most important thing, and then spending all your discretionary resources on D.?

Update: Wouldn't change a thing.

What's the Difference??

You will hear that colleges and universities are too different from other organizations, that only homegrown or customized applications will do. Our institutions are indeed different from others, but only in three important IT respects. Outside these three, there is every reason to go with the commercial mainstream.?

First, colleges and universities have open data networks. We let myriad people connect devices to our networks, and then do very little to control (or even know) who they are or what they are doing. This causes our network-security needs to differ from those outside higher education. It makes us care about Kerberos, security patches to Red Hat, and flow monitoring on routers. It makes us contemptuous of firewalls. It causes the rest of the world to consider us irresponsible havens for network malefactors. Second, research universities have large libraries, whose IT systems require functionality and scale rarely necessary elsewhere. Third, colleges and universities have highly relational student information systems, whose complexity can approach that of airline information systems but whose costs and overhead must be dramatically lower.?

In these three areas the marketplace often fails to provide suitable products, making customization and development necessary. When you have to develop in-house, try to collaborate with peers, and be careful not to mistake areas where you might differ for areas where you must.?

Update: This remains mostly valid, although the second point of course applies to only a few institutions—and the whole concept of "library", even for those, involves many more cloud resources and commercial providers than before. But in retrospect there are other important differences between IT in higher education and elsewhere, especially with regard to governance and finance; see "Why is this IT different from all other ITs?"

Silence is Golden?

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, and your staff do not need to hear your frustration. What they need to hear from you is the praise for invisible success that they will not hear from their customers. You will need to get your own reassurance and support from your peers at other institutions (see "Consort with the enemy," below).?

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. (This may be more important here in Hyde Park, the fount of free-market economics, than elsewhere.) Try to keep institutional options open. Avoid strategies, vendors, architectures, and technologies that constrain choice. Seek interoperability. Wherever possible, have spillover vendors—for example, if your phone switch can manage it, two long-distance carriers, or if your store or purchasing department is willing, two desktop-computer vendors.?

Another way to gain unproductive visibility is by underrating redundancy. Make sure, for example, that the network has at least two physically independent pathways between every pair of mission-critical locations. Avoid star topologies, seeking rings and meshes instead. Pay close attention to backup, especially for data and equipment central to institutional functioning. 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. (Major disasters usually involve campuswide plans, in which your organization should participate actively, but that is a different point.)?

Update: This remains surprisingly valid today, especially the frustrating lack of positive feedback and endless kvetching from one's community.

Follow the Money...

Understanding and controlling money never achieves anything in its own right, but misunderstanding money or letting others control it can cripple you at key junctures.

...to its destination

Know more about IT finances—how things really are and how they might be—than anyone else at your institution. Never let the comptroller’s people, the budget office, or internal audit know more than you do. Learn their lingo. Be especially sure to have at your fingertips (or in your preferred handheld device; see "Practice what you preach," below) broad distributions of headcount, capital investment, and operating expense. Have your own financial officer keep tabs on budget and spending, brief you regularly, and communicate with his or her counterparts in the central financial office. Know which major expenditures go up, which down, which you control, which vary exogenously.?

...from its source

Each major IT activity needs an appropriately scaled funding source. Change any area where fixed funding (such as a core-budget appropriation) supports services that vary with demand, student-body size, or popularity of a particular technology. Help desks frequently display this mismatch. Especially avoid responsibility without control and resources. Departments are tempted to take on IT projects without providing for their long-term sustenance and growth, and then to dump those on the central IT organization when resources run out. You cannot let this strategy work. Making it clear will involve public altercations, and some ill will. Better a little ill will now than a lot of failure later (see "Timing is everything," below).?

Avoid the "we can fund it through the mainframe budget" or "let’s just overcharge for long distance" traps. Give back funds (or reduce rates) in shrinking-cost areas. Request funds (or increase rates) in growing ones. Better to publish this tradeoff than to hide both trends and hope they will balance. Savings from shrinking areas are bounded; growing needs rarely constrain themselves.

...through users?

Although recharge imposes burdens, it does all the right things with regard to budgets, it puts incentives and decision-making into the right balance, and when all the dust settles it tends to optimize service levels. But it makes people mad. Be careful to differentiate true recharge—billing people or departments for their actual well-measured activity levels—from imputed recharge, taxes, or hidden subsidies. Apportioning data-network costs to departments based, for example, on their number of telephones, headcount, space assignment, or overall budget is a perfectly reasonable thing to do. However, it requires very different justification (both legally and politically) than charging people for long-distance calls. If you do a lot of recharge and your institution receives federal funds, read and understand OMB Circular A-21, especially its implications for free rides, funny money, and exceptions.?

...over its lifetime?

Capital items depreciate. To maintain their value, one must either invest continuously in improvement, enhancement, and modernization, or periodically replace them. Most non-IT capital items at colleges and universities—buildings, steam plants, books, pavement, and the like—have long lifetimes, ten years or more. Except for some facilities-and-grounds spending, the value-maintenance strategy is to replace capital items when they wear out. This usually falls to the successors of those who approved the items in the first place, and rarely figures in capital planning. Since budget processes are driven by non-IT traditions, most treat capital expenses as one-time spending.?

This is deadly wrong for IT. Fight such thinking. Except for fiber and wire, little information technology has a projected lifetime longer than seven years. Most is useful for only three to five years without continuous upgrading. Incorporating this into building-based budget processes is very difficult and very important. Move as far down the path from one-time to annualized budgeting as you can. To do this, you will need to estimate depreciation and compare it to actual reinvestment. The gap to be closed almost certainly will be frightening.?

Update: Recharge, despite its advantages, has fallen on hard times. So it's become very much more challenging to make sure there are reasonable linkages between budgets and demand. For years IT was able to duck this problem by harvesting savings price reductions—long distance calls, for example—and using those to cover unfunded service additions or expansion. That let budgeteers think that IT would never need more funding, even as new systems and services increased demand (the "open triangle"—see "Mystery/Mastery, Knowledge as Power, Long Distance Calls, and the Voss Admonition"), and it remains immensely difficult and important to overcome that and either tie resources to activity or—as is never possible—enable the former to limit the latter.

Timing is Everything?

Move deliberately, but avoid dilly-dally when quick action is required. For example, as a new CIO you will be tempted to reorganize right away, since there will be obvious ways to improve structure. Resist the temptation. Your new organization is what it is for reasons, and you should not proceed until you understand them (see "Be where you are," below). That takes time, which you can also use to help staff within the organization themselves suggest the changes you would like, and thereby own rather than resent those changes. Conversely, there is a tendency to hope that bad management or incompetence will fix themselves. This will not happen. Fix such problems before they become bigger.?

When the time comes for changes in technology, services, rates, or structures, get on with it. The only efficient way to do this, unfortunately, sometimes involves detonating mines. If lurking problems threaten a key service or an important project, get those problems out in the open and deal with them early, even at great cost. Otherwise you risk their crippling things later, or you must somehow maneuver around the problems forever—something for which you will not have sufficient time or points. Let mines that do not impede your progress stay buried. For concrete example, avoid unnecessary fights with vocal, well-organized aficionados whose preferences, however different from yours or even the majority’s, do not interfere with institutional progress (see "Silence is golden," above).?

Sometimes you cannot or should not tackle something. Far better to stand firm on this at the outset, rather than tackle it, fail, and then try explaining the failure away later. Similarly, you will be asked to make a gazillion exceptions to every imaginable rule. Although each turndown will cost you, in aggregate they will cost much less than wholesale exceptions. There is an unavoidable exception to this rule against exceptions: the big bosses get a certain number of byes. It is very important for them to understand at the outset that the certain number is small, a few score at most.?

Update: Yup.

Consort with the enemy?

You are a senior administrator, like it or not. You represent IT interests to senior administration. You represent institutional interests to your own staff. You represent both to the outside world. Work on all the relationships this entails.?

Pay special attention to relationships outside your organization. Most institutions have senior collectives that actually hash out most decisions. These may not correspond to formal organization charts or entities. Seek seats at as many decision- and policy-making tables as possible. Since senior collectives often omit key administrators who are your peers and with whom you must work effectively, establish regular lunch rotations or similar devices as necessary.?

Externally, two goals are important: understanding the pace of technological change among peer institutions and in the market, and being prepared for awkward questions of the form "X College does A; why don’t we?" Know who are the big bosses’ friends at other institutions. Know what really goes on in IT at those institutions. Never let your president, provost, or administrative VP know more about IT at peer institutions than you do.?

Update: Parkinson's Law tells us, among other things, that once management councils grow beyond a certain size they will spawn smaller, higher-level management councils. The proliferation of "Chief (whatever) Officer" titles has had this effect on many campuses, meaning that what once was the "decision- and policy-making table" is no longer, and the Chiefs, although perhaps masters of their own domains, are excluded from the key senior collectives. The result is a perceived, and in many cases actual, diminution of the CIO's and by extension IT's importance on campus. When I left UChicago, I was a VP and reported to the President; my successors have been Associate Vice Presidents and reported to the CFO, and central IT no longer plays much of a strategic role on campus or nationally.

Practice what you preach?

As CIO, you are not only a senior administrator, but also an example. If you argue that network-based productivity tools and protocols such as central e-mail, online calendars, Web-based archives, standard document formats, and common hardware and software benefit the institution, then make sure you use them. If you require network identifiers or usernames to be in a certain format, do not grant yourself an exception.?

Beyond this, be an active and visible experimenter with new technologies, since people will expect you to have experience and opinions about the computers, software, and gadgets they hear about. To be effective in information technology, you gotta love it.?

Update: Yup.

Be where you are, not where you were?

If you came from somewhere else, your job, as a favorite bumper sticker of my son’s says, is to subvert the dominant paradigm. In doing this, avoid, except where absolutely essential or as a negative example, any mention of how things were done at your previous institution. If you must bring ideas from your old institution to your new one, find an instance of them at a third institution (see "Consort with the enemy," above) and cite that.?

This is a hidden promo for extensive inter-institutional collaboration and sharing among CIOs in higher education. I like ending on this note, since it speaks to the larger challenge all of us address: making sure that information technology helps make higher education as effective and as efficient as possible.

Update: The "be where you are" admonition is especially important for CIOs who come to higher education from the commercial sector. And so is spending time with (or learning from) colleagues elsewhere who have more experience with peculiar but important ropes.