There is a pattern we see again and again. A leadership team approves a significant AI investment. Tools get procured. Licences get distributed. A kickoff presentation goes out with a slide titled “Our AI Journey.” And then, six months later, almost nothing has changed. Maybe except the number of unused tools on people’s desktops.
The frustration that follows tends to land in the wrong place. Blame gets directed at the technology, or at adoption rates, or at change-resistant engineers. But the diagnosis is almost always wrong. The technology usually works fine. The real failure happened long before the first tool was installed.
The wrong question
Most AI transformation programs begin with the question: “Which AI tools should we adopt?” That framing is the first mistake.
Tools answer the question of what. But a transformation requires answering a completely different question: how does work actually flow through this organisation, and what happens when AI becomes part of that flow?
A copilot embedded into a codebase written by a team drowning in context switching does not reduce cognitive load, it rather adds another decision surface to an already overloaded system. An AI that generates documentation for a team that has no shared documentation culture does not build knowledge, it simply adds to the noise that no one reads.
“Installing AI into a company without redesigning workflows is like bolting a Formula 1 engine onto a bicycle. It doesn’t go faster. It falls apart.”
Structure is the variable nobody controls
In the DevOps era, we learned an uncomfortable lesson: you cannot improve software delivery by improving software alone. Conway’s Law is ruthless. Your systems reflect your communication structures, not your intentions. Teams that were siloed produced siloed architectures. Teams that owned their pipelines end-to-end shipped faster, more reliably, and with less toil.
AI is exposing exactly the same lesson, only faster and with less patience. The organisations seeing real returns from AI adoption are not the ones with the most tools or the largest AI budgets. They are the ones that asked the harder structural question first: how do we need to reorganise the way humans and AI systems work together?
That means looking at team topologies and how teams are shaped, what cognitive load each team carries, where the interaction modes between teams break down. It means identifying where AI belongs as a collaborator in a workflow rather than an afterthought bolted onto it. It means designing governance and trust into the system from the beginning, not as a compliance exercise once something has gone wrong.
What this looks like in practice
Stream-aligned delivery teams that include AI augmentation as a defined capability. Enabling teams that help others adopt AI without creating dependency. Platform teams that expose AI services as reliable internal infrastructure. Governance embedded into the fabric of delivery instead of it being embedded as an after thought upstream.
The calibration problem
There is a reason “transformation” so often fails and “calibration” is a more honest word for what is actually needed. Transformation implies a clean before-and-after. In practice, the organisations that succeed with AI don’t flip a switch. They iteratively adjust their team structures, their workflows, their trust models, their governance practices until the system is tuned to actually use what AI makes possible.
Calibration is slower to sell than transformation. But it is what works. And the organisations that invest in calibrating their structure first are the ones who, twelve months later, are not staring at a shelf of unused tool licences wondering what went wrong.
The AI is not the problem. It rarely is. The structure around it is.
