Category: Systems & Operations

AI speeds up everything except the constraint. And the constraint is rarely the technology.

Every executive board I’ve sat in front of, whether at Te Wānanga o Aotearoa, Te Pūkenga, or earlier in my career, had the same shape underneath it, regardless of what the organisation actually did.

Papers had to go in weeks ahead of the meeting. There was a format, usually one set by governance requirements flowing down from a central government agency, and the format asked the same kind of questions every time. What were the procurement options. What competing quotes did you receive. How did you arrive at this recommendation. What’s the financial case. As a senior leader, you’d spend real time, real effort, getting that paper into shape, because the format mattered as much as the content, sometimes more.

And here’s the thing I noticed, the same thing in more than one organisation. Below a certain financial threshold, things moved. A CEO’s financial delegation might cover spending up to a certain amount, and inside that boundary, decisions happened at a reasonable pace, weeks, not months. Above that threshold, technology spending had to go to the board, or to the chairperson, or to a steering committee specifically constituted because the programme had crossed, say, a million dollars. And the moment something crossed that line, the pace changed completely. Not because the work got harder. Because the decision now belonged to a different cadence, board meetings, steering committee meetings, a calendar that ran on its own schedule regardless of how ready the work was.

Once you got past that approval point, interestingly, things sped up again, often quite quickly. Which tells you something important. The slowdown was about which side of a financial line the work happened to sit on.

The constraint is the threshold itself, and the cadence that governs anything above it.

Now think about what AI actually speeds up in this picture.

AI is very good at producing exactly the kind of paper that format demands. Procurement options, comparative analysis, draft business cases, the research that goes into “how did you arrive at this recommendation.” All of that gets faster. A paper that used to take a team two or three weeks to assemble properly could, with AI doing a lot of the drafting and research legwork, come together in days.

So picture what happens. More papers, better researched, arriving faster, all queuing for the same board cycle, the same steering committee cadence, the same financial delegation threshold that hasn’t moved an inch. The constraint doesn’t get any faster just because the things arriving in front of it got faster to produce. If anything, the queue gets longer, because now it’s cheaper and quicker to generate a business case, so more of them get generated, and they all still have to wait for the same monthly or quarterly slot.

Speeding up the non-constraint doesn’t speed up the system. It just means the constraint now has more sitting in front of it, dressed more convincingly, on the same clock as always.

At Te Pūkenga, this played out in a very specific way. There was a real appetite, especially in technology, to move fast, to make decisions and adjust later if needed. Seek forgiveness rather than permission, the old phrase. But that approach, taken too far, breaks the agreement between the organisation and central government, the governance arrangement that the financial delegation and steering committee structure exists to protect. So the choice sat with whoever held the role, often the Chief Digital Officer, and the choice was political. Move fast and risk the relationship with the centre, and your own position along with it, or stay inside the governance lines and accept that the pace is set by someone else’s calendar.

Most people, reasonably, chose the second option. And the work that had been done, the research, the supplier engagement, the commitment built with development teams, much of it sat there, not wasted exactly, but not moving either, while the business division absorbed the cost of effectively standing still. Spinning the wheels, consuming budget, with nothing to show for it on the outside, because the thing that needed to move was waiting on a decision that hadn’t been made.

And here’s where it gets sharper still, because indecision isn’t neutral. Indecision is itself a decision, usually the decision to keep the status quo running for as long as possible.

At Inland Revenue, I started in January 2013. My first day on the job, we were hit with a Priority 1 incident, the kind that takes taxpayer-facing systems down entirely. My senior manager introduced me to the floor and told everyone I was the one who’d sort it out. That was day one. By the end of that year we’d had 33 Priority 1 incidents, on top of everything lower in severity that never made it into anyone’s headline numbers.

The infrastructure behind it told you why. The WebSphere Application Servers running our channel systems were three versions behind current, and they buckled under unusual load, especially during the tax peak season running April through August, exactly when the system needed to hold up the most. The Business Platform Services Channels team I was part of owned about 40% of Inland Revenue’s applications, and roughly 70% of all application interfaces flowed through its public-facing portal. Alongside that, the document management platform, an IBM Enterprise Content Management system that every tax form and every piece of taxpayer correspondence ran through, was already out of vendor support. We were paying IBM a premium just to keep getting support on a platform it no longer wanted to support, because the realistic fix, an upgrade to the lowest version still covered, never quite made it to the front of the queue.

