AI Transformation Starts With the Change, Not the Technology

I’ve been in some version of this meeting multiple times in the past 40 years. Someone Important walks in, sits down at the head of the table, and says: “We need to do something with AI.”

The room nods … of course we do. We’ve all read the AI Transformation articles, watched the demos, seen the competitors’ press releases. The energy is high and people start talking about tools right away – ChatGPT, Claude, Copilot, maybe something custom. One person mentions a vendor demo they saw last week, while someone else pulls up a pricing page on their laptop.

And nobody – not one person in that room – asks why.

Not “why AI” in the abstract, existential sense, but the practical Why. Why would we do this? What changes for our customers when we succeed? What gets faster, cheaper, or smarter in our operations? What does our business look like on the other side of this, and is that picture compelling enough to justify the disruption we’re about to put our teams through?

I’ve watched this pattern play out with ERP in the ’90s, with internet and e-commerce in the early 2000s, with IoT and smart products a decade later. The technology changes every cycle, but the mistake doesn’t. We jump straight to the what (what tool?, what platform?, what vendor?) and skip the why and the how. Those two questions are where the actual value is created, and it’s where the tough work happens; where the people challenges hide, where the process redesign lurks, and where the team figures out whether this initiative is going to create real value or just generate a passably impressive pilot that nobody adopts.

If you’ve been following the Building Blocks series, you know I think about digital transformation as five interconnected areas – Operations, Customers, Products, Data, and Team. AI touches all five, but it doesn’t necessarily start in any of them. It starts with a decision about what needs to change in your business, and why that change matters. The technology comes after.

The Question Nobody Wants to Answer First

There’s an old framework that’s been kicking around the business world for decades – People, Process, and Technology. I’m not sure who came up with it originally, but I’ve been hearing it referenced with increasing frequency since the late ’90s. It’s a useful little triangle, and the reason it keeps coming back is that it captures a core truth about how organizations actually work. You’ve got the humans doing the work, the methods they follow to do it, and the tools they use along the way. Change one, and you’d better think about the other two.

Here’s the problem, though. Everybody’s comfortable talking about People, Process, and Technology in one of two states. There’s the As-Is – how things work today, with all its familiar frustrations. And there’s the To-Be – the shiny future where everything runs smoothly because we’ve installed The New Thing. Both of those conversations are easy, even comfortable, because you can put them on slides and nod along in meetings without committing to anything.

What almost nobody wants to talk about is the messy, uncomfortable space between those two states. The actual transition. Making change happen across all three legs of that triangle – simultaneously – while the business keeps running and people keep doing their jobs and customers keep expecting things to work. That’s where projects succeed or fail, and it’s where most AI initiatives are going to hit the wall.

Why? Because AI makes this particular trap worse, not better. The technology leg is so visible, so accessible, so cool right now that it pulls all the oxygen out of the room. You can sign up for an AI tool during lunch and have it doing something impressive by 2 PM. That speed is genuinely transformative – but it also creates an illusion that the technology is the change. It isn’t. The technology is the easiest part. The change is what happens to your people’s roles when AI takes over the routine work they’ve been doing for fifteen years. The change is redesigning the process so it actually takes advantage of what AI can do, instead of just bolting AI onto the old process and hoping for magic ¹Automate a mess, and you get an automated mess. The change is figuring out which of your Five Building Blocks – Operations, Customers, Products, Data, Team – actually needs to move, and in what order.

That’s the question nobody wants to answer first. Not “which AI tool should we buy?” but “what specifically needs to change about how we run this business, and are we ready to do the hard work of making that change happen with our people and our processes – not just our technology?”

Four Stops on the Road From “We Should” to “We Did”

So if you don’t start with the technology, where do you start? In my experience, real transformation – the kind that actually sticks and creates measurable value – moves through four stages. I think of them as Inspiration, Art, Science, and Execution. They’re not always neat and sequential (real life rarely is), but they represent genuinely different kinds of work, and understanding which stage you’re in helps you figure out what to do next.

Inspiration is where it begins – and it’s not as fluffy as it sounds. This is the practical act of imagining what’s possible for your specific business. Not what’s possible for Google or Microsoft or the startup that keeps showing up in your LinkedIn feed this week. We really want to find what is possible for you, with your people, your customers, your constraints. The best visions I’ve seen aren’t grandiose – they’re specific enough that you can act on them. “We should be able to quote a custom order in four hours instead of four days.” “Our field techs shouldn’t have to call the office to check inventory.” “We should be able to finish the month and close in five days without killing people’s weekends.”

Here’s where the 80/20 principle earns its keep. I’ve watched too many companies stall out because their AI vision was perfect – perfectly comprehensive, perfectly ambitious, and perfectly impossible to execute in their lifetime. The leaders who get traction are the ones who can look at the full scope of what AI could do for them and say, “That’s all great, but this is the piece we’re going to nail first.” A practical vision knows when enough is enough, and that’s the difference between a strategy and a wish list.

