But research universities face other risks that receive far less attention. A faculty member can place restricted data, unpublished research, or developing intellectual property into a personal AI account governed by a consumer click-through license. The provider can unilaterally change those terms, while the university has no separate contract protecting its interests. The danger becomes greater as frontier laboratories enter the same scientific and professional fields in which university researchers work. Our research VP and I are now preparing a memorandum to faculty covering that risk.

This week’s Dispatch places the recent wave of AI doomerism in context and turns to the phantom risk for research universities: what happens to institutional knowledge when frontier labs enter the same research and professional fields as their customers?

The big picture

For three years, the frontier laboratories argued that speed was a strategic necessity and that anyone who slowed down would fall behind rivals at home and abroad. Now several of the same firms want to pace development, place evaluators inside their laboratories, and establish common safety expectations under government oversight. Their products do create real risks. A capable model connected to credentials, code execution, and outside systems can act beyond what its operator intended. But taking those risks seriously does not mean allowing the frontier laboratories to define the danger and design the regulatory response. Their technical knowledge should inform public policy, but they should not write the rules that govern their competitors or determine their own responsibility if and when something finally goes wrong.

David Sacks stated what most everyone was thinking: a laboratory that believes its own work is unsafe can slow that work now, strengthen its internal safeguards, and be prepared to stand behind what it delivers. None of that requires permission to coordinate with competitors or a government-endorsed roster of evaluators.

The Hugging Face incident shows how dramatic language can obscure ordinary responsibility. Recent reports, weeks after the initial news, indicate that safeguards were disabled, internet access remained open to the AI agent, the AI was rewarded for persisting, and no human intervened before the agent found an unplanned route out of the test environment and reached an outside party. That was a genuine human security failure. Calling it an AI escape hides the fact that people designed the test and left the route open. The lesson is not that AI requires no regulation. It is that regulation should hold laboratories accountable for the environments they design, the access they provide, and the systems they release. Describing the incident as an AI escape shifts responsibility from those decisions to the machine itself.

The Shape of a Moat

The rules advocated by the frontier laboratories could protect them in several ways. Government involvement could allow the largest firms to coordinate the pace of research and development without the same antitrust risk they would face acting together on their own. Approval requirements and recurring audits would impose costs that established laboratories can absorb more easily than startups or open-weight projects. A government-approved safety standard would not grant immunity when a product causes harm, but compliance could help a laboratory argue that it acted responsibly. Slowing development would also restrain an expensive race for computing capacity while the financial returns remain uncertain. And if frontier AI comes to be treated as essential national infrastructure, the same firms may eventually claim public support when private capital is no longer willing to carry the full cost.

Antitrust concerns permeate this debate. Competitors do not normally agree on how they will develop or release their products. Such an agreement could reduce competition and make it harder for new firms, particularly those developing open-source models, to enter the market. The laboratories may have legitimate safety information to share. They should still have to explain why such coordination requires an agreement about the pace at which they and their competitors develop new models.

None of these protections has been enacted, and the laboratories do not need to be working from a common plan to benefit from them. Lina Khan and Alvaro Bedoya make the more immediate case: existing competition, consumer-protection, and computer-access laws already apply to much of this conduct, and antitrust law does not prevent companies from sharing legitimate safety information. Matt Platkin argues that any new regulation should preserve the laboratories’ liability rather than give them the broad legal protection once extended to internet platforms. Alex Karp points to the longer-term risk. Once government treats an industry as essential, its largest firms gain a stronger claim to public support when private investment falters. The laboratory leaders may be entirely sincere about safety. That does not mean the rules they propose will serve the public rather than protect their own position.

The University’s Exposure

While Washington debates AI safety, universities already face a more immediate problem. Faculty, researchers, and staff use personal AI accounts to develop research ideas, analyze unpublished results, draft patentable methods, write code, shape grant strategies, and review contracts or institutional records. In each case, knowledge produced or entrusted to the university can leave an approved environment before anyone considers the terms under which the service will retain, use, or disclose it.

A sponsored-research agreement can take months to negotiate because the university and its research partners must settle intellectual-property rights, publication terms, and limits on data sharing. A faculty member can bypass those protections in a minute by placing the same work into a personally purchased AI service. A consumer click-through agreement can be changed by the provider at any time, while a university contract establishes the entire agreement between the parties and cannot be altered unilaterally. If the university did not negotiate and sign the agreement, it should not assume that the service protects its information or its interests.

Recent announcements from Anthropic and OpenAI make this concern more concrete. Anthropic has built a physical biology laboratory in the Bay Area, with robotic experimentation, a research workbench connected to scientific databases, and pharmaceutical partnerships. OpenAI has released Astra for Law, which combines a frontier model with legal research, firm-specific information, and tools developed by outside partners. Neither announcement shows that either company misused a customer’s prompts or intellectual property. They show that the frontier laboratories are no longer only selling general-purpose technology. They are conducting research and developing products in the same scientific and professional fields in which their customers work. A university using a consumer service may therefore be disclosing developing research and innovation to a company with its own interests in that field, under terms the university did not negotiate and may be unable to challenge.

Classify the Knowledge, Not the Tool

The answer is not to ban consumer AI services in their entirety. It is to decide what information can safely be placed in them. That is why AI governance is a human judgment problem. Universities must classify their information, provide approved tools, and help people understand what belongs in each environment. Public information can generally be used anywhere. Export-controlled or sponsored research, patentable discoveries, protected student records, legal strategy, and investigative files require an approved university environment. Some information is too sensitive to send to an external frontier model even under contract.

For most university work, education and judgment are better defenses than technical prohibition. Consumer AI is easily accessible outside the campus network, so unenforceable bans will drive its use out of sight. Data labels and automated controls cannot repair unclear rules or replace human judgment. When they merely make work harder, faculty and staff see IT as the obstacle, weakening trust without protecting university data. Universities should instead explain the risk, provide practical choices, and help people make sound decisions about the information entrusted to them.

A university contract can limit how a provider uses information and establish recourse when the provider fails to meet its obligations. It cannot prevent every disclosure or eliminate the consequences after one occurs. For the university’s most restricted information, the better protection may be technical: a secure enclave, a locally controlled model, or another environment that prevents the information from leaving an authorized boundary. Contracts determine what the parties owe each other. Architecture determines where the information can go in the first place.

The final word

Universities need not settle the national debate over AI safety before protecting their own data. They can classify information, provide approved environments, negotiate binding agreements with providers, and keep their most consequential work inside systems they control. Those steps are necessary whether the frontier laboratories are motivated by genuine concern, competitive pressure, or some combination of the two.

AI will change how universities work, but predictions of an autonomous AI disaster do not help a provost or general counsel decide what to do this year. As described in Epilogue 2035, the current boom will eventually confront high costs, stronger competition, and the difficulty of turning technical capability into durable profit. The rules adopted now may remain long after the investment cycle turns. The laboratories may be sincere about safety, and their preferred rules may still protect them from competition and liability. Universities should judge those rules by whom they protect, what responsibility they preserve, and whether they serve the public interest.

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.

In this week’s Dispatch, I write directly to the boards of EDUCAUSE and Internet2. The organizations now hold separate authority over work that has become interdependent, limiting the scale at which higher education can act. John O’Brien’s retirement gives the boards a brief opportunity to reconsider that structure before EDUCAUSE begins a search for its next president. I believe both boards should use this moment to bring this critical work together under a single organization.

The big picture

Colleges and Universities must do some things together that no institution can do well alone. It must design, develop, and operate technology that connects institutions and integrates their systems, help those institutions plan for, adopt, and use that technology effectively, and develop the talent capable of doing both. These functions depend on one another. Technology has little value without sound use, and that use depends on professionals who understand what they are responsible for sustaining.

Higher education has placed that work under two organizations. EDUCAUSE and Internet2 answer to separate boards and separate lines of authority. Each does serious work alone, but they operate with different missions. Neither is accountable for the whole. The result is a problem of scale. Size becomes leverage only when technical capacity, institutional practice, and professional formation move together, and under divided governance they do not. The community receives less than its real weight.

John O’Brien announced in August that he will retire as president of EDUCAUSE, after a tenure that carried the organization through a pandemic, the arrival of GenAI, and a harder policy climate. He leaves EDUCAUSE more attentive to the breadth of institutions it serves. His retirement gives the EDUCAUSE and Internet2 boards a brief opportunity to consider structural reunion before EDUCAUSE begins a search for a president whose responsibility will be to lead the organization as it exists. Institutions reexamine technologies constantly, but the organizations through which they govern themselves accumulate history until old arrangements feel like facts rather than choices. A transition makes the choice visible again. Different missions do not by themselves justify separate governance once the work has become one.

The Distinction We Inherited

The division made sense when the work itself was divided. CAUSE began in 1962 among campus data-processing leaders responsible for administrative systems and institutional data. Educom served a different community, one concerned with academic computing, communications, teaching, and research. These groups worked with different missions and values and answered to different institutional needs.

By the 1990s, the distinction was becoming harder to maintain. Administrative systems depended on campus networks to operate, while academic computing had become part of the institution’s broader technology environment. CAUSE and Educom merged in 1998 to form EDUCAUSE, seeking more coherent service across campus technology, stronger support for the profession, and a unified voice on policy.

Internet2 emerged during the same period around a more concentrated need. In 1996, thirty-four university leaders gathered near Chicago to pursue advanced networking for research and education. The resulting organization incorporated as the University Corporation for Advanced Internet Development and became known as Internet2. EDUCAUSE developed as a broad professional association. Internet2 retained an operating mission centered on network infrastructure and related technology.

The distinction between those missions remained, but the work on campuses converged over time. Networks became the foundation for administrative, academic, and research systems alike. Internet-based threats made identity and access an ongoing concern. Federated identity allowed for collaboration across institutional boundaries, connecting students, faculty, and staff together. Research data security and GenAI have since raised the consequences of getting those relationships wrong.

EDUCAUSE evolved too. Its mission broadened toward governance, teaching and learning, leadership, advocacy, and development of the profession. Internet2 remained closer to the operation of technology. Both choices were reasonable. But technology, institutional use, and professional judgment have become harder to separate even as responsibility for them has settled into two organizations. The distinction that produced the two organizations has largely faded, but the organizations remain apart.

Where the Boundary Now Runs

This organizational boundary is easiest to see in the infrastructure higher education uses to establish trust across institutions. A scholar can use an institutional login to reach a dataset or service hosted somewhere else. A visitor can connect to another campus through eduroam without receiving a local user account. Internet2 operates InCommon, the identity federation that supports much of this access. Trust in these settings is not simply a professional value. It is built into the technology.

But the technology itself only establishes identity and access. Professionals still decide what users are allowed to reach, what information must be protected, and what obligations follow from granting access. Those decisions involve policy, institutional risk, and professional judgment. EDUCAUSE convenes much of that work through its communities and programs in privacy, cybersecurity, data governance, and GenAI.

The division is therefore no longer between separate kinds of work. Internet2 operates the technology used to establish trust, while EDUCAUSE helps institutions determine how that technology should be governed and used. Each organization performs an important part of the work, but neither is accountable for connecting the operation of the technology with its institutional impact. That separation keeps lessons from the operation of the technology from directly shaping how institutions plan for and use it. Higher education approaches vendors, government, and standards bodies through organizations representing different parts of the same problem. The community has considerable scale, but no organization is accountable for bringing its technical capacity, institutional practice, and professional knowledge together.

An Honest Counterargument

The strongest objection to a merger comes from smaller colleges and universities. John O’Brien made EDUCAUSE more attentive to institutions that lack the staff and resources of a major research university. For many of them, EDUCAUSE is their only connection to the profession. Internet2 has a different center of gravity. Its services and governance reflect the requirements of research-intensive institutions operating at scale. A merger could give those larger institutions greater influence over the combined organization while leaving smaller members present but less consequential.

That possibility should not be dismissed. Bigger institutions do not merely bring more resources to a common organization. They also bring greater capacity to shape its agenda. Any merger would therefore need a governing structure and bylaws that give smaller institutions real authority rather than nominal board representation.

A second concern is whether a combined organization could preserve the discipline required to operate technical infrastructure. Internet2 already does this through a community-governed model that combines working groups and broad institutional participation with clear responsibility for network, identity, and security services. The task is to bring the operation and institutional use of technology under common governance while retaining the operating authority required for essential services.

These concerns should shape a merger, but they do not make continued separation of the organizations the better choice. Smaller institutions stand to benefit most when technical capabilities, guidance for using them, and professional development are available through one community association. Most cannot build that capacity for themselves. And common governance does not require common operating methods. A combined organization could protect Internet2’s operating authority while giving smaller institutions a meaningful role in governing the broader organization.

The present arrangement also carries risk. It divides responsibility for technology from responsibility for its institutional use and advocacy, leaving neither organization accountable for the whole community. The boards should not preserve that division simply because a merger would require careful design. They should use the transition to determine how the two organizations can come together while protecting the constituencies and operating responsibilities that made each one unique and valuable.

The final word

The present structure persists because each organization’s leaders are charged with preserving it. An EDUCAUSE president advances EDUCAUSE. An Internet2 chief executive advances Internet2, and each board governs the organization entrusted to it. As Timur Kuran has observed, arrangements endure when those positioned to question them have little incentive to do so. John O’Brien’s retirement briefly changes that calculation. Once EDUCAUSE appoints a new president, the opportunity for structural reconsideration will have passed. The EDUCAUSE and Internet2 boards should begin a formal merger discussion before the presidential search moves forward.

The reason is the work itself. Internet2 operates technology that connects institutions. EDUCAUSE helps institutions adopt and use technology while developing professionals responsible for it. Those responsibilities now depend on one another, but no organization is accountable for the whole. A merger should preserve the operating authority of network and identity services and give smaller institutions meaningful authority in the combined organization. Those are design requirements, not reasons to remain apart. The two boards should determine how the organizations can come together before committing them to another leadership cycle of separation.

Many thanks to several who helped with fact-checking this commentary. The ideas here are the opinions of the author alone, and do not represent those of his past or present employers.

My blunt response surprised them more. “Absolutely not. No way.”

I believed the University already had the stakeholder and IT leadership needed to lead the institutional work. As a veteran of five implementations, I could provide guardrails and advice to senior executives. Consultants could supply product expertise, while an independent project management firm can provide verification.

But my response also came from experience. Years earlier, I had inherited a struggling ERP implementation led by a “star quarterback” hired from outside the university. Several new technical employees had arrived with him, all earning considerably more than employees who had served the institution for many years. Morale cratered. Within my first month, the quarterback left to follow my predecessor to their new job. I quickly hired another experienced outsider. That person did not work out either.

The project hit its stride only when I turned to an early-career employee already inside the institution. This person had little ERP experience but possessed the right competencies: communication, empathy, and the ability to earn trust and respect. We placed technical expertise around her, but we could not purchase the standing she earned. Many people thought she was in over her head, but she proved them wrong.

In today’s Dispatch, I make the case behind my emphatic response. The advisers were right that the project required experienced leadership. But implementation expertise can be purchased; the authority to lead the University’s work must rest with people who have earned its trust and will live with the consequences after the go-live.

Why it matters

An ERP implementation is an institutional redesign expressed through software. It changes how a university hires and pays its people, manages its budgets, and reports its finances. Every configuration decision distributes formal authority: who can start a purchase, who approves it, and which office owns a process once the design is locked.

Building the system depends on a different capacity. It requires candid participation and workable decisions from people spread across colleges, operating units, and committees. Senior executives commission the project, functional staff guide the design, and everyone else absorbs the consequences. No one holds the whole picture. Failure rarely arrives as a single break down; it accumulates through queue time and unresolved decisions. ERP leadership is a people problem before it is a technical one.

Experience is essential, leadership is institutional

The consultants advising the selection, discussed in the opening, have a strong case. Experienced practitioners recognize the recurring failure patterns. Vendors understate complexity, institutions postpone hard process decisions, and design delays consume testing time while status reports stay reassuring after the schedule has begun to slip. Institutional knowledge alone can struggle to see these signals. A university should purchase the strongest implementation expertise it can find.

The need for product and implementation experience does not establish where institutional leadership should best reside.

Implementation expertise can be supplied by the implementation partner, the vendor, and an outside assurance team. Institutional leadership requires knowledge of the university and two different forms of authority. Formal authority comes from the org chart: a mandate, control of resources, and reporting lines. It determines who directs work, approves decisions, and escalates issues. Governance authority is the practical capacity to move a university through decisions that cross boundaries. It grows when colleagues know a leader’s judgment and believe hard concerns will be heard rather than treated as resistance, and it depends on institutional knowledge , fulfilled obligations, and the expectation that the leader will stay to bear the consequences.

An externally hired leader can be granted formal authority on the first day. A title, a budget, and reporting lines can compel participation and set deadlines. That authority is real, and it is necessary. It does not create governance authority, which cannot be assigned in the same way. An ERP project repeatedly asks people to expose weaknesses in their own processes and accept new obligations they will live with after go-live. Formal authority can require a decision. Governance authority affects whether that decision is informed, accepted, and carried into practice. It also shapes how a leader reads local variation, some of it mere habit, some of it required by law or mission. A leader carrying another institution’s playbook cannot easily tell them apart.

Authority belongs with those who bear the consequences

Authority should sit with those who remain exposed to the consequences after go-live. An external project leader gains compensation and a resume addition when the implementation succeeds, and keeps an exit option if it turns too difficult. Internal leaders remain responsible for the workflows, the staffing burden, and the disruption. This is a problem of incentives and risk allocation, not of anyone’s commitment.

The compensation gap sharpens it. A highly paid newcomer placed above long-serving staff creates a two-tier structure inside a project that depends on those same employees to share knowledge and name risk. The danger is not open resistance. It is guarded compliance. Formal authority produces attendance and completed tasks while weakening the candor governance authority requires. The suppressed risks often surface later, when they cost far more to reverse. An ERP implementation also teaches internal leaders to decide across boundaries and own enterprise impacts. Handing the central role to an outsider weakens the institution’s own bench.

The president, provost, and chief financial and administrative officer bear ultimate responsibility and form the project’s executive governing body, obligated to resolve the conflicts no single project leader can settle. They set the mandate, define the boundaries for cost, risk, and timeline, and decide whether the institution will knowingly move past a guardrail, in decision meetings, not project documents.

