In September 2018 I gave a talk called “Halfway Digital” at the Common Solutions Group (CSG) in Charlottesville, VA, as part of a workshop on IT’s role in digital transformation. The thesis was simple: most of higher ed thought it had digitally transformed, when in reality it had only made it halfway up the wall.

“Climber dangling off a rock face, halfway up”

Higher ed missed the memo

Joshua Kim had written a piece in Inside Higher Ed the year before — “Technology and the Future of the College Presidency” — that I quoted at length. Three rules of thumb stuck with me:

  1. Technology is strategic. It makes no sense to write the strategic plan and then bring IT in afterward to “implement” it.
  2. Technology is a way of thinking, not just the hardware and software you buy.
  3. Technology is not a magic bullet. It can amplify institutional strengths but cannot cover for an inability to make hard choices.

Higher ed leaders kept treating technology like plumbing — install it, use it, complain when it leaks. The schools that were genuinely transforming treated it like a way of thinking. The difference showed up everywhere.

First stages of transformation always look like the past

The opening illustration was Southwest Airlines’ 1998 home page: a digital interface that visually mimicked a physical counter — rolodex on one side, a printed flight schedule on the other, a CRT screen displaying the price. It was “digital” only in the trivial sense. The mental model was still 1970s ticket agents.

That same trap was everywhere in higher ed in 2018. We had digital systems, but they were faithful reproductions of paper processes. PDF forms. Workflow tools that recreated the path of an inter-office envelope. Help desks that operated like a phone bank with a CRM bolted on.

Case Study: The Berkeley Desktop

At UC Berkeley our Desktop service had solved one important problem — we had standardized the hardware. So I drew a strikethrough through “varying hardware standards” on that slide. Done. But the rest of the list was still very much alive:

  • No significant automation
  • Manual work, no checklists
  • Frontline support staffed by senior technicians
  • Senior technicians diverted from real work to handle VIP requests

Standardizing hardware was the easy half. The hard half was the workflow — automating user setup, deprovisioning, department onboarding, access management — so the senior people could work on hard problems instead of password resets for vice chancellors. That was the work that separated halfway from finished.

Case Study: The iHub

The other case study was Berkeley’s iHub — our API management platform and integration practice. The contrast slide was deliberate: on one side, an old mechanical “Mechanical Turk” automaton crank-driven by a hidden human, and on the other, our API Central portal where developers could find, request, and use campus APIs without ever speaking to anyone in IT. That was what fully-digital looked like: self-service, programmable, and integrated by default.

The iHub wasn’t just a piece of software. It was a way of working. Strategic consulting, integration design, event processing, web service hosting — wrapped around a platform that let anyone with a use case build something real.

Solutions

I closed the talk with a stack of books rather than a recipe, because the answer wasn’t a tool — it was a worldview shift. The four I recommended:

  • Digital Transformation — Lindsay Herbert
  • Effective DevOps — Jennifer Davis & Katherine Daniels
  • Work Rules! — Laszlo Bock (the Google HR experiment)
  • Start With Why — Simon Sinek

The throughline across all four: digital transformation is not an IT project. It’s a leadership project that uses IT as the medium. If your organization can’t articulate why it exists, automating the existing workflow just makes you faster at doing the wrong thing.


Looking back from 2026, the “halfway digital” framing held up better than I expected. The institutions that were halfway in 2018 are mostly still halfway now, just with newer tools. The ones that pushed through built the culture along with the platforms — automation, observability, product thinking, real engineering practices — and that’s what separated them.

Original slide deck (PDF)