Why Your AI Transformation Strategy Is Solving the Wrong Problem

Most AI investments don’t fail because the tools are wrong. They fail because the thinking underneath them hasn’t changed.

The tools are advancing fast. The processes, the org structures, the assumptions about how work gets done – less so. And that gap is where AI transformation strategy goes to die.

This is what’s been rattling around since a recent conversation with Ed Ortega, partner at Machine & Folk, an AI strategy and development firm with 20 years of Silicon Valley runs on the board. Ed is one of those rare humans who is fun to be around, relentlessly curious, and brilliant without being the least bit annoying about it. We spoke on a recent episode of Slideshow with Dave Hayward, and it’s a great watch.

When the constraint disappears, most businesses keep the process anyway.
That’s an underlying reason AI transformation so often fails. Not a lack of tools. Not a lack of budget. A lack of willingness, or ability, to question why the process exists in the first place.

To understand why, we need to go way back. I’m going to talk about cars. I’m going to talk about postwar Japan. I promise this is about AI.

In 1950, an obscure American statistician named W. Edwards Deming flew to Tokyo. Japan had just lost a war. Its factories were rubble. Japanese businessmen were desperate, and they turned to Deming to help them rebuild an economy shattered by World War II.

His big idea: stop inspecting for quality at the end of the line. Build quality into the process from the start. Fix problems where they happen, not downstream after they’ve multiplied.

The Japanese took him extremely seriously. Toyota won the Deming Prize in 1965, and its chairman later said: “There is not a day that goes by that I do not think about what Dr. Deming means to our management.”

America, meanwhile, was busy winning the postwar economy and largely ignored him.

Out of Deming’s thinking came the Toyota Production System, and with it, the Andon cord. Every worker on the line could pull it the moment something went wrong. Teammates would swarm, fix the problem at the source, and keep moving. Across Toyota’s plants, that cord was pulled once every few seconds. Stopping constantly made them faster.

The Andon cord

A different kind of rehydrating

Toyota took the plant. Kept almost the entire workforce. Then flew them to Japan in groups of 30 to learn a completely different way of working.

Same people, different results

Same people. Same Fremont. Defect rates dropped to match Toyota’s plants in Japan. And if you want to go deeper on what actually happened, This American Life returned to the story in 2015 with the full picture, it is well worth your time.

That thinking eventually became Kaizen, which informed a 1986 Harvard Business Review article on iterative teams, which directly shaped the Agile Manifesto in 2001. As Beige Media’s breakdown of the Toyota-Agile lineage makes clear, this wasn’t a coincidence. It was a straight line.

Deming. Toyota. Kaizen. Agile. A straight line from a postwar Tokyo lecture hall to your sprint planning. And now we’re here at AI.

In a recent episode of Slideshow with Dave Hayward, Ed Ortega and I watched a tool called Pencil build a fully designed CRM interface from a single prompt. About ten minutes, start to finish.

But the more interesting conversation was about why the designer/developer handoff exists in the first place.

Designers work in vectors. Developers work in code. The briefs, the markups, the JIRA tickets, the “this corner should be 8 pixels, not 4” back-and-forth: none of that was a design decision. It was a constraint. Two different professional languages with no shared ground, and an expensive process built around the gap between them.

Pencil makes design and code the same thing. Ed’s team are already working in this new paradigm, sprinting a straight line while everyone else is jogging a circuitous route.

Ed also walked through a case study where his team automated an enterprise-scale data extraction system. Halfway through, they realised the entire workflow had been built around a human bottleneck that AI had just dissolved. The database structure, the roles, the whole process, all of it was shaped by a limitation that no longer existed. Once they saw it, they couldn’t unsee it.

This liberated knowledge workers from repetitive work that AI, automation, and machine learning are frankly way better at. Now they’re focused on higher-value tasks that are not only more satisfying but also more billable.

Cognitive science is clear on this: every decision, strategic or trivial, draws from the same limited pool of mental energy. When people are freed from work that only existed because of a constraint, you don’t just get time back. You get thinking back.

The ex-GM workers weren’t bad workers. They were good workers trapped in a bad system. Sound familiar?

GM ended up sending their own people to Fremont. They watched the transformation happen with their own workforce. They had every opportunity to take it back to their other plants.

Most of them didn’t. Or couldn’t. The constraint was gone, but the habits, the assumptions, the org structures, all of it stayed.

That’s the real risk with AI transformation strategy right now. The tools are changing fast. The processes, less so.

Dropping an AI tool into a workflow designed around the limitations AI just removed doesn’t transform anything. It just makes the old process slightly faster. And slightly faster is not what the moment calls for.

1. Why does this process exist? Not what it does, why it exists. What was the original constraint it was built around? Is that constraint still there? If AI has dissolved it, the process needs to go with it.

2. What are your people doing that AI is better at? Not to replace them, to free them. The goal is to move human attention toward work that is genuinely human: judgement, relationship, strategy, creativity. The work that is also, not coincidentally, more valuable.

3. Where are you jogging a circuitous route? Look for the handoffs. The markups. The back-and-forth built around two systems that couldn’t talk to each other. Those are your constraints. Those are your opportunities.

The upstream fix is almost always cheaper than the downstream symptom. And in most cases, the upstream fix isn’t a new tool. It’s a new question.

Ed goes deep on all of this in Slideshow with Dave Hayward, Season 2, Episode 2 — including a live CRM build in Pencil, from scratch, while I try to keep my jaw off the floor.

If your AI strategy isn’t landing the way you hoped, it might not be the tools. It might be the process underneath them. Watch or listen to the full episode and see if anything sounds familiar.