Some of my AI coaching has become a broader conversation about skills, responsibilities, and what a job is meant to accomplish. I want to define that work before deciding which tool someone should learn.
Some of my AI coaching has become a broader conversation about skills, responsibilities, and what a job is meant to accomplish. I want to define that work before deciding which tool someone should learn.
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.
This is part of the three areas of my university AI work.
I started helping people use AI to do things they already needed to do at work. As that developed into individual coaching at a university, the conversations became broader. We were talking about the skills someone needed, how their work fit together, and what they were trying to accomplish in the first place.
For some people, AI is a small part of that work.
That has changed how I think about training. Before I help someone get better at a tool, I want to understand what getting better would let them do. Otherwise, we can spend a session making an existing activity faster without asking whether it is helping anyone.
A person can describe a large part of their day by naming the software they use. They update a board, maintain a spreadsheet, enter records, and prepare a report. Those are real activities. Some take considerable knowledge to do well.
I still want to know what depends on them.
Who uses the report? What decision does it support? What becomes possible when the board is up to date? If a record is wrong, who has a problem?
Those questions connect the activity to its purpose. They also give us a way to decide what training would help. Someone might need a better way to analyze information, a clearer explanation of a process, or more confidence asking another department for a decision. Learning another feature in the software may be useful, but it may leave the main difficulty untouched.
I don't want to lose the person's existing knowledge in that conversation. Knowing the reason for a seemingly unnecessary field, or which exception breaks a process, is valuable. That is often the knowledge we need to understand what the work actually requires.
Consider a hypothetical product manager who wants help using AI to maintain a backlog. They spend time rewriting tickets, chasing updates, moving items between columns, and preparing for meetings.
There is probably something we could try there. AI could help draft a clearer ticket or organize material for review. Accurate records and coordination can make the team's work easier.
But I would also want to understand the product they are trying to move forward.
Suppose the team is improving an appointment-booking service. People start booking and then call the office because they cannot tell which appointment type to choose. The product manager's work includes understanding that confusion, helping the team choose a change, and checking whether the change helps people complete the booking.
The backlog should support those decisions. A carefully maintained collection of tickets could still omit a useful check: can someone now choose the right appointment without calling for help?
Coaching that person might involve working out what to ask users, distinguishing a proposed feature from the problem behind it, or agreeing on what the team needs to learn before committing to a change. We might use AI during that work. We might spend most of the session talking through the decisions ourselves.
I would judge the session by whether the person can move that work forward with a clearer understanding of it.
I think a manager can fall into a similar pattern when defining a role. The immediate need may sound like “we need someone who knows this platform.” That can be a reasonable requirement, especially when a team depends on a complicated system.
I would want the hiring conversation to continue. What should that person accomplish with the platform? Which decisions will they own? What does the manager expect to be better because they are there?
A department can gradually organize its work around the software it has. Reporting follows the available dashboards. Responsibilities follow the permissions. A process becomes familiar enough that its original purpose is harder to see.
I see that as something worth examining together. It would be unfair to ask an employee to rethink their work while continuing to evaluate them only on whether every field is filled in and every status update arrives on time.
The manager needs to help establish priorities and explain which requirements are fixed. A record kept for an audit has a purpose even if it does not produce an immediate improvement for a customer. Some coordination is essential. We need to understand those obligations before deciding what could change.
Once we can describe the result, the training becomes easier to choose.
For one person, the useful skill may be breaking an unclear request into questions they can answer. For another, it may be explaining a recommendation well enough that someone can make a decision. Someone else may need to understand how information moves between systems so they can identify where a mistake begins.
Tool proficiency belongs in that picture. A person who understands a system well can do careful work, recognize its limits, and help others avoid mistakes. I want that proficiency connected to a reason for using it.
The same applies to AI. Generating a draft or a prototype can help us examine an idea. Someone still needs to judge the result, check the relevant facts or behavior, and decide what happens next. A faster first attempt is useful when it gives the person more room to do that work.
AI can give people a reason to ask whether their work could be done differently. I want to use that opening to have an honest conversation about the work itself.
If a session starts with a request for AI training and we find a broader question, I want to make that shift explicit. We can agree that defining the outcome, clarifying a responsibility, or practicing a different skill would be the better use of our time.
After we choose a useful task, there is still practical work to do: choose an appropriate tool, try it within sensible boundaries, and check what it produces. The earlier conversation tells us why that task is worth doing.
If you want to work through this with me, tell me what your work is meant to accomplish and where it gets difficult. We can start there and decide what you need to learn to move it forward.