Frequently Asked Questions About AI Implementation
The questions I hear most, and my honest answers.
Still have questions For Me?
This page answers general questions about my approach to AI implementation.
How I Think About AI
How do you decide whether AI is the right answer?
I look for a spine.
A workflow that benefits from AI is data-driven and follows a recognizable structure, even when the work itself is creative. A marketing brainstorming session is a good example. The output is original — the point is to generate ideas nobody’s had yet — but the process underneath has a rhythm. Once a team finds that rhythm, the model can hold the structure while the people do the thinking.
Repetitive doesn’t mean monotonous. It means there’s a shape you can build from.
What disqualifies a workflow isn’t messiness. It’s the absence of a recommended practice the team agrees on. If one person leads the model through conversation, treating it as a thought partner, and another lets the model drive by asking it what they need first, those two approaches will produce different work — and they’re in conflict from a workflow perspective, even if the outputs look similar on the surface.
The first gets the human’s best ideas before the model can pull from training data. The second leans on what’s already been done.
Both feel reasonable to the people doing them. Neither is wrong in isolation. Together, they make the workflow undefinable.
When I see that, the conversation isn’t about AI yet. It’s about whether the team can agree on a recommended practice. Once they can, we have something to build on. Until they can, we don’t.
What’s the most common mistake you see organizations make with AI?
Treating it as a technology initiative when it’s a change management initiative.
The mistake usually doesn’t look like a mistake at first. Leadership rolls out access, people start experimenting, and the organization counts that as progress. What’s actually happening underneath is that everyone is on a different rung of the same ladder.
Some people are still learning to prompt effectively. Others are already building tools and configuring them for specific tasks. A few haven’t started at all. The uneven ground gets read as momentum because the loudest users are visibly enthusiastic.
Then the gaps start to show. The people further along feel siloed. The people behind feel intimidated or written off. Practices diverge in ways that aren’t reconciled, and by the time leadership notices, the organization has a hodgepodge of habits that have to be un-trained before anything consistent can be built.
That’s the cost of skipping the foundation: not just slow adoption, but adoption debt — work you have to undo before you can do the work you meant to do in the first place.
The fix isn’t slowing experimentation down. It’s giving it a shape. A learning plan, a forum where people share what’s working and what isn’t, hackathons that pull the curious along with the cautious. The technology turns out to be the easier part — most people are already skilled communicators, and once they see that clear prompting produces better results, they pick up the rhythm fast.
The harder part is getting people to learn from each other, especially from each other’s failures. Most professionals have spent careers learning to perform success. Learning to fail your way forward takes rewiring, and that rewiring is what the rollout has to actually support.
What’s the difference between configuring an AI tool and just using one?
Configuration is putting the brain inside the tool.
When I configure a tool, I’m teaching it how I want it to think. That happens through conversation — I work with the model to find out where the boundaries are, where it’s strong, where it’s weaker than I’d like it to be. The goal is to design around what it does well and stay honest about what it doesn’t. Often I’m taking a prompt I’ve used repeatedly because it consistently produces good output, and codifying that approach so we’re not in a perpetual tool rebuilding state.
Using a tool is different. You ask a custom GPT a question. You trigger a skill someone else built. You get a useful output and move on. The tool works, you know how to fire it, but it’s a black box. You don’t know why it works, which means you don’t know what would make it better — or what would tell you it’s quietly getting worse.
The distinction matters because feedback gets less precise the further you are from the build.
Someone who understands how a tool was constructed — what it was designed to do, what constraints shape its behavior — can say with precision: here’s what it isn’t doing that it was designed to do.
Someone who only uses it can usually tell something feels off, but pinpointing what changed and why is a different problem. That gap is the difference between iterating toward a better tool and starting over because you don’t know what to fix.
How do you know when people will actually use what you’ve built?
The truth is, you won’t know until you roll it out.
What you can have is well-grounded confidence, and that comes from how the build was conducted. When the people who own the process are involved in the work — not consulted at the end, but part of the discovery and the development — they bring things to the table I couldn’t see on my own. The critical step that lives in someone’s head and nowhere in the documentation. The edge case that only shows up on the third Tuesday of the month. The reason a previous tool failed. That contribution earns trust in both directions, and it positions some of those people to become the change agents the rollout needs to succeed.
The conditions get read from the outset, while I’m still working to define the workflow:
– Where are my naysayers? Resistance isn’t a problem to suppress; it’s information about what hasn’t been addressed yet, and the sooner I understand it the better.
– Is leadership modeling the behavior they want from their teams, or is that a conversation we still need to have?
– When the early adopters pause to walk through how they’re using a tool, do their practices align with what the recommended practices would be, or are we already drifting toward workflow variations I’d rather catch now?
Sometimes people don’t use what gets built, and they can’t always articulate why. The work I do during the build is partly about creating the conditions for that honesty later — relationships where someone can say I don’t trust this yet or I tried it and it didn’t fit without that being a problem.
Clear communication tends to win the day. And sometimes the answer is that someone simply doesn’t want to adopt, which becomes a decision for leadership rather than a problem to solve through better training.