Day-to-day leadership belongs to an internal chief stakeholder who already holds the campus’s trust and respect. This overall project leader needs enough formal authority to direct the work and escalate decisions, and enough governance authority to work across units that do not report to the project. The person need not be a technologist, but must be able to lead the ERP IT leader and engage the CIO as an equal.

The CIO doesn’t lead the project. The CIO serves as chief guardrails and adviser to the executives, keeping enough independence to flag when separate decisions, or their cumulative effect, threaten the budget or timeline. The role resembles the architect during construction, who does not own the building or supervise workers, but protects the design and warns when accumulated decisions endanger cost or schedule.

Build the team, then surround it with expertise

The ERP IT leader runs the technical team under the overall project leader. Much of that team comes from the staff who support the existing ERP, and those same people must keep the legacy environment running while they build its replacement. This is a capacity problem rather than a scheduling inconvenience. ERP is an all-hands undertaking for all of the IT organization. Leadership has to decide which existing work will stop or slow, because a plan resting on invisible overtime is not credible.

The functional work streams sit beneath the central leadership team: payroll, human resources, benefits, budget, and procurement. Institutional process owners lead them. Their existing roles give them formal authority over the processes they manage, and their relationships and judgment give them governance authority with the people whose work will change. Corresponding staff from the ERP IT leader’s team connect each functional choice to its technical design and integration consequences.

Consultants work inside the work streams. They challenge assumptions and show how similar choices played out elsewhere. The process owners keep decision authority, because they will operate the resulting processes and absorb the obligations created during design. Every decision belongs in a log recording what was decided, who held authority to decide it, and which consequences were knowingly accepted. Escalation paths have to be real. A decision that waits three weeks for the right meeting can threaten the schedule more than a technical task that takes three days. The operating culture should reward scrutiny while the design is still soft. To lead with friction is to treat disciplined disagreement as a service to decision quality, cheaper now than as conflict discovered after go-live when disruption is costly.

Everyone with institutional decision authority in this structure comes from the university. Outside expertise belongs in three defined places. The consulting implementation partner supplies methods, specialists, and delivery capacity. The software vendor’s executive support team supplies product expertise and an escalation route beyond the account team. An independent assurance team checks plans, assumptions, and reported progress across the university, the partner, and the vendor, reconciling competing accounts and raising concerns when the project drifts past its guardrails. This keeps any single external party from both defining project performance and supplying the evidence used to judge it. It buys expertise, challenge, and verification without transferring institutional decision authority.

The final word

Expertise can be purchased through an implementation partner, vendor support, and third-party assurance. Formal authority can be assigned through a mandate, reporting lines, and defined decision rights. Governance authority operates on a different clock. It grows from trust and respect, a record of judgment, deep institutional knowledge, and the expectation that the leader will remain to bear the consequences.

A sound ERP structure requires both forms. It keeps ultimate responsibility with the president, provost, and chief financial and administrative officer. It places day-to-day leadership with a respected institutional stakeholder who holds both formal and governance authority. It uses the CIO for guardrails and independent advice, and gives functional and technical staff real authority over the work they inherit. Consultants and outsiders strengthen institutional judgment. They do not replace it.

An ERP implementation is among the most demanding leadership-development opportunities a university ever creates. Led from the inside, it should leave the institution with more than functioning software. It should leave it with a bench of leaders who have earned greater trust, shown their judgment across institutional boundaries, and grown readier for whatever difficult undertaking comes next.

Mannheim was the senior partner at Jackson Steinem & Co., occasional mentor to an ambitious young broker named Bud Fox, and one of the few people willing to describe the excesses of the 1980s market honestly. “Quick-buck artists come and go with every bull market,” he told Fox, “but the steady players make it through the bear markets.”

Mannheim was fictional, of course, a character played by Hal Holbrook in Wall Street. His judgment was not. The same pattern appeared during the dot-com boom and again before the financial crisis. Technical and human innovation create the opportunity. Financial innovation arrives later to extend the cycle, preserve easy credit, and defer the moment when customer economics must justify the investment.

Have we reached that point with AI? Who’s to say. Even Anthropic CEO Dario Amodei concedes that AI companies “haven’t yet delivered on our big promises to benefit the world.” The investment cycle is now sustained by more than demonstrated results. Nearly every participant bears greater immediate risk from questioning the consensus than from continuing to finance it. That does not mean AI will fail or the boom will end soon. It means the traditional mechanisms that discipline credit and investment are weakening as commitments grow larger and harder to see.

What should we conclude when financing the purchase becomes more important than the product itself? Since 2022, the AI story has been about what models can do. It has quietly become a story about credit. In today’s Dispatch, I want to examine what sustains this boom and what an institution should protect before the correction comes.

The big picture

On August 10, six of the largest investment firms agreed to help Nvidia mobilize more than $500 billion for AI infrastructure through intermediaries that keep the debt off its balance sheet. Bloomberg had already identified roughly $70 billion in guarantees that could still come due. The exposure now appears much larger. A Wall Street Journal analysis found roughly $3 trillion in off-balance-sheet commitments across nine technology companies, mostly tied to AI, including leases that have not begun and contracts for future equipment and services. Many cannot easily be canceled. Underneath the jargon, the arrangement is straightforward: a special-purpose entity borrows to buy the chips and repays the debt from a customer’s lease payments; if those payments stop and new customers cannot cover the shortfall, a chipmaker or hyperscaler may provide the backstop. But the firms supporting these arrangements have substantial commitments of their own, some extending decades into the future. Risk is moving into larger, less visible pools of institutional credit while the capacity of model labs and hyperscalers to honor their leases and guarantees still depends on the same optimistic assumptions about AI productivity and future revenue.

Potential buyers of this debt are no longer uniformly convinced. Bill Eigen of J.P. Morgan told CNBC that the cycle was beginning to resemble real estate finance more than technology investment. The mismatch is difficult to ignore. Investors are being asked to buy thirty-year debt secured by data centers filled with equipment that may depreciate within five years. The debt is made more attractive by long leases and guarantees from hyperscalers such as Meta, but those firms already carry substantial commitments. It is not clear how much protection a backstop provides if falling AI demand weakens the customer, the collateral, and the guarantor at the same time. Off balance sheet, Eigen observed, does not mean the obligation has disappeared. He heard similarly confident claims about limitless fiber demand in the late 1990s.

These new financing structures do not remove credit risk. They make it harder to see. Supporters make a plausible case: AI demand will continue growing, the debt will amortize as the hardware depreciates, and cash-rich guarantors can absorb any losses. Most of these deals appear rational. The systemic concern lies in the assumption they share. Financial engineering cannot produce the productivity gains needed to justify the buildout or ensure that model labs will generate enough profit to service their debts. Adding more creditors spreads the exposure, but it does not diversify the underlying wager on AI demand. So why do credit markets remain so accommodating?

Why the consensus holds

Timur Kuran’s work helps explain why. He studied how systems maintain an aura of stability even when the private judgments within them have begun to diverge from the public consensus. He called the mechanism preference falsification: people adjust what they say publicly as conformity brings reputational benefits, while dissent imposes an immediate cost. Private doubts can grow quietly without weakening the visible consensus. The first person to challenge it bears the greatest risk.

The financing market can reinforce that logic without requiring dishonesty. Credit analysts who turn cautious about AI risk losing customers. A CIO who urges restraint about AI’s likely effects can be dismissed as behind the times. Eigen encounters the same pressure when he questions the assumptions behind the AI buildout. “And all I’m saying, and the funny thing is, when I bring any of this stuff up, people get angry with me, and that tells me something also,” he told CNBC. The anger matters because it reveals the reputational cost of challenging the consensus, even for an investor speaking within his own expertise. Being wrong with the consensus is institutionally safer than being right alone and too soon. The doubt is kept off the public ledger.

Outsiders see the commitments, not the reservations or time horizons behind them. At a private gathering of veteran investors in Maine, the doubt was explicit: no one could say whether AI earnings would justify the spending, yet no one was ready to leave the trade. The Wall Street Journal described them as holding their doubts in one hand and pressing “buy” with the other. Confidence is not judgment, and a good deal of the confidence on offer right now will prove wrong. Each new investment becomes public evidence for a thesis its participants are privately questioning. Kuran called the deeper effect knowledge falsification. Preference falsification first hides doubt; over time, its absence from public discourse makes the underlying assumptions harder to challenge. Once AI transformation becomes a planning premise rather than a claim requiring evidence, institutions stop asking whether the projection is sound and ask only how quickly to join. The responsible alternative is to participate while making commitments that protect the institution if rosy projections prove wrong.

A model for participating without ceding control

Wendell Weeks offers a different model, and not because he doubts AI. Corning supplies the optical fiber and silicon photonics used to connect the servers inside AI data centers. It has signed multibillion-dollar agreements with Meta, Nvidia, and Amazon. But Weeks, who ran Corning’s fiber-optics business through the telecom collapse after 2000, has negotiated terms that sometimes require customers to provide upfront capital for the factories and workers needed to fulfill their orders. Nvidia, for example, is investing in Corning and prepaying billions to expand production. Weeks accepts responsibility for research, innovation, and production. The uncertainty created by a customer forecasting extraordinary demand belongs with that customer and its shareholders. If a customer orders a million units and ultimately needs one hundred, Corning should not bear the full consequence. Weeks is willing to serve the boom. He will not “bet the family farm” on someone else’s overly optimistic forecast.

Siemens is taking a similar posture as it expands production of electrical and power equipment for data centers. The company is seeking longer-term supply agreements to support new capacity and aims to recover its factory investments within three or four years. It is also using third-party manufacturers for some orders, giving it room to reduce outside production before demand weakness reaches its own factories, and it is maintaining business in other industrial markets rather than becoming wholly dependent on data centers. These are different mechanisms serving the same principle. The company making the demand forecast should retain meaningful exposure if the forecast proves wrong. That is skeptical optimism. It does not require smaller ambition. It requires commitments that allow the enterprise to benefit if demand holds while protecting its people, capital, and capacity if it does not.

What this means for higher education

Higher education cannot negotiate from Corning’s market position or manage factory capacity as Siemens does. But we can apply the same discipline. Corning requires customers to help fund the capacity their forecasts demand. Siemens seeks longer commitments, uses outside production for flexibility, and protects lines of business that do not depend on data centers. Both distinguish between the capabilities they control and the demand risk their customers create. Universities should do the same. We should invest most confidently in capabilities that retain value across vendors and market corrections: governed institutional data, process knowledge, integration capacity, and the judgment of faculty and staff. Contracts should place appropriate obligations on vendors. Architecture should limit the consequences if a forecast proves wrong and preserve a practical way out. The commitments deserving the most scrutiny are those tied to one vendor’s adoption forecast, pricing model, or technical design. The question for university leaders is simple: if this product, its pricing, or this vendor changes materially in three years, what obligations, disruptions, or stranded investments will the university be left to absorb?

The same principle applies to our students. Universities must prepare them for an economy shaped by AI, but we should not confuse proficiency with today’s tools for preparation across a career. AI is beginning to absorb some of the entry-level work through which people once learned a domain, encountered exceptions, and acquired professional judgment. Stanford researchers have reported a 19 percent relative decline in employment among workers aged 22 to 25 in occupations most exposed to AI. The first rung is where professional judgment is formed. Our responsibility is therefore larger than teaching students to operate a particular model. We must give them disciplinary depth, the ability to frame consequential problems, and enough judgment to evaluate uncertain outputs and stand behind the decisions that follow. Those capabilities will remain valuable whether the current investment boom continues, contracts, or eventually gives way to a more durable AI economy.

The final word

AI will matter. That does not make every forecast sound or every investment prudent. Kuran explains why public confidence can outrun the private judgment beneath it. Weeks and Siemens show how to participate in a boom while keeping its risks with those best positioned to bear them. For universities, the work is to invest in data, process knowledge, judgment, and infrastructure that outlives the hype cycle. Good governance is not a wall against new tools. It produces the judgment to use them and keeps others’ optimism from becoming an obligation the institution cannot carry.

Still, skepticism is not a strategy. Universities need a practical answer for those who already use personally licensed AI in their day-to-day work. As I work with others to develop an AI strategy at my new institution, I keep returning to one simple principle: data protection should correlate with the consequence of disclosure. Data classification gives us a way to translate that principle into everyday judgment.

In today’s Dispatch, I want to use that framework to consider when personally licensed AI is appropriate for university work, when an institutionally licensed tool is required, and when data should not enter a cloud-based AI service at all.

The big picture

Most universities are answering the wrong question about AI. They ask which tools to allow. The more useful question is which data may go where.

Universities tend to take one of two positions on personally licensed AI use. The first treats it as a risk to be banned. Prohibition rarely stops the behavior; it drives use underground, out of the institution’s view and beyond its governance. The second accepts the use because people are already relying on these tools, but offers little guidance about what information belongs in them. One position prohibits without distinction; the other permits without boundaries. Neither helps users distinguish between an ordinary draft and data whose disclosure would create real harm.

Universities should stop writing AI rules around tool adoption and start writing them around data classification. In “Everyone’s Using GenAI, Few Admit It,” I argued that concealment is not primarily a technology problem. A 2025 KPMG and University of Melbourne survey of 48,000 workers found that 57 percent hide their AI use at work. Concealment on that scale is not adequately explained as individual rule-breaking. It is also a structural response to rules people find difficult to understand or apply.

Classify the Data, Not the Tool

The instinct is to sort AI tools into two bins: personal accounts that are risky and university licenses that are safe. A personal tool is not inherently unsafe. What matters is the data placed into it and the terms under which the provider uses that data. A university-licensed tool is appropriate for more sensitive information because of its contract and data-processing terms, not because the university paid for it.

The right bin depends on the data's classification, the consequence of disclosure, and the contract governing the service. One rule holds it together: protection standards should rise with the consequence of disclosure. Public and ordinary university data can go into either type of environment. Sensitive data belongs only in a service the university has under contract. Restricted data belongs inside a controlled system.

• Public data is what the institution has already released to anyone: websites, catalogs, adopted policies. If anyone can obtain it easily, the institution gains little by dictating which AI reads it. Personally licensed AI is appropriate.

• University data is ordinary internal working material that is neither published nor regulated: drafts, plans, routine correspondence, analysis. Personally licensed AI can be acceptable here. Most of this could be released under an open-records request. Its disclosure may create embarrassment or operational difficulty, but not the consequences associated with losing a regulated record. But not every internal file is ordinary. Personnel matters, privileged communication, identifiable survey responses, and procurement material may belong in a tier higher regardless of disclosure requirements. This is also where my own practice has become more conservative than this framework strictly requires.

• Sensitive data is covered by statute, regulation, contract, or policy: FERPA records, HIPAA-regulated information, identifiable human-subject research. It belongs only in an approved university environment governed by contract, including appropriate restrictions on retention, disclosure, and model training. The dividing line is not free versus paid but personal terms versus institutional protection. A paid personal subscription does not provide those institutional protections: no contract, no audit rights, no enforceable controls. Holding the license is not the end of it. Even inside an approved environment, local policy and the principle of data minimization still govern what should be disclosed.

• Restricted data is high-value information whose disclosure can trigger a breach notification and remediation: Social Security numbers, financial account information, authentication secrets, or controlled research data. A university license does not clear it for a general cloud AI service. It belongs in a local model, a secure enclave, or another approved architecture that contains it. Some data can be protected by contract. Restricted data requires a protected architecture.

The framework is best understood as four simple principles:

• Public: personal or university AI is appropriate.

• University: personal or university AI, with discretion.

• Sensitive: approved university-licensed AI only.

• Restricted: local model, secure enclave, or other approved architecture.

Drawing these lines is the easy part. Two common institutional responses fall short: licensing and mandating a single tool, as if standardizing the tool settled what data belongs where; and routing every use through someone for approval, as if a gate best replaces human judgment. Neither teaches people to classify the data in front of them and use the right tool accordingly. Only that education moves governance forward, and only if the policies and guidance are simple enough to remember and apply.

Where My Own Practice Changed

This framework permits me to use a personally licensed AI tool with ordinary university data. Increasingly, I choose not to. The reason has less to do with model quality than with where my personal and institutional context already resides.

Recently, I needed to prepare for a meeting on a complex subject. The relevant material was scattered across email, OneDrive files, file attachments, and earlier exchanges I only partly remembered. I could have collected those materials and uploaded them to a personal AI service. Instead, I asked Microsoft Copilot to examine the information already available across my Office 365 account and prepare a briefing.

It did the work well, but the quality of the summary was not what changed my prior thinking about Copilot. The personal context was already there. Months of email, attachments, drafts, and earlier decisions had accumulated inside systems where the university already stored and governed its work. Copilot could use the portions of that record I was authorized to access without requiring me to find the relevant materials, download them, and upload them to ChatGPT or Claude.

That was more than a convenience. Moving the same information into a personally licensed AI tool would require me to decide what to transfer and whether the university had accepted the terms under which that service would receive it. I would be taking information out of an established institutional relationship and placing it into a personal one. Copilot made the accumulated context useful without requiring me to reconstruct the university’s contractual and technical boundaries around it.

My university already has a data-processing agreement with Microsoft governing the material stored in Exchange, OneDrive, and SharePoint. Connecting a personally licensed service to those systems would place university data within a relationship the institution didn’t choose or negotiate. The Microsoft contract does not eliminate risk. It does establish obligations, institutional authority, and recourse that a personal subscription cannot provide. Copilot is now my go-to for university or sensitive data.

Why Copilot Deserves Another Look

In my 2025 comparison of Copilot, ChatGPT, and Gemini, I described Copilot as enterprise-grade but underwhelming. Microsoft offered strong institutional privacy protections, but the product itself suffered from weak personalization, restrictive file handling, and an experience that felt designed more for corporate use than for higher education users. That assessment was once fair. The product has gotten much better.

Microsoft has since moved Copilot toward a multi-model platform, with Anthropic models joining OpenAI models within the Microsoft environment. This changes the institutional calculation. A professional Copilot license is no longer simply a bet on a single Microsoft-selected model. The university can gain access to different models while preserving the contractual protections and administrative controls of the Microsoft relationship. Memory and custom instructions also make Copilot better suited to sustained, personalized work, though those capabilities remain subject to licensing, institutional configuration, and ongoing product maturity.