Every outage got noticed. Leadership attention, public criticism, press coverage, a tax agency whose own systems taxpayers couldn’t access to file their returns, accountants scrambling to lodge clients’ returns through whatever workaround they could find. None of that is a small thing for an organisation whose entire mandate depends on people trusting the system enough to use it.

Keeping that infrastructure at 99.9% availability through tax season took real ingenuity, because the investment to actually fix it properly wasn’t coming. Leadership knew it. The plan, such as it was, was to sweat the assets for as long as they could be sweated, until the broader Business Transformation programme eventually arrived to replace everything properly. In the meantime, the onus sat with the people in Business Platform Services, keeping a system three versions behind current running at a reliability target that newer infrastructure would have struggled to hit without strain.

That requirement didn’t soften just because the underlying technology was ageing and the replacement programme was stuck in a queue somewhere above someone’s financial delegation. The risk of that gap, between what the system was being asked to do and what it was realistically capable of doing reliably, didn’t sit with whoever was holding up the approval. It sat with the people keeping the lights on every day, the ones whose job it was to make 99.9% happen on infrastructure that leadership already knew was past its best.

This is what I mean when I say AI exposes the constraint rather than removes it. If AI is used to speed up the analysis, the business cases, the options papers, the reporting, exactly the things that feed into a board cycle or a steering committee, none of that touches the actual bottleneck, which is a financial threshold and a meeting cadence set by governance arrangements that have nothing to do with how fast anyone can write a paper. What changes is the size and polish of the queue sitting in front of that bottleneck, and the distance between what’s technically possible and what’s actually approved gets more visible, faster, because the technical side is now moving at AI speed and the governance side is moving at the same speed it always has.

The gap was always there. Sweating the IRD assets, the Te Pūkenga standstill, these existed long before anyone in those organisations had touched an AI tool. What AI does is make the two speeds, the speed of producing the case for change and the speed of actually deciding on it, diverge so sharply that the gap stops being something you can quietly manage and starts being something everyone downstream can see.

I think that’s worth sitting with, if you’re the one several layers down, keeping something running at 99.9% while the decision about its future sits in someone else’s inbox. AI won’t move that decision any faster. It’ll just make it more obvious, to more people, sooner, exactly how long that decision has been sitting there.

Leadership, in my experience, genuinely doesn’t see this whole chain. They see their piece of it. The approval is pending, that’s a known item on a register somewhere, fine. The systems are running, availability targets are being met, also fine. Nobody in the room is looking at the line connecting those two facts, that the second fact is only true because of effort and risk being absorbed by people several layers down, for as long as the first fact remains unresolved.

As long as it isn’t front-page news, the risk reads as managed.

One morning in 2013, a senior manager stopped at our whiteboard at Inland Revenue while my team was running through the day’s incidents, looked at the columns of cards for a while, and said, “Wayne, we don’t do agile here.”

I said, “No, we’re doing TPS. Toyota Production System.”

She wasn’t satisfied with that. “Just remember, Inland Revenue doesn’t do agile.” Then she walked off.

She ran ICT Solutions. She had sat on the panel that hired me. And she had carried Mary and Tom Poppendieck’s Lean Software Development around during her MBA sometime later, which made the line even better.

That was the entire exchange. Nothing came after it, no memo, no meeting invite to discuss my team’s unauthorised working methods. And looking back, the reason nothing came after it is the whole point of this piece. We never asked permission for what we were doing, and we never argued for it in a meeting room either, because we would have lost that argument. We did the work where people could see it, and let the results carry the case.

