What Changes After the Conference?

I went to a technology conference in Orlando. And one of the most useful stories I brought home was about a hot dog. Not an autonomous hot dog. Not a hot dog with an enterprise subscription and a roadmap to agentic mustard.

A hot dog. Because somebody paid attention to what another person actually wanted. And that is an uncomfortable place to start an episode about AI. We can make the answer faster. We can make the interface friendlier. We can make the slide say transformation.

But did we make the experience better for the person who needed our help? Or did we just make it easier to miss them at scale? Last week, I attended Gartner's IT Symposium in Orlando. There was plenty to think about in the technology.

But today I want to connect three parts of that week: Hospitality. Learning how to keep improving. And being honest about the value and risk of AI. Not a conference highlight reel. Something you can bring back to work.

The question is not just what AI can do next. It is what we need to do differently for people. Quick disclosure before we start. AI-assisted tools were used in parts of the research and production workflow. Final editorial judgment, risk posture, and release approval stayed human-led.

This is operational guidance, not legal advice. These are my opinions and are not representative of any organization. One additional disclosure as the Desk evolves. My current role includes privacy work, so you will hear me pay closer attention to purpose, access, retention, deletion, and accountability.

I will not discuss nonpublic work here. These are my personal views, and they do not represent the State of Oregon or any other organization.

Opening music

Welcome back to AI Change Desk. I am Michael. This is episode fifty-one. Last time, we asked whether the test touched production, and what happened to the people and systems on the receiving end. Today, I want to widen that lens.

Before we add another tool, what kind of experience are we trying to create? What work needs to change? And what do our people need to learn before we ask them to change it? The symposium ran from October nineteenth through the twenty-second.

I am drawing on the sessions in my notes and Gartner's public material checked on October twenty-fifth. I am not going to pretend that a few sessions represent every person at the conference. And I am not going to turn an informal conversation into an industry survey.

These are the connections I want us to examine. The first starts with Will Guidara, and his talk about unreasonable hospitality. He told a story about visitors to his restaurant who had eaten at extraordinary places in New York, but had missed one simple experience: A New York hot dog.

He heard that, arranged for one, and served it as part of their meal. The point was not that every restaurant needs a hot dog cart. It was that an attentive person noticed something the standard experience had not provided.

That is where the story becomes useful for technology leaders. We spend a lot of time designing the service we intend to deliver. We spend less time noticing the experience the other person is actually having. Here is a fictional example.

An employee cannot get into the system they need to finish a time-sensitive task. The assistant finds the correct knowledge article. It sends the link immediately. The interaction is marked resolved. Unfortunately, the instructions require access to the system the employee cannot get into.

The answer is accurate. The experience is a locked door with a beautifully written explanation of the handle. That is not a model problem alone. It is a service-design problem. Somebody needs to ask what successful help looks like from the other side of the conversation.

Can this person complete the task? Do they know what happens next? Can they reach somebody when the normal route fails? Those questions do not become less important because the first response arrives in two seconds. In my notes from Guidara's talk, another detail matters just as much as the hot dog.

Giving people permission to create a better experience was not the same as giving them resources to do it. He described adding support so the team could actually carry those ideas through. That is the part I would bring to an AI planning meeting.

We tell employees to experiment. We tell them to learn. We tell them to challenge the old process. Then we leave their workload exactly where it was. Congratulations. We have launched a learning program whose main resource is somebody else's evening.

Permission is necessary. It is not capacity. If the work matters, give people time, a safe place to practice, access to someone who can help, and a clear route for turning a useful experiment into an approved change.

And there is a privacy boundary here. Making someone feel seen does not mean collecting everything about them. It does not mean inferring personal details so a system can perform intimacy. Sometimes the more respectful design is simpler: Ask what help is needed.

Explain why information is necessary. Give a meaningful choice. Make a human route available when the situation needs one. That is my application of the hospitality lesson, not a claim that a restaurant story solves privacy governance. Good attention is not the same thing as more surveillance.

It also does not mean making every interaction longer. Some people want a quick, reliable answer and then want to get on with their day. We should not make them sit through a performance of warmth before they can reset a password.

The design question is whether the service can respond when the normal route does not fit. Can someone say that the answer did not help? Can they correct a misunderstanding? Can a person with a different access need still complete the task?

