My university AI work includes university-wide strategy, internal product development, and individual coaching. Each needs a different kind of help.
My university AI work includes university-wide strategy, internal product development, and individual coaching. Each needs a different kind of help.
This retrospective entry was prepared from an October 4 draft and first published on October 27, 2026. Its September archive placement is an editorial date.
Over the past several months, I've been working with a university on these different parts of using AI. They connect, but each has its own questions, people, and kind of help. I want to write about them separately so someone can find the part that matches what their team needs.
One area of my work is the university-wide AI strategy. A university has questions about what students should learn, how faculty and staff use AI, and how those choices fit its mission. There are questions about approved tools and data, academic integrity, enrollment, and student support. Different people need to help answer them.
An engineering team can help make a tool available. It cannot decide on behalf of faculty what learning should look like, or on behalf of a student-support team where an automated response is appropriate. Those conversations deserve focused posts of their own.
I also want to keep discussions, experiments, and delivered work distinguishable. Describing the areas a university needs to think through does not mean claiming they are all solved.
A second area is helping IT become an internal software and product team. What can the institution build and maintain for itself, and when could that let it retire an outside contract?
Think of a hypothetical product with 1,000 features. Your team uses 20, but it is missing five capabilities the team needs. You might end up with three subscriptions to complete one workflow. The vendor's price could be fair for its full product and still be a poor fit for what your institution needs.
That creates a more useful question than whether IT can reproduce the entire commercial product. Could the team build and reliably maintain the 25 capabilities it actually needs?
AI-assisted development is changing what I consider practical to build. The opportunity also depends on the people: helping engineers develop product judgment, and helping product managers understand more of the engineering. The distance between describing a problem and trying an implementation can get smaller.
That is the part of the work behind internal ticketing, CRM, communications, design tools, and a shared deployment platform. Here are the different problems within it.
Product and engineering teams both need a way to try an idea before the full investment. AI can help turn a workflow into something people can use and critique.
The people doing the work still have to define what should happen. Who owns the next step? What information should this person be able to see? What happens when the input is incomplete?
A prototype gives product people and engineers something concrete to discuss together. Releasing it to people who depend on it requires another level of checking.
Ticketing has been one of the areas I've helped with. Much of the work lives beyond the form that creates a request.
The request needs an owner, a history, a way to reply, and rules about who can see it. The team needs to understand what happens when someone replies after a ticket is closed or when responsibility moves to another department.
Those are specific behaviors to build and test. A plausible-looking interface can hide an unfinished workflow, so I want the check to follow the request far enough to establish what happened to it.
Another area has been an internal CRM. The starting point is what the team needs to know about a person and what action that information supports.
A list of contacts doesn't answer all of that. Program participation, event history, and previous communication can each change what a staff member needs to do next. Imports and duplicate records also need attention before the team can trust what it sees.
A field that seems obvious to the developer may mean something different to the department. Getting those definitions right requires talking with the people who use the records.
Email and SMS marketing are closely connected to the CRM, but deserve their own discussion. Finding the right group of people and preparing a message are different jobs from maintaining the contact record.
The person responsible needs to understand who is included, what they will receive, and whether someone who should be excluded has slipped into the group.
AI can help build the tools and prepare content. The person sending still needs a reliable way to inspect and approve the result.
I've helped people work on dashboards and automations as well. Often the team already knows which repetitive step it wants to remove or what it needs to see.
A dashboard needs more than a convincing chart. We need to know where the number came from, when the underlying information last changed, and what the number means. An automation needs a clear trigger and a way to notice a failure.
Compare the new version with the existing task on the same input. Can the team catch a missing record or an incomplete run? The checks should be understandable without reading the entire implementation.
Brand consistency has been another part of the work: making approved design information available to the tools people use to build things. If every application has to reconstruct the university's visual rules from scratch, each new project creates another opportunity for the rules to drift.
A shared brand catalog can give those tools a common reference. People still need to review the result, including whether the interface is readable and accessible. Having access to a correct color value doesn't establish that a whole page is well designed.
I've also been exploring an internal design tool in the same general category as Canva. That is a separate product question. Which things should staff be able to create themselves? What should be fixed in a template? Where does the design team need to stay involved?
A working prototype helps people answer those questions. Their feedback determines whether it becomes useful enough to keep developing.
There is a shared platform underneath this work too. Internal applications need a place to live, a way to use the institution's sign-in, a place to store information, and a repeatable deployment process.
That foundation gives the next project fewer basic decisions to repeat and a common place to apply operational standards.
Automating deployment does not establish that a change is ready. Someone still needs to know what is changing, what has been checked, and how to recover if it fails.
My individual coaching began with helping people use AI for their job tasks. It has developed into a broader conversation about skills, productivity, and what the work is meant to accomplish. For some people, AI ends up being a small part of that conversation.
Someone can become very good at operating a tool while the goal behind it gets less attention. For a product manager, maintaining tickets and statuses supports the work of moving a useful product forward. It does not establish that the product is becoming more useful.
The same question applies to managers defining a role or hiring for it. Which outcome do they need this person to help produce? Which skills serve that outcome? Knowing a tool can matter a great deal, but it is one part of the answer.
An AI question gives us an entry point. We can look at the work together, decide what needs to happen, and then choose where better skills, a different process, or a tool could help. When an AI exercise is useful, I like to use a real task with a result the person can check.
Some of these projects involve established workflows; others are still being developed and shaped with the people who will use them. I don't want to flatten those stages into a list that implies everything is equally finished.
Each month's set of projects we're bringing in-house represents at least $10,000 in additional annual contract savings once those transitions are complete. Some months' projects are considerably larger.
Right now, we're bringing more than $50,000 a year in contracts in-house by the end of 2026. These are planned contract transitions, rather than savings already realized. Development, hosting, support, security, migration, and maintenance still belong in the cost comparison.
The same care applies to cost. A canceled software subscription is one part of the calculation. Development time, hosting, support, security work, migration, and ongoing maintenance belong in it too. Building internally creates something the institution can change, and something it has to keep operating.
I've written about how I check AI work before calling it done. The same concern applies here: a test should establish the behavior we care about, and a person still needs to use the thing. AI assistance doesn't remove that responsibility.
The focused posts cover helping IT become an internal product team, skills and responsibilities beyond the tool, and bringing a real task to AI training. You can start with the problem that resembles your team's work. University-wide strategy has questions I want to explore in further posts.
If your university has a workflow you'd like help with, get in touch and describe the task. Tell me who does it, what they use now, and where they get stuck. That gives us a much better starting point than a general request to “do something with AI.”