Some context first. I ran Business Platform Services Channels at Inland Revenue from January 2013 to October 2015, a team of 11 or 12 looking after the systems sitting between New Zealand taxpayers and everything behind the portal. Channel owned about 40 percent of Inland Revenue’s ICT applications in its own right, but as the front end of the service chain, up to 70 percent of all application interfaces flowed through us on their way to the middleware, the databases, and the mainframe at the back. So any incident touching the portal got assigned to us to triage first, whether or not the fault actually lived behind us. We wore every complaint, and that’s how busy we were: sifting through the shit to work out whose it was. When the portal goes down, nobody rings the database team.

The technology was waiting for business transformation to arrive. WebSphere servers out of support from IBM, infrastructure being sweated to survive until the new world got funded and built. Least resources, oldest kit, first in line for blame. And in my first year, 2013, we logged 33 priority one incidents. Thirty-three times in a single year, a system serving every taxpayer in the country fell over badly enough to be declared a P1.

What We Actually Did

Every morning we stood at a whiteboard and went through the work. To do, in progress, done. Whatever needed attention across the entire service line got a card. This wasn’t proper agile; there was no Scrum Master and no sprint cadence, because production support doesn’t run in sprints. Incidents don’t wait for planning day. We were level 2 and level 3 in the support chain, taking what the Service Desk at level 1 passed up, triaging it the way an emergency department triages patients, firming up the diagnosis, fixing what we could ourselves, and passing the rest to the development teams at level 4. Inland Revenue had run Scrum on some projects before, and several of my people knew the ceremonies well, so the muscle memory was there. We simply pointed it at operations instead.

I called it Toyota Production System because that’s what it was: make the work visible, limit what’s in progress, let the team pull the next priority, and treat every incident as a signal about the system rather than a fire to forget once it’s out.

Teru Yanagihashi, my Senior IT Consultant, took the visibility further than I would have on my own. He put a metrics dashboard straight onto the whiteboard, openly displaying where the issues actually lived across the service line, which trends were building, what needed watching next. He also introduced a Niko Niko board, a Japanese practice where each person marks their mood for the day, which sounds soft until you realise it tells you about the condition of the team before the incident queue does. A tired team misses thresholds. Many of the ideas that worked in that team started as Teru’s; his dedication and commitment were second to none.

None of this was electronic. There was no tooling budget. Whiteboard, markers, and a team that showed up every morning.

My peers and my leadership tolerated all of it, I guess because the numbers kept moving in the right direction and it cost them nothing to look the other way. The P1 count kept falling, and they left us alone. Results bought us an autonomy that no argument would have.

The Viral Part

Then something happened that I didn’t plan. Colleagues from the other Business Platform Services teams walked past our corner, saw the board, watched the morning ritual for a while, and whiteboards started appearing in their spaces too. Nobody mandated visual management. There was no workshop, no change programme, no lunchtime session on lean methods. The practice spread because it sat in the line of sight of anyone walking the floor, and because the thing it was attached to, our incident numbers, was visibly improving month after month.

Eventually my Director for ICT Operations bought us a 45 inch TV to display our monitoring dashboards, an envy to the rest of BPS. I suspect that TV did more for adoption across the floor than any presentation I could have given.

The numbers are the part I can still recite. 33 priority one incidents in 2013. Seven in 2014. Three in 2015, my final year.

Behind those numbers was a team watching thresholds against upper control limits, CPU, cache, database log files, queue depths, and taking preventive action in quiet hours before any limit was breached. The whiteboard made the priorities visible. The dashboards made the thresholds visible. The discipline was simply that somebody was always watching and always acting early, and that discipline held availability at 99.9 percent through tax peak seasons, on assets that were officially past their support life. How we sweated those assets through peak season deserves its own piece, so I’ll leave that story for another day.

The Newsletter

Three P1s in a year got attention at the top. The CIO came down and asked what we had done to make that possible, and then he wanted a piece in the internal newsletter about the improvement in operations.

Here’s where I learned something about visibility that the whiteboard hadn’t taught me. I told him the truth: we relied on more eyeballs watching the thresholds of the upper control limits for failure. He looked puzzled. I explained the eyeballs again, and he looked more puzzled. You can’t write “we watched harder and acted earlier” in a newsletter. There’s no chart for it, no milestone, no budget line, nothing that reads like an achievement.

