Embrace the AI Pain: Why Real Transformation Hurts (and Why It’s Worth It)
Key Takeaways
- AI transformation is not just about tools — it’s about systems
- The “messy middle” of actually integrating AI is where most teams struggle
- AI adoption feels like regression before progress
- The true value comes from revisiting and clarifying work
- Success comes to teams who expect the pain — and work through it
We talk a lot about AI in the context of productivity. Doing more with fewer people, faster cycles, fewer errors. The narrative is all about scale and speed. And sometimes the conversation veers toward the existential: What happens to human work when machines can think?
What’s missing is the middle. It’s not called the “Messy Middle” for nothing: the discomfort where teams are actually trying to apply AI across their daily workflows.
I’m not talking about pilots or POC’s here, but rather, at-scale applications.
That part is uncomfortable. It’s frustrating. Especially for teams that already know what they’re doing.
If you’re an enterprise team incorporating AI, you’re likely feeling this.
We want to explore this deeply and loudly because this is the part that matters most, because this is where we usually give up.
If we want to truly embrace AI so that it can make a meaningful difference we need to survive this middle and come out on the other side.
Scaling AI Requires More Than Technology — It Requires Org Design
Insight Teams are already experimenting with personal assistants like ChatGPT or Perplexity. Some have started prototyping small automations. A few have even run pilots that seem promising.
The trouble starts when you try to scale.
We’ve seen this play out repeatedly: teams excited about AI begin with a strong push, a sandbox to get something working. We start with a task that feels relatively contained. Something like standardizing field briefs, or automating top-line summaries, or making old research searchable through natural language.
It makes sense. It seems achievable. It seems like a safe place to start.
Then they get into it at scale.
Teams realize the briefs are inconsistent. That even when they have templates, no two people use them the same way. That key information often comes in follow-up emails, or phone calls, or Slack threads. That the tone, structure, and priorities change based on who the client is, who the project lead is, and what’s happening that week.
Nothing is broken. But nothing is standardized either.
So the first version of the AI output feels off. Not wrong, but not right either. It misses nuance. It over or under explains. It doesn’t reflect the team's judgment.
What often follows is a familiar set of reactions:
- Blame the model
- Assume the use case was flawed
- Move AI back into the lab
- Double down on manual oversight
- Delay the rollout
So at this point, the instinct is to retreat. Either to simplify the AI’s scope or to reframe the problem so it feels like a tech limitation.
But it's actually not just about the tech. It’s something deeper and far more fundamental that’s really needed to unlock this transition successfully.
So let’s step back.
What does it actually mean to implement AI inside teams?
A lot of us think that logging into ChatGPT or using Claude and asking questions means we use AI.
Well, it does, in a sense, but Enterprise-wide AI application is a completely different game. Because it’s not about one person using an assistant. We are now talking about systems that need to work with repeatable consistency, autonomy and agency.
And when we extend our assumptions from consumer use to enterprise workflows, we make the mistake of thinking AI will just plug in. That the structure of work can stay intact while AI quietly handles tasks in the background. In practice, this almost never holds.
Here’s where you might interject that this is the exact reason for doing a sandbox. Fair enough!
In early phases, everything is tightly scoped. A specific team. A single task. A supportive context. There’s an excitement around possibility, and enough attention to handhold through edge cases. And so the pilot works.
But when we scale, the same AI system that performed well in one team is producing inconsistent results in another. The same prompt produces different outputs. The same process drags in one context and moves quickly in another. It starts to feel like the system doesn’t understand how the organization works.
But the deeper issue is that the organization doesn’t understand how it works either.
What I mean by that is that AI demands a level of clarity from systems that were never built to be that explicit. This part gets missed because we over-index on pilot success.
What AI reveals sometimes brutally is just how many of our workflows aren’t designed. They’re inherited, patchworked and evolved. They’re built on top of legacy processes. Interpreted differently across teams. Maintained through habit rather than deliberate intention.
The Messy Middle of AI Transformation: Why Pilots Don’t Prepare You for Scaling AI
Take something as simple as writing a research summary.
One team might expect toplines only; another might want themes, verbatims, recommendations. One researcher relies on templates, another on instinct.
Everyone knows their own way, but no one has articulated what “done” actually looks like.
Until you try to automate it, and realize there’s no single definition to give the system. And now, in order to use AI, teams have to do the hard work of imposing clarity on something that wasn’t designed to be clear.
So the honest truth is that you're not going to be able to effectively integrate AI into your processes without revisiting the process themselves. Because most enterprise workflows were never built cleanly to begin with.
They grew over time. They rely on habit, context, and unspoken rules.
The person writing the report knows the audience. The analyst knows which numbers to highlight because they’ve done it a hundred times. The researcher adjusts tone and phrasing depending on who’s going to read it.
None of this is written down. And now suddenly, the AI needs to be taught.
Most teams have built efficient, if informal, ways of working. They know what needs to be done and how to get it out the door. They don’t always document it, and they don’t need to, because the same people have been doing it for years.
When you try to introduce AI into that system, all of those invisible rules and handoffs suddenly matter.
You realise that a task that looks simple on the surface like generating a summary or preparing a report actually contains a lot of small, judgment-heavy steps.
Things no one has written down because they’ve never had to.
Now they do. Because the AI won’t just figure it out.
Someone has to tell it what matters, what doesn’t, and in what order things should happen. And very quickly, that exercise reveals just how much of the team’s knowledge is undocumented. Because their way of working has never needed to be explained to an outsider.
This is what slows everything down.
Not the tool. Not the model.
The fact that to use it properly, teams are being asked to do something they haven’t done before: make their work explainable. That takes time. And patience. And a willingness to sit with the discomfort of feeling less productive for a while.
You realise quickly that what seemed like a small automation project requires a full teardown of your process. You find naming inconsistencies. You find duplicate work. You find that no one can agree on what “final” even means. You need to now gain better alignment. You need to document the logic that’s been sitting inside people’s heads for years.
And you will hear this again and again “This was faster when we just did it ourselves.”
That’s the messy middle. And no one’s selling that part.
It will feel like regression.
It might also mean rethinking ownership entirely. In a world where AI can do parts of the work, the value of human contribution shifts. Who’s responsible for the final output? Who trains the system? Who decides what gets reused?
These aren’t operational tweaks. They’re changes to how decisions are made, how work is valued, and how people collaborate. They require negotiation, not implementation. And they take time.
This is also why pilots don’t prepare organizations for scale. Pilots happen in protected environments. They don’t account for team-level drift, handover mismatches, or the soft coordination layers that keep things moving in the real world.
When AI is asked to perform in that mess, it fails. More importantly, it reflects and mirrors the org back to itself. And most teams don’t like what they see.
Yes, Scaling AI Feels Like Going Backwards: Here’s Why It’s Worth It
Organizations that avoid this work don’t avoid the cost. They just spread it out across frustrated teams, patchwork fixes, and AI systems that quietly drift out of use. Remember Insight Debt?
So yes, AI adoption feels like regression. Because in a way, it is.
- You slow down.
- You ask basic questions.
- You re-document things that “everyone already knows.”
- You spend more time defining the work than doing it.
What we’ve seen over and over is that the teams who turn back at this point end up keeping AI at the edges. As an assistant. As an experiment. As a slide in the strategy deck. But never as a real part of the system.
But taking this step back isn’t wasted effort. It's an investment. You’re building infrastructure that supports better decisions, better reuse, and better collaboration.
The real ROI doesn’t show up in the pilot. It shows up in what you had to fix in order to scale.
And the teams that get there aren’t the ones who avoided the pain. They’re the ones who expected it and got to work anyway.
Slowly, they begin to define standards. They figure out what “good” actually means in a given task. They realize which steps can be automated and which still need a human in the loop. They discover just how much variation exists in their current processes, and they decide intentionally what to keep and what to change.
This is the hard part of AI adoption that needs to be acknowledged: the process of making your own work legible to a system that doesn’t know your context.
And in doing that, you’re possibly rebuilding the way your team functions.
- You start to build better documentation.
- You start capturing not just outputs, but how those outputs were made.
- You stop relying on tribal knowledge and start creating shared, portable logic.
- And you create workflows that scale not because you have a good model, but because they’re finally designed with intent.
You will still hit limits. Some tasks genuinely aren’t ready to be automated. Some rely too much on soft cues, on gut instinct, on things that don’t make sense to encode.
But even then, you now know that with clarity. You’re making the choice consciously, not defaulting into it.
That clarity outlasts any one model. It’s what gives you flexibility. It’s what lets you iterate. It’s what turns AI from a prototype into part of your infrastructure.
Final Word: Embrace the Discomfort
So if you are keen on transforming your teams with AI, get into it expecting the pain, and even embracing it.
Because AI breaks muscle memory, automation will highlight flaws in existing systems, and early outputs will feel underwhelming.
And that's the point. You're teaching, iterating, and building scaffolds for long-term change.
Want to know how ready your team is to scale AI?
Take our free AI Readiness Assessment for Insight Teams to benchmark where you stand.
