I run a team of Business Analysis, Developers, ServiceNow Specialists amongst other professionals. Over the past nine months, I have spent a great deal of time helping my team learn how to use artificial intelligence. When I look back, however, I do not think the real story is about teaching people how to write prompts or install a new tool.
It is about changing how people approach work.
Our team supports a complex technology environment for a particular states IT Shared Services. We work across ServiceNow, IT financial management, enterprise data, operations management, reporting, transition activities, and contractual deliverables. We are the Multi Sourcing Integrator meaning that we provide the work flow engine which all other providers use to deliver IT services to state agencies. Much of that work involves large volumes of data, complicated processes, manual validation, and documentation that must be accurate. Everything could be audited, this is the government.
That made our environment an ideal place for AI, but not necessarily an easy one.
Some people were excited. Others were skeptical. Some believed AI was only useful for developers. Others had tried Copilot, received a poor answer, and concluded that the technology was not ready. There were also legitimate concerns about security, cost, hallucinations, and what AI might mean for people’s roles. One manager was so skeptical that he started having his team document EVERY “hallucination”. That exercise actually clued me into how the “perception” of a prompt was so far away from the reality of using a tool.
My approach evolved into four basic principles:
- Start with real work.
- Remove the barriers to experimentation.
- Build a community of practitioners.
- Never outsource human understanding.
Start with a problem people already have
One of the earliest lessons was that leading with the technology does not work. Telling someone that AI is “the future” is far less persuasive than showing them how to solve a problem that has frustrated them for weeks.
Early in the year, I developed a phased adoption approach for our ServiceNow team. The idea was not to tell Flow Designer (ServiceNow Low code) users that they needed to become programmers. It was to show them that AI could document inherited flows, explain unfamiliar logic, generate difficult script steps, troubleshoot failed triggers, and help with the work that Flow Designer could not easily perform.
My working model began with browser-based AI for low-friction tasks, then progressed to AI-assisted scripting, Claude Code, and eventually Git-based collaboration. The training concept emphasized optional lunch-and-learn sessions, live demonstrations using real problems, hands-on experimentation, and time for people to voice concerns. The message was simple: this can save you time and help you get unstuck faster. The time you save on toil, can be used for things that are interesting and helpful.
That framing mattered. AI was not positioned as a replacement for someone’s existing skills. It was positioned as a way to extend those skills.
I found that showing was much more effective. One of the most effective ways is to show people that their experience and knowledge can’t be replaced. My step by step is have them outline a problem. Place data in a folder and have start a chat session (prompt) with Claude Code UI (Codex, PI or OpenCode). I have the SME “chat” by describing the problem, the data and the outcome they are looking for. When the prompt comes back with questions, I have the person answer them. Once the output is given, I tell the SME to prompt it to “write this to an HTML file”. The big ah ha moment is when I say “That means absolutely nothing to me because I am not the SME. Does it mean something to you?” I follow up with “See, AI can’t replace your taste, your knowledge and WHAT good looks like. AI is your tool to spend more time on the things you like.”
Demonstration was more effective than explanation
I learned quickly that the best form of AI evangelism is a live demonstration.
During an internal Service Level Resource Touchpoint meeting, the team was discussing how to validate Service Level Agreement calculations across a large number of scenarios. The process involved people comparing results, performing calculations, logging defects, and collecting evidence. The logic was contained in xls with macros and a little VB script someone wrote years prior. Basically, dump data from ServiceNow, import it to a template. Hit run then do a ton of manual verifications. The complicated SLAs required 3 + hours each to validate. We did the first on a prior validated SLA for the prior month to show the output was correct. Then we did it to an SLA that was pending validation. The method proved correct. One team member said, “What am I going to do now that this only takes seconds?” My response was, “Now you can actually get into the algorithms of the SLA. You can begin to identify risk versus SLA. You can identify SLAs that are bogus because they never get triggered. I need your experience, not an excel jockey”.
Instead of treating that as an unavoidable manual exercise, I described how an AI-assisted test harness could interpret the calculation logic, run validations across the entire data set, save the anomalies, and support repeatable testing. I also explained the agentic workflow I was using: plan the work, refine the plan, execute, build tests into the solution, and have the agent continue working through failures. While /plan is good, I really like /grill-me from Matt Pocock.
That same conversation turned into an impromptu demonstration of an AI-generated presentation tool I had built between meetings. I HATE PowerPoint and I find HTML much more friendly. The important part was not the presentation generator itself. It was that the team could see someone using AI to create a functioning solution, not merely talking about what might be possible.
Other demonstrations became equally practical. I showed team members how AI could analyze differences between ITOM and SAM Pro data structures, process tens of thousands of CSV rows, create workflow diagrams, extract logic from Excel workbooks, and transform PowerPoint files into formats that were easier for AI to analyze.
Once people saw those examples, the discussion changed from “Why would I use this?” to “Could it also help me with this other problem?”
That is the moment when evangelism turns into adoption.
Access is part of adoption
Enthusiasm means little if people cannot get through the front door.
A significant part of my effort was not glamorous. It involved pursuing approvals, evaluating licensing approaches, obtaining API access, configuring Claude Code, dealing with Zscaler restrictions, working through SSO issues, and helping people understand which tools were approved for which circumstances.
In June, I notified a cross-functional group that they had been granted Claude.ai access, that they had been added to a whitelisted group, and that they should begin the onboarding process. The responses showed that teams were already considering how to make AI part of their standard work, automate repetitive activities, and identify actionable insights for the state and the service providers.
Access problems did not end with the invitation. People encountered delayed provisioning, login errors, API-key issues, browser limitations, and security controls. I spent time troubleshooting those problems and finding the right support channels.
In another working session, I decided to allocate Claude Teams seats, upgrade heavy users based on actual demand, whitelist Claude.ai through Zscaler and SSO, and use Claude for specific automations and workflow diagrams. The same session included hands-on coaching about document formats, Python notebooks, AI skills, and converting source material into forms that agents could process more effectively.
This taught me an important lesson: access, onboarding, and technical support are not administrative tasks surrounding adoption. They are adoption.
Create a community, not a dependency
I did not want to become the person everyone had to call before using AI. Being the Account Executive means I have a ton of people, processes that depend on me making decisions and being avaiable, that can't be put on a back burner.
We created informal practitioner groups where people shared installation guidance, tested models, discussed prompts, compared costs, and helped one another troubleshoot. The “Claude Code user group” grew into conversations about commands, context windows, agent teams, operating-system troubleshooting, and how to apply the tools to EDM, IT Financial Management, Databricks, ServiceNow, and Apptio work.
The community began to sustain itself. Team members offered to help colleagues install Claude Code, configure endpoints, manage context, and work through GitHub integration. They shared the Claude Code install guide PDFs, exchanged setup instructions, and began generating their own use cases.
We also started moving from individual experimentation toward shared ways of working. In one Teams discussion, I guided colleagues through a collaborative OneDrive and Claude workflow. The team could work from the same data set, store decisions in Markdown, preserve historical context, and build individual dashboards without changing the standard report.
A later working document captured the next step: Claude-based training for GitHub setup and credential management, using private repositories, encouraging branches for collaboration, and making code maintainable by others rather than leaving it on an individual machine.
The lesson was that AI adoption becomes durable when knowledge moves sideways through a team, rather than only downward from a leader.
Match the tool to the work
Another part of my evangelism was helping people move beyond the idea that there is one universal AI tool.
I encouraged the team to use Microsoft 365 Copilot for enterprise-grounded work such as email, meetings, files, and Facilitator, while using Claude for deeper reasoning, coding, large transformations, and agentic workflows. I often moved between the two tools, including using Copilot to develop or improve a prompt that I would then use in Claude.
This was not about declaring a single winner. It was about understanding the strengths of each tool and selecting the right one for the task.
The goal was not “Claude first” or “Copilot first” in every situation. The goal was to develop an AI-first reflex: before beginning hours of repetitive or analytical work, pause and ask whether an AI-assisted approach could produce a faster, more reliable, or more reusable result.
AI adoption without accountability is dangerous
The most important part of my message was also the least promotional: AI output must be verified.
Our team deals with contract language, SLA calculations, customer communications, root-cause analysis, and executive decisions. An answer that sounds correct but is not grounded in evidence can damage credibility very quickly.
The SLM team created an AI Defect - Hallucinations log.xlsx and adopted an “augment, don’t decide” principle. AI-created material needed to be traceable to contracts, tickets, metrics, or documented decisions. The guidance emphasized using AI for structure, grammar, summarization, and first drafts while requiring human and subject-matter-expert validation.
I reinforced that point directly when a a person on my team sent a detailed AI-generated recommendation without fully understanding one of its central terms. The customer/stake holder asked “What does “Hybrid Predicate” mean” and his response was “I don’t know, Claude did that”. This was egg on the face and I quickly had to create a policy stating that every individual will be held account for what they put in front of a customer regardless of how it was generated. “No cut and paste AI Slop is allowed”. In a subsequent communication to the team, I called it “The Magic Box” and my feedback was that everyone must read and understand what AI creates for them. AI can teach us, answer follow-up questions, and accelerate our learning, but it cannot take responsibility for what we communicate.
My rule became straightforward:
Never present AI’s confidence as your own understanding.
That principle helped balance enthusiasm with responsibility. I wanted people to experiment aggressively, but I also wanted them to protect their credibility, our contractual obligations, and the trust placed in our team.
What I would do differently
Looking back, I probably pushed too hard at times. Urgency can motivate early adopters, but it can also make hesitant users feel that something is being done to them rather than with them.
If I were beginning again, I would formalize the volunteer pilot model earlier. I would select a curious user, someone facing a recurring operational problem, and a constructive skeptic. I would capture their before-and-after stories, measure the time saved, and let those practitioners present the results to their peers.
I would also introduce the quality and verification standards at the beginning, rather than after people had already experienced disappointing outputs.
Most importantly, I would spend even more time connecting AI to the individual’s work. People do not adopt a tool because leadership says it is transformative. They adopt it because it helps them finish something, understand something, or accomplish something they could not easily do before. I heard a quote on Lenny’s Podcast from an A16Z partner. He said “People don’t want to save time, they want to spend more time” and this should help shape the approach of “This helps you spend MORE time on the cool stuff and less time on the toil stuff”.
The real measure of evangelism
The strongest evidence of success was not the number of licenses issued or tools installed.
It was hearing team members discuss which model was appropriate for a task, help one another configure tools, propose their own automations, place work in shared repositories, and question whether a manual process still made sense.
That is when AI stopped being my initiative and started becoming part of how the team worked.
In the end, I did not evangelize AI by telling people to believe in it. I evangelized it by showing the work, clearing the path, creating a community, and holding everyone, including myself, accountable for the result.
The technology created the opportunity.
The people created the change.
