AI Will Not Save You From Your Operating Model
AI adoption will fail when organizations try to scale it as a fixed methodology. It will work better when they spread disciplined adaptation: pioneers, constraints, visible learning, and local practic
In In Praise of SWARMing, Dan North names a problem a lot of organizations keep recreating when trying to improve how they work at scale:
When they find a useful way of working, then they try to scale it by turning it into a religion.
And then the ceremonies, language, and templates of that method become the gospel instead of the actual qualities that made the way of working useful in the first place.
North’s alternative is SWARMing: Scaling Without A Religious Methodology. The point is that a framework itself is not change. Real change depends on pioneers, education, practice, communication, investment, leadership, and enough local adaptation for the idea to survive reality. His lesson matters as much, if not more, with AI.
TL;DR: SWARMing is disciplined adaptation
SWARMing does not mean “everyone does whatever they want.” It means useful practice spreads through pioneers and visible learning instead of being frozen into a rigid methodology too early. The discipline comes from shared principles and constraints. The adaptation comes from letting teams shape the practice to fit the work.
AI Is About To Repeat Agile’s Mistake
A lot of organizations are poised to make the same mistakes with AI as they did with Agile. They will create a centralized rollout, define approved use cases and tools, mandate training, standardize prompts, build maturity models, and call that a scaling adoption. Some of that will be necessary or even helpful, like governance as an enabling constraint or default playbooks to guide learning.
But if AI adoption is forced to conform to a scaling model, it’s essentially treating documents and templates and processes as gospel again.
I’ve made the argument before that the inertia of large organizations is hard to stop, In this scenario, an organization that expects AI to conform to their operating model will inherit an AI with the weaknesses of that operating model. The result will look controlled. It will also be brittle.
AI does not make a brittle system adaptive. It gives the system another mechanism to create brittleness.
How Useful Practice Becomes Compliance
You can already imagine the version that fails. It begins with teams trying AI and finding slightly different reasons to keep using it. Each team is learning something different because each team’s work is different.
Then the organization notices the activity and decides it is time to choose a way to scale. A central group packages the practices into an enterprise AI methodology. Everyone gets the same training and access to the same approved workflow. Teams are asked to document use cases in the same format, route exceptions through the same governance path, and report adoption through the same dashboard. The local learning gets flattened into compliance. Successful adoption becomes the amount of code AI writes or the number of completed framework documents.
AI is not just another tool you install. It can and should change its shape depending on the work. A religious methodology tries to stabilize the practice too early. It turns early learning into policy before the organization understands the conditions that made the learning work.
SWARMing Is Disciplined Adaptation
SWARMing gives you a better path. Let pioneers explore in real work. Give them constraints, not scripts. Make the learning visible. Create places for people to compare patterns. Invest in education that helps people think better, not just follow approved workflows. Bring in external perspective where it helps, but do not outsource judgment. Let the practice spread through usefulness before you freeze it into procedure.
That does not mean “let everyone do whatever they want.” This is where SWARMing is often misunderstood. It is not chaos. It is disciplined adaptation.
The discipline comes from shared principles and clear boundaries. What data can be used? What needs human review? Where is AI allowed to assist but not decide? What kinds of work require traceability? What risks are unacceptable? What does good practice look like when the output is wrong, incomplete, or too confident?
Those constraints matter. They create safety. But within those constraints, teams need room to learn.
Different Work Needs Different Practice
A product team using AI to explore customer problems should not have the same workflow as a legal team reviewing contract language. An engineering team using AI inside a test-driven workflow should not be treated the same as a marketing team generating campaign copy. The risks, feedback loops, and expertise required to judge the output are all different.
“How do we roll out AI across the organization?” is a leading question because it already assumes the answer is a rollout. A single methodology hides those differences. SWARMing turns the differences into strategic levers. One rollout strategy is too generic. A bespoke strategy for every team is too much. The useful middle is adapting around real use cases once value appears.
A better approach would be to adapt to different use cases once the value of AI appears there. Better next questions are “What makes the way AI addresses the need in this situation good? What parts of it could be used by others and for what situations?”
Leaders Should Look For Pioneers, Not Playbooks
That shift changes the work of leaders. Instead of asking for a master playbook, leaders should be looking for pioneers. Who is already using AI in a way that improves learning, quality, or flow? What constraints are they respecting? What judgment are they applying? What mistakes did they make? What would break if another team copied the practice blindly? Blind copying is where good ideas go to become templates.
If one team succeeds with AI because they already have strong code review, automated tests, and shared ownership, the lesson is not “everyone should use the same coding assistant workflow.” The lesson might be that AI works well when the team already has fast feedback and strong engineering discipline. If another team copies the tool without the feedback loop, they may not get the same outcome.
AI Inherits The Operating Model
That is what I mean by AI inheriting the operating model. If your organization rewards output over learning, AI will produce more output. If your governance model delays decisions, AI will wait in the same lines. If your teams lack decision rights, AI will become another thing they need permission to use. If your culture punishes mistakes, people will avoid AI to avoid punishment.
AI does not make a brittle system adaptive. It gives the system another mechanism to create brittleness.
The Better Version Is Possible
I believe there are things to be optimistic about too. In a healthier operating model, AI can make SWARMing work better. AI can capture what pioneers learn more reliably, help teams compare experiments, and make winning and losing patterns easier to share. It can help translate a practice from one context to another while preserving the caveats. It can help people rehearse new ways of working before they have to defend them in front of skeptics. Used that way, AI supports the spread of practice.
Are you scaling AI by spreading learning, or are you scaling AI by enforcing sameness?
Sameness will feel safer at first. It gives something to approve and something to measure. It gives transformation teams something to package. But sameness is often a poor substitute for coherence. Coherence means teams are working from shared principles while adapting to their context. Sameness means everyone is following the same shape whether or not it fits the work.
AI needs coherence more than sameness.
The Real Lesson
That is the lesson I take from North’s SWARMing idea in this moment. Scaled practices work best without a rigid methodology, and AI is no different.
The failure mode for AI transformation is the same as the failure mode for agile transformation. Agile became ceremony without agility. Product operating models became role diagrams without product judgment. Transformation became new vocabulary without changed incentives or mindsets. AI can go the same way.
Or it can spread differently. Through small groups of practitioners doing real work. Through constraints that protect the organization without freezing the practice. Through leaders who understand that adoption is not the same thing as learning.
AI does not need a religious methodology. It needs pioneers, practice, feedback, and enough room to adapt to the work.
That is harder to manage than a rollout. It is also much more likely to survive.



