The first comment on Rasmus Lystrøm’s YouTube video called the talk a waste of time. The second was harsher still: the speaker hadn’t said anything new. Replace “AI” with any tool name and the talk would be identical. AI could have written it itself. Lystrøm’s response was characteristically direct: perhaps the audience had heard it before but hadn’t listened. That tension—that we already know what needs to change but somehow never do—lies at the heart of why organizations continue to fail at AI transformation.
The mistake is deceptively simple. Companies buy a tool, roll it out to employees, and declare transformation complete. They have adopted AI. They have not transformed anything. The organization remains structurally identical—just now possessing a new piece of software that may or may not get used. This is the fundamental confusion at the center of most corporate AI strategies: tool adoption is not transformation, no matter how many executive presentations declare otherwise.
The Failed Strategies
Organizations keep returning to the same three approaches, each doomed to produce the same disappointing results.
The first is what Lystrøm calls the FUD strategy—fear, uncertainty, and doubt. Block access to ChatGPT. Prevent data leaks. Solve the compliance problem by simply not allowing the technology. The logic is understandable: if employees cannot access the tools, they cannot leak sensitive data. The problem is that this approach treats employees like water. Water finds a way through. Lystrøm describes speaking with a senior employee at one of Denmark’s largest banks who had been blocked from using ChatGPT on her work computer. Her solution was to photograph code on her screen, enter it into ChatGPT on her phone, photograph the response, and transfer it back. The data leak occurred anyway—except now it happened through an uncontrolled channel that the organization could not monitor or protect. Blocking tools does not block the desire to use them. It merely pushes that behavior into shadows.
The second strategy is the copycat approach: build your own version of ChatGPT. Call it CompanyGPT. Host your own instance using OpenAI’s API, maintain control over your data, and provide employees with a sanctioned alternative to the public tools. The appeal is obvious—you get the benefits without the perceived risks. The reality is less encouraging. As Lystrøm points out, standard chat-based interfaces have already become commodities. Big tech companies have out-innovated everyone in this space. Your shallow copy will never catch up to the original, and your employees will know it. They will use the real thing on their phones while politely nodding at the company-approved alternative. The platform becomes another unused corporate tool, another example of IT failing to understand what people actually need.
The third strategy creates a new silo. Hire a Chief AI Officer. Form an AI Center of Excellence. Build a compliant platform with guardrails that ensure everyone does things the right way. The visual metaphor is striking: imagine a bowling lane with guard rails so narrow that the ball cannot possibly reach the pins. It is a system designed for safety rather than results. The platform becomes the goal rather than the means to a goal. Lystrøm notes that 80% of companies he works with are perpetually 80% done building a new platform that will solve all their problems—problems that remain unsolved because the platform itself has become the project. The irony is that these platforms are often built on top of other platforms, creating layers of abstraction that serve no one.
The Transformation Deficit
The core issue is that none of these strategies address what transformation actually requires. AI transformation, as Lystrøm notes, is defined as “the process of implementing artificial intelligence and machine learning to improve how your business operates and develops strategy. It often requires changes to business processes, organizational structures and employee roles.” The word “requires” does heavy lifting here. Transformation implies fundamental change to how work happens, who makes decisions, and how value is created. Organizations that simply purchase tools have not transformed anything. They have added something to their existing system.
This connects directly to Conway’s Law, the observation from 1967 that organizations are constrained to develop systems that mimic their communication structures. If your organization’s communication is broken—if information flows poorly, if decisions require endless approval chains, if teams operate in isolation—then adding AI will not fix this. It will simply automate broken processes at greater speed. Lystrøm cites an example of an executive celebrating that Copilot can now prioritize their inbox. The observation cuts to the heart of the problem: the executive has so many emails that they need AI to sort them. The real problem is not the sorting. The problem is the volume of unnecessary communication that no one actually needs. Fix the emails, not the sorting.
This is why tool-focused strategies fail. They treat symptoms rather than causes. They assume the technology is the solution when it is merely a tool that amplifies whatever organizational dynamics already exist. A broken organization with AI will simply produce broken outputs faster.
The Empowered Team Alternative
Lystrøm’s alternative centers on a concept that sounds simple but requires profound organizational restructuring: empowered teams. The definition he offers is precise. To be empowered means being part of a team that has the appropriate skills, authority, and experience, and whose sole focus is getting the entire job done. This is not the same as being given permission to use new tools. It means having the autonomy to make decisions, the resources to act on those decisions, and the accountability for the results.
This stands in stark contrast to how most organizations operate. You are not empowered if you must ask permission from security to do your job. You are not empowered if you can only use a specific set of cloud resources governed by a platform team. You are not empowered if you cannot release software without approval from a change advisory board. These structures exist for legitimate reasons—security, compliance, stability—but they fundamentally undermine the autonomy that transformation requires.
The platform approach, Lystrøm argues, is premature optimization. Build the product first. Understand what actually works. Only then, if there are common patterns worth consolidating, consider building a platform. Starting with the platform is like designing a city before anyone lives in it. The needs will be different than you imagined, and you will have built the wrong thing.
This requires trusting people. Lystrøm poses a question: has anyone ever woken up on a Friday morning thinking “I’m going to go to work and deliberately destroy something”? He has never met anyone who intentionally tries to break systems. Yet organizations behave as though employees cannot be trusted. They impose restrictions, require approvals, and create processes that assume malicious intent. If someone genuinely wanted to cause damage, these controls would not stop them. The restrictions merely slow down people who are trying to do good work.
Building What Works
The alternative to grand transformation strategies is smaller, more grounded approaches. Build things that work and get them into production. This sounds obvious, but it contradicts how most organizations plan technology investments. They want detailed requirements, large teams, multi-year timelines, and maximum safety. They want to build the entire system before anything runs.
The principle echoes what John Gall wrote in 1974: “A complex system that works is invariably found to evolve from a simple system that works. The inverse proposition also appears to be true. A complex system designed from scratch never works and cannot be made to work. You have to start over beginning with a working simple system.” This is not a new insight. It is decades old. And yet organizations continue to ignore it, believing that this time will be different, that their detailed planning will overcome the fundamental challenge of building complex systems.
The practical implication is to let teams experiment. Give them the tools they need. Let them build something interesting—machine learning for fault detection, conversational interfaces for customer support, predictive maintenance systems. Let it run in production. Learn from what works. Only later, if there are genuine economies of scale to be captured, consider consolidation.
The Human Element
What emerges from Lystrøm’s analysis is a picture of transformation that has almost nothing to do with technology and everything to do with organizational culture. The failure to transform is not a technical problem. It is a human problem. Organizations keep trying the same approaches because they are comfortable—because they do not require changing how power is distributed, how decisions are made, or how work is structured.
The transformation requires trusting people more than processes. It requires building small things that work rather than grand platforms that don’t. It requires empowering teams with authority rather than just tools. And it requires recognizing that AI is not a solution to broken organizational dynamics—it is a tool that will amplify whatever dynamics already exist.
The question is not whether to adopt AI. The question is whether organizations are willing to change in ways that actually matter. The tools are available. The strategies are known. What remains is the harder task of doing what we already know we should do.
The broader implication here extends beyond AI. The pattern of mistaking tool adoption for transformation describes how organizations approach most technological changes. The real question is whether organizations can develop the cultural capacity to treat technology as what it truly is: an amplifier of human intent, not a substitute for human change. The organizations that will thrive in an AI-augmented world are not those that buy the most sophisticated tools, but those that have already done the harder work of building trust, autonomy, and genuine empowerment into their structures. The technology is the easy part. The transformation is human.