Takeaways from the Snowpal Podcast with Trehan Stenton, founder of AI Integration Partner
Most organizations have already tried AI. They’ve drafted emails with ChatGPT, built slides with Claude, and maybe run a pilot or two. Many of those pilots quietly stalled. In this episode of the Snowpal Podcast, Krish talks with Trehan Stenton, who helps multi-location and growing businesses turn strategy into process and then uses AI and change management to make those changes stick. His main argument: when AI implementations fail, the tool is rarely the cause. The usual causes are unclear processes, messy data, missing governance, and people who were never told why the change is happening.
Podcast
The Human Side of AI: Leading Change That Lasts — on Apple and Spotify.
1. Why pilots fail
Trehan cites research estimating that about 95% of AI pilots fail. In his experience, the causes are consistent:
The expected results are unrealistic. Leadership treats AI as a fix for the whole organization, but it can’t be one.
The rollout moves faster than people can absorb it. An excited CEO pushes AI down the org chart, and middle managers are left unsure how to apply it.
The tools sit on broken processes. If the process underneath is incomplete, the data is dirty, or information is spread across systems, the model gives wrong answers. Automating a mess makes the mess bigger.
People stop trusting it. One bad answer (”I tried Claude and it was completely wrong”) turns into resistance to every AI tool that comes after.
His key distinction is that using AI as a personal assistant and using it inside business workflows are different disciplines. Writing emails and slides needs no governance. Automating workflows and deploying agents need defined requirements, success metrics, exception handling, and a governance model.
2. Case study: two AI rollouts in dentistry
Trehan has a healthcare background and offers two examples from dental practices. They show that the same kind of technology can fail or succeed depending on how it’s introduced.
AI radiography: what went wrong, then what fixed it
AI-assisted radiograph analysis marks likely decay, recession, and cracks on the image, which helps both the clinician and the patient see the problem. The first rollout struggled:
Clinicians weren’t told how the model reaches its conclusions, so they didn’t trust it.
Nobody explained that the system has to be trained with feedback, the same way a new dental assistant isn’t fully capable on day one.
Distrust of this one tool spread into resistance to AI tools in general.
The fix was mostly about positioning. The tool was reintroduced as a “second opinion.” The clinician is still the primary decision-maker, and the AI adds another view. After that change, adoption picked up quickly.
Ambient transcription: success from the first day
Ambient AI scribes record the clinical conversation (in a HIPAA-compliant way) and draft notes and treatment outcomes. This rollout worked from the start because it:
Started small with one group of users, the hygienists.
Delivered an obvious benefit right away: about 10 minutes saved per hour on writing notes.
Kept a human reviewing the output. Hygienists checked the notes before they went into the system.
Posed a low threat to clinicians’ professional identity. It took over a chore and left their judgment alone.
Pattern to reuse: choose first use cases that are high-benefit, low-risk, and low ego-impact. They produce people who will advocate for the next rollout.
3. Process first: a framework for implementation
Trehan jokes that his advice is always “boring,” but the order of steps matters:
Start with why. Leadership states the direction and the reasons behind it, so the team understands the change instead of seeing it as a threat.
Set priorities. Decide what the effort is for: efficiency, revenue, or customer experience.
Map the core processes. Document how work actually gets done today, including where the bottlenecks are.
Redesign the processes, don’t just speed them up. She cites research finding that only about 35% of organizations implementing AI actually redesign the underlying process. The rest try to make a five-year-old workflow run faster.
Clean the data and plan for exceptions. Models are only as good as the data and edge-case handling underneath them.
Apply tools to specific areas, at specific times, for specific outputs. Avoid broad multi-department transformations.
Define failure along with success. Run a time-boxed trial (for example, three months) with clear kill criteria, so a failing initiative gets shut down and replaced instead of lingering.
Build on small wins. Each quick win makes people more willing to accept the next change.
4. Governance and the cost of letting everyone experiment
Without governance, broad access to AI burns budget without producing results. Trehan mentions a report that Uber employees used about three months’ worth of tokens in one week after the company opened generative AI to everyone, with little to show for it.
Governance also covers accountability. Directors and boards are still responsible for decisions made in the business, whether a person or a model produced them. Trehan points to the case where an airline argued that its customer-service chatbot was effectively a separate entity. The court disagreed: the bot belongs to the company, so its decisions are the company’s responsibility. In legal and regulated settings especially, “the model told me” is not an audit trail.
Questions every AI program should be able to answer:
Is the organization aligned on direction and priorities?
Does the governance model keep up with how fast decisions are now being made?
Where does risk sit in each automated process, and who owns it?
What is the budget for tokens and compute, and how is usage monitored?
5. The real cost of an AI-assisted role
Krish raises a practical question that many startups now face. The cost of getting work done is no longer just salary:
Total cost of output = Human cost + AI cost (tokens, models, tooling)
Take two extremes for an engineering role:
Trehan’s answer: it depends on the process, but he would pay more for someone with a curious, questioning mind. His reasoning is that cheap labor producing AI output still needs an expensive person to validate it. When she builds agents for a manufacturing client, she wants a strong analyst who can question the numbers, understand what they mean for the business, and make recommendations, not someone who just generates answers.
The cost that gets overlooked is validation. If nobody on the team can tell whether an output is correct, the AI spend is wasted.
6. Discernment: knowing when to stop thinking and when not to
The word that comes up most in the conversation is discernment. AI can get a task about 90% of the way done. The remaining 10%, which includes judgment, reasoning, and context, is where people add value. Because AI speeds up decisions, organizations have to deliberately protect time for that judgment.
Krish describes the tension from an engineer’s point of view:
When to delegate: if Claude or Cursor can do the work, he lets it, then reviews, adjusts, and merges.
When not to: sometimes delegating made him slower on problems he has solved many times before, because the tool “sent him on a wild goose chase.”
Both hosts gave examples of AI not saving time. Trehan gave up on having AI build a presentation slide and made it himself in PowerPoint. Snowpal set aside two four-hour sessions to generate course images with ChatGPT instead of Canva, and after all the back-and-forth it took the same time. The images may have been better, but no time was saved.
Krish compares this to mental math. Calculators exist, but when he sets a stop-loss on a day trade, working out 1.6% in his head is faster than reaching for a tool. If you hand off every skill you have, you stop being different from anyone else using the same tools.
Trehan takes this further: value is shifting from IQ to EQ. That means noticing when a P&L looks wrong before running it through a model, sensing problems inside an organization, and explaining a vision clearly. These are the soft skills that make good leaders, and they are becoming more valuable as everyone else focuses on hard outputs.
7. What this means for software engineers
Asked how developers should adapt, Krish, who has built software for over 20 years, makes several points:
The pace of change is what’s new. Software has always changed; now it changes much faster. What worked a month ago may not work today.
Programming languages matter less. Snowpal has always used several languages and stacks. With current tools, the specific language or framework matters much less than knowing how to approach and architect an engineering problem so it scales and lasts.
Consistency is the new hard problem. Checking that generated code works is fairly easy. You can even test it with other code-generation tools. Keeping code from several AI tools consistent with the rest of the codebase is harder. Without that discipline, the result looks like a thousand developers each contributing in their own style.
Engineers still own production. When something breaks, AI will help find the bug, but the engineer needs to understand the codebase and how it grew: which tools generated which parts, how contributions were made, and how deployments run.
Structural decisions still need people. Monorepo or polyrepo, how the team is organized, how contributions and deployments flow: these are still engineering leadership decisions.
Being comfortable with constant change is a core skill. Expect something to be significantly different every week.
Trehan adds that specialists increasingly need to work like generalists. They should understand the upstream and downstream effects of a change, how it affects the customer journey, and how it connects to other parts of the business.
8. The consultant’s changing role
Both the client and the consultant now have access to ChatGPT, Claude, and Cursor. So why hire outside help? Trehan’s answer:
Time and follow-through. Clients often have ideas but not the bandwidth to finish them while running the business. Consultants commit to timelines, measurement, and outcomes.
An outside view. Clients tend to think about processes in terms of how they’ve always done them. Consultants bring patterns from across the industry.
Transparency. Be open about when and how AI is used to produce deliverables.
Teaching the client. Build the methodology into the client’s team, such as documenting processes and finding bottlenecks, so they can keep going on their own.
Pricing on outcomes instead of hours. Tie fees to efficiency gains, revenue, or acquisitions delivered, rather than billable hours or documents.
9. Workforce and global perspective
On jobs, the conversation is candid. Trehan notes that many corporate layoffs are driven by share price as much as by AI. Still, as a small-business operator she now asks “hire or automate?” and has found that growing the business 4x no longer means growing headcount 4x. Back-office work such as accounting is an obvious target for automation. Commoditized offshore work is at real risk, and some of that capacity may move toward quality assurance.
His view is that AI is revolutionary in what it can do but will be evolutionary in how it rolls out, similar to the printing press or the early internet, when “SeniorNet” classes taught people how to get online. Adoption will be uneven, even within a single neighborhood.
On global competition, she describes New Zealand’s “number 8 wire” mindset: the idea that you can fix anything with basic fencing wire and ingenuity. Smaller countries and companies can iterate faster in niche markets (Xero is a New Zealand example). AI helps level the field further because meaningful products no longer need large teams.
Key takeaways
Fix the process before adding AI. Automating a broken workflow makes it worse.
Start small, choose low-ego use cases, and show value quickly. Ambient transcription succeeded where radiography first struggled.
Position AI as a second opinion, and explain how it works and how it learns.
Define failure and set kill criteria up front.
Govern token usage and accountability. The organization owns its bots’ decisions.
Budget for validation. Total cost = people + tokens + review.
Protect discernment. Delegate what the tool does well and keep the skills that set you apart.
For engineers: architecture, consistency across the codebase, and comfort with constant change matter more than any single language.
As Trehan put it at the end: “We’re only limited by the questions that we can ask.”
Statistics mentioned in the episode (95% pilot failure rate, 35% process redesign, 65% wage premium for AI roles, the Uber token figure) are as cited by the guest and have not been independently verified here.