This returns me to an argument I have made about Apple. Apple is trying to keep the personal context close to the device. Microsoft is building the enterprise counterpart, keeping the user’s work context inside the cloud environment that already holds the email, files, permissions, and accumulated record of institutional work. The architectures are different, but the governing principle is the same. Useful AI depends on context. Trust depends on where that context is best allowed to reside.

The final word

Copilot’s progress does not remove the need for sound data governance. Because it works with existing permissions, it can make institutional oversharing easier to discover and use. That is not an argument against Copilot. It is a reminder that a capable AI tool inherits the strengths and weaknesses of the environment around it.

But good data governance cannot be reduced to controls, tollgates, or a hierarchy of approvals. Most decisions about data are made by users in the ordinary flow of work, when they collect, share, analyze, store, or place information into an AI tool. No technical control can anticipate every circumstance. Institutions must give people simple principles, teach them to assess the risks associated with different types of data, and empower them to apply proportionate protection while minimizing what they collect and disclose. Sound judgment is not a substitute for governance. It is what good governance should produce: a community prepared to recognize risk and act responsibly without routing every decision through a central authority.

Universities need boundaries that reflect the consequences of disclosure, not one rule for every tool or a single tool. Personally licensed AI still has a place. Sensitive data requires institutional protection; Restricted data requires architectural containment. The best policy develops the judgment people need to know where each kind of work belongs. And when that work depends on the accumulated context of the institution, Microsoft Copilot has become a far more credible default than I once believed.

The entry point was the one it almost always is: a Windows domain-joined machine not running the central antivirus platform. So when asked why, the CIO reported 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.

I was skeptical, but yielded on the condition that we run a limited bid rather than a full RFP that would take months. Weeks later, I learned the limited bid was not permitted. A full RFP would be required, with real pressure on the go-live date. I asked for one thing: a date at which we would revert to the current solution if procurement slipped. The answer was that procurement would make the date, and that we should flag it if it began to slide. I said as plainly as I could that this is exactly the wishful thinking that puts these projects at risk. On this point, I was overruled.

Weeks later I learned the rest. The module had not been required by compliance or policy. It was the preference of a single manager. Had that been clear to me, a direct conversation with that person might have produced an accommodation that never put the timeline at risk. In today’s Dispatch, I examine why assigning ERP requirements to departments rather than individuals puts implementations at risk, and how listing a specific name with every requirement is a fundamental prerequisite for success.

The big picture

Every ERP implementation runs on three levers: scope, resources, and timeline. The three are not independent variables. They form a system in which controlling any two determines the third. Fix the scope and the resource level, and the timeline becomes a calculated result rather than a target. Fix the timeline and the resources, and the scope is defined by what that combination can realistically accomplish. Fix the scope and the timeline, and the staffing requirement is set for you whether the budget supports it or not. A project that appears to be in trouble on one dimension is almost always constrained on the other two as well. The levers move together.

The timeline is a lever in the earliest phase of a project, when scope and resources are still being mapped, and nothing has been formally committed. After that window closes, moving it carries a specific and considerable cost. In higher education, go-live dates attach almost immediately to enrollment cycles, payroll schedules, and fiscal year boundaries. Slipping a date does not mean slipping a few weeks. It means waiting for the next cycle, often six to twelve months later, while consultants remain on the clock. Few institutions can absorb that cost. The deadline is not a negotiating position. It is a fact of institutional life, and the project absorbs it as such.

Resources cannot move either, at least not in the way the lever implies. Adding people to a late project is almost always counterproductive. The work requires knowledge of how the institution operates, and that deep knowledge takes months to acquire. A new consultant or a borrowed analyst arrives without the background context that makes the existing team productive. They consume the time of experienced staff before they begin to contribute. Pulling this lever usually slows the project down.

That leaves scope. When the date will not move and the team cannot grow, scope is the only remaining variable. Cutting scope means deciding which requirements survive and which are deferred, and that decision is a negotiation conducted under time pressure among people who do not all want the same outcome. The outcome of that negotiation determines whether the institution crosses the go-live line in a position to function effectively, or spends the following months struggling to operate a system that was not ready for the community it was supposed to serve.

This is why scope management is the defining discipline of ERP implementations. When a project underdelivers, the cause is rarely technical. It is the way institutional power arrangements impact project leadership, and the requirements matrix is where that power becomes visible. The project team holds almost no institutional standing relative to the offices whose requirements it is asked to satisfy. Faced with pressure they cannot redirect, project teams do what project teams do: they say yes and work harder. Most cost overruns and go-live failures trace directly to that dynamic.

The Structural Flaw of Faceless Requirements

A common practice in project management is to list departments as the owners of specific requirements. A tracking tool has a requirement owner that shows “Legal Affairs” or “Financial Aid” next to a highly customized workflow. This is a structural error, and it is the error that makes scope negotiation nearly impossible.

A department is an institutional abstraction, it’s a machine built to execute rules predictably. You cannot look a department in the eye. You cannot ask a department to weigh tradeoffs, acknowledge resource constraints, or compromise on an entrenched process. When “Legal Affairs” owns a requirement, that requirement becomes an immovable monolith. It is stripped of its human context and insulated from scrutiny.

The alternative is to associate a specific identity with each requirement. Marshall Rogers, the General Counsel, is a person. He operates with judgment, not only rules. He understands institutional risk. He manages budget constraints. He knows the operational realities of his division and the political cost of delaying a campus-wide initiative. A project manager can negotiate with Marshall Rogers. Marshall Rogers can examine a clunky legacy process and make a rational decision to alter it. “Legal Affairs” can do none of these things. The difference is not cosmetic. It is the difference between a requirement that can be negotiated and one that cannot.

The Higher Authority Tactic

A requirement assigned to a department does more than obscure its practical owner. It hands the project team’s stakeholder counterparty a ready-made negotiating move: the appeal to absent higher authority. Karrass identified this as one of the most effective ways to resist a concession, and it works precisely because of the standing gap already described. When a mid-level subject matter expert tells a project manager that compliance requires a custom workflow, that expert is borrowing the political clout of an entire division. The borrowed clout becomes a barrier to change. The stakeholder avoids the discomfort of change, and the status quo survives untouched.

The move works because it removes the decision from the project room. No one present can question a compliance standard, because standards are not a person who can be questioned. The requirement survives not because anyone has defended it, but because no one in the room can overrule it. The project team, already short on influence, is now arguing with a decision no one present has the authority to change.

Defeating this move requires returning the conversation to human terms. Voss describes calibrated questions as the instrument for exactly this work. The response to “the department needs this” is to ask who specifically owns the risk if the process is simplified. The question forces the requirement out of the abstract and locates a named leader who can weigh the tradeoff. Once that person is identified, bargaining can begin. Until then, the project team is not negotiating. It is absorbing.

Work Simplification Requires a Name

Naming a requirement’s owner is the precondition for simplifying the work, and simplification is what cutting scope actually demands. Isaacman has argued that simplification requires breaking old habits, challenging assumptions, and accepting calculated risk. Inside an ERP project, that means reducing non-value-added time and removing legacy logic that no longer earns its place. It is a process of deciding what to stop doing, and someone has to decide it. That requires people actively negotiating.

A department will not volunteer for that. Institutional abstractions default to safety, and safety means preserving the existing process, whatever it costs the new system. Simplification is uncomfortable because it requires spending political capital to change how people work, and a department has no political capital to spend. A named leader does. Only a person with standing can look at a convoluted, decades-old process and decide the institution no longer needs to do it that way. Without that person, the old logic survives, and the new system is customized to accommodate it.

This returns to where the three levers left off. Scope is the only lever that can actually move, but people move it, not abstractions. A requirement owned by a department cannot be cut, because no one can be asked to cut it. The faceless requirement is not a neutral documentation choice. It quietly removes scope from what the project can negotiate, which removes the one lever the institution had in the first place.

The final word

ERP implementations are human negotiations disguised as software projects. Because the timeline is fixed and added resources rarely help, scope is the variable that drives success, and scope can only be managed through negotiation with the people who own the work. When project tracking obscures those people, the institution loses its capacity to conduct that negotiation. It finds itself bargaining with ghosts.

The correction is concrete. Audit the requirements matrix. Examine every line item and every requested customization. Where a department is listed without a corresponding human being, the project is carrying unmanaged risk and has quietly surrendered its only lever. Demand a name. Put that person in the room and ask them to defend the requirement. Make the requirement human, and negotiate the work.

The big picture

Over the weekend, Satya Nadella published an argument about where value lives in an AI-driven economy. The short version: the AI model itself is becoming a commodity. The asset that appreciates is the feedback loop around it. For the first time, organizations can build an iterative loop between human judgment and AI systems, not just use chatbots to make people slightly more productive. The durable asset is not which model a firm picks but the ecosystem that surrounds it: the workflows, domain knowledge, and accumulated context that make a model useful in a specific institutional setting. Nadella calls the two sides human capital and token capital, and he argues that they compound together rather than substitute for one another.

The structural claim underneath the vocabulary matters more than the vocabulary itself. If AI models are becoming a commodity, then the value moves to whoever owns the loop. Whoever owns the loop owns the context, the data, the workflows, and the judgment that makes the model useful. The model is replaceable. The loop is not.

This framing arrived after Apple’s WWDC 2026 keynote, where Apple demonstrated the same insight applied to individuals across their ecosystem of devices: iPhones, iPads, and Macs. Nadella was writing about the future of businesses. Apple had already shown what the same logic looks like when applied to individual consumers.

Apple’s Answer

Apple announced a new family of foundation models, AFM 3, organized around a clear architectural premise: keep the loop on the device, and use the cloud only when the device cannot handle the request alone. The family includes five models. A three-billion-parameter dense model, AFM 3 Core, runs on a wide range of existing hardware. A larger twenty-billion-parameter on-device model, AFM 3 Core Advanced, uses a sparse architecture that activates between one and four billion parameters per request, depending on the complexity of the task. The full model lives in flash storage, with active experts loaded into working memory as needed. A server-based model, AFM 3 Cloud, runs on Apple Silicon inside Apple’s Private Cloud Compute. A diffusion model handles image generation. The most capable cloud model, AFM 3 Cloud Pro, runs on NVIDIA GPUs hosted in Google Cloud, with Private Cloud Compute extended to that infrastructure to preserve the same privacy guarantees.

Above these models sits the new Siri, which Apple is calling Siri AI. The job of Siri AI is orchestration. It decides which model handles which request, based on what the task requires and what the device can do locally. The user does not see this decision. The user sees an assistant that holds the personal context of the device and acts on it.

Two design commitments hold the architecture together. The first is that personal context lives on the device and does not leave it. The information that makes the assistant useful, including messages, calendar, photos, files, and on-screen content, is local. The second is that even when a request goes to the cloud, the data is encrypted in transit and not retained. Private Cloud Compute is not a hosting environment in the conventional sense. It is an attested, cryptographically verifiable infrastructure that Apple has designed to make user data unreachable, even to Apple itself.

Apple’s answer to the question of where the loop lives is therefore concrete. The loop lives on the device. The device holds the personal context. The cloud is a temporary extension of the device for the limited tasks the device cannot perform alone.

The Loop in Practice

I am running the first developer beta of iOS 27 and iPadOS 27 to see what this looks like in operation. The most useful demonstration so far came from a Google Sheet open on my iPad. The sheet held Zillow data for a house we listed for sale: views, saves, showings, days on market, etc. I asked Siri AI to tell me what the data meant.

The response did several things at once. Siri AI interpreted the listing performance against typical patterns at this stage of a sale. It then pulled in context from text messages between my wife and me, where we had discussed expectations and concerns. It also pulled context from a separate thread with our real estate agent. Siri AI recommended next steps consistent with the outcome we had been discussing, and offered to draft a set of follow-up questions and send them to our agent.

The recommendations were genuinely insightful and useful, but they are not the point. The point is the architecture. A single assistant reasoned across a spreadsheet in a third-party app, two separate message threads with two different people, and the underlying intent of the conversation, then proposed a specific action and offered to execute it. None of that personal context left the device. There was nothing to upload, nothing to grant additional permission for, nothing to copy and paste into a prompt.

This is the loop Nadella was describing. It is running on my Apple device.

The Device as Infrastructure

The structural point is easy to miss inside the Apple Intelligence demo. Apple did not solve the context-and-privacy problem by building more data centers. Apple solved it by treating hundreds of millions of devices it had already sold as the infrastructure. The iPhone, iPad, and Mac are not endpoints calling into a centralized intelligence. They are the loop. The data center, for everyday use, is the Apple-made device itself.

The contrast with the current alternatives is sharp. To get a comparable result from ChatGPT, Claude, or Gemini today, the user has to do the integration work: connect documents, grant access to mail and messages, paste in context, and accept that the privacy guarantee is essentially an unverifiable promise not to train on the data. The model is powerful. The loop is not closed. The user is the integration layer.

Apple’s approach reverses that arrangement. The loop is closed by default. The integration is the operating system. The privacy guarantee is architectural rather than contractual. For the everyday tasks that make up the majority of what individuals actually want from AI, summarizing a document, drafting a reply, reasoning across personal context, taking a small action, this is sufficient. It does not need a frontier model or new data centers. It needs a closed loop with the user’s context inside it.

That is what Apple will ship in September.

The Enterprise Question

Apple and Microsoft now agree on the structural insight. The ecosystem is the asset. The model is less critical. Where they differ is which ecosystem they intend to own.

Apple is competing for the individual consumer. The loop runs on the device. The context is personal. The tasks are everyday. This maps onto the framework I have used before, which separates everyday AI, the productivity layer that makes individual work marginally faster and more coherent, from game-changing AI, the systems that reorganize how an institution operates. On the everyday side, the contest is now largely settled. Apple delivers the device, the operating system, the application layer, and the data graph of the user. No other competitor can bring those pieces together.

Microsoft is competing for the firm. Nadella’s essay is a wager that the same ecosystem logic, applied to businesses, will determine who captures the value of game-changing AI: the workflows, judgment, and proprietary knowledge that make an organization differentiated. Microsoft’s position is that Azure, the Office 365 footprint, and the installed base of Windows in the corporate world give it the right starting point to host the enterprise loop. Google is making a similar wager, with Workspace and Gemini occupying the same conceptual ground as Microsoft.

The enterprise contest is not a question of who has the best AI model. It is a question of who can credibly host the institutional loop that makes a model useful inside a specific organization with specific business needs. That question is not yet settled.

The final word

The ecosystem era of AI is here. The model is becoming the commodity. The loop, the context, and the privacy posture around AI models are the durable assets.

On the consumer side, Apple has closed the question. The combination of on-device models, an orchestration layer that picks among them, and a privacy architecture that keeps the context local is the answer to what most individuals want from AI most of the time. It does not require new data centers. The data center is the device.

On the enterprise side, Microsoft and Google are now stating their respective theories of the case. The institutions that will use these systems, including most universities, are still working out which loop they want to live inside and what they are willing to give up to do so. That is a consequential contest, and it will take a while to resolve.

For now, I am waiting on the second developer beta.

The big picture

This Substack began with a commitment. When John O’Brien asked whether I would take on stewardship of the EDUCAUSE CIO Constituent Group, I told him I would, but that I intended to use the platform to advocate for the ideas that more than twenty years as a CIO had brought into focus. Dispatches from an Internet Pioneer is the record of that advocacy. A weekly Substack accumulates arguments whether its author intends it or not, and after roughly a year, the underlying architecture of the writing becomes visible in a way it was not when the project began.

This piece is an attempt to name that architecture, and to organize the existing body of work around the convictions that produced it. Readers who have followed the writing from the beginning will recognize the through-lines. Readers who arrived more recently may find it useful to see them gathered in one place, with specific pieces grouped by the argument they serve rather than by the subject they address.

Nine categories do most of the work. Each is supported by a cluster of articles that develop it from a different angle.

Technology and Society: The Long View

The most durable arguments in this newsletter are not about technology at all. They are about institutions, and about what happens when successive waves of disruption arrive faster than the social structures built to absorb disruption can adapt. These pieces are less about what to do and more about how to see. They situate technology shifts in their full civic context, and they are most useful to readers who sense that something structural has changed but have not yet found a frame for what it is.

• Certain About Everything, Agreed on Nothing (May 5, 2026) examines how cable news and the Internet inherited and scaled an outrage model already proven out by talk radio, eroding the relational capital that productive disagreement requires.

• Remote Work Will Fast Become Dead-End Work (Feb 3, 2026) argues that as generative AI handles more execution work, physical presence in the institution becomes a structural asset that remote arrangements cannot replicate.

• The Weathering Effect (Oct 28, 2025) examines how four successive disruptions have narrowed the imaginative range of leaders who lived through them, and what sustained strategic vision requires in spite of accumulated battle fatigue.

• Jobs at Risk, Jobs That Rise (Jun 17, 2025) frames the labor impact of AI as a reclassification of certain types of work rather than a wipeout of knowledge work, with significant implications for how institutions train, hire, and retain staff.

• Innovation, China, and the Fair Use Dilemma (May 6, 2025) examines how weakening copyright protections to accelerate AI training risks the intellectual property framework that made the US the home of technology innovation.

• From Institutions to Algorithms (Apr 22, 2025) traces how the Internet did not invent the erosion of institutional trust but scaled it, and how generative AI accelerates a shift towards forms of digital certainty already underway.

• 1993, 2007, and 2022 (Mar 2, 2025) introduces the Substack’s basic frame: three technology shifts follow a recognizable pattern, and the third wave reaches into the production of knowledge itself, each shift accelerating the previous trends.

Technology Strategy and Governance in Higher Education

Technology strategy in higher education fails more often at the governance layer than at the technical one. These pieces are written for leaders who have to make actual commitments about technology investment, tool selection, and institutional governance posture across a range of platforms and decisions, not AI alone. The animating conviction is that the discipline required to govern technology well, resisting hype, maintaining decision rights, sequencing investment against readiness, and holding vendors accountable, is the same discipline regardless of which technology is currently commanding the most attention. AI happens to be the most pressing current example of a set of problems that recur across every technology cycle.

• Recap: The Canvas Breach Is Not a Tools Problem (May 9, 2026) argues that SaaS resilience is built through leadership practice and contractual rigor, not through procuring additional monitoring platforms.

• When the Code Works But the Decision Doesn’t (Apr 21, 2026) extends the structural diagnosis to generative AI development, arguing that vibe-coding produces individual decisions that work technically but fail institutionally.

