AI inherits the operating system of the organisation.
When I joined Stats New Zealand in October 2016, the technology staff were quick to set me straight. “Wayne, you don’t have to teach us Agile. We really know what Agile is.”
They weren’t wrong, just years out of date about it. A senior leader had run a serious programme to introduce Scrum across the technology function sometime before March 2014, before the CDO I’d eventually report to had even started in the role. Staff were trained. They were immersed. They had the cadence, the ceremonies, the story points, the full picture. Everyone was involved, not just a small team running an experiment off to the side, but the whole technology function, committed. By any reasonable measure, the organisation had done Agile properly, at the time.
I knew something about that period myself, from the other side of Wellington. I was at Inland Revenue from January 2013 to October 2015, and there was an active Agile community of practice running across the public and private sectors through those years, people moving between organisations, comparing notes, working out what Agile actually looked like inside companies or government work rather than in a textbook. Stats NZ’s programme would have been part of that same wave.
And then the senior leader left.
And Agile left with him.
By the time I arrived, two and a half years later, the practice the staff were so proud to tell me they knew had already been gone for years. I asked, genuinely curious: how come you’re not doing Agile now? The room went quiet in the way rooms do when people know the answer but don’t want to give it. When it came, the answer was simple: leadership stopped it. The leaders above them had ended the practice, and so the practice ended.
I found that puzzling, honestly. If the team believed in Agile, if they had the knowledge and the experience to run it well, why did they need a senior leader’s permission to continue, more than two years after that leader was gone? Why didn’t they fight for it? The answer to that question tells you more about an organisation than any strategy document ever will.
Now contrast that with BNZ.
BNZ Digital operated as its own self-contained unit, deliberately isolated from the traditional technology development cycles running on waterfall. They had their own product managers, their own designers, their own development team, their own mobile development team, their own leadership, their own funding allocation. They were inside BNZ but running a completely different operating rhythm, and their interaction with the broader technology function was structured around getting changes into production without the traditional organisation absorbing them back into its own slower pace.
They weren’t waiting for the rest of the organisation to be ready. They built a perimeter and worked inside it.
The result was visible enough that when the broader BNZ Technology function restructured, it adopted the BNZ Digital model. No mandate from above, no big transformation programme, no consultants brought in to explain why digital delivery mattered. The results made the case, and the wider organisation accepted the approach as the way forward.
Two organisations. The same method. Completely different outcomes.
The difference sat underneath the method, in something I’ve come to think of as the immunity system. Both organisations understood Agile, the people at Stats NZ knew it well enough to tell me I didn’t need to teach them, so knowledge was never what separated them.
Every organisation has one. It operates independently of the official structures, the stated values, the executive messaging, the strategy deck that gets presented at the all-hands. It’s the collection of behavioural patterns, power structures, unspoken rules, historical grievances, and self-interest calculations that determine what the organisation actually accepts and what it quietly rejects. The immunity system does not announce itself. It appears in small decisions. In which proposals get funded and which get delayed until they die of inaction. In who gets consulted and who doesn’t. In which meetings matter and which ones produce nothing except a follow-up meeting.
At Stats New Zealand, I heard a phrase more than once: “If it’s not invented here, we don’t use it.”
Stats is a deeply technical organisation. Smart people, rigorous people, people who deal in mathematics, statistics, census methodology, where precision matters and intellectual credibility is the currency. That culture produces excellent analytical work. It also produces a particular kind of resistance to external ideas, because if the idea didn’t originate inside the organisation, it carries a faint suspicion, a sense that it might not be suited to the specific complexity of the work, or that adopting it would imply the organisation hadn’t already solved the problem itself.
The immunity system at Stats NZ was protecting something real: the organisation’s sense of its own expertise and identity. The logic is coherent from the inside. The cost is that good ideas, including Agile, get treated as foreign objects and rejected when the circumstances that introduced them change. When the senior leader left, the immunity system reasserted itself, and Agile, which had been tolerated because of that leader’s authority, went with him. The staff didn’t fight for it because the immunity system had never fully accepted it. They knew how to do Agile. They had just never decided it was theirs.
BNZ Digital made a different calculation. When the restructure came, the wider technology function could see clearly enough that the BNZ Digital model was something the organisation needed for its own survival. The immunity system accepted rather than rejected, because the case for acceptance was strong enough, and because the threat was positioned as a competitor in the market rather than a threat to the people inside the building.
This is the deeper mechanism, and I think it leads back to people’s own self-interest. If something new is introduced and it affects the livelihood and power structure of people in an organisation, there will be resistance. The polite word is resistance to change. The more accurate word, and I’ll say it plainly because I’ve watched it happen, is sabotage. It’s rarely dramatic. It’s the report that doesn’t get filed, the meeting that gets rescheduled until the momentum is gone, the budget approval that keeps getting pushed to the next quarter. It happens in organisations more often than leadership is willing to acknowledge, and it almost never shows up in the post-implementation review.
Now consider what AI introduces into this same system.
AI redistributes cognitive work. It compresses tasks that previously required specific expertise. It changes who can produce what and at what speed. An analyst who spent years building the ability to synthesise large volumes of information is looking at a tool that can do a version of that in minutes. A manager whose authority came partly from controlling access to information now operates in an environment where information is far less scarce. These are real shifts, and the immunity system in most organisations will register them as threats to livelihood and power, because that is exactly what they are.
Only this time, the disruption shows up on an invoice as well.
This is already playing out, and it’s more underreported than it should be. Uber reportedly exhausted its entire annual AI coding budget by April 2026, because adoption was higher than expected and nobody had modelled what happens when engineers start using agentic workflows at scale, where a single task can trigger multiple model calls, repeated context loads, verification loops, and retries. The budget assumption was built on a SaaS licensing model. AI behaves more like cloud infrastructure: usage-based, scaling with adoption, and expensive in ways that only become clear after the bill arrives.1
A KPMG survey found that only a minority of organisations have a comprehensive understanding of their AI costs, with many discovering the numbers after the fact. KPMG’s own global head of AI has said some of their clients exhausted annual token and cloud budgets within months, one of them watching usage climb sixfold.2 CFOs are getting surprised. This is an organisational maturity problem more than a technology one, the same governance gap that Agile exposed a decade ago, now running at the speed of token billing.
There is a term circulating in enterprise AI circles now: tokenmaxxing. Organisations, in some cases deliberately, encouraging employees to maximise AI usage. Some built token-consumption leaderboards, rewarding the most active users. Replit’s own AI head has called these leaderboards “very dystopian,” arguing publicly that more tokens do not equal more business value.3
The Agile comparison is almost too clean. Messy Agile measured velocity instead of value, and teams ran sprints full of story points that delivered nothing useful. Tokenmaxxing measures consumption instead of outcome, and organisations run up bills generating AI-produced work that doesn’t change anything meaningful downstream. The metric changed. The dysfunction is the same.
The games an organisation chooses to play internally with AI will be its own demise if the path is wrong. And the path is almost always determined not by the technology but by the invisible operating system underneath it.
In organisations whose immunity system is oriented toward protecting existing power, AI generates a particular kind of dysfunction: the theatre of adoption without the substance. Tools purchased, training announced, dashboards built, constraints untouched. In organisations with a healthier operating system, AI costs get managed the way cloud infrastructure costs eventually got managed: per-team budgets, model routing, usage governance, ROI tracking per workflow. What is now being called AI FinOps. The discipline looks familiar because the problem is familiar. Every time a new technology scales faster than the operating model around it, the organisation has to build the governance infrastructure after the fact, and the bill for that delay is always larger than expected.
The technology doesn’t determine which path an organisation takes. The invisible operating system does.
Two organisations can buy the same tools, run the same training, appoint the same internal AI champion, and arrive at completely different results, because the immune response they brought to the implementation was different. One accepted. One rejected. And neither the acceptance nor the rejection showed up in the original business case.
The question worth more time, before any AI rollout, is not the technology question. The technology question gets answered relatively quickly. The organisational question is harder: what does this institution’s immunity system protect, what will it accept as necessary for survival, and who controls the informal decisions that will actually determine whether this takes root or gets quietly extinguished?
Most organisations don’t ask it. They buy the tools, announce the programme, train a cohort, and spend the next eighteen months wondering why adoption is low and the results are thin.
I’ve seen this before. The technology was different. The immunity system was the same.
- Uber capped AI coding spend after exhausting its annual budget by April 2026: PYMNTS, CryptoBriefing. ↩︎
- KPMG AI Quarterly Pulse Survey on AI cost visibility (only around 26% of firms report a comprehensive view), plus KPMG’s global head of AI on clients exhausting budgets within months: Implicator.ai, KPMG. ↩︎
- “Tokenmaxxing” and Replit AI head Michele Catasta calling consumption leaderboards “very dystopian”: AOL, CIO, Pragmatic Engineer. ↩︎