For a public service, that matters beyond customer preference. People may not have an alternative provider. So my test would include the person who cannot comfortably use the preferred digital route. Efficiency and care are not opposites. But the efficiency measure has to include the effort we are asking the other person to absorb.

The second connection came from Serena Williams's conversation with Soledad O'Brien. My notes emphasize the difference between reaching a level and continuing to improve once you are there. Learning. Coaching. Adapting. And accepting that being very good at something does not make you finished.

I am taking a leadership lesson from that discussion, not making a prediction about her career. For technology teams, this is more useful than another argument about whether people should be excited or afraid. We need a practice model.

An AI license is not a practice model. A recording of a ninety-minute webinar is also not a practice model. It is a recording. Possibly a very good one. Possibly playing in another tab while someone answers the messages that arrived during training.

Practice means a person tries a specific task, receives usable feedback, and gets another attempt. For an employee using AI to draft a response, the useful skill is not only producing the response. It is recognizing when the available information does not support the answer.

It is noticing when the question itself is wrong. It is knowing when an apparently helpful next step would exceed the person's authority. Those are things we can rehearse. Use an invented request. Give the team an incomplete source.

Ask what can be answered, what must be checked, and what should not be inferred. Then let people compare their reasoning about the task. Not private model reasoning. Their own explanation of what evidence they relied on. The goal is not to reward whoever gets the fastest draft.

It is to build judgment people can use when the answer looks convincing and the situation is not simple. There is a management question hiding in this too. If somebody flags a limitation, does the organization treat that as useful work?

Or does the dashboard make them look slower than the person who accepted the first answer? We cannot ask for careful judgment and then design every incentive around skipping it. Imagine a team learning to prepare a weekly service summary.

In the first practice round, the source includes a request that has been reopened. The draft summary calls it complete. One employee catches that mismatch. The useful response from the coach is not simply, good catch. Ask what made the mismatch visible.

Was the reopened status easy to find? Did the instructions define completion clearly? Would another person have had the same opportunity to notice? Then improve the practice case or the workflow. Otherwise we are depending on the most attentive person to rescue the process every time.

That is not a sustainable staffing strategy. It is a compliment we have accidentally turned into a job description. The person who notices the problem should help us make the next attempt better, not become the permanent workaround.

The third connection is Gartner's public message about managing AI value and risk together. I read that as a challenge to the way we describe progress. More activity is not automatically more useful work. More generated material is not automatically better service.

And a pilot that looks promising does not tell us everything about the cost of operating it. Gartner's October nineteenth release describes a survey of two thousand and two CIOs and technology executives, conducted from May through July.

It reports that only thirteen percent of CIOs said their enterprise had realized significant or transformational AI value. That is a reported assessment, not an independent audit of every organization's results. It does not mean everyone else received no benefit.

It is a reason to ask a more specific question: What changed enough to matter, and how would we know? The opening keynote also connected governance with the way organizations coordinate people, technology and investment. My takeaway is not that every organization needs another committee with a complicated name.

It is that the people making the spending decision need to understand the service decision and the risk decision. Those cannot be three unrelated conversations that meet for the first time after launch. Return to our fictional employee who cannot sign in.

Suppose the assistant has made first responses faster. That is useful information. Now look at the whole experience. Are people completing the task? Are they reopening the request? How much human time goes into correcting the response? Does the assistant ask for information that the task does not need?

If the quick answer sends more work downstream, the improvement may be real in one place and lost somewhere else. That is why I would put the person doing the work, the service owner, and someone responsible for the data boundaries in the same conversation early.

Not to hold a meeting about holding a meeting. To agree on what a better outcome actually is. This is where the themes from the week connect for me. Hospitality asks us to notice the person. Sustained performance asks us to practice and adapt.

Value and risk ask us to be honest about the whole result. That gives us a more useful learning agenda than trying to memorize the name of every new platform. There is a technical side to this, too.

Gartner's published trends for the coming year include AI agent identity and AI context platforms. Those are useful prompts for a practical conversation, not instructions to buy two more things. If an agent acts on someone's behalf, how does its authority fit the particular task?

If it uses organizational context, which information is relevant and permitted for that task? My concern is the distance between a broad product capability and a specific service interaction. A system may be able to search a large collection.

That does not make every item in the collection appropriate for every request. And helping a person draft an answer is different from giving software authority to change their account or send that answer elsewhere. Keep those decisions separate.