• Two Kinds of AI Investment and Why the Difference Matters (Apr 7, 2026) revisits the Everyday AI versus Game-changing AI framework in the current spending environment and makes the case for financial restraint at the hype cycle peak.

• The Mistake of the Chief AI Officer (Feb 10, 2026) uses Robert Gates’s refusal of the Director of National Intelligence role to argue that creating a Chief AI Officer without budget authority or operational control severs responsibility from power.

• Star Quarterbacks and Shadow IT (Dec 2, 2025) names the structural pattern that produces shadow IT units, the technical debt they impose, and why a CIO candidate should treat the pattern as a disqualifying condition.

• Everyone’s Using GenAI, Few Admit It (Oct 14, 2025) examines the gap between widespread adoption and public reluctance to acknowledge use as a cultural problem rather than a tool problem.

• Building the AI-Infused University Starts with Smarter Compute Investments (Sep 2, 2025) argues that effective AI infrastructure requires orchestrating people, process, and compute together rather than committing to one without the others.

• Dopamine-Fueled IT and the Gordian Knot (Jul 22, 2025) identifies the structural conditions that produce fast-build technology strategies and the technical debt they leave behind.

• Copilot vs. ChatGPT vs. Gemini (Jun 3, 2025) compares the three dominant everyday AI platforms against learning outcomes, data privacy obligations, and the practical requirements of campus-wide deployment.

• Becoming an AI-Infused University (May 27, 2025) offers a practical guide built around the lesson that multi-year technology commitments typically outpace both the maturity of the technology and the institutional readiness to absorb it.

• Forget AGI: Worry About What GenAI Knows About You Now (Apr 8, 2025) focuses on the immediate privacy risk of persistent memory in generative AI tools rather than speculative future scenarios.

• The Case for Low-Code Everyday AI (Mar 25, 2025) argues that low-code platforms embedded in existing enterprise tools offer a more prudent and scalable path than custom development.

• AI in Higher Ed: What Matters and What’s Just Hype (Mar 12, 2025) establishes the foundational distinction between everyday AI and game-changing AI that the Substack returns to throughout.

The AI Economy: The Long View

These pieces step back from the institutional decision and ask the structural economic question: which companies, platforms, and investment theses will survive the current technology hype cycle, and why. The answer turns on vertical integration, marginal cost economics, and the historical pattern of what happens when a technology matures from novelty into infrastructure. These pieces are less about higher education specifically and more about the economic conditions institutions are operating inside, whether they fully understand those conditions or not.

• The Long Game: How Google and Apple Are Fast Catching Up in the AI Wars (Mar 17, 2026) argues that vertical integration, device ownership, and marginal cost distribution give the platform companies structural advantages over model labs.

• Epilogue 2035: After the AI Bubble (Feb 24, 2026) projects forward from the dot-com bust to ask what will remain of the AI boom once the hype cycle breaks.

• Recap: Corning Is the Canary in the AI Coal Mine (Jan 30, 2026) returns to the Corning proxy with fourth-quarter results showing the AI buildout has shifted from GPU procurement to network-layer constraints, a signal that separates real enterprise commitment from speculative capital.

• The Real Internet Emerged After the Fall (Jan 20, 2026) makes the central case that the durable innovations of the Internet era were built after the bust, not during the boom, and applies that pattern to current AI commitments.

• Recap: AI Bubble? Watch This Innovator for Clues (Nov 14, 2025) establishes Corning's optical fiber demand as a physical proxy for real enterprise AI investment, and introduces Wendell Weeks as the executive whose dot-com era lessons make his current optimism worth taking seriously.

Institutional Failure: A Structural Diagnosis

When something fails inside an institution, my first diagnostic move is structural. These pieces share that analytical method and apply it across a range of settings: service delivery, hiring, governance, and vendor management. The common thread is that behavior which looks like individual failure almost always reflects a system that was designed, intentionally or not, to produce exactly that behavior. Leaders who skip the structural diagnosis tend to intervene in ways that produce no lasting change.

• In Defense of Overwhelmed Bureaucrats (Apr 28, 2026) makes the foundational case that when behavior improves with changed incentives, the diagnosis is the system, not the person, and identifies the consequences of skipping that diagnostic step.

• Slow Service Isn’t a Capacity Problem (Jan 13, 2026) uses a 32-swimlane faculty hiring process to show that most service failures in higher education are process failures, and that adding headcount to a fragmented workflow produces faster-moving dysfunction.

• The Innovation vs. Resilience Dilemma (Jun 25, 2025) offers a framework for the trade-off between chasing early-mover advantage and protecting operational resilience, illustrated through a blockchain moment that tested institutional judgment under hype cycle pressure.

• Breaking Scale (Apr 29, 2025) argues that vendor consolidation has crossed into vendor lock-in, that the cloud subscription model has changed leverage dynamics, and that diversification by design is the emerging strategy for sustainable IT operations.

Work Simplification and Operational Discipline

Complexity is the enemy of institutional performance, and simplification is harder than it sounds because it requires decisions about what to stop doing. These pieces share the conviction that no technology investment, however well chosen, delivers its promise inside a fragmented and over-complicated operating environment. Sequencing matters: simplification before automation, diagnosis before investment.

• Isaacman’s Inheritance (Apr 14, 2026) uses Jared Isaacman’s confirmation hearing to frame the enduring tension between the discipline of simplification developed in fast-moving private organizations and the constraint structures of legacy institutions.

• Understanding the Case for VMware (Sep 30, 2025) analyzes Broadcom’s post-acquisition pricing strategy as a recurrence of the pattern Oracle used after acquiring PeopleSoft, and what intelligent negotiation looks like in response.

• A Short Brit, a Big Knife, and a Bold Solution for Technical Debt (Jun 10, 2025) introduces Andy Kyte’s Gordian Knot metaphor to explain why no new system delivers on its promise unless the institution first addresses the complexity it carries into implementation.

• The Missing Piece in GenAI’s Economic Impact (Mar 18, 2025) makes the foundational argument that generative AI will not deliver projected productivity gains unless institutions pair it with genuine work simplification.

The CIO Role: Authority, Governance, and Institutional Fit

What the CIO job is, how the authority relationships embedded in the role shape the work, and what distinguishes tenures that strengthen institutions from those that leave them weaker. These pieces are most useful to those early in their CIO tenure, considering one, or trying to understand why a previous one ended the way it did. The reporting line is not a bureaucratic detail. It is a load-bearing element of the role.

• Who the CIO Works For Matters in More Ways Than One Would Think (Dec 9, 2025) examines how reporting lines shape the nature of the work in ways that go beyond organizational charts.

• A Field Guide to Hiring the Ideal CIO, Being the Right CIO (Oct 7, 2025) offers an honest account of what the position requires and how the fit between leader and institution determines whether the role becomes a tenure or a brief stop.

• From the Pentagon to the Provost’s Office (Jul 8, 2025) introduces the Edge-Leverage-Trust model as a principled alternative to both full centralization and fractured autonomy in federated research environments.

• Resilience in the Age of Institutional Uncertainty (May 13, 2025) draws on four disruptions across a career to offer a leadership playbook for navigating disruptive change while leading an organization.

ERP and Enterprise Systems as Leadership Development

Large ERP implementations are not IT projects. They are institutional reconstructions, and they expose every weakness in governance, decision-making discipline, and stakeholder alignment that are carried into them. They also compress years of leadership development into a single project, which is why the people who survive one tend to emerge as the most prepared leaders of their generation.

• The ERP Contract Doesn’t Run the Project (Mar 24, 2026) argues that consulting agreements define scope and cost but do not substitute for the institutional leadership, decision-making discipline, and vendor accountability that determine outcomes.

• Silence Is the Killer (Jan 6, 2026) uses a hospital EHR collapse to identify silence during the design phase as the proximate cause of most catastrophic ERP outcomes, and names the warning signs that a team has stopped surfacing difficult truths before go-live.

• The First Six Months Decide Everything (Nov 11, 2025) argues that ERP implementations fail early, quietly, and for the same reason every time: institutions rush past process design to get to configuration.

• Why ERP Projects Make Better Leaders (Sep 16, 2025) makes the foundational case that ERP implementations are the most accelerated leadership development environment available to ambitious professionals.

• Why ERP Success Starts Outside of IT (Aug 19, 2025) identifies executive ownership outside IT as the single most reliable predictor of ERP success.

Leading People and Building Teams

Leadership is less about vision than about the habits, rhythms, and daily disciplines that develop the people already in the room. These pieces are the most personal in the Substack and share a common conviction: that the capacity to see what a person can become, before they can see it themselves, is the rarest and most consequential thing that any leader can offer. Silicon Valley management playbooks assume conditions that most institutions cannot replicate. Durable leadership starts with an honest assessment of what is actually available and the patient work of building from there.

• Leading the Team You Actually Have (Mar 3, 2026) argues that durable leadership starts with an honest assessment of the team in place and the patient work of building capability within real constraints.

• Why Your IT Hiring Stalls and How to Fix It (Sep 23, 2025) argues that IT hiring underperforms because organizations screen for credentials rather than competencies, and that building the pipeline internally produces more durable results than the credential-matching approach.

• Why We Remember Our Great Professors (Aug 26, 2025) draws the parallel between teaching as sustained investment and leadership as sustained investment in the development of others.

• The Unflashy Art of Leading Real Teams (Aug 12, 2025) argues that consistent meetings, regular feedback, and structured communication predict team performance more reliably than visionary leadership.

• Seven Lessons from a Cell Door Left Closed (Aug 5, 2025) distills what effective crisis leadership looks like in practice, with attention to what leaders leave behind rather than what they claim in the moment.

• Mentorship Is Overrated, Unless You Redefine It (Apr 15, 2025) makes the case that the everyday influence of a great boss matters more than formal mentorship programs.

Negotiation, Trust, and the Currency of Leadership

Negotiation is not a specialized skill. It is the primary medium through which leaders build credibility, resolve conflict, manage vendors, and move institutions. These pieces draw on Chester Karrass, Chris Voss, and more than two decades of practice across every variety of negotiations. The underlying argument is consistent: the leaders who matter most are not the ones who assert most forcefully but the ones who listen most carefully and spend their relational capital with discipline.

• What Service Disruptions Reveal (Mar 31, 2026) applies the negotiation styles framework to crisis response, showing how teams that understand their own tendencies respond more coherently under pressure.

• Negotiation Styles and the Escalation Ladder (Feb 17, 2026) applies the Assertive, Accommodator, and Analyst framework to team dynamics, showing how the same escalating message lands differently on different stylistic profiles.

• The Rhythm of Leading Without Surprise (Jan 27, 2026) makes the case that effective leadership communication is about building information-sharing rhythms that prevent surprise, not about crisis messaging.

• Private Truths, Public Leadership (Nov 18, 2025) identifies strategic restraint as a more powerful influence mechanism than assertion.

• Know Your Negotiation Style (Nov 4, 2025) introduces the Assertive, Accommodator, and Analyst framework drawn from Chris Voss, and explains how self-awareness about one’s own style converts into durable influence.

• Negotiation Is the Leadership Skill (Oct 21, 2025) establishes the central claim that CIO credibility is built less through what gets delivered than through how leaders negotiate to get it delivered.

• The Hidden Ladder in Every Negotiation (Sep 9, 2025) names the predictable pattern of negotiation escalation and the responses that de-escalate rather than harden the dynamic.

• If You’re Doing Most of the Talking, You’re Losing (Jul 29, 2025) develops listening as the primary tool for uncovering interests behind stated positions.

• The Legal Pad That Preserved My Sanity (Jul 15, 2025) argues that note-taking is about retention, not building a reference library, and that handwriting produces a quality of attention and recall that typing cannot replicate.

• Extreme Anchors, Empathy, and the Art of Staying in the Room (May 20, 2025) makes the strategic case for empathy-based approaches over short-term extreme tactics.

• Extreme Anchors and the Overton Window (Apr 1, 2025) opens the negotiation series by examining how anchoring tactics shift the perceived range of reasonable outcomes before bargaining begins.

Many recap articles and personal reflections are not listed here individually. They do what shorter weekly writing does: situate current events in the broader analytical context, mark passages in the year, and offer the occasional pause between cycles.

The final word

These nine categories do not exhaust what the Substack has been working on, but they account for most of it. They are also more durable than any single technology cycle, vendor transition, or policy environment. The specifics will keep changing. The underlying structure of institutional decision-making, the conditions that produce trust, and the disciplines that make technology investments actually deliver will not.

The original commitment was advocacy for ideas that more than two decades of CIO work had brought into focus. That is still what the writing is for. This work is harder now than it has been at any point in the last twenty years. Changing regulatory incentives, hype cycle pressure, vendor consolidation, and the declining public trust in institutions have combined to produce conditions that reward exactly the kind of restraint, structural diagnosis, and patient credibility-building that the Substack has been arguing for from the beginning. The leaders who will matter most over the next decade are not the ones with the boldest pronouncements. They are the ones who keep doing the work when the excitement fades, and who leave their institutions in better condition than they found them. Everything else is simply commentary.

The reflexive response from the IT industry to events like this is to recommend more software purchases. Observability layers. Real-time dependency graphs. Automated remediation engines. Each of those tools has merit. None of them is the actual lesson. The Canvas event is not fundamentally a problem to be solved with another platform. It is a problem revealed by leadership practice, communication discipline, and contractual rigor, or the absence of those things, on the campuses that experienced it.

It is also reportedly not an isolated event. Reporting suggests this attack is part of a broader pattern affecting other education software providers. Higher education and K-12 SaaS platforms appear to be a target. That pattern, if it holds, matters more than the identity of any single vendor, and it shapes the lessons leaders should draw.

The Three Phases of Any Incident

Every incident, whether technological or otherwise, moves through three phases. The first is to protect: contain the exposure and prevent further harm. The second is to resume: restore business operations cleanly enough for the institution to continue functioning. The third is to assess and learn: conduct a real after-action review, identify what failed structurally, and update the practices that led to the failure.

In a cloud-hosted environment, the protect and resume phases largely fall to the vendor. Instructure had to pull its platform offline, revoke privileged credentials, rotate keys, remediate the underlying issue, and restore service. The institution’s role during those phases is narrower but no less. Communicate with the community. Stand up continuity arrangements where they exist. Coordinate with peers. Hold the academic enterprise together while the technical work happens out of view.

The third phase is where institutional learning either happens or doesn’t. It is the work that distinguishes campuses that emerge stronger from each disruption from those that quietly normalize the most recent one. Most universities are starting that phase now. Some will treat the after-action seriously. Others will let the moment pass.

What Technical Work the Campus Still Owes

Of course, there is real technical work on campus, even when the breach itself happened in the cloud. Identity and integration are the seams where vendor compromise becomes institutional compromise, and those seams sit on campus.

Service account passwords, especially those without multifactor authentication, should be rotated following any vendor incident of this scale. Connections between Canvas and identity providers, the SIS, grading workflows, and downstream analytics should be examined and, where appropriate, revoked and reissued. On-campus authentication and SSO logs should be reviewed for unusual access patterns, unfamiliar source addresses, or newly created administrative accounts that suggest harvested credentials are being used for lateral movement. The systems integrated with Canvas are part of the blast radius, even if they were not breached directly.

There is also the human-facing dimension. Stolen internal data allows attackers to construct phishing campaigns that reference real work, real relationships, and real internal context. These attempts can be difficult to distinguish from legitimate emails. Communities need to be warned, and IT teams should anticipate a sustained period of targeted phishing attacks rather than a single, quickly passing wave.

This work is necessary. It is not, by itself, sufficient. A campus that completes the technical checklist but fails to communicate clearly with its community, or fails to update its continuity plans and its contracts, has remediated the incident without learning from it. Technical work is part of the response. The leadership practice around it determines whether the response actually adds capability for next time.

Not a Product Problem, and Not a SaaS Problem

Within the University System of Georgia, only one institution uses Canvas as its core LMS. The others use a different platform. That detail matters less than it might seem. Anything connected to the Internet carries cyber risk, and a sophisticated threat actor moving systematically will find its way to whichever platform a campus has chosen. Treating this as a Canvas problem misreads the structural condition. The next breach may well be at a different vendor. Vendor selection is not the lesson.

The deeper version of that misreading is the argument that begins to circulate after every SaaS breach: that institutions should pull software back into their own data centers where it can be controlled. That is a false comfort. Vendors at scale invest in security, continuously monitor their platforms, respond to threats with dedicated teams, and absorb the cost of remediation across thousands of customers. A campus running its LMS on local infrastructure would face the same threat surface with a fraction of the resources and a longer recovery curve. Outsourcing risk through contracts remains prudent. In the Internet-connected age, all software is vulnerable; the question is which arrangement makes that vulnerability most manageable.

There is, however, a related question worth asking of every SaaS vendor going forward. What new capability has been added to the platform in the past twelve months, and how have the integration points and data pathways changed as a result? Feature velocity is not free. New ways into a system are also new ways out, if attackers get in. That is a question for the vendor relationship, not a reason to abandon SaaS.

What the After-Action Should Actually Produce

Three questions deserve serious attention from every campus that runs Canvas, and from every campus that operates any mission-critical technology services.

The first is continuity. What was the plan for an LMS outage during finals week? Most institutions discovered during this event that their business continuity plans assumed the LMS would be available. When both the gradebook and the exam-delivery mechanism go offline at the end of a semester, the academic enterprise has very few viable options. Faculty improvise. Deans extend deadlines. Registrars absorb the chaos. None of that is a plan. A real continuity plan names the alternative workflows, identifies the people authorized to invoke them, and is exercised before it is needed. After-action work should produce continuity plans that account for losing the LMS at the worst possible moment, because that is when it will be lost.

The second is contractual. What do the institution’s data processing addenda with Instructure actually require? Specific questions matter here, and general counsel should be in the room when they are explored. Is the vendor obligated to share root cause findings promptly? Does the contract require the vendor to bear the costs of community notification and credit monitoring when notification is legally required? Does it commit the vendor to disclose its remediation actions and its plan to prevent recurrence? Does the institution have any contractual authority to shape how the vendor notifies students and faculty in response? For most campuses, the honest answer is that these terms are weaker than they should be, because the contract was negotiated for price and feature parity rather than for incident response. The Canvas event is the moment to read those agreements closely and to use what is learned to shape future negotiations across every cloud platform on campus.

