Organizational learning is supposed to be how we get better over time. Here’s why we keep skipping it — and what AI reveals about that failure.
I’ve been the person who knew better.
Not once. More than once. You have data. You have a model. You have something that genuinely works, that you’ve tested, that you believe in. And you walk into a room with the business and you expect the quality of the thing to do the persuasion work. Because it’s good. Because you can see what it will do for them. Because if they just understood it the way you understand it, they’d want it too.
It almost never works that way.
The business isn’t wrong to resist. They have a roadmap. They have commitments. They have things they’re already behind on. You’re asking them to absorb something new, change how they work, take on risk, and trust that the upside you’re describing will actually materialize. The idea being good doesn’t answer any of those questions. It just asks them to take your word for it.
I’ve watched this pattern play out more times than I can count — in myself, in colleagues, across organizations. Someone builds something they believe in, takes it to the business, gets a lukewarm response or an outright no, adjusts the what, and tries again. New idea, same method. The next version is better. The pitch is cleaner. The deck has more data. And it fails for the same reason the first one did, because the method didn’t change, only the artifact.
The question that would have helped — and almost never gets asked — is this: based on what has and hasn’t worked before, what does successful adoption actually look like here, and what’s the path to get there?
That’s not a question about the idea. It’s a question about the method. And it requires looking back at your own history before you move forward.
We don’t do that. Not consistently. Not structurally. We survive the last failure, close the chapter, and start the next project with conviction instead of context.
The Pageantry of the Post-Mortem
When something goes badly enough that it demands acknowledgment, we have rituals for it. The retrospective. The lessons learned document. The post-mortem that produces action items nobody looks at again.
I’ve sat in those rooms. There’s a specific energy to a post-mortem that’s being performed rather than practiced. Everyone agrees on what went wrong. The right language gets used. The document gets written. And then the next project starts and nobody opens it. Nobody asks: have we seen this before? Nobody maps the current situation against the last one.
The lesson learned becomes a historical artifact rather than an operational input.
I’ve watched senior leaders run the same failing initiative multiple times — different team, different framing, different artifact — because the diagnosis from the last attempt never got applied to the next one. The what kept changing. The how never did. The loop ran for years.
Nobody was malicious. Nobody was incompetent. The lesson was available every time. It just never got encoded into anything that changed the next decision.
What AI Does That We Don’t
There’s a specific irony in this pattern emerging at the same moment that AI has become the dominant technology investment across industries.
AI systems learn from the past. Not as a best practice or a cultural value, but as a structural requirement. A model that hasn’t been trained on historical data isn’t a model. The learning is automatic, systematic, and non-optional. Every inference is shaped by everything that came before it.
More precisely: AI doesn’t just learn what happened. It learns the conditions under which things happened. A recommendation model doesn’t encode that users liked item X. It encodes that users liked item X when they arrived from a certain channel, at a certain point in their journey, after certain prior interactions. The context is part of the pattern. The how is part of what gets learned.
We tend to only learn from the what.
The product team changes the idea but not the method. The senior leader changes the team but not the diagnosis. The organization runs the post-mortem but doesn’t connect it to the next decision. We update the what and treat the how as a fresh problem every time.
And then we deploy AI — a technology whose entire value proposition is systematic learning from history — without applying that same discipline to the organizational decisions about how to deploy it.
We ask the model to learn from the past. We don’t ask ourselves the same thing.
The Question Nobody Asks
Before AI it was a compelling cloud architecture. Before that a web framework that would change everything. The pattern doesn’t belong to any particular technology. Conviction about the what has always had a way of short-circuiting the discipline of asking about the how.
The question that would break the pattern isn’t complicated. It’s just uncomfortable.
What has and hasn’t worked before, in this organization, with this kind of change? Not in general. Not at other companies. Here. With these people. Under these conditions. What did we try? What did we learn? What were the conditions when it worked, and what were the conditions when it didn’t?
And then: given all of that, what’s the approach that gives this the best chance of actually landing?
Before the next project kicks off, before the roadmap gets locked, before the pitch deck goes to leadership — pull up the last one. Not to relitigate it. To learn from it. Ask: did we change the how, or just the what?
If the honest answer is just the what, you already know how this one ends.