Art is the communication layer – and I use that word deliberately. Taking a practical vision and making it land with the people who have to live inside the change is genuinely creative work. You can run the flashiest AI demo in the world, and it won’t matter if your operations team walks out thinking, “That’s impressive, but I still don’t see how it helps me do my job.” The art is in bridging that gap – finding the words, the examples, the visuals that make someone see themselves in the future state, not as a spectator but as a participant.

This is where a lot of AI initiatives quietly die. The technology demos are easy and impressive and the vendor slides are polished, but nobody’s done the harder work of translating what the AI does into what it means for Maria in accounts receivable or what it changes about how the warehouse team prioritizes their morning. That translation is art, and it takes time, empathy, and usually a few false starts.

Science is where you build something real. Sooner or later, the hand-waving has to stop and somebody has to create something that actually works – a prototype, a proof of concept, a working process that demonstrates the vision isn’t just talk. This has always been true, but what’s changed with AI is the barrier to entry. You don’t need a server room or a six-month development cycle. You need curiosity, some data, and a weekend. (More on that in a minute.)

But the ease of building can be deceptive. I’ve seen plenty of impressive proofs of concept that never made the jump to production because nobody thought about how they’d be maintained, who’d own them, or how they’d scale beyond the one person who built them. Building something that works on your laptop is science, but building something that works for your organization is engineering – they’re related, but they’re not the same thing.

Execution is where rubber meets road – where the process changes, the roles shift, the training happens, and you find out whether the results you promised are actually going to show up. This is the stage most people think of as “the project,” but if you’ve done the first three stages well, execution is less about heroics and more about follow-through. The vision is clear, the communication has landed, the prototype has proven the concept works, and now you’re implementing, measuring, and adjusting.

The leaders who get this right tend to have a particular quality that’s hard to teach: they know when to call for help. There’s real value in being a jack-of-all-trades across these four stages – having enough inspiration to set direction, enough art to communicate it, enough science to evaluate what’s being built, and enough execution discipline to see it through. But you don’t have to be the expert at every stage. You have to be the person who knows when the work has shifted from one stage to the next, and whether you’ve got the right people engaged for what comes next.

A Long Weekend and a Routing App

A friend of mine who does tech consulting with small nonprofits had a familiar problem. His client knew AI was out there, but when Mike sat down with them to talk about it, the conversation kept stalling in the same place: That’s all very interesting, but what would we actually do with it? They couldn’t see the connection between the technology everyone was talking about and the work they did every day.

The nonprofit ran a fleet of drivers – not a huge operation, but complex enough that routing and scheduling was a constant headache. It was one of those problems that everybody worked around and nobody thought of as solvable, because it had always been manual and that’s just how things work here. The kind of thing where someone with fifteen years of experience keeps most of the logic in their head and everybody else just hopes that person doesn’t retire.

Mike didn’t try to sell them on AI as a concept. He didn’t build a slide deck about digital transformation or walk them through vendor comparisons. Instead, he went home and spent a long weekend building a mobile app that handled driver routing. Not a prototype on a whiteboard – a working app their drivers could actually use.

When he showed it to them the following week, the conversation changed completely. This wasn’t a demo of what AI could do someday, in theory, for companies with big IT budgets. This was their routes, their drivers, their problem – and it was solved. The skepticism didn’t just soften; it evaporated, because the proof wasn’t a pitch, it was a working tool in their hands.

I love this story because it illustrates all four stages compressed into a remarkably short timeline. The inspiration was specific and operational – not “let’s use AI” but “let’s fix the routing problem.” The art was Mike’s instinct to skip the explanation and just build the thing, letting the working app communicate what no slide deck could. The science was a weekend of focused building, made possible because AI tools have lowered the barrier to entry so dramatically. And the execution was walking in with something real that people could touch and use immediately.

Ten years ago, that kind of turnaround would have taken months – requirements gathering, vendor selection, development sprints, testing cycles. Mike did it in a long weekend, not because he’s superhuman but because the tools have fundamentally changed what’s possible for someone with the right combination of technical skill and business understanding. That compression is what makes this moment different from every previous technology wave. The gap between “good idea” and “working software” has shrunk to almost nothing.

But here’s the part that matters most: Mike started with the change, not the technology. He didn’t walk in and say “you need AI.” He looked at their operation, found a real problem that was costing them real time and real frustration, and then figured out whether AI could help solve it. The technology was the last decision, not the first one – and that’s exactly why it worked.

Why the Speed Is Dangerous

Mike’s story is exciting, and it should be. But there’s a trap hiding inside it that catches a lot of organizations off guard, and it has to do with the relationship between the three legs of that People, Process, and Technology triangle.