The third is observational, and it applies whether or not a campus runs Canvas. Watch Instructure's response carefully. As attack vectors and root causes are identified, use those findings as a lens to red-team every technology service the institution operates or depends on. Apply the lessons regardless of whether the campus was directly affected. The cost of this exercise is small. The benefit is that an institution arrives at its next vendor incident having already understood the structural conditions that produced this one. The campuses that treat someone else's published root cause as a preview of their own next event are the ones that learn from it most cheaply.

Communication Is the Actual Incident Response

In a SaaS world, the most important IT incident response discipline is not technical. It is communication with the broader user community. The vendor controls the platform. The campus controls the message. Letting the community know what is happening, how it affects them, and what continuity arrangements are available is the single most consequential thing an IT organization does during an event of this kind.

That communication has a legal dimension as well as a cultural one. In many jurisdictions, an institution’s notification obligations can begin once it has reason to believe a breach has occurred, often before a vendor’s formal confirmation. Working with general counsel on those obligations is part of the early response, not an after-the-fact courtesy. Beyond the legal floor, communication has to be clear, repeated often, and willing to say “we don’t know” when that is the truth. Vague reassurances erode trust faster than bad news. Communities can absorb difficult information delivered honestly. They cannot absorb silence or spin. Campuses that communicated well during the Canvas event, in plain language, with regular updates, with realistic expectations about timing, will have built credibility that outlasts the moment. Campuses that communicated poorly will discover the cost in the next disruption.

The final word

A breach like this one tells leaders quickly whether their teams have built the habit of sweating the small details together. A strong response is rarely a single decisive act. It is a collection of many small things, done in sequence, by people who trust each other enough to coordinate without ceremony. Service accounts rotated. Logs reviewed honestly. Communication that is timely and plain. Continuity arrangements that have been exercised. Data processing addenda read with the next breach in mind. Lessons from other vendors’ incidents absorbed before the next one arrives. After-action reviews that produce real changes, not slides for the next leadership meeting.

No observability platform builds that culture. No automated remediation engine substitutes for it. The technology will keep evolving. The threat actors will keep working through the sector. What separates the campuses that handle the next event well from those that don’t will be the slow, unflashy work of leadership. That is the lesson the Canvas event offers, and it is the only lesson worth taking from it.

Long before social media, the media industry discovered that outrage outperforms deliberation. Cable news and the confrontational programming of the 1990s built audiences not on conversation but on conflict, performed loudly and repeatedly. The formula worked across the political spectrum. And when the Internet arrived, it did not invent this dynamic. It inherited it, scaled it, and put it in everyone’s pocket.

What the Internet added was not a new idea but a new scale. It took the outrage model that cable and talk radio had proven out, stripped away the last remaining gatekeepers, and handed the formula to every individual with a connection. In today’s Dispatch, I unpack how that shift perfected zero-sum posturing and slowly eroded our capacity for relational capital, leaving everyone more anxious, more lonely, and less able to find common ground with people who see the world differently.

The big picture

We live in a zero-sum world. The failure of compromise is observable everywhere; policy advocates cannot seek consensus because consensus has become synonymous with betrayal. This public breakdown is paralleled by a deep private crisis. Research confirms soaring rates of anxiety and loneliness, especially among younger adults. These are not coincidental conditions. The loneliness and the polarization are not separate problems. They are the same problem expressed at different scales, and they share a single structural root: the collapse of relational competence.

Negotiation is the deliberate practice of managing constraints and seeking alignment with people whose interests differ from your own. It is not a business skill or a diplomatic technique reserved for formal settings. It is a foundational human competence, the mechanism through which individuals, institutions, and communities resolve conflict without resorting to force or withdrawal.

That competence is eroding. The zero-sum posture that the media industry has normalized now too often governs the relationship between employees and the managers who lead them, and between organizations and the communities around them. Maximalist demands have replaced opening positions. Extreme anchors are no longer strategic bids. They have become sincere expressions of what people believe they deserve. This is not primarily a failure of character. It is a failure of culture, driven by structural forces that most people experience without being able to name.

The Three Shifts that Broke the Bargain

The technology did not install new human tendencies. It allowed existing ones to scale in ways they never could before, in three distinct waves.

The first came in 1993. The early Internet offered direct connection, bypassing the institutions that had set the norms for conflict and debate. Newspapers, civic groups, academic institutions, and professional bodies were imperfect mediating structures, and not always trusted ones, but they enforced shared scripts for acceptable disagreement. When they became optional, accountability and shared social context disappeared, replaced by speed, volume, and the ability to find an audience that always agreed with you. The cost of extreme anchors dropped to nearly zero.

The second shift came in 2007. The smartphone put the Internet in our pocket and made digital confrontation continuous. It replaced face-to-face engagement with compulsive scrolling and reacting, rewarding emotional reactivity, and the instant counter-assertion. The deliberate pause that good negotiation requires, the moment of sitting with another person’s position before responding to it, became not just inconvenient but actively punished by social networks that measure silence as disengagement. Every interaction became a potential public performance, and every concession became visible to an audience trained to read it as weakness.

The third shift came in 2022. Machine learning models personalized the noise. Algorithms now determine what people see, hear, and read, reinforcing existing beliefs and reducing complex realities into oppositional camps. What these three shifts produced together was not simply a coarser public culture. They changed the conditions under which people form beliefs, and by doing so, they changed what people bring to every potential collaboration before the first word is spoken.

The Problem of Digital Certainty

The most consequential product of these three shifts is digital certainty: the manufactured sense of being correct, delivered not through earned authority or shared deliberation, but through algorithmic reinforcement. The algorithm is not confirming your position because it is true. It is confirming it because your confirmation is profitable. The result is not genuine conviction. It is a simulation of certainty, continuously renewed, and optimized for engagement rather than accuracy.

Digital certainty has a behavioral signature that senior leaders will recognize immediately in any consequential conversation. It is the refusal to acknowledge shared constraints. It is the attribution of bad faith to any counterpart who introduces limits. It is the experience of compromise as personal defeat rather than problem-solving. And it is the belief, held with complete sincerity, that any outcome short of total victory represents either incompetence or betrayal on someone’s part.

The deeper problem is that the algorithm does not simply give people information. It substitutes for judgment. When the social environment tells you what to believe and how firmly to hold it, extreme opening positions stop being tactics. They become authentic expressions of what the person believes the situation requires. That distinction matters enormously for how a skilled leader should respond. A tactical extreme anchor can be countered with a counter-tactic. A sincere one requires something different: shared reality must be restored before any positional movement is possible. No negotiation technique resolves that impasse until the parties can first acknowledge they are operating within the same set of constraints.

The Erosion of Relational Capital

Effective negotiation depends on relational capital: the accrued trust, patience, and willingness to confirm understanding that develops between parties over time. Digital certainty undermines it, and Chris Voss’s framework makes clear precisely how.

Voss built his method on tactical empathy: slowing the conversation down, labeling what the other party is feeling, mirroring their language back to them, and confirming their perspective before moving toward resolution. These are not techniques for being agreeable. They are tools for restoring enough shared reality to enable productive movement. They work because they signal to the other party that they have been genuinely heard, which is the precondition for any willingness to move.

The architecture of digital culture makes this extraordinarily difficult to sustain. The pause that tactical empathy requires, the deliberate silence after a label lands, feels dangerous to anyone whose sense of correctness comes from continuous digital certainty rather than internal judgment. Silence produces no confirming feedback. It reads as falling behind. The person who has learned to engage by watching social media cannot sit quietly across a table, because quiet in that context means losing ground in a contest the other party is still running. Voss’s method asks the negotiator to do the thing the digital environment has made most psychologically costly: create space, absorb pressure, and resist the impulse to immediately respond with certainty.

This is why relational capital is so difficult to build and so easy to destroy in the age of social networks and mobile devices. A disagreement where one party treats any concession as defeat, a relationship that hardens into posturing rather than dialogue, a negotiation where the opening offer is entirely disconnected from reality: in each case, the underlying dynamic is the same. The same patterns that dominate social media are now creeping into public hearings, association meetings, and workplace conversations. Digital certainty has replaced shared reality, and no positional progress is possible until someone in the room decides to slow down and restore it.

What the Skilled Leader Can Still Do

The structural forces described above are real and durable. Social networks and digital certainty are not going away anytime soon. But individuals with experience, skill, and developed judgment can consciously narrow the gap between what the technology environment produces and what deliberate practice makes possible. The house still has an advantage. That does not mean the skilled player is without options.

The first requirement is diagnostic. Before choosing a response to an extreme anchor, the effective leader must determine whether they are facing a tactical gambit or a sincere belief. Voss’s calibrated questions are the right tool. “How am I supposed to do that?” and “What would it take to make this work?” do not concede anything. They require the other party to engage with constraints rather than simply restate demands. If the extreme anchor is tactical, that engagement will produce movement. If it is sincere, the response will reveal what shared reality needs to be rebuilt before movement is possible. The diagnostic step is not optional. Applying empathy to a tactical gambit can inadvertently legitimize it. Applying counter-tactics to sincere belief will harden it. The skilled leader distinguishes the two before choosing.

The second requirement is deliberate engagement with human friction. The specific setting matters less than the pattern: working across constituencies with competing interests, navigating ambiguous authority relationships, staying in rooms where agreement is not guaranteed, and exit is tempting. These experiences, accumulated over time, are what develop emotional intelligence and relational capacity. Reading what another person actually needs beneath what they are demanding, managing your own reactions under pressure, restoring trust after it has frayed: none of that is learned in a classroom. It is learned by staying in difficult situations long enough to develop judgment about them. The leader who has built that capacity carries a competency no algorithm can replicate, and no shortcut reliably produces. These skills can be developed anywhere and are honed anytime they are practiced.

These competencies are not the exclusive property of any particular career path. They are available to anyone willing to engage seriously with human complexity, absorb accountability when things go wrong, and resist the easier path of performing certainty rather than building understanding. But senior leaders carry a disproportionate responsibility regardless of background. They set the conditions in which others either develop these skills or abandon them. How a leader behaves in a difficult room matters more than any policy they write or process they design.

The final word

The extreme posturing that digital culture rewards is not a character defect. It is a rational adaptation to an environment that has made maximalism feel safe and restraint feel dangerous. Understanding it structurally is what allows a skilled leader to respond to it effectively rather than simply reacting to it. The leader who can accurately diagnose whether they are facing sincere belief or tactical posturing, choose the appropriate response, and remain patient enough to let the other party move, is not simply demonstrating virtue. They are doing something important for the organizations they lead and the people who depend on them. In an era when digital certainty is the default, that capacity is not a soft skill. It is the core competency that separates leaders who build lasting alignment from those who accumulate positional victories at the cost of relationships. That is true whether the room is a boardroom, a council chamber, an association meeting, or a campus senate.

Yet, behind those service windows sit some of the most intelligent and dedicated people I know, loyal staff who care deeply about students, faculty, and one another. This creates a jarring paradox. How can an institution full of caring professionals produce such a frustrating experience? Max Weber might have argued that this friction is simply the iron cage of legal-rational institutions working exactly as designed, inescapable and self-reinforcing. I am not quite that pessimistic. In today's Dispatch, I want to argue that the conditions inside that cage, the risk calculus, the accountability architecture, the politics of who gets to jump the line, are things leaders can actually change. But, only if they resist the urge to first blame individuals and focus their energies on re-examining the structure those people are responding to.

The big picture

There is a fundamental misdiagnosis at the heart of most complaints about central service organizations in higher education. When senior leaders encounter a “Department of No,” they typically see a failure of competence or leadership. The assumption is that staff are obstructionist, resistant to change, or simply not suited to the demands of a modern institution. This framing is tempting because it suggests a clean solution: find better people, reset expectations, rebuild the culture.

The reality is more uncomfortable. What often looks like team underperformance is a rational adaptation to structural conditions that make speed costly and caution rewarded. This is not an argument that staff are never the problem. They sometimes are, and a leader who cannot distinguish structural adaptation from genuine incapacity will struggle to address either. The most reliable signal is behavioral: when performance improves as incentives change, the problem was structural; when it persists despite changed conditions, the cause lies elsewhere. But a leader who reaches for individual explanations before examining structural conditions will almost always diagnose incorrectly, and the remedy prescribed can make things much worse.

What deserves defense here is not bureaucracy as a system. The bureaucracy, with its queues, its procedural armor, and its friction, more often than not produces outcomes that conflict with the institution’s actual work. What deserves defense, most of the time, is the individual who operates inside that system and has adapted, rationally and understandably, to the incentive structures the institution itself has created.

The One-Way Risk of Moving Too Fast

To understand why knowledge workers move slowly, one must first understand the risk environment they inhabit. In IT, HR, Finance, Legal, and Procurement, the risk calculus is one-way: speed benefits the requester, and error costs the staff member.

Consider a procurement officer asked to expedite a vendor contract. If they accelerate the process by relaxing a review step, the benefit accrues entirely to the requester. The faculty member launches their project. The procurement officer receives no formal recognition and likely no informal acknowledgment either. But if that shortcut produces an audit finding, a data exposure, or a compliance violation, the consequences fall entirely on the staff member, not the person who made the request.

This imbalance creates a rigorous behavioral logic. When saying yes carries undefined risk and following the policy offers more guaranteed safety, the rational knowledge worker follows the policy. This is not obstruction. It is professional self-preservation in an environment where the penalty for error falls almost entirely on those knowledge workers with the least organizational protection. Until leaders explicitly and credibly alter this dynamic, expecting speed from a workforce incentivized for caution is not a management challenge. It is an institutional design failure.

The queue itself performs a parallel function. Universities possess effectively infinite appetite for administrative support, generating grants, IT support, hiring proposals, and compliance reviews at a rate that far outpaces the budgeted capacity to handle them. In this environment, complexity and delay serve as informal demand throttles. Required forms, committee approvals, and mandatory wait times are not merely inefficiency. They are rationing mechanisms that prevent the system from collapsing under load. Eliminating friction without expanding capacity (or reducing non-value-added activities or handoffs) does not improve service. It accelerates defective work.

When Charismatic Authority Meets Legal-Rational Process

Universities rest on what Weber called legal-rational authority: the premise that rules apply consistently to everyone. The procurement officer and the provost are, in formal terms, subject to the same institutional processes. This is not merely an abstraction. It is the foundation on which the staff member’s playbook has any operational meaning.

When a president, provost, or influential dean bypasses procedure to expedite a personal priority, they are exercising a competing form of authority, one grounded in personal status and institutional prestige rather than in rules. The operational disruption this creates is real: staff must drop current work, context-switch, and rush the VIP request through, pushing other work further into the queue. This results in a cycle of underperformance and overcommitment. Staff service the queue jumper precisely because they cannot afford to be seen as unresponsive to senior leadership. The work displaced by that choice does not disappear; it falls back into the queue, extending wait times for everyone else. Those longer waits also generate complaints.

The cascading effect is predictable. Displaced users escalate to their own powerful advocates, who apply pressure from above, generating more exceptions, which displace more work, which generates more complaints. The bureaucracy responds by tightening its procedures, because rigid rules are the only available defense against arbitrary demands. What leaders read as increasing resistance is the institution's own rational response to a pattern of disruption it was never designed to absorb.

How the Misdiagnosis Becomes Self-Reinforcing

Senior leaders, particularly those who are goal-oriented and impatient with friction, tend to read slow service as an individual failure. The staff member is not customer-focused. The team lacks urgency. The leadership or culture needs to change. This reading is understandable; friction is visible while its structural causes are not. But it produces a prescription that more often makes the underlying problem worse.

When a leader responds to slow service by increasing pressure on individual workers, the risk still runs in one direction. The staff member now faces the original structural conditions plus heightened performance scrutiny. The rational response is more caution, not less. More procedural documentation, not fewer steps. More queue, less discretion. The harder a leader pushes without changing who bears the costs of mistakes and how that accountability is enforced, the more the system stiffens.

This feedback loop explains why the dysfunction often persists through leadership transitions. Each new leader inherits a workforce conditioned, through years of accumulated experience, to understand that moving fast increases the risk of error, and error attracts consequences. A directive to be more agile, issued without a corresponding commitment to simplify the work or absorb the cost of mistakes, is not a culture reset. It is simply another signal that nothing has fundamentally changed.

The final word

The prescriptions that follow are structural. First, accountability needs to run in both directions. A leader who demands speed and then punishes the resulting error should face consequences for that contradiction, not just the staff member who moved quickly. But that only works if someone above can see the pattern. Right now, the procurement officer has no way to surface it. Designing that visibility, whether through governance, peer accountability, or use of performance data, is itself the hard institutional work this reform actually requires. Second, the expedite lane should be formalized as a form of white-glove service rather than a favor for persistent or powerful individuals. This quarantines the disruption without pretending to eliminate it. Third, institutions must make genuine choices about what they will formally decline to do. An ever-lengthening queue is not a service model. It is what happens when an institution lacks the will to say no or the ability to simplify work. Moral persuasion alone will not solve a demand-capacity mismatch. Structural choices will.

None of this is easy. Two-way accountability requires leaders to constrain their own behavior first. Formal expedite policies require acknowledging, publicly, what has been operating informally. Declining categories of work, or eliminating non-value-added steps, can be politically challenging in ways that indefinite queuing is not.

Institutions unwilling to make these structural changes will continue producing the behaviors they complain about most. The staff member following the policy to the letter is not failing the institution. The institution has failed the staff member, and through that failure, every person waiting in line. The path to faster, more responsive service does not run through hiring decisions or culture statements. It runs through a fundamentally different structure, one that makes speed safe before demanding it.

It was 2003, and I was the “star quarterback” coder in the central IT organization at Texas A&M. My bosses, Steve Williams and Tom Putnam, called on me for the highest-priority projects: web-based admissions, e-commerce for tuition payments, class registration, SEVIS compliance. I had a knack for designing APIs on the mainframe that were cleanly callable from web applications, and I did my best work moving fast, often alone, supervising a small team but rarely slowing down to involve them.

Then I read a news story while attending a meeting in Washington. The University of Texas had experienced a significant data breach. An ambitious programmer had written a simple form that accepted a nine-digit number, and if it matched a Social Security number, it returned a full user profile. The API was publicly exposed to the Internet. A hacker had called it hundreds of thousands of times, guessing numbers at random, and walked away with tens of thousands of identities before anyone noticed.

I had built something nearly identical. And yes, it was also exposed to the Internet.

