Many people taught me how to do the work I now practice each day. Brad Wheeler taught me how IT is best organized to serve a research university. Diana Oblinger showed me that trust and respect are the true currency of leadership, and that the credibility to convene an important conversation matters more than authority inherited from an organization chart. Steve Williams, Tom Putnam, Pierce Cantrell, and others taught me to lead a large organization with discipline, shared accountability, and sustained attention to developing talent. But it was Greg Jackson who taught me that technology advocacy is the defining responsibility of a CIO.
In this week’s Dispatch, I want to think about technology advocacy in a new role: how a CIO can help a research university build a shared understanding of how technology should be organized, governed, and delivered. A survey instrument like TechQual+ helps establish a common baseline of how the institution experiences those services.
The big picture
In 2004, Greg Jackson, then CIO at the University of Chicago, argued that four responsibilities justify the CIO role at a University: running central systems, capturing economies of scale, setting technical standards, and advocacy. The first three carried over from the 1990s. Advocacy was the new one, and Jackson called it the most rapidly evolving element of the job. His reasoning was structural. Universities decide how much to spend on technology, and toward what ends, amid competition among schools, units, and central operations for money and control. Technical reasoning cannot settle that competition. Someone has to help the institution develop and act upon a consistent view of technology, and Jackson believed only a CIO could.
Two years later, I extended the argument, distinguishing CIO leaders from technology mechanics. CIO leaders convene the conversations about where technology can advance teaching, research, and administration. The premise was that IT succeeds only when the people it serves succeed, so its value must be judged from outside the IT organization. A CIO cannot credibly argue for new investment or changes in business processes on technical authority alone. That work requires trust based in part on systematic evidence about how the institution experiences technology.
That same year, I began piloting such an instrument at Texas A&M University at Qatar. It drew on SERVQUAL and, more directly, on LibQUAL+, the library service-quality survey. The instrument became TechQual+. By 2015, the project reported more than 250,000 responses from more than 100 institutions over a ten-year period.
That kind of evidence matters when starting a new role. Before advocating for a different organization, investment pattern, or service model, the CIO needs to know which strengths to preserve, which weaknesses are broadly felt, and which complaints are local rather than systemic. At a complex research university, assessment helps a new CIO understand the existing environment before deciding what needs to change.
What TechQual+ measures now
The 2026 version of the survey works at two levels. It opens with sixteen core perception items covering connectivity, collaboration tools, data for decisions, support, training, and, new this year, AI access and guidance. For most of these items, respondents mark three levels: the minimum service they would find acceptable, the level they desire, and the level they believe the institution provides. The method is diagnostic rather than a satisfaction score: it shows where experience falls below the minimum people will tolerate, and how far current service sits from what they want.
The core items describe the general experience of technology; they do not tell you which specific services produce it. So the survey then asks respondents to rate the particular services they use, using names specific to the institution using the survey.
Each half is incomplete without the other. General sentiment tells you something is wrong, but not where to act; service ratings show which systems people struggle with, but miss the larger mood. Read together, they let you move from “people say IT is a problem” to a more precise account of who is experiencing what, where, and in relation to which expectations. TechQual+ tells us how people experience technology services. We should consider those perceptions alongside evidence about reliability, cost, security, and use when setting priorities and deciding what should change.
From measurement to advocacy
Last year, in an EDUCAUSE piece, I named five areas where I think CIO leadership will matter most over the next decade: simplifying work, protecting the institution, making data useful, connecting the ecosystem, and driving adoption that sticks. They are not a survey taxonomy but a lens for reading what the evidence asks you to advocate for; the sixteen core TechQual+ items do not divide neatly among them.
Two of the five areas concern how people experience technology in their work. Simplifying work begins with identifying friction. Broad concerns about difficult services or slow support become more useful when compared with ratings for ERP systems, identity and access, and support services. Together, those findings can show where technology makes work easier and where it adds unnecessary complexity.
Driving adoption that sticks asks a related but different question: whether people have incorporated a service into how they teach, conduct research, or perform administrative work. Ratings of training and support, considered alongside evaluations of teaching, collaboration, and AI services, help distinguish a tool that is merely available from one that people can use effectively. The new AI questions are especially relevant. Access matters, but sustained adoption also depends on institutional guidance, appropriate support, and confidence about acceptable use.
Two others concern coherence. Making data useful pairs the timely-data item with ratings of reporting, analytics, and ERP applications, showing whether people can get and use data to make sound decisions. Connecting the ecosystem is broader: evidence about connectivity, access, consistency, and particular systems shows where the environment feels coherent and where people meet it as disconnected parts. Protection stands somewhat apart, appearing indirectly in perceptions of reliability, access, and confidence. The survey does not measure how secure the institution is, but it can reveal whether safeguards are experienced as obstacles to ordinary work.
None of this determines what should be centralized, funded, redesigned, or retired. It reveals which experiences are broadly shared, where results diverge by constituency, and where our ambitions have outrun performance. The decisions remain judgments. The evidence establishes the conditions under which those judgments are made.
The final word
Advocacy is easy to picture as a single event: the strategic plan, the budget presentation, the slides for the board. Most though is more smaller and more constant. It happens in cabinet discussions, meetings with deans, governance and operating reviews, the monthly status report, and everyday staff discussions about which projects move and which wait. Those are the settings where a university slowly forms its common understanding of how technology should be run and judged.
Jackson began with the observation that, for technology, invisibility constitutes success. That creates a measurement problem: failures interrupt work and generate stories, while dependable services recede and draw little comment. A survey records both the problems people remember and the services they seldom have reason to discuss. In my experience, surveys like TechQual+ produce a fuller and more favorable account than anecdotes alone, while still identifying weaknesses that need attention.
This does not make complaints invalid, and it does not promise flattering results. A broadly positive finding can sit alongside a serious failure in one unit or process, and the comments are how you locate it. Evidence does not eliminate competing interests or settle questions of authority and priority. It narrows the space in which a single anecdote can define the institution’s understanding of IT, and it guards against the opposite error of using good aggregate numbers to wave off a serious local problem.
That is what separates a CIO from the director of a central computing organization. The work is helping the university understand how technology should advance its mission, how institutional experience compares with its expectations, where competing interests require common choices, and how governance, funding models, organization, and services should change over time, with evidence rather than impression. That work cannot rest on technical authority, a persuasive presentation, or the loudest story in the room. It requires evidence broad enough to be credible, specific enough to guide helpful actions, and repeated often enough to establish trust, respect, and accountability. That is the foundation TechQual+ is meant to provide.
Before the pandemic, TechQual+ operated as a Website for administering the survey and analyzing its results. Web accessibility requirements made long-term management of that site problematic, and now tools like Qualtrics and Claude Code can distribute the survey and produce analyses of the results more easily. This site contains information on the 2006 version of the survey and a Claude prompt that can be used to begin analysis of exported data.