Author: Wayne Loke

  • What AI Exposes – Part 4 of 6

    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.

  • Two Kinds of Visibility

    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.

  • What AI Exposes – Part 3 of 6

    AI can generate strategy decks. It cannot create organisational coherence.

    One of the things I’ve come to dread is sitting on a steering committee and watching a project go AMBER, sometimes RED, and knowing I can’t ask the question that actually matters.

    The programme manager or project manager gives the update. The status is AMBER. As a committee member who isn’t in the programme day to day, I can’t ask, “What’s the smallest next step that would move this from AMBER to GREEN?” because that’s not a question the report is built to answer. The answer to that question lives with a development team somewhere, and the person presenting to the committee doesn’t have it either, not in the room. They’ll go back, check with the team, and come back to the committee, usually at the next monthly meeting, with more information.

    It’s a show. I don’t mean that unkindly, everyone in the room is doing exactly what the format asks of them. But the format itself is built for visibility, not for progress. It exists so that senior leadership is aware something is happening, and so that some form of governance can say it’s watching. It was never built to surface the bottleneck.

    I see the same instinct well beyond steering committees. When governance feels weak, the instinct is to add more governance, another sign-off, another layer of review. When accountability is unclear, the instinct is to add more reporting, more dashboards, more visibility, as if seeing a problem more clearly were the same as fixing it. Usually this comes from smart, well-intentioned people reaching for the lever that’s actually within their control, because they can’t always fix the trust deficit or the unclear ownership three layers down, but they can build a dashboard.

    I’ve sat in that room at ANZ, at Inland Revenue, at Stats NZ, and going back further, at ABN AMRO too. Different organisations, different programmes, same shape. When you’re invited as a specialist or a senior leader but you’re not in the programme itself, you are, by design, removed from the day to day. The report is the only window you get, and the report operates at a macro level because that’s the altitude the committee operates at.

    The clearest version of this for me was when Stats NZ put me forward as an external steering committee member for the Department of Corrections, on a programme migrating their infrastructure to the cloud. My role was to provide independent advice. And what I found was that the questions the committee actually spent time on were almost always about cost, where the budget sat, what the forecast was, rather than about the next concrete step that would unstick the work. Whenever the conversation drifted toward the nitty-gritty, what’s actually blocking this, the chairperson would, gently but consistently, pull us back to the governance agenda. Cost, status, risk register. Not “what do we do on Monday.”

    And to be fair to everyone involved, some of that is the nature of the work. Legacy systems, especially in government, need a lot of fine tuning and conversion effort before something genuinely moves from RED to AMBER to GREEN. That’s real. But the steering committee, as a format, has almost no line of sight into that fine tuning. It sees a colour and a sentence, once a month.

    I see the same pattern across programme management more broadly, on high-value programmes run under a formal methodology, a programme board, a risk register, stage gates, sign-off criteria at every milestone. I’ve wondered more than once whether the methodology itself is built the wrong way round. It exists to provide assurance: a defensible record that decisions were made properly, risks were logged and treated, money was spent against an approved budget. Removing the actual roadblock in front of the people doing the work was never really part of the design. The methodology can tell you, accurately, that a stage gate was passed on schedule. It has very little to say about what it took to get there, or what’s quietly still broken underneath the tick.

    None of this is a criticism of the programme managers running these things. Most are doing exactly what the methodology asks of them, properly, under real pressure. The bigger comment is about what the methodology was built for: assurance and audit trail on one side, delivery speed and blocker removal on the other. They aren’t the same job, and most high-value programmes are structured to do the first one well, because that’s the one funders, auditors, and boards actually ask to see evidence of.

    Here’s the part that I think matters most, and it’s the part that’s different from Agile.

    What’s actually happening on the ground moves faster than what the steering committee sees. The report is a snapshot, taken at a point in time, and by the time it’s presented, the ground has often already moved, the team has hit a different blocker, solved a different problem, found a workaround for a third thing nobody reported on. The feedback loop back to the committee is the next steering committee. A month, sometimes longer.

    In Agile, the whole design is to shorten that loop, daily stand-ups, sprint reviews every two weeks, the team surfaces blockers in near real time. Steering committees don’t work that way, and structurally can’t, because the people on them have their own jobs, their own functions, and following up between meetings isn’t something most of them have the bandwidth or the mandate to do. The exception is when a committee member has genuine skin in the game, when the outcome affects them directly enough that they chase progress between meetings rather than waiting for the next snapshot. In my experience that’s rare.

    So you end up with two timelines running in parallel. The real one, on the ground, fast, messy, full of small decisions nobody upstream sees. And the reported one, monthly, macro, AMBER-to-GREEN, cost-and-risk, several steps removed from whatever actually moved the needle that month.

    Now bring AI into this picture.

    AI is very good at producing the second timeline. Feed it the underlying data, the status updates, the risk register entries, and it will generate a steering committee pack that reads better than most humans could write under time pressure. Clean summaries. Confident language. A narrative that ties the quarter together. The report gets faster to produce and more polished to read.

    What AI cannot do is shorten the first timeline’s distance from the second. It doesn’t put the committee any closer to the ground. If anything, a more polished, more confidently-worded AMBER status is easier to nod through than a rough one, because it reads like someone has already thought it through. The committee spends the same amount of time on cost and risk register, the chairperson still pulls the conversation back when someone asks the awkward question, and now the summary in front of everyone sounds more finished than the situation actually is.

    This is the version of organisational theatre that worries me most with AI: it closes the gap in how things read while leaving the gap in how things are untouched. Nobody sits down and decides to make AMBER sound like GREEN. The report and the reality were always two different things. AI just makes the report a much better-written version of the wrong altitude.

    I wrote in the first piece about situations where three different parties end up steering the same change, the team, the leadership that announced it, and an external mandate sitting above both. The steering committee is often where those three voices are supposed to meet. If AI is producing the pack that frames that meeting, and the pack reads more confidently than the underlying programme deserves, the committee’s already limited line of sight gets shorter still, dressed up to look longer.

    I don’t have a tidy fix for this. The steering committee format exists for a reason, visibility matters, governance matters, and most of the people in that room are doing their jobs properly. But if AI is going to sit inside that format, generating the packs, summarising the updates, someone needs to keep asking the question the format was never built to answer. What’s the smallest next step. Who’s blocked, on what, right now.

    I asked that question more than once, in more than one of those rooms. Mostly I got told we’d come back to it.

  • What I Left Off my CV

    I asked an AI if it could replace me. The honest answer was sitting in the two jobs I deleted.

    Back in 2024 I updated my CV for a role at Open Polytechnic, and I left two things out. ANZ. ABN AMRO. Two banks, real years, real work, missing from the page.

    I wasn’t job-hunting for sport. I was at Te Pūkenga while the whole thing was being unwound, and a good slice of the tertiary education sector was reapplying for its own jobs at the same time. The CV had to do real work, against a crowd, in a hurry.

    I’m not ashamed of them. They just didn’t fit the story I was telling that one reader. A CV is a signal. You’re pointing at one person who has to decide something about you with very little to go on, and you choose what they get to see.

    That’s the whole game. Most people never name it.

    So when I sat down a few weeks ago and asked an AI the question half my generation is quietly asking, “Can you replace me,” I already suspected the interesting answer wasn’t going to be about what I know.

    The part I’ll concede first

    Let’s be clear about where the machine wins, because denying it is how you lose the argument before you start.

    AI is better than me at most of what I used to get paid for, and faster. Drafting a strategy paper, producing three architecture options with the trade-offs laid out, writing the policy, building the dashboard, generating the risk register. These were once high-value cognitive outputs. They were what a senior person produced to prove a senior person was in the room. They are now close to free.

    A comic where a staff informs his boss that AI can do his job. His boss replies that he can replace his staff. Bu then the staff also points to AI replacing him.

    And here’s the uncomfortable bit. The knowledge underneath all that was never mine to begin with. It’s out there. It’s in the books, the case studies, the frameworks, the same material anyone could find if they read more and researched harder. Gladwell’s 10,000 hours, the tipping point, Lean, Agile, service management, the whole canon I spent decades absorbing. I didn’t invent it. I accumulated it. And accumulation is exactly the thing a model does better than a human.

    So if my value were the knowledge, I’d already be replaced. I think a lot of experienced people sense this and don’t say it out loud, because the alternative feels like admitting the years didn’t count.

    They counted. Just not for the reason most people think.

    What the machine can’t see

    Here’s what I kept coming back to. The AI doesn’t know me. It knows what I’ve published, what’s documented, what’s in the public record. It doesn’t know the things that aren’t written down anywhere: my taste, what I’d refuse to do, how I read a room, why I left two banks off a CV.

    I studied economics at LSE and forgot most of it, but two ideas stuck, and they turn out to be the whole story.

    The first is asymmetric information. The seller knows things the buyer can’t see. George Akerlof wrote about the used-car market, where buyers can’t tell a good car from a lemon, so they assume the average, so they only pay the average price, so the good cars leave the market and you’re left trading lemons. When the buyer can’t tell quality apart, quality stops being rewarded.

    The second is signalling. Michael Spence’s idea, same Nobel as Akerlof. When you can’t show your real quality directly, you send a signal that’s expensive enough that a weaker player couldn’t fake it. The degree, the track record, the reputation you’d lose if you lied. The signal works precisely because it costs something to produce.

    A CV is a signal. My About Me notes, the ones I feed to an AI so it writes in my voice instead of a generic one, those are a signal too. They’re me trying to make the undocumented legible. My taste, my values, the patterns I trust, written down so the machine can see what the public record can’t.

    For about a week I thought that was the answer. Document the judgment, encode the taste, and the part of me that’s scarce becomes portable. Then I noticed the problem.

    The signal gets cheap the moment everyone sends it

    A signal only holds its value while it stays expensive to fake. That’s the entire mechanism. The day it becomes cheap, it stops separating the strong from the weak, and the market does to it exactly what it did to Akerlof’s used cars. It discounts everyone back to the average.

    A documented “here is my judgment” file is cheap. I could generate a plausible one for a stranger in a minute, full of values they’ve never lived and lessons they never paid for. So could you. So when everyone has an AI producing polished strategic thinking, polished thinking stops proving anything. The mid-level manager now sounds strategic. The junior consultant now produces partner-grade decks. The signal floods, and a flooded signal is noise.

    This is the part the AI’s own answer to me missed completely. It told me to “evolve from delivering outputs to architecting judgement systems,” to become a fractional this, an AI-era that. Reasonable, fluent, and indistinguishable from what it would tell anyone with a similar CV. A lemon. Confident, generic, average.

    The drift toward the mean

    I’ve watched this happen with my own hands, in a small and stupid way that taught me more than the economics did.

    I draw a comic strip. Bald characters, no mouths, just eyes and a nose, dry organisational humour. I trained Gemini on a few years of my strips and asked what it needed to draw in my style. After some back and forth it rendered a panel that looked exactly like mine. Then the next one had mouths. And collars. And shirt buttons, on a character that wears nothing but eyes and a nose.

    Gemini drifts. Left alone, it slides back toward its training data, toward the average idea of what a character should look like, and I have to reload my source strips and re-edit the prompt to drag it back. Five or six rounds for a strip I’m willing to publish.

    That’s the mechanism, sitting right there in a cartoon. The machine reverts to the mean unless something private and specific keeps pulling it off course. Feed it your broken process and you get a faster broken process. Feed it the public average and it gives you back a more confident average. The tool doesn’t audit what you hand it, it multiplies it, at a speed that makes the sameness harder to notice.

    So the documented signal doesn’t save you, because the documented signal is what the machine is built to average. The thing that survives is the source material, the actual strip, the actual record of what you really did, the part you keep having to reassert because the average is always pulling the other way.

    The only signal left standing

    Strip it back and one signal is still expensive to fake. The track record of real choices, made under real consequence, that you would defend out loud in a room full of people who were there.

    Look at the choices. Lifting staff engagement 64% at Stats NZ while the organisation was mid-transformation and exhausted. Taking Priority 1 incidents at Inland Revenue from 33 in one year to 3 two years later. Pulling 20% out of platform costs at Te Pūkenga while the whole institution was being disestablished underneath me. Those aren’t artefacts a model can generate. They’re decisions I owned, with my name on them, where being wrong would have cost me something real.

    And the omission belongs in that list too. Leaving ANZ and ABN AMRO off the CV was a judgment, made for a specific reader, with reasons I could explain and defend. The AI can write the CV. It cannot make the call about what to leave out, because that call needs private context it doesn’t have and a consequence it will never carry. The edited CV is the proof of the whole argument. The judgment is in the deletion, and the deletion is the part that isn’t documented anywhere.

    So what’s left to learn

    If the process work and the first-pass decisions go to the machine, and the polished output stops signalling competence, what’s actually worth learning?

    More knowledge won’t do it. The machine already has more than you can accumulate.

    Two things, I think, and neither of them is new, they’ve just become the whole job rather than the senior part of it.

    The first is deciding what’s worth deciding. Framing the real question out of a mess of people, politics, money and history, before anyone produces a single artefact. The machine answers questions beautifully. It has no idea which question matters, and it never carries the cost of getting that wrong.

    The second is signal literacy, in both directions. Reading which signals are still real when the cheap ones are everywhere, and being able to produce one that holds. In a market drowning in fluent, confident, average output, the scarce skill is telling the lemon from the car, and not becoming a lemon yourself.

    The years didn’t buy me knowledge the machine can now match in seconds. They bought me the taste to know which ten minutes of a problem actually matter, and the scars to prove I once paid for getting it wrong.

    The machine has all my knowledge and none of my consequences.

    That’s the gap. I’m not worried about it closing.