In the end, I suggested he attribute the improvement to the mainframe, since we had a mainframe project running at the time. A project is quantifiable. It has a name, a start date, an end date, a cost. It fits the shape a newsletter expects. So the mainframe got the credit, and I’m the one who offered it, because I understood the constraint he was working under. The improvement he actually came down to ask about was the ingenuity of an entire team monitoring thresholds and sweating aging assets, and that never gets published, because it sounds simple and boring.

Two Kinds of Visibility

I’ve thought about this a lot since. There were two kinds of visibility in that story, and they behave completely differently.

Sideways visibility spreads practice. Peers copied the whiteboard because they could see it working with their own eyes, on their own floor, attached to numbers that kept falling; no persuasion required, no business case, no mandate. When results are physically visible, adoption becomes voluntary, and voluntary adoption sticks in a way that mandated change rarely does. That’s the persistence half of the story. We kept doing the same simple things, quietly, for three years, and the copying followed the results.

Upward visibility grants credit, and it only registers what is countable and project-shaped. The institution could see the mainframe project because it had the right form. It couldn’t see the eyeballs, even when the person responsible stood in front of the CIO and explained them twice. So the official record of that improvement, if anyone ever digs out that newsletter, says the mainframe did it.

Both kinds are real, and both matter. But if you run operations anywhere, it’s worth knowing that the work that spreads among practitioners and the work that gets credited by the institution can be entirely different work, and the gap between them is where a lot of quiet operational excellence lives and dies unrecorded.

Teru returned to Japan after 2021. The senior manager was right in the end; Inland Revenue never did do agile, at least while I was there. It did TPS for three years in one corner of the floor, and the whiteboards told everyone who cared to look. Even she was converted before I left.

I still think the eyeballs deserved the newsletter.

AI exposes organisational constraints faster.

I’ve seen this with Agile adoption before.

When Agile arrived in earnest, the promise was faster delivery, tighter feedback loops, smaller batches of work shipped more frequently. And to be fair, the delivery engine did get faster. Sprints ran. Stand-ups happened. Velocity metrics climbed.

What nobody anticipated was what faster delivery would surface underneath.

At ANZ, one of the wholesale development teams adopted Scrum to make their development work more productive. The sprints ran. The stories got written. The cadence held. And then the team hit the same wall, every cycle: the production team, the backend that actually implemented and released the code, was the bottleneck. You can’t release on a two-week cadence when the deployment pipeline is controlled by a separate team operating on a different rhythm entirely. Scrum didn’t create that constraint. It just made it impossible to ignore.

That’s the thing about faster feedback loops. They take the problems you’d been working around and drop them onto a schedule.

Governance bottlenecks that had been invisible suddenly became obvious, because the team was now waiting on approvals that used to take weeks, and the wait was now a sprint event. Procurement delays, executive indecision, fragmented ownership between teams, overloaded support functions, the kind of organisational friction that had always been quietly present, all of it became visible, quickly, repeatedly.

The delivery engine ran faster than the surrounding operating model could handle, and every gap showed.

There’s a second version of this, and it’s less about the gap between teams than about a gap inside one team, a gap between the credential and the experience.

Back then, in the early years of Agile adoption in New Zealand, there weren’t many people who knew how to run it well. The training existed. The certifications existed. What didn’t exist yet was depth, people who’d been through a full end-to-end Scrum implementation enough times to know where it actually breaks.

So what happened, more than once, was someone attended a few days of certification training, came back with a freshly printed credential, and was treated, by the team and often by themselves, as the expert in the room. At ANZ, I watched this directly. Two staff were sent away for a five-day Scrum course, back at their desks the following Monday, expected to design how the team would work and then run it, as if five days in a classroom had given them everything a real implementation actually needed. Nobody was bluffing. They simply hadn’t done it long enough yet to know what they didn’t know. It was truly a version of the blind leading the blind, well-meaning, certified, and still learning on the job in front of the people they were supposed to be guiding.

There’s a third version too, and it’s less about people than about fit, a gap between the method and the work itself.

