This article was published in CAUSE/EFFECT journal, Volume 22 Number 1 1999. The copyright is by EDUCAUSE and the author(s). See http://www.educause.edu/copyright for additional copyright information.
'Follow the Money'’ and Other Unsolicited Advice for CIOs
by Gregory A. Jackson
Who is a CIO? Despite the acronym, few of us carry the title "chief information officer." We are vice presidents, directors, associate provosts, chief technology officers, even deans. We report to presidents, to provosts, to executive vice presidents, or to other senior officers. Our responsibilities and organizations cover most information technology on a campus. We are the senior administrators in information technology on our campuses, and we generally speak for our institution on IT matters.
Who am I? This is my third year as a CIO, making my tenure average for our ilk. My prior experience is the mishmash increasingly typical of college and university CIOs. I spent many years as a faculty member elsewhere. Some of my research led unexpectedly but not surprisingly to an academic-computing directorship. That job’s national tendrils led indirectly into my current job. Some say I do this job because no one questions my buying all the computer toys I want. There is much to what they say, as much of the job’s reward is its substance.
The advice I have compiled below 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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
Gregory A. Jackson (firstname.lastname@example.org) is Associate Provost at the University of Chicago.
...to the table of contents