The interface can look almost identical while the permission and consequence are very different. That is a useful topic for training, architecture, and privacy teams to work through together. Here are the questions I would put in front of a team.

These are my proposed questions, not a poll of the people I met in Orlando. First, how do we decide which problem deserves AI? Start with a person's task, not with the product we already want to use.

Describe what is hard today. Try to separate a missing-information problem from a broken-process problem. Sometimes the right improvement is a clearer instruction, a changed approval rule, or an ordinary piece of automation. Choosing that is not a failure to innovate.

It is the point of understanding the problem. Second, what does a good human-AI handoff look like? Not just an answer and a confidence-sounding sentence. What information was used? What remains uncertain? What does the next person need to decide?

That connects to the question in episode forty-seven: Does the evidence actually support the decision? We do not need to make this week's episode another tour of every control. We need to make the handoff usable. Third, what must people be able to do before we call them trained?

Give them a realistic but invented task. See whether they can identify an unsupported claim, recognize a sensitive-data boundary, and explain when they would ask for help. Passing that exercise is not proof that they will never make a mistake.

It is better evidence of practice than attendance at an introductory presentation. And fourth, what support makes that learning sustainable? Who has time to coach? What work are we pausing to make room? Where can people bring an awkward result without feeling that they have failed the adoption campaign?

That last question matters. If every report back has to sound like a success story, we are not learning. We are producing internal marketing. Here is the practical step for this week. Pick one service interaction. Not an entire transformation program.

One interaction that regularly leaves somebody confused, waiting, or doing the same work twice. Set aside forty-five minutes with the people who understand that interaction. This is a proposed working session, not a validated assessment or a compliance certification.

For the first ten minutes, describe the experience without mentioning an AI product. Who needs help? What are they trying to finish? Where do they get stuck? Use an invented or appropriately de-identified example. Do not paste a real employee's problem into an unapproved tool to make the exercise more realistic.

For the next ten minutes, draw the current route from request to actual resolution. Include the return trips. Include the person who quietly fixes the answer after the official process says it is done. That invisible work is still work.

For the next ten, try one change on paper. It might be an AI-assisted draft. It might be a better human escalation route. It might be removing a step that nobody can explain anymore. Write down what the change should improve and what must not get worse.

For the final fifteen minutes, decide how a small, authorized trial would work. Who will support the people trying it? What information is permitted? How will they reach a person when they need one? What evidence will tell us to continue, revise, or leave the current process alone?

Do not launch a production change from this exercise. Take the proposal through the approvals that apply to the actual system and data. The output can fit on one page. The person and their need. The change we want to test.

The resources the team will receive. The boundary we will preserve. And the outcome we will check. If all you have at the end is a product name, you are not finished yet. Before you try to scale anything, choose a comparison that matches the real job.

For our fictional access request, that might mean comparing whether people can finish the task, how much help they need, and whether they have to return the next day. Keep the size and limits of the trial visible.

A handful of invented cases can help you find a flaw. They cannot tell you how every user will experience the service. And when you do move to an authorized real-world trial, ask for feedback from the people receiving the service, not only the team proud of building it.

The person presenting the dashboard is not always the person waiting for help. Give both a voice in the result. And resist the temptation to declare victory after the easiest example works. Ask what happens when the request is incomplete, when the usual approver is away, or when the answer is technically correct but the person still cannot proceed.

Those are not inconvenient edge cases to hide from the demonstration. They are candidates for the next practice round. Write down what you learned and what you deliberately did not test. That gives the next team a starting point instead of a polished success story with no usable details.

Sharing the limits is part of sharing the learning. Then use the same discipline on the learning program. Did practice time actually happen? Was someone available to answer questions? Did a difficult example change the design, or did it get parked because it complicated the success story?

That is how the conference becomes something useful after the badge comes off. One change that reaches a person. One lesson that reaches the next attempt. One decision grounded in what happened, instead of what we hoped the tool would do.

I came home from Orlando with technology questions worth following. But this is the connection I want to carry into Monday. We cannot automate our way out of caring what happens to the person at the other end.

We cannot ask people to adapt without giving them time and support. And we cannot call something valuable only because we found a way to produce more of it. Keep the curiosity. Keep testing what the technology makes possible.

But bring the human experience into the design, not just the closing slide. Make the work better for someone. Then check whether you did. This is AI Change Desk. I am Michael. I will see you next week.

Closing music