The Director of Central Computing
Managing the central IT organization is a real job. Governing technology across a research university is a different one.
Not long ago, one of the universities I indirectly supervised had a ransomware near miss. These incidents almost always begin the same way. A staff member on a Windows domain-joined machine downloads something they should not have, the malware starts beaconing out to a threat actor, and eventually a human takes the keyboard and begins working laterally, hunting for a way to escalate privileges. This one had some success. But the intruder made enough noise on the network that they were caught, and with outside help, contained before they forced the university offline.
The entry point was the one it almost always is: a Windows domain-joined machine not running the central antivirus platform. So I asked the CIO why. The answer came without hesitation. “That one is in one of our colleges, and they do not report to me.”
That is not an acceptable answer from a CIO. He was right about the reporting line. What failed was his understanding of what his role entails at a research university. In today's Dispatch, I want to explain why. The answer runs through the limits of operating authority and the point where governance authority begins. It ends somewhere uncomfortable. A CIO unwilling to be accountable for what they do not directly control is not really a CIO. They are the director of central computing.
The big picture
The instinct on reading that anecdote is to treat the unmanaged machine as proof that the leadership approach to managing IT is broken. It is not. Distributed IT staff embedded in colleges and research centers are not an oversight in the org chart. They exist because a research university needs them there to support innovation.
Engineering runs makerspaces. Medicine has its own electronic records. Executive programs configure Salesforce around admissions cycles that undergraduate admissions never has to think about. Each of these units needs a velocity and local judgment that a single central IT organization always struggles to deliver. This is the edge in the Edge, Leverage, Trust model: identity, network, ERP, and baseline information security belong in a leverage layer, standardized and centrally enforced, while specialized IT services stay close to the people who must depend on them.
So the vulnerability in the opening anecdote did not come because a distributed IT team existed. It came from a belief, held by the institution’s CIO, that distributed teams sit outside his authority because they sit outside his organization chart. That belief is the actual failure, and it rests on a confusion worth exploring in detail.
Two Kinds of Authority
There are two kinds of authority in an institution, and the CIO who cannot tell them apart will misread the entire job.
Operating authority is the power to direct people and resources. It flows through the organization chart. It is what a dean has over a college’s administrative staff and what the CIO has over the central IT organization. It is real, it is bounded, and in a research university it is distributed across dozens of local cost centers by design.
Governance authority is different. It is the power to set the IT policies, standards, and risk posture that everyone must operate within, regardless of reporting lines. It is delegated from institutional policy, and ultimately from the board, to the CIO. Trust and respect are what make it work day to day. Without it, the title CIO is meaningless.
The CIO in the opening story had operating authority over central IT and mistook it for the entire job. When the unmanaged machine surfaced, he reached for the only authority he recognized, looked at the reporting line, found the distributed IT group outside it, and concluded there was nothing he could have done. He was correct about his operating authority and wrong about his governance authority, which extended to that laptop the entire time. A baseline endpoint standard is a governance instrument. It binds the college whether or not the college’s IT staff appear on his org chart.
Everything else follows from the distinction between operations and governance. A CIO does not need operational control over every IT staff member working across the institution. A CIO does need governance authority over the things that determine institutional risk. Confusing the two produces the executive reflex to centralize: if accountability requires the reporting line, then everything must be pulled into the reporting line. That reflex is not just impractical in a federation. It solves the wrong problem, because the accountability gap was never about who reports where.
Why the Reporting Line Was Never the Point
Consider why the distributed IT staff allowed a machine to run without proper anti-virus. They were not negligent, and they were not insubordinate. They responded rationally to the incentives around them. Their dean controls their domain and their budget, and the faculty they support set the daily context for their work. Central IT controls none of it. So when a security expectation from central IT meets a competing demand from the faculty, the staff member serves the department every time, keeping complaints from ever reaching the dean. Any reasonable employee does the same.
But this is not an org chart problem. Two things were missing, and neither is fixed by a reporting line. No institutional standard reached across that boundary to make baseline endpoint protection binding, and the college’s leadership had never been brought into an enterprise risk conversation, so they saw none of the exposure their local discretion created. Creating that awareness is the CIO’s job. Enforcing the standard is the work of internal audit and compliance. Consolidating the technologist onto the central org chart does neither, because someone in a lab or a department will always stand up something outside the rules, and the hard part was never the reporting line. It is finding those pockets before they become the next incident.
This is the condition the CIO lives in: responsibility that runs well past operating authority. It is not a defect in the way an institution organizes its IT. It is the structural signature of every executive role that governs across boundaries in a complex, federated enterprise where research and innovation are core deliverables. The CIO who waits for operating authority before accepting direct accountability is holding out for a job that a research university does not offer, and never will.
How Federations Actually Hold Together
Some research universities do not produce this failure. They tend to be the ones running the Edge-Leverage-Trust model that Brad Wheeler championed at Indiana University. Inside that model, operating authority and governance authority each hold a defined place, and that arrangement is exactly what the opening incident lacked.
Start with why the model creates room for governance authority at all. Edge-Leverage-Trust does not draw its line on the org chart. It draws it on the service catalog. Some services scale, and they belong in a central leverage layer that is standardized and enforced everywhere: identity, the network, the ERP, cybersecurity monitoring. Others stay local because standardizing them would destroy what makes them valuable: a college’s makerspace, a business school’s recruiting platform, a health center’s electronic health record. Because the model settles in advance which category a service falls in, it also settles where governance authority applies. The leverage layer is governed centrally by design, and no dean has to be talked out of the reporting line to accept that, because the reporting line was never the basis for the leverage.
That distinction gives governance authority its basis, but standing is not enforcement. The endpoint standard that binds a reluctant college does not carry force because the CIO wrote it. It carries force because it flows from institutional policy that ultimately rests on board policy, and a board mandate is not something a dean declines the way he would decline a CIO’s request. The CIO’s job is to translate policy into a real risk assessment, to advocate for it, and to give units the operational support to comply. Enforcement itself belongs to internal audit and compliance, who treat adherence as institutional risk rather than a preference. Policy drives the risk assessment. Risk assessment and acceptance drive compliance. The CIO is the advocate, not the enforcer, which is why the work does not require operating authority over anyone.
None of it holds without trust running between the two layers. Local technologists accept central standards when they have learned, over time, that those standards protect their capacity rather than tax it, and central IT leaves the edge alone once it has learned that local discretion is not the same as institutional exposure. That reciprocal confidence is the Trust in the model. It keeps either layer from testing whether the other has any real authority, which is the moment things stop working.
This is a culture, not a project. A CIO who inherits it can govern across boundaries from the first day. A CIO who does not can advocate for it and move the needle slowly, one policy and conversation at a time. What the opening story exposed was not a missing line on an org chart. It was a university operating without that culture, where the leverage layer had never been settled, the risk conversation had never happened, and no one had built the trust that would have made the standard hold.
The final word
Boards often distrust federated models, and the reason is legitimate. Diffuse accountability is exactly what a board fears will surface during the next crisis. But a CIO who responds by advocating for more operational authority reveals more than bad instincts. That CIO does not understand an institution built around research and innovation, where the rush to consolidate creates the friction that erodes the mission itself. It is a failure to grasp the role, and behind it a thin understanding of how authority, influence, trust, and respect combine into leadership. The centralization may succeed on the org chart. But it will generate so much friction and destroy so much trust that the real problem, unnecessary risk, ends up worse than it was before.
The more useful answer for the board sounds something like this:
"I am accountable for all technology, including the staff and services that do not report to me. I hold that accountability through governance, not the org chart: policy the board stands behind, architecture that decides what is centralized and what stays local, internal audit and compliance reviews that treat our standards as institutional risk, and the trust and respect I have built with the leaders who run those units. I do not need operating authority over every technologist to be accountable for the whole. I need governance authority over what determines our risk, and I have it."
Every CIO at a research university eventually faces the choice that statement resolves. A CIO is someone willing to say it and to mean it, someone who understands how trust and respect, operating control and governance authority work on each other across a federation. A leader who will not say it is not really a CIO; they are the director of central computing. "They do not report to us" is a true claim about operating authority and a confession about everything else. It describes a reporting line, and the executive part of the job begins where the reporting line ends.