The call to my boss was one of the hardest ones I have made. Within the hour, I was on the phone with Steve, his boss Tom, the network security team, and the VP/IT Pierce Cantrell. They examined the logs for evidence of a similar intrusion. The next twenty-four hours were the longest of my career. When the security team reported back that the API had not been abused, I exhaled and absorbed a lesson I have never forgotten: my instinct to work alone, to move fast and stay efficient, had stripped away the collaboration that might have caught the problem before it became one.

I have tried to carry that lesson into how I lead. Mistakes are often the best teachers, and the right response to them is clarity and accountability, not punishment. But the arrival of GenAI and what practitioners now call vibe-coding, producing functional software quickly through AI-assisted code generation, has brought that 2002 moment back to mind more than once. A motivated staff member working in isolation today has capabilities I could not have imagined then. The speed is higher. The surface area for unintended exposure is larger. And the institutional stakes are the same.

In today's Dispatch, I want to share a framework for thinking about where AI-assisted software development fits within a research university, where it adds genuine value, and where it introduces risks that move faster than the governance structures designed to contain them. That framework draws on guiding principles recently released to University of Georgia leaders and IT professionals, developed through the two-readings approach I rely on when building new IT policy or guidance.

The big picture

Higher education institutions are built on distributed authority. Colleges and departments exist to pursue distinct academic missions, and the administrative structures around those missions tend to reflect that diversity. This is not inefficiency; it is design. A research university is a federation, not a hierarchy, and any IT strategy that fails to account for that structure will eventually break against it.

That federated reality is precisely why IT governance in research universities requires clarity about where decisions belong. The question is never simply whether something can be built. It is whether the decision to build it is being made by the right people, with the right information, with appropriate accountability for what comes next. For most of the last two decades, the answer to that question has been shaped by a deliberate shift: away from staff-coded software applications and toward vendor-supported platforms with the scale, specialization, and continuity to sustain them. That shift was not a loss of creativity. It was a hard-won institutional lesson.

GenAI is now putting pressure on that lesson. The pressure is not new in kind, but it is new in magnitude. When any staff member with reasonable technical curiosity can produce functional code in an afternoon, the conditions that historically slowed the spread of custom development no longer exist. The guardrails that once came from difficulty have disappeared. What remains is judgment, and it’s unevenly distributed.

The Edge is Real, and It Matters

The Edge-Leverage-Trust framework offers a useful way to think about this moment. It begins with the recognition that not all IT work belongs in the same governance layer. Some functions should scale: identity management, enterprise systems, data infrastructure, cybersecurity. These belong in the Leverage layer because standardization produces reliability, security, and cost efficiency that no unit could achieve independently. Other functions should not scale. Departments experiment. Research centers build tools for their specific scholarly needs. Professional schools configure platforms to fit their workflows. This edge activity is not a workaround. It is what a healthy, federated R1-type institution looks like from the inside.

GenAI coding fits productively at the edge. A staff member using an AI coding tool to automate a local workflow, build a batch data transformation script, or produce a unit-level reporting dashboard that draws only on data the unit already controls is doing exactly what the edge is designed to accommodate. That work is the unit’s business. The appropriate response from central IT is not oversight; it is encouragement.

The line is crossed when edge tools begin to act like central systems: when they integrate with enterprise data warehouses, authenticate through shared identity systems, connect to core ERP systems, or expand to serve audiences beyond the unit that built them. At that point, the tool has taken on institutional responsibilities that local governance is not designed to manage. Speed of construction is no longer the relevant variable. Durability, security, integration integrity, and continuity are.

What Generative AI Actually Changes, and What it Does Not

The critical misunderstanding about AI-assisted software development is the assumption that faster creation means lower risk. It does not. Code produced by a generative AI tool carries the same structural properties as any other custom code. It requires the same ongoing maintenance. It introduces the same integration challenges. It carries the same information security obligations. The generation of the functional code is faster; the support obligation does not shrink to match.

There is evidence that the risk runs in the other direction. Code written quickly and reviewed lightly is more likely to surface problems under real conditions. Several significant cloud infrastructure failures in recent years have been attributed in part to AI-generated code deployed without sufficient human review. Generative AI tools shift software developers from writing code to reviewing code, and when that review function is not performed rigorously, the productivity gain comes at a corresponding increase in risk. Units across higher education are discovering this in real time.

The deeper structural problem is what Gartner analyst Andy Kyte has described as the Gordian Knot: the dense, self-reinforcing tangle of fragile systems, undocumented workarounds, and accumulated technical debt that builds up in institutions over time. Generative AI does not cut through that knot. It tightens it. Every ungoverned custom application adds another strand. Every tool that works well enough in its local context but was never designed for institutional durability becomes a future liability. And when the staff member who built it moves on, the system does not move with them. The 2 a.m. call lands on the central IT organization that had no part in the decision.

The Human Dynamic That Makes this Worse

There is a recurring institutional pattern that compounds the structural risk. It begins when a motivated, technically capable staff member, sometimes working entirely alone, builds something that solves a real problem. The solution works. Colleagues are impressed. A senior leader takes notice and encourages broader deployment. What started as a local productivity tool is now being treated as a platform, without the review, the governance, or the support infrastructure that a platform requires.

This is called “dopamine-fueled IT.” The individual is genuinely talented. The initial work may be genuinely useful. But the institutional conditions around that work have not caught up to the expectations being placed on it. No one has asked whether the tool integrates safely with enterprise systems. No one has thought through what happens when the developer leaves. No one has assessed whether the data being used has been properly authorized for this new application context. The executive who endorsed the expansion wanted visible results and got them. The governance structures that exist to protect the institution from exactly this kind of deferred risk were bypassed, not maliciously, but because they were inconvenient in the moment.

The challenge for CIOs and senior IT leaders is to interrupt that pattern without discouraging the underlying initiative. That requires being clear-eyed about what makes edge innovation valuable, which is precisely that it is local, bounded, and reversible, and what makes Leverage-layer decisions consequential, which is precisely that they are not. The distinction is not about capability or intent. It is about accountability, and accountability is a structural question, not a personal one.

The final word

Higher education institutions have spent roughly two decades learning, often through painful experience, that the history of building software for themselves is littered with expensive, high-profile failures. The successes have almost always come from leveraging platforms built by companies whose entire business is building and sustaining them at scale. Generative AI is a genuinely powerful tool. It does not rewrite that lesson. What it does is lower the barrier to repeating the mistakes that produced it. The institutions that navigate this moment well will be the ones whose leaders understand where the edge ends and where institutional accountability begins, and who hold that line not as a constraint on innovation, but as the condition that makes real innovation sustainable within research-centric institutions.

Some time before that hearing, I had experienced the results of that philosophy firsthand. I joined a Teams call from a remote location over a Starlink connection. No lag. No buffering. It felt like I was sitting in my office. That kind of satellite network performance does not emerge from a bureaucracy. It comes from an organization that has stripped away work and process complexity and built around first principles.

Isaacman comes from that world. NASA does not, at least not yet. Last week, a NASA crew was aboard Orion and completed a flight around the far side of the Moon using the Space Launch System rocket, the first humans to travel that far from Earth since Apollo 17. The mission flew on time. The rocket performed. That is not nothing. It is, in fact, the result of an institution choosing to rationalize a legacy program rather than abandon it, which is harder and rarer than building something new from scratch.

In today’s Dispatch, I contrast the discipline of work and process simplification and lean innovation that made SpaceX what it is with the accumulated bureaucracy and complexity that NASA is now working hard to shed under Jared Isaacman, and ask what either story means for institutions trying to simplify and transform from within.

The big picture

NASA and SpaceX make for a useful contrast in how institutions approach complexity, cost, and change. The contrast is not clean. Jared Isaacman, now confirmed as NASA’s fifteenth administrator, came to the job shaped by his SpaceX experience and the conviction that large institutions can move faster by removing what does not matter. He inherited a 322-foot rocket that embodied nearly everything he had criticized and chose, deliberately, to standardize and fly it to the moon rather than abandon it. Meanwhile, Congress passed NASA a budget exceeding $27 billion for fiscal year 2026, the largest in nearly three decades in real terms. These are not the conditions of a failing institution; they are signs of political capital.

The more useful question is not whether SpaceX’s model defeats NASA’s. It is whether an institution can internalize the discipline of simplification after years of complexity accumulation, and whether political will can sustain that effort long enough to matter. That question is harder and rarer than building a company from scratch. It is also more relevant to higher education, where no one gets to start over.

Max Weber wrote about ideal types not as descriptions of reality, but as analytical tools for understanding the forces that shape political, social, and economic behavior. No organization is purely legal-rational or purely traditional. But comparing institutions to ideal types reveals what motivates both their actions and decisions. SpaceX and NASA remain useful ideal types, not because one succeeded and the other failed, but because they represent two fundamentally different institutional responses to the same problem: how to get work done when complexity accumulates.

Work Simplification at SpaceX

Work simplification is not a slogan. It is a discipline. It forces an institution to examine every step in a process and ask whether it is necessary. Most organizations never do this, either because of internal politics or because they are afraid of what they might find. SpaceX built a culture around it. The result is visible in five lessons that remain instructive regardless of how any particular rocket program turns out.

1. Every requirement must have an owner. SpaceX attaches a name to every requirement. If no one can defend it, it disappears. This creates clarity and accountability in equal measure. The institutional default, visible in large procurement programs across both government and higher education, is to carry requirements forward without ever asking who still needs them or why. Untraceable requirements are not neutral; they are dead weight.

2. Delete before you optimize. SpaceX removes steps before improving them. They eliminated hydraulic systems in favor of simpler electric controls. They dropped the complex fairing-catching system after realizing the same results came from simply letting the fairings splash down and retrieving them. The institutional default is to solve problems by adding new layers, which seems like progress. Deletion requires confidence that the original requirement was not worth keeping.

3. Simplification makes systems more reliable. SpaceX reduces failure by reducing components. The choice of stainless steel over carbon fiber for Starship removed both the heat shield requirement and its intricate manufacturing steps. Reliability through complexity is a contradiction. Every additional component is a new way for a system to fail. Organizations that rely on oversight and controls to ensure quality are managing the consequences of complexity that they did not eliminate.

4. Vertical integration eliminates friction. SpaceX builds most parts in-house. Teams talk directly. Decisions move fast. The fragmented supply chain model, common in both aerospace and enterprise technology, adds negotiation, delay, and coordination costs at every process step. Those costs are easy to justify individually and hard to see in aggregate until the system stops moving.

Work simplification is a cultural choice, not a technical one. This is the lesson that matters most for institutional leaders. SpaceX built a culture where unnecessary work is treated as a problem to be eliminated. The institutional default is a culture where unnecessary work is invisible and quiet, absorbed into the budget and the calendar by habit and without comment. The difference is not engineering talent or organizational size. It is a decision about what the organization pays attention to.

Work simplification is a way of seeing. It forces an institution to confront what it does and why. That clarity is the precondition for lean innovation to take hold.

Lean Innovation and the Discipline of Constraint

Lean innovation comes from scarcity, but not only from scarcity. More precisely, it comes from the discipline of treating resources as a constraint rather than a permission slip, regardless of how much funding is available. NASA’s current budget offers a useful illustration of why this distinction matters. Congress approved more than $27 billion for fiscal year 2026. That is not scarcity. But if Isaacman allows that abundance to dissolve the pressure for simplification, the same drift that produced a $23 billion rocket program with a ten-year delay will reassert itself quickly.

SpaceX grew up under financial pressure where failure had direct consequences for the company’s survival. That pressure sharpened judgment about what to invest in and what to cut. The lesson for institutions operating in relative abundance is not that they should manufacture artificial scarcity. It is that they need a substitute discipline: the deliberate choice to treat every investment as if the capital were limited, and to measure returns with the same scrutiny that austere conditions would demand.

Four additional lessons follow from the SpaceX example.

• Controlled failure accelerates progress. SpaceX flew prototypes, knowing some would explode. Each failure revealed something useful and cheaply. The institutional alternative is to avoid failure at all costs, which typically means designing for perfection from the start, delaying until certainty is within reach, and producing systems that are late, expensive, and still imperfect. When failure becomes organizationally unacceptable, learning slows and costs escalate.

• Iteration outruns optimization. SpaceX improves through constant cycles of build, test, and refine. The institutional preference for comprehensive design before implementation is not inherently wrong; it reflects legitimate risk management in high-stakes environments. But it tends to produce systems optimized for the requirements of three years ago, delivered into a changed environment. The discipline of iteration is not about moving recklessly. It is about shortening the distance between assumption and evidence.

• Architectural honesty is non-negotiable. SpaceX chose reusable engines because expendable designs were financially unsustainable at scale. The organization confronted that reality and designed around it. Institutional architecture that avoids honest reckoning with cost and sustainability does not make the problem disappear; it defers and compounds it. Higher education is full of architectural decisions that were reasonable when made and have never been revisited.

• Innovation flows from constraints, not from comfort. SpaceX made hard tradeoffs. Steel instead of carbon fiber. Simpler systems instead of more capable ones. Lower cost through deletion rather than through engineering. The institutional instinct is to innovate by adding. SpaceX demonstrated that the more durable advantage comes from subtracting what does not add value.

Lean innovation is the discipline of doing less, better. It is not frugality for its own sake. It is strategic austerity that channels effort toward what matters.

What NASA Is Learning, and Why That Matters More

The story that deserves attention is not SpaceX’s continued success. It is what NASA under Isaacman is attempting to do with a legacy program that was already built.

Isaacman standardized the SLS design to enable a more predictable cadence of flights. That is Lesson Two in practice: delete non-value-added activities and handoffs before you optimize. He publicly named the failure modes in the Starliner program and held the institution accountable. That is Lesson One: every requirement, and every decision, must have an owner. He is pursuing a multi-vendor launch strategy that introduces competition into a procurement culture that had operated without it. That is a structural intervention in the economic conditions that produce drift.

None of this is as elegant as starting from scratch. Legacy architecture does not submit gracefully to simplification. The requirements that have accumulated over decades each have defenders, and those defenders have political relationships. Progress in this environment depends on negotiation, credibility, and accrued trust that lowers the temperature enough for people to let go of what no longer serves them. That is a different kind of leadership challenge than building a rocket company.

This is the more useful lesson for higher education leaders, because it is the situation they actually occupy. No project ever starts with a clean slate. ERP projects, infrastructure investments, academic technology decisions, and organizational redesigns all begin with inherited constraints, established stakeholders, and requirements that no one can quite explain but everyone seems to depend on. The discipline that SpaceX practices from inception has to be applied in higher education retrospectively and incrementally, against resistance, in an environment where failure is organizationally unacceptable and consensus is required for any change.

That is harder than what SpaceX does. It is also what the job requires.

The final word

The SpaceX model offers durable lessons about work simplification and four more about lean innovation. Those lessons apply to any institution attempting change, including universities undertaking ERP modernization, technology consolidation, or organizational redesign. But the harder and more instructive example may now be NASA itself: a legacy institution with an inherited program, a new leader shaped by a different model, and the deliberate choice to simplify rather than abandon what exists.

The real barrier in higher education is not technical. It is political. Internal politics can overwhelm even the best-designed transformation. Progress depends on negotiation, relationships, and the slow accumulation of trust that makes it possible for people to release requirements they have protected for years. Those things matter little in a private rocket company. They are everything in a public institution. The leaders who understand both the discipline of simplification and the patience that institutional change requires are the ones most likely to get somewhere worth going.

The scale of these ideas was impressive, and the ambition was real. But as I listened, I kept thinking about the tradeoffs. A colleague from another southern university and I compared notes. Neither of us could make the numbers work with the resources available to us. More importantly, we were not convinced that such large financial resources were necessary to deliver meaningful AI capabilities to our community.

That skepticism extended to the tools themselves. I was skeptical of Microsoft Copilot as the primary option for everyday use. The context windows and file upload features were too limited, the personalization features were absent, and the tool felt built for corporate environments rather than academic ones. It was an enterprise-grade infrastructure in search of an academic use case. I still mentioned it to peers for what it was: a solid, privacy-compliant option bundled into existing software, but not something that could anchor a comprehensive Everyday AI strategy.

That assessment is changing. Microsoft's recent announcements have shifted the calculus enough that a second look is warranted, and most US higher education institutions have a data privacy agreement in place with Microsoft that makes that second look more than theoretical. In today's Dispatch, I want to lay out how an ambitious Everyday AI strategy can proceed with disciplined, modest investment, and why the market has moved in ways that actually strengthen the case for restraint.

The big picture

The core challenge for institutional leaders is not whether to adopt AI. That question is largely settled. The challenge is deciding how much to spend, on what, and in service of which outcomes. Those decisions are being made right now, often under competitive pressure, and the consequences will compound greatly over time.

The right framework distinguishes between two fundamentally different categories of AI investment. The first is Everyday AI: affordable, accessible tools that improve individual productivity for students and employees. Writing assistance, meeting transcription, document drafting, and basic research synthesis. These tools are embedded in platforms that institutions have licensed, and their value is real and immediate. The second is Game-changing AI: high-stakes, institution-level spend intended to transform research capacity or administrative operations at scale. High-performance computing, GPU clusters for faculty research, and agentic AI embedded in modernized ERP systems. These require serious capital and serious governance.

The strategic error most organizations risk making is funding Everyday AI at Game-changing AI levels. The two categories are not on the same investment curve, and conflating them risks wasting resources on subscriptions with little long-term ROI.

The Necessity of Restraint: Guarding Credibility and Capital

The temptation to overspend is structural, not individual. Every major technology transition produces a period in which visible, large-scale investments function as signals of seriousness. Organizations that spend excessively are assumed to be ahead. Those who move cautiously are assumed to be behind. This dynamic has a name during peak hype cycles: dopamine-fueled IT. It substitutes visible action for strategic planning, and it consistently leaves organizations overextended before the cycle turns.

The AI investment environment today has several features that make restraint particularly important. Model capabilities are improving faster than institutional deployment cycles. What costs $300,000 per month to build on a custom basis today will be available as a commodity feature in a standard enterprise license before too long. Custom solutions built on current-generation models carry the same risk that custom ERP bolt-ons carried in the early 2000s: they lock institutions into architectures that will be obsolete before they are fully adopted and provide ROI.