In the old days – and by “old days” I mean basically every technology cycle before this one – the technology leg was the slowest part of the journey. An ERP implementation took eighteen months, sometimes longer. Building a custom application meant months of requirements, development, and testing. That slowness was painful, but it had an unintended benefit: it gave the organization time to get ready. Time to rethink processes. Time to train people. Time to have the difficult conversations about whose job was about to change and how. The technology was the bottleneck, and everything else could (more or less) keep pace.

AI flipped that equation. The technology leg just got radically shorter. Mike built a working app over a long weekend. Your team can have a proof of concept running by Thursday. A department head with some curiosity and an API key can automate a workflow before anyone in leadership knows it’s happening. That speed is genuinely remarkable, but it creates a problem that nobody talks about enough: the people and process legs didn’t get any shorter. They’re still the same messy, human-paced work they’ve always been.

So now you’ve got a gap. The technology races ahead – demo ready, prototype working, results visible – and the organization is still trying to figure out what it means. People haven’t been prepared for how their roles will shift. Processes haven’t been redesigned to take advantage of what the new tool can actually do. The person who built the prototype is the only one who understands it, and they’re already thinking about the next thing. I’ve seen this pattern create a peculiar kind of organizational whiplash, where leadership gets excited by how fast the technology moves, then gets frustrated when the rest of the organization can’t keep up. But the organization isn’t slow – the technology is just unprecedentedly fast, and nobody adjusted their expectations for the human side of the work.

This is why starting with the change matters so much more now than it did even five years ago. When the technology was slow, you could afford to figure out the people and process pieces along the way. You had time. With AI, you don’t have that luxury. If you haven’t thought through the why and the how before someone builds the what, you’ll end up with working technology that nobody’s ready to use – and that’s a more expensive failure than not building it at all, because now you’ve got a tool that works, a team that’s confused, and leadership wondering why the promised results aren’t materializing.

Five Places to Look Before You Look at Technology

So how do you actually do this? When someone walks into that meeting and says “we need to do something with AI,” how do you redirect the conversation from the technology to the change?

I’ve found it helps to have a map. Not a project plan – it’s way too early for that – but a framework for asking better questions about where AI might create real value in your business. That’s what the Five Building Blocks are designed to do. Each one represents a fundamental area of your business, and each one suggests different kinds of change with different implications for your people and your processes.

Operations is usually where the most immediate opportunities live – the daily work of making and delivering whatever your business makes and delivers. This is where Mike found the routing problem. When you look at your operations through an AI lens, the question isn’t “what can AI automate?” It’s “where are our people spending time on work that doesn’t require their judgment, experience, or relationships?” That’s a fundamentally different question, and it leads to fundamentally different conversations about what needs to change.

Customer Connections is about how you find, serve, and keep your customers. AI can do remarkable things here, but only if you understand what’s actually broken or missing in your customer relationships first. If your sales team can’t articulate why customers choose you over the competition, AI isn’t going to figure that out for them. It’ll just help them do the wrong things faster.

Product Intelligence asks whether your products and services are as smart as they could be. For manufacturers, this is where IoT and AI intersect in interesting ways – products that can report on their own condition, predict their own maintenance needs, or adapt to how they’re actually being used. But again, the starting question isn’t about the technology. It’s about what your customers actually need from your products that they’re not getting today.

Data Mastery is the one that underpins everything else. AI runs on data, and most organizations have plenty of it – they just can’t get to it, trust it, or connect it across systems in any useful way. If your team is spending half their time wrestling data out of spreadsheets and legacy systems just to answer basic questions, that’s a change problem that needs to be solved before any AI initiative can deliver on its promises.

And Team Dynamics is the human layer that makes all of it work or not. Do your people understand their jobs well enough to know which parts AI should handle and which parts require human judgment? Do they trust that AI is here to help them, not replace them? Is leadership creating an environment where it’s safe to experiment, fail, learn, and try again? These are the hardest questions on the list, and they’re the ones that most directly determine whether your AI investment creates lasting value or just generates a brief period of excitement followed by a quiet return to the way things were.

The Building Blocks aren’t a checklist – you don’t have to address all five before you can start. But they give you a structured way to ask where the change needs to happen before you start debating how to implement the technology. And that’s the whole point of this article, really. Start with the change.

Where This Goes Next

I’ve been talking about the big picture – the frameworks, the stages, the mindset shift from technology-first to change-first. But frameworks only get you so far. At some point, you have to get specific about the people who are going to live inside the changes you’re planning.

In the next article, we’ll dig into something I’ve been thinking about for years, long before AI made it urgent: the difference between people who know their jobs and people who truly understand them. That distinction has always mattered, but AI is about to make it matter a lot more – and if you’re leading a team through an AI transformation, it’s the single most important thing to get right about your people.

Because the change doesn’t start with the technology, and it doesn’t start with the process either. It starts with the people. It always has.

If you’re working through how to lead AI into your business and want practical frameworks – not vendor hype – join our mailing list for the rest of this series and more.