The post-mortem nobody does
When an AI initiative stalls, the explanation is almost always one of three things: the technology wasn't ready, the change management wasn't thorough enough, or the organization wasn't mature enough. I've been in enough of these post-mortems to know that these answers are usually right and almost always incomplete. They point at symptoms. The actual cause tends to be something simpler and harder to fix: nobody designed the conditions that would have made the change stick.
What under-structuring actually looks like
In practice, it looks like this. The AI tool is deployed. The training is done. People know how to use it. And then nothing changes, because nobody asked who was accountable for AI adoption on each team, where the time was supposed to come from to experiment, what should happen when the AI recommendation contradicted the manager's instinct, or how the learning was supposed to travel across the organization. These aren't exotic questions. But in most transformations, they haven't been answered. And absence of answers means the default kicks in, which is usually just the old way of working with a new tool on top.
The pilot problem
Pilots work because they're exceptional. They get the best people, protected time, executive attention, and freedom from the usual organizational drag. Then the pilot succeeds and the organization tries to scale it. Same tool, different conditions. The people running the scaled version don't have the same mandate or motivation. The managers aren't shielding them from competing priorities. The governance structures that supported the pilot don't exist at scale. The technology is identical. Everything else has changed. This is why so many AI transformations have a portfolio of successful pilots and very little actual transformation.
What structural design actually involves
It means making explicit decisions about accountability, time, collaboration, and governance before you deploy. Who owns AI adoption on this team? How much time per week is protected for experimentation? When a data team and a domain team disagree about an output, how does that get resolved? What does good AI use actually look like here, and how will we know it when we see it? These decisions aren't glamorous. They don't make for compelling board presentations. But they're the difference between a transformation that compounds and one that reverts.
The honest question
If your AI transformation has stalled, the question worth asking isn't what you need to do differently. It's what conditions are missing that would make the right behaviors feel natural rather than forced. In my experience, the answer is almost always some version of: the structural foundations weren't built before the change was expected to happen.