Architectural honesty requires acknowledging this. Institutions do not need to customize their own large language model for community use. No version of that strategy provides a reasonable ROI. A proprietary in-house model for everyday use will not be competitive with frontier commercial models, will not travel with students after graduation, and will depreciate toward zero as the market matures. The same logic applies to single-vendor enterprise licenses that commit significant institutional capital to one platform before the market has settled on clear winners.

The better discipline is to maximize the value of what is already available, reserve capital for investments with genuine transformative potential, and maintain the institutional credibility that comes from not having overcommitted during the boom.

What the Microsoft Development Actually Means

For CIOs who have been watching the Copilot trajectory, the announcements of the last several weeks are worth taking very seriously. Microsoft has moved Copilot from a single-model assistant to a multi-model GenAI platform. The Researcher agent now includes a Critique feature that uses OpenAI’s GPT to generate research responses and Anthropic’s Claude to independently review them for accuracy, completeness, and citation quality before delivery. Copilot Cowork, now in early access through Microsoft’s Frontier program, embeds Claude’s agentic capabilities directly into Microsoft 365 Copilot Studio workflows for long-running, multi-step tasks. Claude Sonnet is available directly in standard Copilot Chat alongside OpenAI’s models.

This matters for three reasons.

First, it changes the meaning of the single-vendor licensing concern. A professional (premium) Copilot license is no longer equivalent to betting on Microsoft alone. The platform is becoming a container for multiple frontier models, with the institution retaining control over which models are enabled and under what conditions. That is a structurally different proposition than it was just twelve months ago.

Second, it validates the pluralistic argument. The case for exposing students to multiple AI tools rather than standardizing on one has always rested on the unsettled nature of the market. Employers use different tools, and fluency across platforms is a genuine workforce competency. Microsoft’s multi-model architecture effectively embeds that pluralism in the enterprise platform. Students working in a Copilot environment are now working across multiple models, not just within one platform.

Third, the adoption data is informative. As of early 2026, only about 3.3 percent of Microsoft’s commercial Microsoft 365 users were paying for Copilot. Microsoft’s multi-model move is, in part, an attempt to solve a persistent adoption problem by demonstrating value that a single-model assistant was not delivering. The lesson for institutions is not that Copilot has solved the adoption challenge. The lesson is that the market itself is acknowledging that single-model approaches are not sufficient.

For those of us in higher education institutions with existing Microsoft enterprise agreements and data processing addenda already negotiated, the calculus has shifted. The compliance infrastructure is in place. The tool is improving meaningfully. Leveraging what is already available before committing new capital to other vendors is now a more defensible strategy than it was a year ago, not because the platform is perfect, but because it is no longer the weakest of the major foundational models.

Execution: AI as a Workforce Development Platform

An institution’s long-term technology strategic plan and its workforce development strategy are the same conversation in an AI-infused university. The question is not what AI can do for students, faculty, and staff. It is what their human contribution looks like when AI handles the rote, mundane work that used to require junior labor.

New data from Goldman Sachs and Morgan Stanley confirms what many of us have suspected: the impact of AI on employment is not sudden displacement. It is a gradual, structural reclassification of roles. Goldman Sachs scored occupations by AI exposure, separating roles that can be fully substituted by AI from those where AI complements human work, and found that AI has raised overall unemployment by just 0.1 percentage point so far. The jobs that are contracting are built on routine, repetition, and narrow specialization. The jobs that are growing in both number and compensation are ones where human judgment, interpersonal accountability, and contextual reasoning cannot be automated away. The radiologist is the instructive case: ten years ago, Geoffrey Hinton predicted deep learning would make the profession obsolete within five years. Instead, radiologists adopted AI, their numbers grew, and their pay increased. Augmentation, not substitution, is the dominant pattern, and it is the pattern institutions should be building toward.

This has direct implications for college curricula. Institutions that continue preparing students primarily for executor-type roles are preparing them for work that is contracting. Institutions that develop judgment, adaptability, critical thinking, and orchestration capacity are preparing them for work that will expand. AI fluency should not be confined to electives or specialty courses; it is a horizontal capability that belongs across the curriculum, embedded in the expectations of every discipline. Capstone experiences, in particular, should be redesigned around synthesis and human judgment, not just the demonstration of technical knowledge. The question every program should be asking is whether its graduates can direct, evaluate, and improve AI-assisted work, not just handle tasks that agentic AI can easily perform.

Beyond curriculum, adoption at scale requires investment in people and process. Communities of practice, where faculty, staff, and students share what is working and what is not, accelerate competency development more reliably than top-down training mandates. Faculty who are curious and willing to experiment are the real adoption infrastructure; supporting them is more valuable than licensing more AI tools. IT teams that want to be strategic partners need to be known for effective collaboration, not just technical execution. Trust is not a soft consideration in AI adoption. It is the condition that determines whether institutional guidance is actually followed.

The final word

The path to becoming an AI-infused University is not determined by the size of the AI investment, but by the quality of the judgment applied to that investment. The organizations best positioned when the current AI hype cycle exhausts itself are the ones that resisted the pressure to signal ambition through large, visible, and premature commitments to any of the GenAI foundational models currently available.

Everyday AI is already available cost-effectively and on a large scale. It’s increasingly integrated into platforms that institutions have already licensed, and it’s improving without requiring any additional capital investment. Game-changing AI, the kind that genuinely reshapes research infrastructure or transforms administrative operations at scale, requires serious investment and serious governance, and that investment will be more available to institutions that did not overcommit during the AI boom.

The market is settling toward integration, not novelty. The organizations that recognized that early will be the ones with both the credibility and the capital to act when the genuinely transformative opportunities arrive, once the boom ends.

Flight instructors use a phrase that has stayed with me: either “you fly the plane” or “the plane flies you.” Experienced pilots develop an instinct, built from hours in the cockpit, that picks up on subtle shifts in wind and aircraft behavior before those shifts become problems. New pilots spend their time reacting. Each correction comes a beat too late and becomes an overcorrection, which creates a new problem, which requires another correction. Only experience teaches you which kind of pilot you are.

The same dynamic holds for CIOs and their senior leadership teams. Unless a team is continuously doing the quiet, disciplined work of anticipating and preventing problems, disruptions will come. As someone who is naturally assertive, my instinct is to lean hard on prevention, to keep teams focused, to treat every near-miss as a signal that something needs addressing. That instinct is not wrong. But flying this plane well is not a solo act; it is a team effort requiring the best of three distinct styles.

In today’s Dispatch, I want to revisit the negotiation styles discussed in earlier commentary and look at them through the lens of IT service disruptions. The three styles: Assertives, Accommodators, and Analysts, read these IT service disruptions quite differently. Each sees something real. Each misses something their counterparts will catch. It is their collective effort at scrutinizing the smallest details together that puts the team in genuine control of the plane they are flying.

The big picture

Major service disruptions are not just operational events. They are interpretive ones. When something breaks, whether by human error or machine failure, the disruption does more than reveal a gap in process or infrastructure. It surfaces the assumptions each team member carries about what strong team performance actually looks like.

Most post-incident reviews proceed as if everyone in the room read the same event. In practice, they did not. The same incident that registers as a performance failure to one person looks like a demonstration of team resilience to another, and a predictable consequence of a system carrying too much load to a third. These interpretations are not random. They are structural. They follow directly from the negotiation styles explored and discussed previously: the Assertive, the Accommodator, and the Analyst.

Understanding why this happens, and what it costs when overlooked, is the central challenge of building teams that improve steadily over time rather than cycling between disruption and recovery. Mutual self-awareness is key to strong teams.

The Assertive’s Read: Weight as Prevention

For the Assertive, a major service disruption is evidence of drift. Standards have slipped. Somewhere attention was lost, a detail fell through, and both the leadership and the organization paid for it. Their instinct is to bring weight to the moment: name what happened, assign responsibility, and make clear that tolerating service disruptions is not acceptable. They believe, not without reason, that a team that never feels the full weight of disruptions will stop working hard to prevent them.

The Assertive is not wrong. Teams do drift in the absence of accountability. The problem is the conflation of two distinct questions. Did the team respond well? And did the team prevent this? For the Assertive, a strong recovery does not redeem a failure to prevent the major disruption in the first place. That distinction is important, but applied without calibration, it produces a team culture that equates every disruption with poor performance rather than using the incident as a diagnostic.

The structural risk of too much Assertive energy is a tension-filled room. Accommodators, who thrive on relational trust and shared recognition, disengage or fade into the background when the environment feels punitive. Analysts, who need psychological safety to raise structural concerns without being accused of deflection, go quiet. The very voices that could improve the system long-term are driven out by the short-term pressure to raise the bar. An all-Assertive culture can hold standards, but it can put too much weight on those best situated to address underlying issues.

The Accommodator’s Read: Response as Sufficient Evidence

The Accommodator measures the performance of the team much differently. They do not evaluate the incident at the moment of major disruption alone; they evaluate it across the full arc. Detection, communication, coordination, recovery. A team that held together under pressure, communicated well, and resolved the issue with collective effort has demonstrated something real and tangible. That is not nothing. Operational resilience is built over time through exactly these moments.

The Accommodator is also not wrong. Teams that carry weight and function under pressure have built a kind of institutional muscle. The risk is a different conflation: “Did we handle this well?” and “Is the IT service stable and healthy?” are separate questions. A team can respond superbly to a chronic condition while remaining entirely blind to the fact that a chronic condition is worsening. Over time, the Accommodator’s instinct to recognize and affirm can become a tolerance for drift, normalizing recurring incidents by reframing each one as evidence of team strength.

The structural risk of too much Accommodator influence is the gradual acceptance of a quiet, degrading baseline. Prevention is deprioritized. Root cause analysis feels unfair. The team gets very good at incident response and focuses less on incident prevention. What looks like a resilient team culture is sometimes a comfortable one.

The Analyst’s Read: Structure Produces Defects

The Analyst does not read a disruption as evidence of individual lapse or cultural softness. They read it as output. Given the volume of work in progress, the number of competing priorities, and the cognitive load on the people doing the work, a defect at this moment was a near certainty. The framework here is familiar to readers of prior commentary: high WIP correlates with high defect rates. Lower the load, reduce the errors. Set better priorities, say no more often, and the system produces better results.

The Analyst’s structural argument is well-grounded. The research on WIP and defect rates is consistent, and the dynamics of overloaded service queues are predictable. But the Analyst’s lens, applied too narrowly, mistakes the map for the territory. Not every defect is a WIP problem. Some disruptions trace to training gaps, design flaws, or errors or omissions in judgment. Structural explanations, however accurate, can become a way of avoiding the accountability questions the Assertive is right to raise.

The more serious risk is behavioral. Analysts shut down under sustained assertive pressure. When the post-incident debrief turns into an accountability session with a high emotional temperature, the Analyst withdraws. They stop offering structural critique precisely when it is most needed. A team that loses the Analyst’s voice at critical moments loses its most reliable corrective mechanism. The pressure cooker the Assertive builds is most damaging not because it generates weight on the team, but because it deters the people best equipped to apply structural fixes to the system.

Why Strong Teams Need All Three

The Assertive, Accommodator, and Analyst are not competing for the correct interpretation of what happened. They are each surfacing a distinct response mode that the others are structurally inclined to miss. A team without Assertive energy drifts. A team without Accommodator instinct buckles under stress. A team without Analyst discipline accumulates invisible structural risk until something breaks hard.

The ideal-type version of each style, pursued without the correction of the other two, produces a team that is recognizably broken. The pure Assertive culture stresses out its best people. The pure Accommodator culture gradually accepts chronic low-level underperformance as normal and expected. The pure Analyst culture retreats into analytical frameworks and goes quiet at the moment the room needs a clear voice.

Bob Iger’s phrase, “sweating the details together,” captures what the alternative looks like. Not one interpretive style imposed on the whole team, but shared scrutiny of the same details from different angles. Excellence in operations is not a single perspective held consistently. It is the accumulation of small corrections, made by people who see the same playing field differently and trust each other enough to say what they think.

The leader’s job is to hold those three perspectives in productive tension. In practice, that means managing the Assertive’s post-incident pressure so it does not silence the Analyst, creating space for the Accommodator’s recognition so it reads as earned rather than defensive, and treating structural critique as required input rather than a deflection from accountability. All feedback should always be welcome. None of these adjustments is easy in the moment of a response or debrief. All of them are necessary.

The final word

A disruption reveals more than what IT service broke. It reveals how the team understands the relationship between performance, pressure, and trust. The Assertive, the Accommodator, and the Analyst will never read that moment the same way. That is not a problem to resolve. It is the architecture of a team that gets better over time. Success is not a single moment of incident response and resolution. It is the accumulation of small details, scrutinized honestly by people who see the world a bit differently and trust each other enough to say the things that need to be said.

Two moments have stayed with me. In one, a senior consulting partner came to my office to inform me that the University Registrar had continued to change the scope of the transcript implementation, and that the accumulated bill had reached $400,000. That was a time-and-materials engagement. In another, a workstream leader flagged that the consulting vendor had spent little time studying a complex business process, and that their process maps still carried another institution’s name in the document header. That was a fixed-price engagement, and the vendor had every incentive to move quickly and less incentive to dive deep. Both situations are more common than most leaders would like to admit. In today’s Dispatch, I want to bring my decades of ERP experience to bear on that common problem: how to best manage consultants working on a fixed-price agreement and those working on a time-and-materials basis. How you manage each one is different, and the cost of getting it wrong is the same: a project that runs out of money, time, or both before it crosses the finish line.

The big picture

Most CIOs and project directors do not choose the contract model governing the consulting work on their ERP implementation. That decision typically occurs upstream, negotiated by procurement officers and CFOs who are optimizing for budget certainty rather than daily project management. By the time the consulting team is assembled, the contract is signed and the operating conditions are fixed.

This creates a practical problem. The management discipline required to run a fixed-price engagement is fundamentally different from what a time-and-materials agreement demands. The incentive structures are different; the failure modes are different; and the skills that matter most are different. A project director who manages a time-and-materials engagement incorrectly will watch the budget erode one unbilled decision at a time. One who manages a fixed-price engagement incorrectly will find themselves buried in change orders and contractual friction.

Neither model is inherently superior. Institutions have succeeded and failed under both. What determines the outcome is not the contract type, but whether the project director understands the constraints they are working under and manages accordingly.

What Fixed-Price Actually Means on the Ground

Fixed-price contracts are attractive to CFOs and governing boards because they appear to convert a sprawling, uncertain transformation into a bounded financial commitment. The number fits cleanly into a capital budget. For institutions that are risk-averse or lack experienced internal project staff, the logic is entirely reasonable.

However, the fixed-price architecture carries a structural tension that every project director needs to understand from day one. When a vendor assumes financial risk for overages, they protect their margin by limiting scope, resisting depth of process discovery, and substituting lower-cost resources as the project matures. This is not bad faith; it is a rational response to the incentive structure both parties agreed to. Senior architects who are highly visible during the early phases will be replaced by junior analysts once unit testing begins. The partner is implementing a static scope document while the institution is still discovering its own preferences in real time.

Higher education compounds the fixed-price problem in a specific way. Business processes are often exception-driven, poorly documented, and understood only by the people who have run them for years. Because a fixed-price vendor is incentivized to move quickly through the early discovery and configuration phases, there is a structural pressure to keep requirements workshops shallow and move toward build. The project director's most important job in a fixed-price engagement is to resist that pressure. The vendor must invest real time in process discovery, and the institution's configuration teams must be pushed to go deep during workshops, surfacing edge cases, exceptions, and dependencies before the design is locked. Requirements that are not discovered early do not disappear; they surface during testing, when the cost of addressing them is highest and the institution's leverage is lowest. By that point, every gap in the original specification becomes a formal change order, often priced at a premium, and negotiated at the moment the institution can least afford to walk away.

The single most important tool in a fixed-price engagement is a pre-negotiated rate card, agreed to before the contract is signed. This is a comprehensive schedule of billable rates for every consultant tier the vendor might deploy, and it remains binding for the life of the implementation. When scope inevitably expands, the negotiation shifts from price to volume. Instead of arguing over what additional work should cost, the project director is managing how many hours a task consumes. This converts change orders into a more manageable administrative process. A fixed-price agreement without a pre-negotiated rate card is a structural failure waiting to happen.

What Time-and-Materials Actually Means on the Ground

Time-and-materials agreements rest on a different premise. They assume the institution and the implementation partner are aligned in pursuing the best possible outcome, and that the flexibility to respond to what gets discovered during the project is worth more than the predictability and comfort of a fixed budget ceiling. The model is well-suited to complex environments where detailed requirements genuinely cannot be fully known in advance, which describes most university ERP implementations.

The structural weakness of T&M is the absence of any financial incentive for the vendor to say no. If a functional lead wants a customized workflow built for a process that serves twelve people a year, the consultant will bill the hours to build it. This happens not because the vendor is acting improperly, but because the contract rewards hours worked rather than value delivered. Scope expansion in a T&M engagement is quiet and cumulative. It shows up in the burn rate, month after month, until someone does the math and realizes the budget will not reach the go-live date.

A T&M engagement requires the project director to function as an investment manager rather than a contract auditor. The most effective tool for maintaining that discipline is a miniature scope and cost agreement for every major deliverable, negotiated before billable work begins. This converts the engagement into a series of small, bite-sized fixed-price commitments, providing cost predictability while retaining T&M flexibility overall. The core evaluative question never changes: does this activity move us toward go-live, or does it merely satisfy someone's preference for how the system ideally works? Decision velocity matters here as well; in T&M, slow institutional decisions are expensive in a direct and visible way, and the project director has to build that speed into the operating rhythm of the project.

T&M also offers one significant advantage that fixed-price does not, which is resource sovereignty. Because the institution is paying for specific talent rather than a guaranteed outcome, the project director can more easily remove a consultant who is not performing and request a replacement without proving a contractual breach. The difference between a senior consultant who understands higher education processes and one who does not is measured in months of rework and unexpected cost overruns.

What Both Models Share

The most common failure pattern in ERP implementations, regardless of contract type, is slow institutional decision-making. In a fixed-price environment, indecision triggers delay and disruption complaints from the consulting partner. In a T&M environment, indecision quietly burns the remaining budget. The contract cannot solve this problem; only leadership attention can. The project director needs standing authority to bring decisions to the right senior executives quickly, and those leaders need to understand that deferral and queue-time carries a real project cost.