Stats New Zealand’s technology function isn’t structured the way a bank’s is. At BNZ, BNZ Digital was purely a development outfit, building the future of online retail banking and parts of wholesale. Production issues were limited, and when they happened, they got folded into the backlog as a future release. One focus, one rhythm. The team ran a blend of Scrum and Kanban that worked because the work itself was singular: build things, ship things.

At Stats NZ, each technology team was both a development unit and a production support unit for its own applications, at the same time, every sprint. Development work fits Scrum naturally, you can estimate it, size it, accumulate story points toward a sprint goal. Production support doesn’t work that way. An outage doesn’t wait for the next sprint planning session, and you can’t put a story point estimate on “the census database fell over at 2am.”

So which method do you run? Scrum says commit to a sprint goal. Kanban says manage flow, work moves through states as it arrives, no fixed commitment. Both are legitimate. Neither one, on its own, matches a team that is doing both kinds of work simultaneously. What I saw at Stats NZ was teams trying to run Scrum and Kanban at the same time, in the same team, without anyone resolving which one governed which kind of work. That’s a fit problem. The method didn’t match what the team actually was.

We did try to fix it. A Kanban coach came in to help shift the technology operation toward something more workflow-based, more suited to the support side of the work. I’m not saying it solved the problem. What it did, immediately, was create tension between the people who had built their identity around Scrum and a coach whose entire philosophy ran in a different direction, workflow versus story points, two ways of seeing the work that don’t fully reconcile. Some teams adapted well. Others carried on reluctantly, doing what they were told without believing in it, which is its own kind of cost, quieter than resistance but not really different from it.

In the end, the team managers carried it. They were still accountable for what they’d promised the business and its customers, and that didn’t change just because the method underneath them did.

And there was a layer above all of this that nobody at the team level controlled. Around the same time, there was pressure from outside the organisation, government agencies signalling that SAFe was the direction Agile adoption should take across the public sector. Another flavour, another framework, arriving with its own philosophy and its own assumptions about what “good” looks like, and requiring dedicated leadership to steer it properly, leadership that was already stretched thin steering the first change.

Fixing a fit problem doesn’t happen in a vacuum. The fix creates its own friction, and external pressure arrives with its own opinion about what the fix should have been, usually without much interest in what’s already underway.

AI is going the same way, faster than Agile did.

AI increases analytical speed, automation, report generation, content production, decision support, all at once, across every kind of organisation, regardless of what that organisation is actually for. A bank building new digital products and a statistics agency keeping the national data infrastructure running will both get offered the same AI tools, the same vendor pitches, the same “transform your organisation” programme. Neither tool knows which kind of organisation it landed in. Neither does the implementation plan, usually, because nobody asked the question first.

And the same expertise gap that hollowed out early Agile rollouts is already showing up here. There isn’t enough deep AI experience to go around yet, the kind built from actually deploying these tools inside a real organisation and watching what breaks. What there’s no shortage of is the credentialed version, a course completed, a badge on a LinkedIn profile, a confident voice in a steering committee. None of that is false. It’s just early, the same way Agile was early once, and the gap between the credential and the experience is exactly the gap that costs an organisation real money once the rollout actually starts.

And when an organisation does try to course-correct, bringing in an AI lead, an AI coach, a new framework, expect the same pattern. New tension between the people who’d built expertise around the old approach and whoever’s now steering the new one. Some teams adapting well, others complying without believing it. And somewhere above all of it, an industry body, a government directive, a board that read something in the Financial Times, arriving with an opinion about which AI framework or governance model the organisation should really be using, usually with no visibility into what’s already half-built underneath.

And AI, unlike Agile, has a bill attached to every experiment. If an organisation hasn’t worked out what it’s actually for, before it starts pointing AI at its problems, and before it layers a fix on top of a fix while external pressure adds a third opinion, it will spend heavily finding all of this out the hard way. At least a wasted Scrum sprint was just time. A wasted month of AI experimentation, run at scale across a team, shows up as a number someone in finance has to explain.

So before any AI rollout: what is this organisation actually for? Does the thing we’re about to deploy match that? And are we steering it ourselves, or about to hand the wheel to three parties at once?

Most organisations skip that question entirely. They go straight to the tooling.

I’d rather know what I’m building before I see the bill for it.