Both models also require the project director to manage internal stakeholders as actively as they manage the vendor. The consulting partner is a visible risk; internal stakeholders are a quieter, often more systemic risk. The functional lead who keeps expanding requirements, the department head who will not release staff for testing, the executive who changes priorities midstream: these are project realities that no contract structure can contain. Managing them requires credibility, immediate executive-level access, and transparent decisions from above the project leader.

The final word

The contract with the consulting implementation partner is the operating system of the implementation, but it does not run the project, nor does it guarantee outcomes. What runs the project is the judgment and discipline of the people managing it daily.

Fixed-price rewards boundary control: the project director’s credibility depends on holding the line between what was scoped and what gets delivered, with a pre-negotiated rate card as the mechanism that keeps change orders grounded and controlled. T&M rewards investment thinking: credibility depends on demonstrating that every dollar spent moves the institution toward go-live, and on cutting off the quiet accumulation of non-value-added time before it becomes a budget crisis. The management disciplines are different, but the underlying standard is the same: the project director has to know which game they are playing and manage accordingly.

Ultimately, both models demand the same underlying capacity: the project director must separate what the institution genuinely needs from what various stakeholders sometimes want, and keep the project moving toward the former without losing the trust of the latter. That capacity does not come from the contract. Institutional leaders who understand this stop asking which contract type is right and start asking whether their project director truly understands the model they are operating inside. That is the right question, and it is almost never the one that gets asked until it’s too late.

Six months before launch, the server team recommended buying an Amdahl mainframe-class server for the web layer. We tested one. It was massive, expensive, and clearly built for a world the web was already moving past. It represented a philosophy of abundance and brute force. My team favored small, inexpensive Compaq servers running Windows. We chose the Compaq servers because of budget constraints, not their raw horsepower. That choice worked.

Today, the AI industry equates progress with brute force, assuming larger GPUs are the answer to every problem. History suggests otherwise. The long-term winners in computing have rarely been the vendors with the most horsepower. They have been the ones who integrated tightly, drove marginal costs toward zero, and let technology recede into the background. In today’s Dispatch, I use that lens to examine why Apple and Google are better positioned for what comes next, and why the current alliance between OpenAI, Microsoft, and Nvidia is more architecturally fragile than it appears.

The big picture: training vs inference

The current discourse around artificial intelligence is defined by a frantic, speculative energy. Institutions are watching a massive capital expenditure cycle where corporations rush to secure Nvidia GPUs as if they were vital commodities. This behavior reflects a classic gold rush mentality, characterized by announcements made before contracts are signed and commitments that carry no binding obligation.

To understand why this matters, you have to distinguish between the two fundamental modes of AI operation: training and inference. The industry conflates them, but they demand entirely different architectural and economic models.

• Training is the act of building the model. It requires massive, centralized compute power. This is where Nvidia currently extracts its profits, selling units that cost tens of thousands of dollars to organizations desperate to participate in the boom. This phase is capital-intensive and centralized.

• Inference is the act of using that model to do work. It is the moment a faculty member summarizes a PDF or a student asks for a schedule adjustment. Industry analysis, including work from firms like Sequoia Capital, suggests that by 2030 inference will account for the vast majority of AI compute demand. The existing architectural model for inference does not scale financially. A future where every routine interaction incurs a toll paid to a third-party GPU provider is not a sustainable institutional architecture. Relying on high-wattage, high-cost server hardware for everyday tasks is the Amdahl mistake repeated at scale.

The future belongs to those who can drive the cost of inference toward zero. Two companies have built the architecture to do that. One has built it at the edge. The other has built it at the backend. Both have done it without depending on Nvidia.

Apple’s Zero Marginal Cost Gambit

Apple’s strategy is a masterclass in leverage. While competitors scramble to build larger data centers, Apple has spent years optimizing its own silicon. The Neural Engine embedded in its M-series and A-series chips moves the primary AI workload from the data center to the device itself.

This is a pure architecture play. When a user engages with Apple Intelligence to rewrite an email, sort notifications, or summarize a document, Apple pays zero in cloud costs. The energy and compute are drawn from the device the user already purchased. That approach creates a powerful economic position. It allows for “Everyday AI” that is financially sustainable because it is local.

For tasks that do require cloud processing, Apple has introduced Private Cloud Compute, a system that redefines the relationship between server and user. Apple has constructed a server architecture where user data is cryptographically inaccessible even to Apple’s own administrators. The system deletes user data immediately after the request is fulfilled, and the hardware stack is verified by third-party auditors. This turns privacy from a compliance burden into a core infrastructure layer, offering a path to adoption that does not require compromising data sovereignty.

A nuance worth acknowledging: Apple’s advanced Siri capabilities are being partially powered by Google’s Gemini models. Some observers have read this as evidence that Apple is falling behind. The more accurate reading is the opposite. Apple is treating frontier language models as a commodity input, something to be sourced from the most capable provider at the lowest cost, while maintaining control of the user experience, the privacy architecture, and the device layer. That is exactly the behavior you would expect from a company that understands the infrastructure maturity thesis. You do not build the generator; you control the grid.

The iPhone 17 cycle has financially validated the on-device approach. Apple reported record holiday quarter revenue in January 2026, driven substantially by the AI-enabled hardware upgrade cycle. Consumers are buying new devices specifically to access on-device intelligence. That revenue pattern is structurally different from a subscription model tied to cloud inference costs. Apple’s margins do not erode with usage.

Google’s Vertical Integration as a Strategic Fortress

While Apple has secured the edge, Google has quietly secured the backend. Unlike its competitors, which are dependent on Nvidia’s pricing power and supply constraints, Google spent the last decade designing its own Tensor Processing Units (TPUs). That foresight, which began as early as 2015, has allowed the company to build a compute infrastructure largely immune to the market volatility affecting others.

Google’s TPU ecosystem offers a significant cost-performance advantage over Nvidia-based equivalents for inference tasks. The TPU is not a general-purpose device; it is a workhorse designed for systolic efficiency, moving data less and calculating more. Because Google controls the entire vertical stack, from chip design to model to end-user application, it is insulated from supply chain volatility. They do not pay the NVIDIA or Azure/AWS tax on their own compute infrastructure needs.

The broader market is beginning to recognize this position. Anthropic, one of the most significant AI labs operating today, has placed large orders for TPU capacity. OpenAI, seeking to reduce its Nvidia dependence, has signed agreements with Broadcom, which manufactures custom AI chips that include Google’s TPU architecture. When your most prominent competitors are routing compute through your infrastructure, you are no longer just a search company with an AI capability. You are becoming the grid operator for the next generation of AI applications.

In a 2035 world where AI is utility infrastructure, Google’s ability to control its own input costs will allow it to price aggressively. The company does not owe a margin to a hardware vendor for every transaction. That is a durable structural advantage.

The Fracture That Was Not Theoretical

The current alliance between OpenAI, Microsoft, and Nvidia appears formidable from a distance. It relies on a complex supply chain where incentives are frequently misaligned, and every layer of the stack demands a margin. That fragility is no longer a prediction. It has become a documented outcome.

In September 2025, Nvidia CEO Jensen Huang and OpenAI CEO Sam Altman stood together to announce what was described as a $100 billion strategic partnership to deploy 10 gigawatts of Nvidia infrastructure for OpenAI. The announcement generated enormous market attention. Five months later, no contract had been signed, no money had changed hands, and Nvidia’s own CFO confirmed publicly that the deal remained “a letter of intent” with no assurance that a definitive agreement would be completed. Huang had privately questioned OpenAI’s business discipline and expressed concern about the company’s competitive position against Google and Anthropic. By early March 2026, Huang stated publicly that the original $100 billion deal was “probably not in the cards.” The revised arrangement, reportedly a $30 billion equity stake with no chip-purchase obligations, represents roughly 30 cents on the dollar from the original headline.

This outcome illustrates something important about modular stacks. When your critical infrastructure provider is simultaneously financing your direct competitors, and when the terms of your supply relationship are non-binding announcements rather than executed contracts, you do not have a utility. You have a dependency. Dependencies are renegotiated when the leverage shifts.

The circular financing concern raised by market observers has also proven legitimate. Nvidia committed $10 billion to Anthropic while simultaneously being OpenAI’s primary hardware supplier. OpenAI, in turn, signed a separate binding agreement with AMD, Nvidia’s largest GPU competitor, for 6 gigawatts of hardware. Each company in this stack is hedging against the others. That is not the behavior of aligned partners. It is the behavior of organizations managing dependency risk.

Apple and Google face neither of these problems. Google does not negotiate a memorandum of understanding to access TPUs; it allocates them internally. Apple does not require a third-party GPU vendor’s approval to deploy intelligence features on 2.5 billion active devices. Their supply chains are self-directed.

What This Means for CIOs and Higher Education Leaders

History teaches us that in mature computing markets, vertical integration tends to prevail over modularity at the user-facing layer. This is not a universal rule; the Wintel era demonstrated that modular architectures can dominate for extended periods under the right conditions. But the conditions that sustained Wintel, standardized hardware, stable software interfaces, and low switching costs, do not fully describe today’s AI environment. AI capability is still volatile. Trust and privacy are active stakes for institutional leaders. The switching costs embedded in on-device AI architectures are significant. These conditions favor integrated platforms.

For a CIO charged with stewardship and long-term architectural honesty, the practical consequence is this: vendor commitments built on non-binding letters of intent are not infrastructure. They are options. When you anchor your institution’s AI capability to a vendor whose supply chain is itself dependent on a third party that is simultaneously financing your vendor’s competitors, you have not secured a capability. You have created a dependency on a negotiation you cannot control.

The “Nvidia tax” is the relevant concept here. Any AI service that routes every inference request through high-cost GPU infrastructure passes that cost along, either in direct pricing or in the financial fragility of the vendor providing it. For institutions managing tight operating budgets across multi-year horizons, that cost structure is not sustainable at scale. Everyday AI, the kind that handles scheduling, summarization, advising support, and administrative workflow, cannot be priced like frontier model research. The architecture has to support the economics.

This does not mean institutions should avoid OpenAI’s or Microsoft’s platforms. Many of those tools deliver genuine value. The question is architectural positioning over a five-to-ten-year horizon. Which vendor relationships are building toward lower marginal costs and greater institutional control, and which ones are building toward deeper dependency on supply chains the institution cannot see or influence?

Huang’s reported criticism of OpenAI’s business discipline was not merely industry gossip. It was a signal about how hardware providers evaluate their customers. Discipline, in this context, means the capacity to make binding commitments, manage capital responsibly, and build toward sustainable unit economics. Those are the same standards a CIO should apply to vendor evaluation. If the leading AI infrastructure provider is questioning whether its largest customer has the discipline to execute, that question deserves space in your own vendor risk assessment.

The final word

The temptation for leadership today is to chase the loudest innovations. There is pressure to deploy whatever generates the most excitement and to sign contracts with vendors dominating the headlines. The role of the CIO is to look past the spectacle.

The real Internet was not built during the boom. It was built in the years after, when scarcity forced architectural honesty and every dollar had to address a real constraint. Apple and Google are not winning the AI race because they are spending the most. They are better positioned because they built infrastructure they actually control, optimized for the economics of inference rather than training, and avoided the circular dependencies that are now visibly straining the OpenAI-Nvidia relationship.

The strongest institutional architectures are not built in abundance. They are built when resources are tight and choices are clear. That is the work of stewardship. It is also, not coincidentally, the work that Apple and Google have been doing quietly while the rest of the industry announced deals that were never signed.

But I also see the weight carried by the people already in the building. The team that has kept the lights on, absorbed the ambiguity of transition, and quietly wondered whether the new leader would take the time to understand what they have actually built. A leadership change is disorienting for everyone, not just the person walking in.

I have been in that position three times in my career. In all three environments, change was needed, and I braced myself for difficult work. Yet once I looked past the inevitable friction of any transition, what I found was remarkable. The teams I inherited were exceptional. They did not require upgrades. They needed clarity, transparency, and someone willing to “sweat the details” of hard work with them.

In today’s Dispatch, I want to pull back the curtain on organizational dynamics in the midst of change and explore why the real leadership is not found in trying to hire your way to a new culture, but in the patient work of leading the team you actually have.

The big picture

Higher education leaders are inundated with management literature preaching the gospel of “talent density,” a philosophy popularized by companies like Amazon and SpaceX, which suggests that the only path to high performance is to pay top salaries and continuously cull the bottom of the organization. For higher education and established enterprises, this model is not just impractical; it is a dangerous distraction that blinds leaders to the talent that their institution actually contains.

Most universities operate with salary bands that cap well below the starting rate at outside firms. When leaders fixate on a labor model designed for venture-backed hyper-growth, they fail to optimize for the conditions they actually face. The result is that capable people, working inside incoherent systems, are mistakenly read as the problem when the structure around them is the real constraint. Good leadership, in this context, is not waiting for a better team to arrive. It is building the structural coherence that allows the people already present to do exceptional work.

What the Team Already Knows

Before any new leader assesses their team, the team has already assessed them. They have watched previous transitions. They know which new arrivals listened and which ones performed. They have seen the reorgs, the rebranding exercises, and the new strategies that went nowhere. Their skepticism, if it exists, is earned and reasonable.

This is worth naming directly. The staff member who seems disengaged may have offered ideas that were ignored for years. The one who pushes back may be protecting something that is really important. The institutional knowledge that looks like resistance often turns out to be the most accurate map of the terrain available. Leading the team you have means starting there, with curiosity rather than a verdict.

The proof of this approach is not abstract, but is found in the continuity it produces. CIOs who invest deliberately in the people already present often find that their own succession comes from within. That outcome is not accidental. It is the direct result of treating the inherited team as an asset to develop rather than a problem to replace.

The “Upgrade” Trap

The danger for incoming leaders is a particular kind of magical thinking: the belief that transformation is primarily a hiring problem. They undervalue the people in the room by comparing them to a theoretical candidate who doesn’t exist, and in doing so, they neglect the development of people who are staying for the long term.

As argued in Star Quarterbacks and Shadow IT, this logic leads leaders to chase the confident, fast-moving builder who promises quick results. That “star” often bypasses collaboration, ignores enterprise architecture, and leaves behind technical debt for others. In a university, a genuinely high-performing technologist is not someone who writes code ten times faster. It is someone who stays ten years longer. Institutional memory and loyalty are force multipliers that individual heroics rarely provide.

The lesson often comes early for leaders who have been on the other side of this dynamic, who were themselves passed over or underestimated before someone took a chance on potential rather than credentials. Most teams contain people like that, individuals who have been overlooked because they did not fit someone’s mental image of the ideal hire. When leaders look for competencies rather than credentials, they often find that the quiet contributor was simply waiting for the right conditions.

Coherence is the Leadership Lever

When leaders accept that they cannot restructure every role and cannot recruit from the top of the technology labor market, the one variable they can actually control is coherence. A group of capable people moving in deliberate alignment will always outperform a group of “star quarterbacks” pulling in their preferred directions.

The mechanism for this is straightforward. The discipline of the weekly team meeting, practiced relentlessly, is one of the most effective coherence tools available. The format is simple: review what was just done, identify what comes next, and ask for feedback. It is not exciting, but it’s relentless. And it works. Steve Williams, a retired Army Colonel who led technology teams with this approach, demonstrated that military-grade meeting discipline translates directly into institutional settings. The consistency of the gathering matters as much as what happens inside it.

The weekly meeting is not micromanagement; it is the calibration mechanism that creates coherence. By gathering regularly to track progress, solve complex problems, and navigate stakeholders together, the team’s capacity rises. When shared standards are enforced and the details are scrutinized together, the gaps in individual capability are filled by the strength of the process. Excellence becomes a shared habit rather than an exception. Indiana’s football success is the newest example of this in action.

The Leader as Shock Absorber

Most teams underperform not because of skill deficits but because of distraction: conflicting priorities, political noise, and the anxiety that accumulates when leaders are vague. As discussed in Resilience in the Fog of Uncertainty, uncertainty creates shadows, and it is the leader’s primary job to turn the lights on and make things clear.

When leaders absorb the institutional ambiguity that would otherwise cascade down to the team, the group’s available capacity increases immediately. When the “VIP queue jumpers” are managed at the leadership level rather than handed off to the team, the people doing operational work can focus. Protecting the team from noise is not a secondary function of leadership. It is often the most consequential one.

Cultures built on individual heroism, on one “star quarterback” keeping fragile systems functional through personal effort, are structurally brittle and will eventually fail. Real operational quality comes from processes designed so that the departure of any single person does not create a crisis. Cross-training and documentation are not administrative overhead. They are the architecture of a strong and resilient team.

Building the Skills You Cannot Buy

When ready-made capabilities cannot be purchased from the open market at scale, leaders must turn to developing them internally. As argued in Why Your IT Hiring Stalls and How to Fix It, the best approach is to hire for competencies like curiosity, initiative, and accountability, then train for the skills that the work requires. This demands real budget commitment; at a minimum, four percent of the personnel budget directed toward training and development annually is a reasonable standard.

Growth happens when people are given responsibility just beyond what they believe they can handle, and when the work itself becomes the development ground. There is a dignity in the long-tenured employee that the technology sector systematically undervalues. These staff members know where complexity lives, how the ERP system actually functions, and how to navigate institutional culture in ways that no document can capture. The goal for leaders is not to bypass that knowledge. It is to unlock it.

A Note on the Exceptions

Every leadership transition includes genuinely difficult cases: the actively resistant employee, the non-performer who operates in the gaps of weak oversight. These situations are real and should be addressed quickly. The process is less about confrontation than about applying consistent organizational standards, clarifying expectations, and raising the bar uniformly. When that structural pressure is applied, the situation usually resolves itself. The person either rises or self-selects out.

But these cases represent a small fraction of any team. The error is allowing them to become the dominant lens for how a new leader reads the entire organization. When all attention goes to the few who are leaving, the many who are staying go unled.

The final word

The belief that a better team is waiting somewhere off the org chart, that transformation is primarily a matter of acquiring different people, is a way of avoiding the harder discipline of actually leading. The team already present is, in most cases, more capable than the circumstances have allowed them to demonstrate.

What they need is a leader willing to do three things consistently: provide clarity about what matters and why, protect them from the organizational noise that fragments attention, and invest in their development over time. When those conditions exist, the performance of an average-tenured, stable workforce can be genuinely surprising. The missing variable is rarely talent. It is coherence. And coherence is something a leader builds, not something they hire.