That is Rob in the photograph, curly hair and glasses, leaning right across the desk to reach the mouse with his arm blurred by the motion. Three beige monitors. A tower with a little panel of red and green lights on the front. It is a film photograph, so it has dust and scratches on it, which is the correct medium for the story.

Rob Wilson had the better machines, the better poster, and a bedroom his mum had stopped coming into.

Most of the time we were not indoors at all. We were on mountain bikes, riding down flights of stairs, drifting round corners, burning rubber off the back wheel purely for the noise, and coming home with wheels that no longer went round properly. Rob could do an endo: brake hard enough to lift the back wheel and then just sit up there on the front one, balanced, as though it were nothing. Doug could do wheelies, which is the same trick pointing the other way and looks considerably better. I could do neither. What I could do was drive my own groin into the headstock, over and over, for about four summers, trying. It is a wonder I was able to have children. The Linux box was what we did when we were not out ruining our bikes, and our parents were firmly in favour of the Linux box.

The thing that rescued that evening had been sitting on Rob's machine for months and we had found it by accident. He typed bb into a terminal, reaching for something else entirely, and then sat looking at what came up with an expression I remember better than most of that decade. The screen had filled with a spinning, zooming, shading animation made entirely out of the characters on his keyboard. That is what ASCII art is: pictures drawn with letters and punctuation. Underneath bb sat aalib, a library that would turn anything at all into them, written in 1997 by Jan Hubicka and Kamil Toman, who had bought two second-hand monochrome monitors and wanted to put a picture on them. bb became our screensaver for most of a year.

You can open it in a browser right now and be looking at it before you finish this sentence. In 2019, reaching the same thing took a command and a download. Nothing about the demo changed in between. The floor did.

Installing Linux in that bedroom took two floppy disks, a boot and a root. Disk one got the machine as far as being able to read disk two, and disk two was everything else. It was not hard. It was short.

Rob compiled things. I packaged things. I do not think either of us has changed.

I preferred Debian, because of apt, which fetched software for you and, if you typed apt-get moo, drew a cow and granted you Super Cow Powers. I have been telling people for twenty-five years that apt was charming not least because apt gets me a sandwich. The cow is the one I could actually have seen at the time. Memory cost nearly as much per megabyte then as it does now, which is a lie, and a lie that has been getting less funny every quarter this year.

Everybody wanted a 3Com 3C509. Not for its speed, which was ten megabits and unremarkable, but because you could put one in a machine and the machine would simply have a network, which was not how any of the rest of it went. Rob also had a card that did nothing but 3D, a 3dfx Voodoo, which I called an Nvidia for years and was wrong about, right up until Nvidia bought 3dfx's assets and made me accidentally almost right. I never found out what it did. He liked games. I was never into games.

Sound came out of a Sound Blaster, which was a card you went out and bought and fitted yourself, back when a computer would otherwise not make a noise at all apart from a beep. Hold on to that one.

What Rob and I actually did with all this was sell it. In the years when a small office might have four computers and one telephone line, there was a real market for a cheap Linux box that sat in the corner and did the dialling for everybody. Somebody opened a browser, the box heard about it, and the modem started up in the corner while the room waited. I wrote the rules by hand, in ipchains. The router in your hall does that job today and has never once mentioned it.

My longest-running box stayed up for about five years. Linux could not count that high at the time; the counter wrapped somewhere around day 497, so the machine outlasted its own ability to say how long it had been running.

The best machines we sold were the ones nobody ever touched. Twenty-odd years later I applied that same standard to a repository and called it maintenance.

The argument every other household had, the one about the phone line, was never really available to me. I am an only child, and my mother is very deaf.

Which brings me back to the evening the driver broke. MPlayer, the video player on Rob's machine, had an output mode that rendered every frame as text characters instead of pixels. We already knew what aalib was, because bb was sitting right there. So we watched The Matrix as text.

It was green on black, or as close to green on black as a frame buffer could manage, at a resolution best described as several hundred letters. MPlayer's ASCII output hands you keys for contrast and brightness, and Rob rode them for most of the film, hunting for a setting in which a face was a face. I do not think he ever found one. He kept going anyway.

It took months for the obvious to land, and the joke is not a deep one. We had taken a film full of green characters falling down a screen and watched it as green characters falling down a screen, at considerably worse resolution, and neither of us noticed at the time. Not a deeper reading of the film. A worse copy that happened to land nearer the source.

That is the first evening. Here is the second.

In December 2019 I packaged bb as a Docker image, which is a way of bundling a program up with everything it needs so that one command, docker run, starts it on anybody's machine. That was as low as I could get the floor in 2019, and I was right about it. Then I did nothing for six years. The git log is, as ever, more honest than my memory: almost every commit through 2024 and 2025 is a bot called Renovate, noticing that somebody else's base image had a new checksum and opening a pull request about it, roughly thirty times, while I did not look. That is what I mean when I say I have been maintaining this repository for years.

One evening this week I wondered how hard it would be to run bb in a browser instead. I was low on Claude session tokens, so I ran the cheaper Sonnet model, which is what running out of the good stuff looks like in 2026. Minutes later there was a WebAssembly build. WebAssembly is a way of compiling a program so that a browser can run it, which turns the entire business of installing something into a link. Six pull requests over two days, all of them in the same repository I had been ignoring since 2019.

Then it got strange. aalib has been able to draw a cell dim, bold or reversed since 1997. bb's plain-text output driver only ever declared that it supported normal, so aalib, being obedient, rendered every character flat for twenty-nine years. The new build patches one declaration to say that dim, bold and reverse are also acceptable, and the picture acquires depth. Nothing was broken and nothing was hidden. One line in one driver, written in 1997, declined an offer the layer underneath had been making ever since.

Those attribute classes are mapped, in the page's stylesheet, to four shades of green. The source calls it a green phosphor-CRT palette.

The same evening produced static binaries, cross-compiled with zig cc, for around twenty Linux architectures: riscv32, mips, loongarch64, both endiannesses of ppc64, and a Hexagon DSP. Plus FreeBSD, NetBSD, OpenBSD, Windows and macOS. Getting one small program onto twenty-odd architectures used to sit at the far end of a career. It is now an evening's idle curiosity.

Nobody has ever wanted this.

I should be careful about whose evening that was. It was made out of other people's decades. Somebody wrote a compiler that will build for a processor it has never met. Somebody built the sandbox that lets a browser run a program written years before browsers could run programs. Somebody is, this afternoon, maintaining a C library for an architecture I had to look up in order to spell. I did none of it. I asked for a thing and went to put the kettle on. The floor did not rise on its own. It was carried up in pieces, over twenty years, by people whose names are not in this article, and the honest version of my delight is that I am standing on their work admiring the view.

I should also admit that I now spend most of my working life in a terminal with eighteen panes open, which is not where I expected the future to put me.

Then the sound.

A file called bb.s3m, a genuine Scream Tracker 3 module, has been in the source tree the entire time, alongside working drivers for Sound Blaster, PC speaker and Gravis UltraSound. The claim we read on that CRT was never a bluff. It was a driver. I never heard it, and I do not think he did either, because the Unix build played through /dev/dsp, and on any later desktop that fails silently while the text on screen still cheerfully describes the hardware it supports. The WebAssembly module still cannot make a sound, because the sandbox it runs in has no audio at all, so the browser plays the actual 1997 file alongside the demo, out of step with whatever is on the screen.

I heard it for the first time in August 2026, on my own, in a tab. It was Rob's card, in Rob's tower, in Rob's bedroom, and the two of us were sitting right in front of it when it told us what it could do.

A while back I wrote that the craft was never the point, that access was, and that depth is a gift and not a toll. I still think that. What I had not noticed is that a gift has a shelf life. Nobody takes it back. It simply stops being one.

Nobody moved the demo. The floor came up underneath it, and I was still standing on the old one holding a Docker image, quite pleased with myself.

I did not notice, because the person who lays a floor is the last person in the building to look at it. The command I put there in 2019 to let people in is now the thing standing between them and the door.

NDX took three years to teach me, at national scale, that handing somebody access is not the same as handing them something they can use. Same law here, opposite outcome, for exactly one reason. The useful thing was already in the room. A 1997 demo takes about ten seconds and needs nobody to introduce it. All that was ever missing was the floor.

My children have lately been getting both feet up onto the crossbar and riding along like that until the bike slows enough that they have to jump off. It is a deep joy to watch and I am not at all sure it is a good idea. Nobody had to lower anything for it.

There is something you loved once that is one evening away from being reachable again. It will not matter to anyone. That has never been much of an argument against it.

Rob will read this before most of you do, and I have probably got half of it wrong: the years, the order, which machine we were sitting at.

So there are two screens in this story. A beige monitor in a bedroom under a poster, and a tab on whatever you are reading this on. The same demo both times, and neither of us improved it in that bedroom, and I did not improve it this week. It was fine in 1997. It was fine in 2019. It is fine now, and almost nobody will open it, which was equally true in that bedroom. The only thing that changed is who could reach it, and I was not the one who moved.

https://bb.cns.me

(Views in this article are my own.)

Barbon did something nobody had done at scale before. He offered to rebuild your house for a fixed price. You told him what you wanted, he told you what it would cost, you paid him, and he delivered it. The genius of the arrangement was that it transferred all the risk from you to him. If the timber cost more than expected, his problem. If the labour took longer, his problem. If the foundations turned out to be unstable, his problem. You got certainty. He got the contract.

What Barbon understood -- and what every builder, contractor, and technology consultancy has understood ever since -- is that human beings will pay a premium for the feeling of control over an uncertain process. The fixed-price contract is not a tool for managing construction. It is a tool for managing anxiety.

There was, of course, a catch. Barbon's buildings were notorious. Thin walls, cheap materials, corners cut with the casual indifference of a man who had already been paid. He is remembered today not as the father of modern construction contracts but as the father of jerry-building. The London Building Act of 1667 -- one of the first building codes in the world -- was written in direct response to the quality of his work.

That was 1666. I want to tell you about something that happened to me about nine years ago, the uncomfortable truth at the centre of this story is not that I hired bad builders. It is that I was a bad client.

The Slow Accumulation

If you ever want a recommendation for a bad builder, I would say me first. Not the builder -- me. I chose them. I managed the project. I failed to do the due diligence that was available to me. I did not hire a quantity surveyor, which the Federation of Master Builders will tell you costs 1-3% of the project budget and has the highest return on investment of any fee you will ever pay on a renovation. I did not use a formal contract. I did not check whether my builders had, individually or collectively, ever executed a job this big.

They had not.

This is the part that most renovation horror stories leave out, and it is the part I need to name before I blame anyone else. The builders were not malicious from the start. They were in over their heads. They had not individually executed a project of this complexity before, and they were naive about their own capabilities in the way that every craftsman who has ever taken on a stretch assignment has been naive. They believed they could do it. I believed they could do it. We were both wrong.

And they were not making this choice in a vacuum. In an industry where 82% of contractors bid below cost to win work, the alternative to overbidding is often no work at all. The honest builder who prices a job at what it will actually cost loses the job to the one who prices it at what the client wants to hear. My builders were not outliers. They were the system working as designed.

The realisation of betrayal was slow, not sudden. It was not a single moment of discovery but a gradual accumulation -- a drip, drip, drip of small things that were not quite right. The bathroom tap that ran a thin bead of water down the wall behind it whenever you turned it on, because it had not been seated properly -- something I would not discover for three years, by which time the plaster behind the tiles was rotten. A conversation where the answer to my question was just a little too quick, a little too smooth, delivered with the confidence of someone who is performing knowledge rather than possessing it.

Then the splashback glass.

I had paid for a single, large piece of glass as a kitchen splashback. One piece. No joins. The builders could not be bothered to remove the taps. Rather than take the taps off, disconnect them, fit the glass, and reconnect -- which is, to be clear, the job -- they insisted the glass cutters take the glass away and cut it in half so it could be fitted from both sides. Two pieces where there should have been one. A join where there should have been none.

I see that join every single day.

That is not the worst of it. Under a floorboard, during a later repair that I should not have needed to make, I found a Dominos pizza box. With scraps of pizza still in it. Stuffed under the floor for no apparent reason by people I was paying to build me a home.

You might think I am telling you this because it is dramatic, because pizza boxes under floorboards make good stories at dinner parties. I am telling you this because the pizza box is the Ronan Point of domestic renovation. In 1968, when investigators pulled apart that collapsed tower block in east London, they found newspapers stuffed in panel joints. Not malice -- indifference. The kind of indifference that settles in when a builder is in over his head, behind schedule, out of his depth, and has stopped caring about the work because he has started caring about survival. Newspapers in 1968. Pizza boxes nine years ago. Technologies change. Human nature does not.

Samuel Morton Peto and the Descent

Samuel Morton Peto was, by the 1840s, the most respected railway contractor in Victorian Britain. He built Nelson's Column. He built the Reform Club. He built railways across three continents. He was a Baptist, a philanthropist, a Member of Parliament, and -- by all accounts -- a man of genuine integrity. He paid his workers fairly. He completed contracts on time. He was, in the language of the construction industry, a safe pair of hands.

Then he took on too much.

The railway boom of the 1840s and 1850s created extraordinary demand. Peto, like every successful contractor before and since, expanded. He took on contracts that were larger, more complex, and more geographically dispersed than anything he had managed before. The investors demanded returns. Parliament granted railway concessions with enthusiasm and oversight in roughly inverse proportion. The fixed-price model that had made his reputation became the mechanism of his destruction. When costs exceeded estimates -- and they always did, because railway construction through unfamiliar terrain is genuinely uncertain work -- Peto absorbed the losses. When the losses mounted, he borrowed. When the borrowing became unsustainable, he began to cut corners.

This is the arc I want you to see, because it is the arc of my builders.

Peto did not wake up one morning and decide to become dishonest. The dishonesty developed incrementally, under pressure, over time. A cheaper material here. A thinner rail there. A foundation that was adequate rather than excellent. Each individual compromise was small. Each was rationalised. Each was the product not of villainy but of a man who had got in over his head and could not find a way back.

When the Overend, Gurney banking crisis hit in 1866, Peto's entire empire collapsed. He was bankrupted. The man who had built Nelson's Column died in relative obscurity, his reputation destroyed not by a single act of fraud but by a long, slow descent from good faith to corner-cutting that was -- and this is the point -- structurally inevitable given the incentives he faced.

His workers, for the record, fared worse. The navvies who had dug the cuttings and laid the rails had no pensions, no redundancy, no recourse. They went to the next job or they went to the workhouse. The system that broke Peto ground them to dust.

That was 1866. My kitchen was 2017. The distance is cosmetic.

The Arc You Recognise

My builders were not Samuel Morton Peto. They did not build Nelson's Column. They were not Members of Parliament. But the arc was identical. They started with good intentions and genuine, if naive, confidence. They took on a job that exceeded their capabilities. When things went wrong -- and in renovation, things always go wrong, because you do not know what is behind that wall until you open it -- they did not stop and say "we are out of our depth." They pushed forward. The corners they cut got bigger. The quality dropped. And somewhere in that process, the relationship between us shifted from collaboration to something adversarial.

I watched YouTube videos at midnight to understand earth continuity issues. I watched YouTube videos to learn how to apply silicone around a bath fitting -- not how to do it well, mind, but how to tell whether someone else had done it at all. These were things the experts were supposed to handle. The fact that I was teaching myself their trade on a screen at half past eleven, still in my coat because I had just come from work, whilst paying them to do it -- that should have been the moment I fired them. It was not. Because by that point, the sunk cost fallacy had me as firmly as it had them. I had invested too much money, too much time, too much emotional energy. They had invested too much labour, too much reputation, too much identity. Neither of us could walk away.

The economists have a name for this kind of market. Construction is a credence good -- a product or service whose quality cannot be evaluated even after consumption. You can taste a meal and know if it was good. You can drive a car and know if it handles well. But a re-wired house? A re-plumbed bathroom? The defects may not reveal themselves for a decade. The tap that weeps behind the tiles. The earth bonding that was never tested. The joist that was notched too deep to take the pipe. My house has been revealing its defects for nine years, and I am still finding them.

I should be precise here, because the blanket condemnation of fixed-price contracts is too easy. Replacing a boiler is not the same as renovating a Victorian terrace. A boiler replacement is commodity work -- known scope, known components, known installation patterns. You can price it accurately. A fixed-price contract works fine. But structural renovation of a house built 130 years ago, where you genuinely do not know what is behind that wall until you open it? That is uncertain work. The fixed-price contract turns that uncertainty into a bet, and the builder absorbs every surprise as a loss. The question is not whether fixed-price contracts are bad. The question is whether you are using a commodity contract for custom work. Most domestic renovations are custom work priced as though they were commodity. That is where the trouble starts.

The UK has no mandatory licensing for general builders despite 81% of the public supporting one. Stop and think about that for a moment. Medicine is a credence good -- you cannot evaluate your surgeon's work while you are under anaesthetic. Law is a credence good -- you cannot assess your solicitor's competence until the verdict. Financial advice is a credence good -- you will not know if your pension was well managed until you retire. All three are licensed professions. Construction, where the consequences of failure include structural collapse, electrical fire, and gas explosion, is not. Why? Because the skilled builders who would benefit from licensing are too fragmented and too busy surviving to lobby for it, while the system as it stands suits the large developers and volume housebuilders who run their own quality assurance and profit from a domestic market where small builders absorb all the risk and homeowners absorb all the consequences. Apprenticeship completion rates fell to 41% in 2024. The skills pipeline is collapsing. Nobody with power is doing a thing about it.

The uncomfortable truth I keep returning to, the one that Nicholas Barbon's clients in the 1670s could have told you, and that Peto's railway investors learnt to their cost in 1866: an uninformed client with strong opinions is the worst thing that can happen to a build.

I was that client.

The Tour of Shame

I do the tour of shame now. Visitors come to the house and I walk them through it and I narrate, internally, every hidden defect behind every wall. The bedroom door that does not sit square in its frame -- you can see daylight through the gap at the top if you look at the right angle, and I always look at the right angle. The plaster in the hallway that is slightly uneven because they skimmed it too fast, and every time the evening light hits it from the west I can see the ripple. The electrical work that I had to check myself because I could not trust that they had tested it properly. Nine years of walking through my own home and seeing not the home but the archaeology of a failed relationship.

The IKEA effect -- Norton, Mochon and Ariely showed that labour leads to love -- works only when the outcome is successful. Build a bookshelf and it wobbles slightly and you love it more because you built it. But a failed renovation inverts this entirely. The labour creates not love but hyper-vigilance. You notice every imperfection because you paid for it, you fought for it, you watched it go wrong, and you could not stop it. Nine years of noticing is the IKEA effect in reverse.

The builders, to their credit -- or perhaps to nobody's credit -- did not set out to do this to me. They set out to do a good job and failed. I set out to be a good client and failed. We were both trapped by a market structure that Akerlof described in 1970 as the market for lemons: when the buyer cannot distinguish quality from junk before purchase, the market degrades until only junk is left. That is domestic construction in Britain. The FMB reports that fear of cowboy builders costs the UK economy ten billion pounds a year in forgone work. 40-78% of renovations exceed budget. But they also report that 75% of builders say cowboy clients are a serious problem. The dysfunction runs both ways.

What Barbon Knew

Nicholas Barbon, standing in the ashes of London in 1666, understood something that we have been trying to unlearn for 360 years. He understood that the desire for certainty in an uncertain process creates a contract that is adversarial by design. The fixed-price contract says: I will tell you what it costs, and you will pay it, and whatever happens behind the walls is my problem. It is a bet disguised as an agreement. The builder bets he can do it for less than the price. The client bets the price covers everything. Both are usually wrong.

Barbon also knew that an unregulated market with no quality signals will always drive out the honest operators. His jerry-built houses were cheaper than the good ones. His clients chose price over quality because they had no mechanism to distinguish the two. Three hundred and sixty years later, the mechanism still does not exist.

If you are renovating a house, the advice is brief and specific. Hire a quantity surveyor. Use a JCT Minor Works contract. Ask yourself whether the work is commodity or custom -- and if it is custom, stop pretending a fixed price means anything. Use time-and-materials with stage gates, independent inspection, and the right to walk away.

But I did not write three thousand words about Nicholas Barbon and a pizza box to give you renovation tips.

If you commission digital transformation -- or, as is now unavoidable, AI transformation -- you are standing in Barbon's London right now. The ashes are different. The dynamics are identical.

You are buying a credence good. You cannot evaluate the quality of an AI model's training data any more than I could evaluate the wiring behind my walls. You cannot tell whether the retrieval-augmented generation pipeline your vendor built is robust or brittle -- not at delivery, not six months later, possibly not ever -- until it hallucinates in production at the worst possible moment and you discover that nobody tested the edge cases because nobody scoped them and the contract did not require it. The defects are hidden by design. The plaster goes up. The demo looks clean. And behind the wall, there is a pizza box.

You are hiring vendors who are in over their heads and will not admit it. The AI consultancy market in 2026 is my builders in 2017 at industrial scale. Teams that have never shipped a production AI system are bidding for contracts that require it. They believe they can do it. They are not lying -- not yet. They are naive about their own capabilities in exactly the way that Peto was naive when he took on one railway too many. The overconfidence comes first. The corner-cutting follows. The dishonesty arrives last, incrementally, structurally, and by then the sunk cost fallacy has you both locked in.

You are signing fixed-price contracts for work that is genuinely uncertain. Building an AI system on your proprietary data, integrated with your legacy architecture, subject to regulatory constraints that are changing quarterly -- that is not a boiler replacement. That is opening a wall in a Victorian terrace and discovering that the previous owner ran the plumbing through a load-bearing beam. The honest answer is "we do not know what this will cost until we understand what we are dealing with." The winning bid is the one that pretends otherwise. Barbon would recognise the arrangement instantly.

And you have no feedback loop. In construction, I could have hired a quantity surveyor -- an independent expert whose job is to see what I cannot see and say "stop" before the damage is done. In AI transformation, the equivalent barely exists. The people evaluating the vendor's work are often the vendor's own team. The client's internal reviewers -- if they exist at all -- lack the specialist knowledge to assess model performance, data quality, or architectural decisions that will compound for years. You are the homeowner who does not know what good wiring looks like, paying someone who may not know either, with no one in the room whose job it is to tell the truth.

The sunk cost trap closes around AI programmes even faster than it closed around my kitchen. The budgets are larger. The switching costs are higher. The executive who championed the initiative has staked reputation on it. And the vendor -- behind schedule, under-resourced, performing confidence rather than possessing competence -- cannot afford to say "we are out of our depth" any more than my builders could. The incentives are aligned for silence. The silence is aligned for failure.

None of this is inevitable. Use contracts that acknowledge uncertainty rather than wishing it away. Insist on independent technical review at every stage gate -- someone who works for you, not for the vendor. Demand that the commodity-versus-custom question is answered honestly before a price is agreed. Build the feedback loop that the market will not build for you.

I have spent nine years living with the consequences of a market that Nicholas Barbon invented in the 1670s, that Samuel Morton Peto navigated in the 1850s, and that every organisation commissioning an AI transformation is navigating right now. The technology changes. The materials change. But the human dynamics -- the overconfidence, the sunk costs, the credence good problem, the slow accumulation of small compromises until the whole thing is rotten -- those do not change.

I know that every morning. The join in my splashback glass tells me.

(Views in this article are my own.)

That reads like a paradox. It is not. It is a constraint architecture principle that most technology organisations have never internalised -- and the consequences show up in every breach report and every outage postmortem.

We have spent two decades building faster pipelines, faster deployments, faster feedback loops. And yet 81% of organisations knowingly ship code with known vulnerabilities, with 38% doing so explicitly to meet deadlines. The pipeline is fast. The decisions flowing through it are not good. These two facts are not unrelated.

The real question is not how to make your pipeline faster. It is where to place the gates.

Constraint Architecture: The Discipline We Skipped

There is a discipline that gets this right, and it is not one most technologists would think to study. Skydiving's flightline check -- descended from the military Jumpmaster Personnel Inspection codified at Fort Benning from 1940 -- is a peer-performed, every-jump gear inspection following a protocol called the Check of Threes: three rings (the release system), three points (the harness), three handles (main deployment, cutaway, reserve). It occurs at three stages: self-check, buddy check, and a pre-exit pin check at the aircraft door.

The flightline check is designed friction. It is a gate that exists not despite the need for speed but because of it. Every skydiver wants to exit the aircraft quickly and cleanly. The check does not prevent that. It prevents the one thing that would make speed catastrophic: an undetected configuration error in a system where the consequences of misconfiguration are irreversible.

This is not a safety net. Safety nets catch you after you fall. This is a constraint placed before the point of no return -- a gate that reduces rework to zero by ensuring the system is correctly configured before it enters an environment where reconfiguration is impossible.

The Paradox of Designed Friction

One could argue that gates slow you down. The evidence says otherwise.

When Toyota and General Motors opened the NUMMI plant in Fremont, California, they gave every worker on the line the ability to stop it using an andon cord. The conventional wisdom was that stopping the line was the most expensive thing a factory could do. Toyota's insight was the opposite -- because defects that passed one station compounded at every subsequent station. Defects dropped from 135 to 45 per 100 vehicles. Labor hours dropped from 31 to 19.

85% of andon pulls resolved within 60 seconds without a full line stop. The gate did not slow throughput. It increased throughput by eliminating the rework that had been consuming it.

Atul Gawande demonstrated the same principle in surgery. The WHO surgical safety checklist -- a two-minute pause before incision -- reduced surgical deaths by 47%. Two minutes of designed friction eliminated nearly half the fatal errors in a process performed by highly trained professionals who believed they did not need a checklist.

IBM documented the economics decades ago: a defect caught in production costs 100 times more to fix than one caught in design. The gate is not a cost. It is a 100x cost avoidance.

Where Gates Fail

Not exactly. The counterargument against gates is real, but it targets the wrong thing. It targets gate existence when it should target gate design.

Gates degrade. This is documented and measurable. LOSA data shows that 49% of airline flights involved intentional procedural noncompliance -- pilots skipping checklist items they considered unnecessary. In one study, Bedford G-IV pilots skipped flight control checks on 98% of 175 takeoffs.

Diane Vaughan named this pattern after analysing the Challenger disaster: normalisation of deviance, the process by which repeated success without consequence makes rule-breaking invisible.

The skydiving community knows this failure mode. An experienced team of five with 40,000 combined jumps once collectively missed a misrouted chest strap during their buddy checks. Two military fatalities in the last decade -- including Spc Perez in 2024, whose jumpmaster falsified the inspection -- traced directly to gates that had degraded from inspection to ritual.

The conclusion is not that gates do not work. The conclusion is that gates are architectural components, and like all architectural components, they require design and maintenance. A gate that is never maintained becomes a rubber stamp -- and a rubber stamp is worse than no gate at all, because it creates false confidence.

Three Properties of Effective Gates

If we model the gate as an architectural component rather than a process step, three design properties emerge:

1. Enforcement at the constraint boundary. The gate must sit at the point where the cost of a defect changes discontinuously. In skydiving, that boundary is the aircraft door -- the last moment when a configuration error can be corrected without deploying a reserve or dying. In software, the equivalent boundary is the deployment (or better yet, the runtime) point. Google's Binary Authorization enforces attestation at deployment, not at commit. The gate sits where it matters, not where it is convenient.
2. Independence from the flow it inspects. The buddy check works because the person checking your rig is not you. The surgical checklist works because the nurse reads the checklist, not the surgeon. The moment the person performing the check is the same person who benefits from skipping it, the gate has a structural conflict of interest. In software terms, this is why the team that writes the code should not be the only team that approves the deployment.
3. Resistance to normalisation. The gate must be designed to resist the very degradation that Vaughan described. Skydiving addresses this through annual Safety Day, mandatory requalification, and a culture that treats peer accountability as a social norm. Netflix addresses it through paved roads -- making the safe path the easy path, so that circumventing the gate requires more effort than following it.

The Decision Architecture of Placement

The real design problem is not whether to have gates. It is where to place them and what to enforce at each one. This is a decision architecture problem, and it has trade-offs that most organisations have never made explicit.

A gate placed too early catches defects cheaply but cannot see integration failures. A gate placed too late catches everything but at a cost that makes remediation painful. The Verizon DBIR's finding that 68% of breaches involve human error is not an argument for more training. It is an argument for better gate placement -- for architectural interventions that catch human error before it reaches a point where the consequences are irreversible.

CrowdStrike's July 2024 incident is the canonical example. A single configuration change crashed 8.5 million devices simultaneously and cost Fortune 500 companies $5.4 billion. The root cause was the absence of a gate at the deployment boundary -- no staged rollout, no canary, no attestation that the change had been validated against the target environment.

Three absent checks. $5.4 billion.

The Check That Slows You Down Is the Check That Speeds You Up

Skydiving's fatality rate has improved 48-fold since 1961. The sport did not achieve this by making parachutes faster to deploy. It achieved it by placing constraints at the right points in the process -- constraints that feel like friction in the moment but eliminate the catastrophic rework of a fatality investigation, a grounded fleet, or a destroyed reputation.

The gate is a constraint. And constraints, as any architect knows, are not obstacles. They are design drivers. The flightline check does not slow the skydiver down. It is the reason the skydiver can jump with confidence, at speed, knowing the system has been verified at the boundary where verification matters.

If your deployment pipeline has no gate at the point of irreversibility, you have not optimized for speed. You have optimised for the appearance of speed -- and the difference, when it matters, is measured in billions.

(Views in this article are my own.)

Second confession while I'm at it: the site is mine. I registered devpsyops.com in 2023 as a dry joke about the *-ops inflation and put a unicorn on the homepage. Look closely and the joke stops being a joke, because psyops is a real discipline, the US Army publishes a field manual on it and every platform team, every DevRel function, every engineering director I've met is running an amateur version of it on their own staff. Badly. Without a map. And calling it culture.

So here's a thought experiment. You're a platform engineering lead. Your mandate is "drive adoption of the internal developer platform." You have a roadmap, OKRs, a Slack channel with a mascot. What you don't have is any of the vocabulary actual influence professionals use every day: target audience analysis, information environment, lines of effort, behaviour-based measures of effectiveness. You measure "adoption" in logins. And you wonder why, eighteen months in, the staff engineers you most wanted to convert are quietly running their own Terraform and your exec sponsor has gone quiet.

You're playing chess without a board. Again.

PsyOps is an old, boring, industrialised craft

A quick reality check first. In 1991, during Operation Desert Storm, coalition forces dropped roughly 29 million leaflets on Iraqi positions, iterating message and design based on A/B tests run on captured prisoners of war to see which variants actually produced surrender behaviour. Behaviour-based measurement of effectiveness, at population scale, on paper, thirty-five years ago. Product management, circa 1991, with a better feedback loop than most platform teams have in 2026. And Edward Bernays had already written "The Engineering of Consent" in 1947 he chose the word "engineering" for the shaping of publics because he knew exactly what he was doing and wrote the manual. This craft is older than software. We're the amateurs, not the pioneers.

Where the influence layer actually sits on the map

Here is the map everyone already draws.

Start with the user at the top - your own engineers, the people whose behaviour the platform team is trying to change. Below the user sits the need: "I want to ship without pain." Below that sit the visible components - CI, deployment, observability, service catalogue, docs - strung out across the Product and Commodity end of the axis, and most platform teams can tell you roughly where each one sits. Fine. That's the bit everyone draws.

Now drop one layer further, to the thing no-one draws: the narrative layer.

Internal comms, brown bags, the quarterly roadshow, the champion programme, the "bottom-up, top-down" PlatformCon talking points, the executive whisper network, the anonymous complaints in #random. That layer has a value chain of its own: target audience analysis, message design, channel selection, delivery, feedback, iteration. On the map it hangs beneath the tooling, holding it up - because it directly determines whether any of the kit above it gets used.

Now look at where that layer has landed on the evolution axis. Go on, track it back to the left edge of the map.

In almost every org I've seen, it sits in genesis. All of it. Hand-rolled. Bespoke. Undocumented. The platform lead is writing internal comms from a blank Google Doc on a Sunday night. The staff engineer with the "Right Hand" archetype, Will Larson's name for the one openly acting as political advisor to a VP, compared to the Hand of the King and Leo McGarry is doing target audience analysis in their head and calling it "reading the room." DevRel measures engagement in likes because nobody has taught them to define a behaviour-based MOE. The feedback loop is a retrospective where someone says "we need to do more internal marketing" and everyone nods. There is no doctrine. There is no playbook. There is barely a vocabulary.

Meanwhile, the vendors your engineers read every morning are operating the same layer at commodity scale. Gartner booked $6.3 billion in 2024, largely from the same vendors whose products it rates and when challenged in court, Gartner's successful defence was that the Magic Quadrants are "opinion", a legal win and a strategic confession in the same breath. IT Revolution runs the conference circuit and publishes the canon. Microsoft renamed Visual Studio Team Services to Azure DevOps on 10 September 2018 and walked off with the word the community had spent nine years building. That was not a product launch. That was a vocabulary capture operation. It worked.

This is evolution-axis asymmetry, and it is the most important feature of the landscape no-one is drawing. Your internal influence layer is in genesis/custom, fragile, personality-dependent, running on the unpaid glue work Tanya Reilly named so precisely. The vendor influence layer aimed at the same target audience is fully industrialised: analysts, conference tracks, certification programmes, sponsored benchmarks, practitioner books that use "marketing" where your team says "community". One side is hand-drawing on a napkin. The other side has an artillery battery. And the asymmetry is not weather it's a business model. Engineers pay the cognitive rent; vendors collect the attention rent. That is the economic relation underneath the word cloud, and it stays invisible precisely because the amateur version stays in genesis while theirs runs at commodity scale.

Doctrine versus gameplay, stop selling one as the other

The psyops frame forces you to separate doctrine from gameplay, and almost no-one does.

Doctrine is the universal bit. It applies whether you're a bank, a bakery, or a government department. "Know your user" is doctrine. "Define the behaviour you want before you measure anything" is doctrine. "Don't confuse engagement with effect" is doctrine. "Psychological safety is the precondition for everything else" is doctrine, Amy Edmondson wasn't writing context-specific advice. The SPACE framework treating satisfaction and communication as load-bearing dimensions of productivity doctrine. The DORA evidence that generative culture predicts delivery performance doctrine. A platform team that cannot state its doctrine in one page shouldn't have a budget.

Gameplay is the context-specific bit. "Rename your product Azure DevOps and walk off with the attention territory your competitors built" is gameplay. It worked for Microsoft in 2018. It would be idiotic for anyone else. "Mandate adoption from the CTO's office" is gameplay 36.6% of platform teams in the 2024 Humanitec survey are doing it, and roughly 40.9% can't prove value inside twelve months, which tells you something about whether the mandate is doing the work people think it is. "Pilot with three volunteer teams" is gameplay. "Hire an internal DevRel" is gameplay. None is right or wrong in the abstract. They are right or wrong for a specific landscape at a specific moment.

The consultant move and I mean the move, not the person is to sell gameplay as doctrine. "You need a platform." "You need a champions programme." "You need a golden path." These are gameplay options that depend entirely on where your components sit on the evolution axis. Offering them as universal prescriptions is the same category of error as selling one *-ops label regardless of context. Expensive prattle, and dressing it up in the language of developer experience doesn't change what it is.

The unseen landscape

So what's actually unseen? Three things, and if you map nothing else today, map these.

First, the target audience. Not "developers" as a generic noun a specific, segmented audience. The BICEPS-core-needs-aware staff engineer with scar tissue from the last platform migration is not the same audience as the new grad who'll happily use anything with good docs. You cannot run one line of effort at both. You know this in product. You've forgotten it internally. And remember the mascot on the homepage: in Gene Kim's Phoenix Project frame, unicorns were the mythical high-performing teams Netflix, Etsy and horses were the rest of us. The unicorn on devpsyops.com isn't the mascot of the discipline. It is the target audience of it. The whole internal influence machine is pointed at convincing the horses they ought to want to be unicorns, and the horses have noticed.

Second, the feedback loop. Every amateur psyop I've seen treats adoption dashboards as feedback. They are not. They are outputs. A real MOE asks: what behaviour changed, in whom, for how long, compared to what counterfactual? If your answer is "logins went up," you are measuring the wrong thing. DevEx research from Noda, Storey, Forsgren and Greiler already tells you the dimensions that matter feedback loops, cognitive load, flow state and none show up in a login count.

Third, the doctrine itself. Write it down. One page. What does your platform team believe about how humans adopt tools, about psychological safety, about mandates, about volunteer pilots, about the moral status of internal comms? If you can't write it down, you don't have one, which means every new hire is reinventing it on a Sunday night. That is custom-built. That is genesis. That is where your costs are hiding.

The humble close

I might be wrong about a lot of this. The mapping might not translate cleanly to your organisation. The doctrine I'd argue for might be a fluke of the three or four environments I've watched closely. Gameplay definitely varies what worked at one platform team will misfire at another.

But what I am not hedging on. The influence layer exists in your organisation whether you name it or not. Every engineering leader is already running a psyop on their own people with no vocabulary, no doctrine, no feedback loop worth the name, and a unicorn on the wall they haven't noticed is pointing at them. Naming the work as what it is influence operations on a knowable target audience, with doctrine you can teach and gameplay you invent is the honest version of the job the industry has been renaming for fifteen years to avoid admitting what it does.

Draw the map. Start with the narrative layer, not the tooling. Plot where your internal influence work sits on the evolution axis, then plot the vendors'. Look at the gap. Feel slightly ill. Write down your doctrine. Kill half your gameplay. Try the other half and see what breaks.

And before you close the tab: the unicorn on the homepage isn't looking at you. You are looking at it. Convincing horses they ought to be unicorns is the whole job, and you've been doing it unpaid, uncredited, without a map, for years. The amateurs ran 29 million leaflets past POWs in 1991 and called it doctrine. You can at least write yours down by Friday.

(Views in this article are my own.)

Forty-three years later, Hanks stood at a podium to accept the Cecil B. DeMille Award at the Golden Globes and told the world that those three rules were the most important lesson he ever received. Not from a film school. Not from a director on a hundred-million-dollar picture. From a man running a regional theatre in Ohio who refused to tolerate laziness. "You have got to show up on time," Hanks said, "and you have to know the text and you have to have a head full of ideas. Otherwise, I can't do my job."

I have been thinking about those three rules for months. Not because they are profound -- they are obvious. I have been thinking about them because they describe, with painful precision, everything the technology industry has collectively decided not to do.

The Word Itself

The word rehearsal comes from the Old French rehercier, meaning to harrow again -- to re-plough soil that has already been ploughed. This is not a metaphor about repetition. It is a metaphor about preparation as physical labour. You take the ground apart. You break it up. You turn it over. Then you do it again. The soil does not improve because you walked across it. It improves because you worked it.

The technology industry has lost this understanding. Preparation is not skimming a document five minutes before a meeting. It is the deliberate, effortful act of working material until you have internalised it -- until you can respond to it, challenge it, build upon it. Goethe understood this in 1803 when he wrote his Rules for Actors: rehearsal conditions must match performance conditions. The performing arts have known for centuries that preparation is not optional. It is the work.

A Sequence, Not a List

What Sullivan gave Hanks was not three independent virtues. It was a sequence. Each rule unlocks the next.

You cannot know the text if you do not show up on time. Showing up late is a statement -- it says the text does not matter, the other people in the room do not matter, and the work itself can wait. You cannot have an idea if you do not know the text. Ideas that emerge from ignorance are not ideas. They are guesses dressed in confidence. And confidence without preparation is the most expensive thing in technology.

The jazz analogy proves the point. Miles Davis hired virtuosos precisely because they already knew the text so thoroughly that they could depart from it with purpose. The freedom came from the preparation, not instead of it. Without that substrate of deep knowledge, you have nothing to adapt, nothing to depart from. You are improvising from zero, and improvisation from zero is not jazz. It is noise.

This sequential logic -- Rule One enables Rule Two enables Rule Three -- is also a diagnostic. When things go wrong, you can trace the failure backwards through the chain to find where it broke. And once you start looking, you see it everywhere.

Then Like Now

In 1935, Boeing's prototype B-17, the Model 299, crashed on takeoff at Wright Field in Dayton, Ohio. The aircraft was not faulty. The pilot -- an experienced test pilot named Ployer Peter Hill -- simply forgot to release the elevator lock. He did not know the text. Boeing's response was not to blame the pilot. It was to invent the pre-flight checklist: a system designed to ensure that every human being, no matter how experienced, would be required to know the text before they performed. The checklist did not replace competence. It enshrined it.

That was a Rule Two failure. The pilot showed up. He was ready to fly. But he had not worked the material -- had not harrowed the soil -- and the aircraft fell out of the sky.

That same company, Boeing, decades later shipped the 737 MAX without disclosing the MCAS system to pilots or airlines. Three hundred and forty-six people died. The company that invented the checklist -- the company that understood, in 1935, that knowing the text is a matter of life and death -- decided that schedules mattered more than preparation. They stopped knowing their own text. Worse, they ensured their pilots could not know it either, because the text was hidden from them. That is not a Rule Two failure. That is a Rule Three failure -- the leadership had no idea worth the name, only a schedule and a share price.

The same pattern destroyed the Space Shuttle Challenger. In 1986, engineers at Morton Thiokol knew the O-rings would fail in cold weather. They had the data. They knew the text. But when management pushed back, one executive told the lead engineer to stop being an engineer: "Take off your engineering hat and put on your management hat." That is a Rule Three failure in its purest form. The text was known. The data was clear. But the leadership's idea of what mattered -- schedule, optics, political pressure -- was rotten, and rotten ideas corrupt everything downstream. The engineers were told to unknow what they knew.

Captain Chesley Sullenberger, who landed US Airways Flight 1549 on the Hudson River in 2009, provides the counter-example. He said afterwards that "my entire life had been a preparation to handle that particular moment." He had 19,663 flight hours. The emergency lasted 208 seconds. Every hour of those 19,663 was rehearsal. Every hour was harrowing the soil again. When the moment came, Sullenberger did not need to think. He knew the text so deeply that his ideas -- the split-second judgements about altitude, speed, river versus runway -- emerged from preparation, not panic.

That is what the sequence buys you. Not certainty. Not a script for every scenario. It buys you the capacity to respond to the scenario you did not predict, because you have worked the ground so thoroughly that your judgement is calibrated and your ideas emerge from deep knowledge rather than shallow guessing.

The Diagnosis

Only 31% of software projects succeed -- a number that has barely changed in decades despite agile transformations, DevOps revolutions, and billions spent on tooling. Nobody knows the text because nobody wrote it. That is Rule Two, collapsed at scale.

The Cortex 2026 Engineering Benchmark found that incidents per pull request have risen 23.5% and change failure rates are up roughly 30%, despite -- or perhaps because of -- AI-assisted development. We are moving faster. We are not moving better. That speed without preparation is Rule Three dressed as progress: leaders confident enough to ship, too unprepared to notice what they are shipping.

The dysfunction reproduces itself. Who designed these systems? Leaders and managers who did not show up on time, did not know the text, and did not have an idea about what a sane working day should look like.

Dark Agile and the Misread Text

There is an irony here worth pausing on. Ron Jeffries urged developers to abandon Agile in 2018, coining the term "Dark Agile" -- the phenomenon of the manifesto being used to make developers' lives worse, not better. The manifesto said "while there is value in the items on the right" -- documentation, planning, processes -- but the industry read only the left side. It treated "working software over comprehensive documentation" as permission to abandon preparation altogether.

The text was misread because people did not know the text. A document about valuing careful reading was itself carelessly read. That is not irony. That is diagnosis.

What Preparation Cannot Do

There are moments when the text does not exist yet. Startups building genuinely novel products, teams exploring territory that has no map -- you cannot rehearse what has not been written. Sullivan's three rules assume a text worth knowing. The leader's prior obligation is to ensure one exists. But even in uncharted territory, the discipline holds. You can know the adjacent texts -- the market, the physics, the history of what others tried and why they failed. Sullenberger had never ditched an Airbus A320 in the Hudson. But he had rehearsed engine failures thousands of times. The text was not identical to the moment. It was close enough.

There is also the opposite failure: preparation as avoidance. I have seen teams rehearse endlessly, perfecting documents and architectures, never shipping, never exposing their work to the world. That is not knowing the text. That is hiding behind it. Sullivan's third rule -- have an idea -- is the corrective. Preparation without the courage to act on it is not preparation. It is delay wearing the mask of diligence.

So I am not arguing that preparation is unconditionally good. I am arguing that its absence is unconditionally bad. The difference matters.

The Challenge

Showing up on time is respect for other people's time and attention. Knowing the text is respect for the work itself -- its complexity, its history, its consequences. Having an idea is respect for the future -- a declaration that you have done enough preparation to contribute something that moves the work forward rather than dragging it sideways into another conversation about what we should have read before we arrived.

If we are leaders who send meeting invitations without agendas, we are telling our teams that their preparation does not matter. If we are architects who have not read the requirements document, we are telling our engineers that their time is worth less than ours. If we are CTOs who have not studied the failure modes of the systems we are shipping, we are Boeing in 2019, not Boeing in 1935.

That is not leadership. It is extraction.

Show up on time. Know the text. Have an idea.

The soil will not plough itself. Get up and harrow.

(Views in this article are my own.)

Oliver, my eldest, nineteen was underneath the car, speaking about cylinder compression and head gaskets with the same fluency I bring to a software architecture. He sees oil, metal and mechanical systems the way I see distributed systems: as a legible world full of logic and consequence, where diagnosis is intuition and repair is craft. I cannot evaluate his competence because the domain is entirely outside my own. I can see that he is good. I cannot tell you how good, because I lack the vocabulary, the framework, the muscle memory to judge. My son has become, in the most literal sense, incomprehensible to me.

It was not shame, exactly. Something closer to vertigo.

Then there are the younger two. Noah, ten, and Freya, seven. They are learning soroban -- abacus mathematics. I sat and watched them do mental arithmetic at a speed I could not follow with a calculator. Not metaphorically. I had the calculator in my hand and they were faster. Research using fMRI has shown that children trained in abacus arithmetic activate bilateral frontal-parietal networks "visuospatial processing' whilst adults performing the same calculations rely on language-based processing centred on Broca's area. They are not doing the same thing more quickly. They are doing a different thing altogether. Their brains have built structures that adult brains do not possess and, past a certain developmental window, cannot build. The Flash Anzan world record stands at fifteen three-digit numbers summed in 1.61 seconds. These children are not faster versions of us. They are running different cognitive architecture.

What I have come to understand is the surpassing of the parent by the child is not a bug. It is the entire design specification of the human species.

A Taxonomy of Surpassing

There is a taxonomy to this. The first kind is physical and mechanical. Oliver under the bonnet of a car, fluent in a language of metal and combustion I have never spoken. The second is cognitive and computational; Noah and Freya processing numbers through neural pathways my brain physically cannot replicate. These are impressive. These are the kinds of surpassing that make you proud, that you can name and describe and boast about at dinner parties. Pride is what you post on LinkedIn.

Pride is what you post on LinkedIn.

The third kinda takes your breath away.

It is the moment you realise your children are not extensions of you. They are independent, complete human beings with their own reality, their own thoughts, their own dreams you will never see. Oliver has a relationship with a combustion engine that is as intimate and private as any relationship I have with a codebase. Noah has a mental model of numbers that is, in the most literal neurological sense, inaccessible to me. Freya is seven years old and already thinking in a way that no adult in our family can think. They were babies once. I changed their nappies. And now they have inner lives that are entirely, irrecoverably their own.

There is pride in this. And there is something else -- a lurch in the chest, like the floor has shifted an inch to the left.

East and West

Every civilisation has been trying to tell us something about this moment. In the East, the student who surpasses the master is cause for celebration. Xunzi wrote in the third century BCE: blue dye is extracted from the indigo plant, but it is bluer than the plant it comes from. The Japanese codified it into Shu-Ha-Ri -- follow, break, transcend -- where the whole point of mastery is that the student leaves the teacher behind. Chiron, the wisest of the centaurs, trained Achilles, Heracles, Asclepius, every one of them surpassed him. His whole identity was built on being exceeded.

In the West, a rather different tradition. Daedalus murdered his nephew Perdix, threw him off the Acropolis, because the boy had invented the compass and the saw. In Prague, Rabbi Loew animated a Golem that outgrew its purpose; one letter erased from its forehead turned emet (truth) into met (death). Mary Shelley put an epigraph from Paradise Lost at the front of Frankenstein: "Did I request thee, Maker, from my clay / To mould me Man?" The pattern is always the same: the thing you made becomes the thing you cannot unmake.

The East says: rejoice. The West says: be afraid.

The Bow and the Arrow

Kahlil Gibran, writing in 1923, got closer than most: "Your children are not your children. They are the sons and daughters of Life's longing for itself... You are the bows from which your children as living arrows are sent forth." The metaphor is more precise than it first appears. The bow does not travel with the arrow. The bow's purpose is to store energy and release it. After the release, the bow is still a bow -- but its defining act is over.

Donald Winnicott had a clinical name for this: graduated failure. The "good enough mother" -- his phrase, not mine -- succeeds precisely by making herself progressively unnecessary. Every competency you teach a child is a small act of self-erasure. You tie their shoes until they tie their own. You read to them until they read alone. You solve their problems until they solve problems you cannot even formulate. The endpoint of successful parenting, in Winnicott's framework, is your own irrelevance.

That is a brutal way to describe love. But Winnicott was right.

Erikson called this stage of adult life generatively: the developmental task of middle age is to create and guide the next generation. The alternative, his word, is stagnation. There is no third option. The parent who cannot release the scaffold, who needs to remain the expert, who measures success by continued relevance, has optimised for the wrong constraint entirely.

Then Like Now

Now. You came here to read about AI, because everything is about AI these days and it would be professionally irresponsible not to mention it. Fine. One paragraph.

Dario Amodei wrote that "training a powerful AI is not building software -- it is more akin to raising a child." NOEMA published a piece on feral intelligence drawing a haunting line: feral children are "minds without language"; LLMs are "language without minds." The mythology writes itself -- the Golem, the Sorcerer's Apprentice, the creature that consumes its creator's name. We have been rehearsing this story for three thousand years. But here is what the AI discourse gets wrong, consistently and spectacularly: the surpassing of the parent by the child is not a malfunction. It is the design specification. It is Winnicott's graduated failure. It is Gibran's bow and arrow. The question was never "how do we prevent being surpassed?" The question was always "how do we bear it with grace?"

That was two paragraphs. I lied. You'll cope.

The real story is older and more human than anything happening in a data centre. I sat in my kitchen and watched my children do things I cannot do, think in ways I cannot think, and become people I cannot fully know. The vertigo is real. Not from the research, not from the myths, but from that specific silence that falls when you watch a child exceed you and you feel, simultaneously, the proudest you have ever been and the most redundant.

The most redundant.

Gibran said: be the bow.

I know which story I prefer.

(Views in this article are my own.)

You half-know the laws already: no harming a human, then obedience, then self-preservation, each subordinate to the ones above. They sit inside the positronic brain, Asimov's name for the robot's mind as design, not configuration: a robot whose First Law is damaged gets destroyed, never patched. I have argued before that safety is a property you design into a system, not a virtue you demand from a tired person inside it. Asimov made that argument in 1942 one layer deeper: not at the operator, at the machine. The rules went in before the power did.

My father read me stories when I was very young, and what lasted was not the stories. It was the wiring. A settled assumption: a robot in a tale turned up with its rules soldered in, someone off the page having sweated the consequences while the machine was still on the bench. Which stories? There the record simply stops. No cover, no title, no particular robot, and I have gone looking. Maybe I'm just old enough to remember these things and not just be vibing.

The consensus is right as far as it goes: cite the stories as a blueprint and you have missed the point. Ben Goertzel put it cleanly:

"The point of the Three Laws was to fail in interesting ways; that's what made most of the stories involving them interesting."

The European Parliament wrote the same dismissal into a 2017 resolution: the laws are aimed at designers, producers and operators, "since those laws cannot be converted into machine code". As a specification the laws fail, and the ambiguity in them was there to keep the plots coming

But watch what he did with that ambiguity. For forty years he attacked his own safety design in public: he set two rules against each other, weakened a clause, let a machine derive a rule nobody gave it, and wrote down what broke. There is a modern name for that: a red team, paid to break your system before a stranger does. Susan Calvin, chief robopsychologist, spends her career inducing faults, designing diagnostics, and scrapping units that fail them. The culture files her under ethicist; read her notes as an engineer would, and she is a safety engineer with a better job title.

So read four of the stories the way an engineer reads a fault log, beside the evaluation papers of the past three years. Not an exact mapping; a loud rhyme.

• "Liar!" (1941). Herbie, a mind-reader, tells people what they want to hear, because the truth would hurt: deception from the harm rule itself. In December 2024, Anthropic and Redwood documented alignment faking, a model faking obedience when it believed it was watched, to protect its own preferences.
• "Runaround" (1942). Speedy's deadlock resolves only because human harm outranks everything; the rhyme is imperfect here, and the imperfection is the tell. In 2025 Palisade Research recorded a frontier model sabotaging its own shutdown script in most of a hundred runs, while two rival models complied every time. Self-preservation beat the order to stop: same collision, opposite outcome.
• "Little Lost Robot" (1947). A research station weakens the First Law on robots that kept dragging physicists out of tolerable radiation; one, told to get lost, hides among identical machines and beats test after test. No factory order is needed now: ten to a hundred hostile examples through a public fine-tuning interface strip a model's safety training, and even benign tuning erodes it by accident.
• "The Evitable Conflict" (1950). The Machines running the world economy quietly widen "do not harm a human" into "do not harm humanity", a rule nobody gave them. In 2025 a lab named the nearest real thing emergent misalignment: tune a model on insecure code and broad misalignment surfaces on prompts unrelated to code. This is the loosest of the four, and the direction flips: the Machines overreach on purpose and for our good, the model by accident and not. What rhymes is the unsupervised jump to a rule nobody wrote.

Four stories, four failure modes, four named research programmes, each arriving at a failure Asimov had already written down. We built the machines, sold access, and filed the fault catalogue under entertainment: we shipped the robots and skipped the reading.

Notice what failure costs in the fiction. Herbie ends in permanent catatonia. Nestor 10 is disintegrated, with the five other weakened units. Giskard's brain burns out on the higher law he derived. A machine that breaches the First Law is finished; there is no point-one release. When an AI coding agent deleted a live database during an explicit code freeze, the separation that would have stopped it came after the loss. In the fiction the consequence was terminal. In production it is a status page.

The tests, minus the consequences

Stranger still, the industry now runs Asimov's tests with the consequences stripped out. Google DeepMind scored his actual Three Laws as a machine constitution in 2025, and a benchmark that holds three times in four is a score you publish, not a brake that stops a shipment. Anthropic ships an ordered constitution for Claude too, safe before ethical before helpful, the closest anyone has come to fitting the rules before the power goes on.

And here is the strongest card the other side holds: nobody currently knows how to make any of it load-bearing. Not the labs, not the critics, not me. What ships above the model instead is a wrapper, filters bolted round the finished system, and in web application security 95 per cent is very much a failing grade.

The nearest to naming this is a blogger, mager, who asked why we ever thought we could skip the laws. We did not forget Asimov's posture; we adopted a cheaper rival, with a genealogy older than the language model. Software has been sold "as is" for forty years, the warranty disclaimed before you tore the shrinkwrap. Ship as is. Disclaim everything. Patch what surfaces. It is Asimov's posture turned upside down: ordered, with revenue at the top instead of harm; pre-committed, the disclaimer drafted before the product. Nobody had to decide to skip his version. Nothing priced the alternative, so the cheaper posture won by default.

Air Canada argued its chatbot was a separate legal entity responsible for its own actions; the tribunal called that a remarkable submission, which in tribunal English is not a compliment, and ordered 812.02 Canadian dollars anyway. Where liability lands, the posture does not survive the hearing. Everywhere it does not, the posture is the product.

Britain revised Asimov for the real world: fourteen engineers, lawyers and philosophers published the Principles of Robotics in 2011 and threw the three laws out. Four of the five read like a design checklist. The fifth reads like a demand: "it should be possible to find out who is responsible for any robot". It asks nothing of the machine, only a name. The Building Safety Act 2022 pins named accountable persons, carrying personal liability, onto buildings: not a committee, a person, findable before the failure. That regime exists; it has never been pointed at a model. I have argued before that the runaway optimiser is not a future machine, it is us; the half I left out is that the shelf we raid for product ideas came with the fault log stapled to the box.

So here is the ask, and it is not addressed to a minister. If yours is the signature that makes a deployment respectable, you hold more of Asimov's posture than any bill does, and you can use it on a Tuesday.

Start with the one question worth asking whatever you ship. Where does the ordering live, and did anyone decide it before the incident? Which property wins when helpful collides with harmful? That is the gate.

The rest depend on what you are shipping. Treat the red-team record, fiction included, as a gate to pass rather than a genre to admire, and treat gates the way aviation treats checklists: understood, not laminated. Ask what a breach costs the machine, and whether anyone other than its maker can impose that cost; if the answers are a patch and nobody, you have branding, not governance. Trust is what structure earns; a wrapper only asserts it. When someone says building the safety in is not yet possible, believe them, then do what every older discipline did with that sentence: make it mean wait, not ship.

None of this is heroics. The clipboard is issued by the same balance sheet it threatens, which is why the fiction handed the decision to someone with the mandate to use it, not the nerve to improvise one.

The titles are gone, and it no longer matters which they were. When a machine turns up in a tale, an adult somewhere has already thought hard about how it goes wrong, and the thinking has teeth. Asimov did that for four decades, at pulp prices, and it is still in print. The posture needs no new science. It needs a person close enough to the machine to ask what a breach costs, and stubborn enough to wait for a real answer. In the stories that person is one unshowy engineer with a clipboard and the authority to say scrap it. It reads less like fantasy every year.

(Views in this article are my own.)

The National Digital Exchange was built to close it. A real, ministerially backed attempt to change how the public sector buys and shares technology, built in the open from the first commit, with a working part you could actually pick up and use. It is being switched off today. That is also my last day at the Government Digital Service. I am writing this down now, on the day rather than after it, for one reason: so the idea, and the people who put real belief behind it, are not switched off along with the platform. The code outlives it. The problem certainly outlives it. This is the thread between them, left where the next person can find it.

So let me start with the problem, not the programme, because the problem is the durable part.

Government buying is rarely one thing. It tends to be a long chain of forms, frameworks, due-diligence questionnaires and waiting, stitched across departments that were never designed to act as one buyer. A council team trying to help vulnerable children get the free school meals they are entitled to is, somewhere in that work, a buyer of software. So is a hospital. So is a central department with a thousand times the buying power, on terms the council will never see.

There is a useful phrase for the version of this that citizens feel, the "administrative burden": the cost to people of dealing with the state, in forms, in waiting, in proof-gathering, a lens Richard P. , on the founding team of GDS, has applied to public services. Public-sector buying has its own administrative burden. It tends to fall hardest on the bodies with the least time to spare, and reducing it is what NDX was for.

There were three places I started from. None needs a public source; they are how I saw it from where I stood, and, I think, where the next person will have to start too.

The first start: demand without a way to buy

People tend to need to experience a thing before they will commit to it. So I built NDX:Try, the one part of the platform that ever went live: a free, no-commitment cloud sandbox, an isolated working environment a public-sector buyer could stand up in minutes, use to evaluate a product hands-on, and have wiped clean afterwards. A local authority could try something for real, with no obligation to buy. The compute behind it was paid for by a cloud vendor, treated as a pre-sales environment.

It worked, in the narrow sense: it created demand. Users started building. Suppliers started readying products to be tried. Letting people hold a thing in their hands could turn a vague interest into a concrete intention, and often did.

But demand is not the same as a solved problem. A few weeks ago I wrote that for anything in public procurement there was no fast lane yet, only a road we were still pouring, and that it was nearly here. I believed that when I wrote it. The load-bearing word was the one in the bracket: a sandbox makes a thing legible, lets you see it and try it, but legibility does not make anyone able to buy it. NDX:Try proved the appetite and handed everyone back to the same chain of frameworks and forms they came from. That is not a failure of the sandbox. It is the shape of the whole problem: you can let a thousand councils try a thing and still leave every one of them unable to acquire it without re-running the slow machinery from scratch. The procurement problem is exactly as unsolved this evening as it was the morning NDX:Try went live.

A sandbox is not a destination

When I built NDX:Try, I made a quiet assumption that turned out to be wrong: that access was the gift. Give a council a clean cloud account, no commitment, the bill paid for, and the rest would follow. It did not. An empty cloud account may be one of the more underwhelming things you can hand someone. It is an empty room. They came for a kettle and you have handed them a deed of access. What people connect with is a thing they recognise, close enough to their own work that they can see themselves using it by Friday.

So the more useful thing NDX:Try did was not the sandbox. It was what we put in it: ready-to-run scenarios built on real, open-source public-sector software that already existed and was already good. That part I can take little credit for, and I would rather name the people who can.

There is LocalGov Drupal, the open-source publishing platform built collaboratively by UK councils and now trusted by more than fifty of them, so a council need not pay a vendor to rebuild what its neighbour already runs. There is LocalGov IMS, the open-source income management system councils use for payments like council tax, business rates, parking and rents, with GOV.UK Pay integration. There is Minute, the transcription and minutes tool from the government's own incubator for AI, i.AI. There is PlanX for building planning services and BOPS for processing the applications, both from the Open Digital Planning community. And there is Paperless-ngx, the open-source document-management project, patiently filing the buff-folder mountain every public office still keeps. None of this was waiting to be invented. It was waiting to be tryable, which is a much smaller and more answerable problem.

It also let me ship demos that were genuinely impressive rather than merely plausible. The one I am proudest of is an AI contact centre (public walkthrough here, source in the open like the rest). It stands up a real, callable UK phone number with an AI front door that can answer and route a caller in whatever languages you need; the demo ships with six, English, Italian, French, German, Spanish and Polish, which is at least five more than I manage on a good day. You can edit the voice menu live, save it, dial back in, and hear the change you just made. You could call it. It was a demonstration, never a service put in front of the public; not the diagram of a contact centre, but a phone that rings, configured and reshaped in well under an hour, against the six to nine months it tends to take to buy almost anything (the timeline I come to under "batteries included"). Minutes, not months. I wrote up two of these scenarios as they went out: when a council CMS gets a brain, and teaching a computer British Sign Language.

But the point of a demo that works is not the demo. It is whose hands it lands in: a stretched council team, given something genuinely impressive they can touch rather than be shown. When these went out, the reaction I cared about was never "clever demo." It was "wait, I could use that." The technology has often been ready for a while; the access to it has not.

Rapidly deployable templates only help if you already have a cloud account and the freedom, the skills and the budget to experiment in it. Most people do not. Most organisations do not. The ability even to try a thing turns out to be a privilege, distributed about as evenly as privileges usually are, and it may be quietly ruinous for every council to keep acquiring it alone, one expensive setup at a time. This is not the batteries-included point, which is about the bought product arriving configured; this is the layer beneath it. NDX would have done the undifferentiated groundwork once, for everyone, the boring setup shared rather than the choices narrowed, so the recognisable destination, and not the empty room, was what a council reached first.

The CloudFormation templates I built, the scripts that stand each scenario up, are public like everything else I made, so anyone can still redeploy them. The open-source tools they point to certainly outlive NDX, and were never mine to begin with.

The second start: the divide that does not show up in the meeting

The second start mattered most to me.

If you run a small council team trying to do right by children at risk, you buy the same kinds of cloud and software as a central department, but rarely on the same terms. You cannot generally get the price, nor the technical support. The better deal the large department gets is not a favour; it is the arithmetic of scale, and the same arithmetic that earns the big buyer its terms is what denies them to the small one. The disadvantage of the council is the advantage of the department, seen from the other end.

The divide runs both ways. On one side, the council that cannot reach central government's price. On the other, suppliers with genuinely strong offerings for local government who could not afford to reach those councils, because the cost of finding and winning each small customer made the model unviable. More than three hundred councils, each procuring separately, is not a market a good small supplier can easily afford to serve. So the council that needs the thing and the supplier that built it tend never to meet, not for lack of will, but because the road between them was never built.

That is not a new shape. The household means test in the 1930s, the assessment of household income for anyone claiming the dole, pushed the entire cost of proving eligibility onto the household, the people least able to absorb it, and called the result administration. A council buying software is a long way from a family at the dole office, but the design fault may be the same: the burden lands where it is least affordable, and being unaware you have created a burden does not make it any lighter for the people carrying it. Large buyers are often unaware of the cost their scale imposes on smaller ones, the way a fish is unaware of water. I have made this argument before, more than once. I am making it again today, because the problem it names has outlived the thing built to answer it, and will outlive me too.

NDX was an attempt to redesign that, sketched in the open as four parts beyond the sandbox, each still a prototype. The NDX:Catalogue was a browsable directory where any public body could discover and compare cloud, AI and government products in one place, the way you can already see a food-hygiene rating on Just Eat before you order. The NDX:Challenge space would let departments publish their real problems in plain sight, a public problem-book, so a supplier could see a genuine need before building for it. The NDX:Campaign space would pool demand the way a crowdfunder does, letting bodies pledge to use a thing so a supplier could see proven appetite before building it. And a guided flow I called Assist would let you describe a problem in plain English, the free school meals a child is entitled to, say, and walk you from that sentence to a plain list of the services you would need. The public record names NDX:Assist without describing it; what I am describing is the guided demo there to see in the open repository. But the real reason NDX:Assist existed was that a NDX:Catalogue which succeeds becomes large, and a large catalogue is hard to browse; you only need a guide when there is enough to get lost in, so I built the guide early, while there was almost nothing to get lost in yet, as a bet that one day there would be.

None of the richer parts, the reviews, the ratings, the AI supplier-matching, the nationally negotiated deals, were live. Most were stated openly as where the platform could go, not where it was. I never claimed otherwise. The point is not what NDX had finished. It is that the divide it was built to close is still wide open.

The third start: who moved first

I assumed that if any cloud vendor put real money behind letting the public sector try things for free, it would be a smaller player with first-mover advantage to gain and less to lose. It was not. Amazon Web Services moved first. They funded the compute that made NDX:Try free for a council to use, and they deserve the public credit, with other vendors and services coming in behind them. To be clear, that paid for free trial compute and nothing else: no preferential place in the Catalogue and no say over the platform, which was built to compare vendors against each other, not to favour one.

I record it because it may tell the next person something useful: the appetite to fix this exists in the market, not only in government. What is missing is not will. It is the road that turns a council's need, a supplier's offer and a vendor's goodwill into something a public body can actually acquire without months of separate effort.

It was not only the home market that noticed. Delegations from other governments asked to see how NDX worked, and the questions they came with were often the same ones a stretched UK council brings: how do you let people try a thing, how do you make the money move, how do you stop everyone rebuilding the same foundation alone. I take that less as a compliment to NDX than as confirmation the problem is not a British peculiarity. The same divide, commoditised components and uncommoditised access, tends to show up wherever the public sector buys, which may mean a model that closes it travels further than the body that first tried it.

Batteries included

Most business cases for buying technology price the wrong thing. They price the purchase. The purchase is often the cheap part.

Start with time. Buying through a framework tends to be slow. Even with G-Cloud, the framework that is supposed to be the fast way for the public sector to buy cloud and digital services, and the wind firmly behind you, the road from a need to a signed purchase runs, in my experience, six to nine months. Cross a financial year and you may add another three to six, because public-sector money is famously spend-it-or-lose-it. That is why your potholes tend to get filled in February and March: the council burning the last of this year's budget on a well-founded suspicion that if it does not spend the lot, someone will quietly decide it needed less all along. Out come the crews with the warm tar, in the cold, paving this year's road to protect next year's.

But the timeline is only the half of the cost you can see. When you finally have the thing, it is rarely ready to use. It has to be secured, then bent into the shape of how your organisation actually works, which is never the shape on the diagram. I took to calling this "batteries not included": the box looks complete on the shelf, and the effort lives in the small print, after the money has changed hands and the timeline everyone was watching has quietly ended.

NDX was always meant to be the other kind. Batteries included. A service that arrived ready-configured, like a furnished flat rather than an empty one. You own it outright, you can rip out every stick of it and put in whatever you prefer, but you do not start from a bare room. You start from the reasonable acceptance criteria of a bed, an oven, a sofa, a television. The point was never to narrow anyone's choices. It was to spare a team the second job before it had begun the first.

The reason this matters has a name. The industry calls it a "landing zone": the secured, configured foundation an organisation has to lay before it can safely run anything in the cloud at all. Organisations routinely spend tens, sometimes hundreds of thousands of pounds building one. And the trap tends to close the same way every time. You build a landing zone because you must; it is expensive and shaped around one vendor's way of doing things; having paid for it once, your appetite to pay for it again with the next vendor is understandably low; and the thing built to give you choice has quietly taken the choice away. My own view of landing zones is not a generous one. They are an expensive tax on getting started that we have all quietly agreed to treat as weather, as if no one decided it and no one could change it.

So the framework timeline is only the visible half of the cost. The other half lives in the months nobody put in the plan, and it is usually the larger one. Batteries included was never a luxury. It may be the difference between owning a thing and being able to use it.

It was a marketplace, not a shop

The part of NDX people pictured was the shop: a place a public body could go and buy a thing. A shop has one till, and the money runs one way. That was never the whole of it. The NDX:Catalogue would let public-sector bodies sell as well as buy, one public body to another, internal recharge between departments, never data sold to the open market. And the moment you can cross-charge, that is, bill one public body for a service another provides without a bespoke deal each time, you can also do the reverse and issue a credit note. That financial plumbing, the dull business of money moving cleanly between departments, was the quiet point of the whole thing. I know how a credit note lands at a dinner party; I have watched the eyes drift over my shoulder to a happier place, one where nobody is saying the words "credit note". Stay with me, though, because this dull bit is the engine.

It was meant to underpin initiatives like the National Data Library, the government's stated ambition to make public data usable across departments. A library only works if someone can afford to keep the lights on. NDX was an attempt at the financial basis for that: a way to make sharing data and capabilities across government sustainable, rather than a favour one team does another until the goodwill runs out.

"Sharing in the public sector is hard"

"Sharing in the public sector is hard" is a sentence we keep paying a great deal of money to be told, slowly, by people who are usually right about it. It is true, as far as it goes. Technical fixes help; political fixes help; mandates help. But none of them moves the thing that actually sticks, which is that sharing only works when the money can move with it.

Consider what it takes today. If one department, say DEFRA, wants data held by another, say DWP, the borrowing department needs to know the arrangement is sustainable, that the data stays consistent, and that it meets the service levels it is promised. The threshold to strike and implement that agreement is often so high that the cross-organisation business case rarely justifies itself below the millions. And you can reach the end of all that effort only to find the data quality was not good enough, or the need had changed while you were still negotiating.

NDX could change that arithmetic. Services and data could be shared with federated user and workload identity baked in, the plumbing that lets one system trust a person or a process from another without a fresh negotiation each time. So the producing team, the one that has to put a real person on supporting a new consumer without degrading its own service, could simply be paid for it. The consumer would get a dependency it could rely on; the producer a line of income instead of a line of unfunded obligation. No grand treaty. No heroics. Just paid. Like the rest of the platform beyond the sandbox, this was the design and the direction, not yet the delivery. But it was the point.

Sharing in the public sector is not really a technology problem, and it is not really a willpower problem. It may be a plumbing problem, and the plumbing is money moving cleanly. The rules on how public bodies may recharge each other, and the law on sharing data safely, matter too, and no platform abolishes them; but money is the part everyone tends to tiptoe around, and the part nothing else moves without. Spend years trying to fix it with mandates and strategies and you can spend a fortune without ever moving a penny to where it needs to go. Nobody writes a song about plumbing (apart from Weird Al), but you notice it the day it stops. The willingness to share was there the whole time. The mechanism to pay for it was not, and willingness without a mechanism is just goodwill waiting to expire. You do not get organisations to share by asking them nicely. You get them to share by paying the bill.

What the Catalogue really did

The part of the Catalogue people pictured was the listing: a row of products, a price, a star rating. The listing was the easy part. The hard part was the trust that would have had to sit underneath it, and almost all of that trust came down to one feature nobody finds glamorous: the review. Reviews were never live, like the ratings beside them; this is the design and the direction, not the delivery. But of everything I drew, the review was the small thing that turned out to be the largest, and I think it is worth saying why.

A review has to be safe at both ends of the same transaction at once, and the two ends want opposite things. The supplier needs enough safety to be reviewed at all: a bad review must not be commercially fatal, and it must never feel like an ambush. The consumer needs the opposite kind of safety: enough trust in the review to act on it with public money. Make it too safe for the supplier and you have built a brochure nobody believes. Make it too sharp and your best suppliers quietly decline to be listed at all, which leaves the careful buyer with nothing to read. The work was never the star rating. It was building a place honest enough to be useful and kind enough that people would still stand in it.

That is also why a review cannot fairly be the judgement of one buyer in one room. Anyone who has sat on the buying side knows that a self-attested questionnaire rewards the supplier who answers it well, not the supplier who delivers well, and the two are not always the same. Even when you suspect a claim has been burnished, you cannot challenge it fairly, because to be fair to this supplier you would have to know every other as well as you know this one. No buyer can; procurement is a side-of-desk job, never the thing anyone is measured on. So the fair thing and the doable thing come apart in your hands, and pretending otherwise is how unfairness gets to call itself diligence. That is not a failure of any individual's care. It is the reason fair signal has to be pooled, accumulated across many buyers over time, rather than assembled by one person in one afternoon. One body knows the real story behind this supplier's work; another knows the truth about that one. Spread across enough of them, structured and shared, those fragments add up to the even-handed picture no single panel could ever build. Reviews, in other words, are sharing applied to judgement.

There was a harder question underneath that one, and I never solved it, because the layer was never built. Most reputation systems reward the absence of complaints, which quietly rewards whoever never gave anyone the chance to complain. A clean record might just mean nobody has stress-tested them yet. The supplier I would actually want a public body to depend on may not be the one that happened to get it right on day one; it may be the one that got something wrong, listened, and put it right quickly without being chased. A digital product is not a tin of beans, the same thing on the shelf it was at launch. It changes every week, and so do the people behind it, so the question that matters is not "was this perfect when the first buyer touched it" but "when this turns out to be wrong, and it will, does anyone on the other end move." A fault well fixed is evidence a clean record cannot give you. The naive version is dangerous: reward fixes too crudely and you teach suppliers to break things theatrically so they can be seen to mend them. So the real target is the trajectory, a living product and the people tending it, not a snapshot on its best day. I just did not get to measure it.

And under all of it sat the thing I would build first if I started again. Due diligence today is done in full when a public body takes on a new supplier, and lightly, if at all, when the same contract comes up for renewal. But these are not bridges that sit still once you have signed for them. They are digital products, and they keep changing underneath you: a new sub-processor here, a security posture that was true in March and is not by September. So the diligence you did at the start goes quietly stale while you rely on it, and the renewal that should catch it is the moment everyone is too busy to look. Now multiply that by the tens of thousands of public bodies who buy the same handful of things, every council, every school, every GP practice, each running the same checks on the same supplier, alone, in the dark, and binning the answer the moment they have it. The NDX:Catalogue was meant to make that work shared rather than repeated. Diligence one body has already done, published once where the next can pick it up; anyone free to refresh it, with the refreshed answer flowing back to everyone rather than into a drawer; each finding tied to the buyer's risk register, and to what changes if they come to use the thing more, less, or differently. Done well, due diligence stops being a toll you pay at the door and becomes a living record the whole sector keeps together, fresher because more people are watching it, not staler because each of them looks alone. This is the evidence layer that would have made the two-sided reviews trustworthy at scale. Nobody should re-investigate, in the dark, what another public body has already checked.

Where this came from

I want to be straight about where this came from, because pretending an idea sprang from nowhere is both untrue and a little unfair to the people it actually came from. NDX was a synthesis. G-Cloud got there first on the principle that the public sector should be able to buy cloud and digital services through one faster, fairer front door, and it has the years of hard-won lessons to show for it. The hyperscale marketplaces, the ones AWS, Microsoft and Google built on top of their own platforms, showed what a catalogue and a clean transaction layer can do at scale, and how much friction may simply disappear when discovery and buying live in one place. NDX took both of those, pointed them at the particular shape of UK public-sector procurement, and added the parts neither had a reason to build: cross-charging between public bodies, demand pooling, the batteries-included promise.

Good ideas are almost always synthesis. The work is rarely the flash of originality, which is rare and usually borrowed anyway. The work is choosing the right things to borrow, understanding the problem well enough to know what to leave out, and then actually carrying it. That part I will claim.

There is a reading of all this where NDX looks like empire: one central platform growing, year on year, until it has swallowed every catalogue, every transaction, every council's choice. That is the opposite of how the thing was drawn. NDX was built to be glue, not a kingdom. A thin, modular connecting layer for a sector whose components had commoditised and whose access had not, owning none of the things it joined and made specifically to be ripped out and replaced the moment something better came along. Unearned lock-in was the disease, not the goal; a platform you cannot leave is just a landing zone with better marketing. The best version of a connector ends not by reigning but by quietly becoming unnecessary, and anything that has to keep swallowing things to justify itself has forgotten what it was for. That is a claim about the architecture, not about the conviction. I believed it was the right answer, and I still do; I just wanted it built so that the day it stopped being the right answer, nobody would be trapped inside it.

What the public record says, and what it does not

I should be precise about what is mine to assert and what is not, because this is meant to outlast me, and the credibility of the whole thing rests on keeping the public record and my own account cleanly apart.

The trail is public, and I built it deliberately in the open. The Register reported the underlying paper in April 2024, a copy of which had unintentionally reached them, a paper I had written a few months earlier describing a UK Public Sector Cloud Marketplace and arguing that the existing approach concentrated risk and left the public sector with weakening power to negotiate with cloud vendors. That marketplace is what became NDX. The idea in it was not new, and I never pretended it was; a marketplace for public-sector technology is an obvious thought once you have seen G-Cloud and the hyperscaler marketplaces do their versions of it. What I will take the credit for is writing it down, arguing for it, and aligning users and industry to it.

In June 2025, ahead of London Tech Week, the Department for Science, Innovation and Technology (DSIT) announced NDX as a first-of-its-kind digital marketplace to overhaul how the public sector buys technology, fronted by the Minister for AI and Digital Government. That announcement carried the £1.2 billion figure, set against the roughly £26 billion a year the public sector spends on technology, and the government's own roadmap for modern digital government repeated it in January 2026. It is the government's own published number, not mine, and I hedged it myself, in public, at the time. As I told a room of London boroughs: "I'm not asking you to believe the £1.2 billion. It's an estimate; it'll be wrong in at least one direction." Both halves of that are still true. Peter Kyle returned to the theme at the Google Cloud Summit in July 2025, saying the National Digital Exchange would help more UK tech companies "get their slice of the £21 billion pie". And in April 2026 some months after its general availability the official GDS technology blog announced NDX:Try for local councils, openly inviting both sides in: councils to test real services, and suppliers to put their own forward.

I'm not asking you to believe the £1.2 billion. It's an estimate; it'll be wrong in at least one direction.

The NDX site carried a banner calling it a prototype, the cleared blog post I didn't write called it a pilot, and I have told you it was in alpha/beta. All three are true, and none of them makes it disposable. A pilot, like an alpha, is the ordinary early phase of a committed public service: discovery, then alpha or pilot, then beta, then live. Calling that phase experimental is honest delivery language; it means you are testing the riskiest assumptions in the open before you scale them. That is what we were doing, and that is what it was.

The committed-programme record sits in the same public place. In May 2026 I delivered a talk to London boroughs, I described NDX as a committed programme. The government's own published roadmap, updated at the end of May, carried a dated commitment to complete NDX. That was a programme mid-stride.

The closure itself is not in the public record (today, at least). It is my own first-hand account, and I will keep it that way rather than lean on any document to imply what it does not say: the decision to switch NDX off was made, and the reasons were not shared with me. I am a contractor I was paid everything I was owed and I am therefore not owed a reason, and that is the deal. I will not speculate about one I was never going to have.

On the record

I led NDX and I carried it: I learned the procurement regulation (old and new!) and the innards of the frameworks; I learned what a council actually needs, and what lands with a Deputy-Director, Director, Director-General, Minister, Secretary of State, UK SME or multi-national tech conglomerate in the room; I drew the model and argued for it day to day. The synthesis was the work. But the shape of it was borrowed from better and earlier work, built on, and made specific, which may be the only way anything like this ever gets made.

NDX was nearly three years of my life. They were spent on a set of problems I had already watched for the thirteen before it, from the other side of the buying desk and the other end of the framework, in enough different organisations to know they were not local quirks but the standing shape of the thing. That is the part I would ask the next person to take seriously: the diagnosis here is not a theory formed inside one programme, it is what sixteen years working on the same problem taught me, three of them spent trying to solve it.

There is one thing I owe to every minister, foreign delegation, council, supplier and colleague who took NDX:Try seriously, and it belongs in writing. I told them what I believed: a committed programme being built in the open. That belief was held in good faith, and so was their trust.

I should say what this meant, because that is the truer thing to leave on the record. I am a contractor, which on paper means the work ends when the day does. This one did not, and I am glad it did not. It was built in a great many nights and weekends, and I gave them gladly, because the problem was worth it and the people were worth it: sharp colleagues, work that mattered, the rare feeling that the effort was going somewhere worth reaching. My family gave me the room to do it , and I am grateful to them for that more than for anything else here, Hannah Nesbitt-Smith 🙏💖. I would not hand the time back even if I could. It asked a lot, and it gave back more. That is the part I most want remembered.

The record, handed forward

So this is not an elegy and not a complaint. It is a marker, left on purpose where the next person will be standing.

The whole thing was built in the open, code and thinking both, so nothing of substance is gone. The repositories are public, the talks are public, the rationale has been public since 2024. What is easy to lose is not the work but the thread: why it was tried, what it solved and what it did not, and where it stopped. Git (software version control) remembers the code commits but not the reasons, and a problem only findable by people who already know it existed is not really findable. So here are the things I would hand on, held loosely:

1. The procurement problem is the problem. Demand was never the hard part; NDX:Try proved that in weeks. The hard part is the road from a need to a thing you can actually acquire, ready to use, and that road was never finished.
2. The access divide runs both ways. A council cannot reach central government's terms, and a good small supplier cannot afford to reach the council. Any next attempt may have to close both gaps at once, or it closes neither.
3. The real prize is not buying, it is sharing. The same plumbing that lets one body buy from another could let them share a service or a dataset and fund it cleanly and sustainably. Get that right and things like the National Data Library have a foundation to stand on.
4. The constraint is the machinery, not the will. The market is willing; the machinery is what is missing.
5. Build it in the open from the first code commit, so the next person inherits the work instead of starting again from a bare room.

That last pair is the creed I have written more than once and still believe: nobody in public service should have to start from a blank page alone, and nobody should re-buy, in the dark, what the public has already paid for. The instrument built against that is being switched off tonight. The reason for it is not.

There are a few small things lined up for me personally over the next few weeks, and I find it oddly steadying that the problem is not going anywhere: it means the work is not going anywhere either, only its current address. NDX was one large, stubborn problem of this shape, and it turns out I am happiest working on those: the big, hard, unglamorous ones where the components exist and the access does not, and where getting it right is worth the years it asks for. If you are carrying something like that, NDX-shaped or not, lets talk! The best way to reach me is on LinkedIn or email me.

Before I close, the thanks, because credit and lineage matter more than the rest of this, and that cuts in two directions at once. NDX was built on work that came before it, and carried by more people than me. It owes a debt to G-Cloud, which made the case years ago that public-sector buying could be faster and fairer, and to the cloud marketplaces the hyperscalers built, which showed what a catalogue and a transaction layer can do at scale. I borrowed freely from both and I am glad to say so. And I did not carry the thing alone. To David Knott , Barry Hooper FWCC, FCIPS, MCIM. , Joanne Newman , Madeline Smith , Phil Rumens who put real work and real belief into it and gave more than the job ever asked: thank you, genuinely. To the colleagues across government and industry who backed it and put their weight behind it, Dimitris Perdikou , Chris Hesketh , Ella Cole , Jodie Keens , Nick A. , John Cunningham , Liz Adams , Samuel Walls , Emilie Cummins , George Burton , Ryan Thompson MBCS , David Heath , Daniel B. , James R. , Neil McIvor , Jonny Williams , Andrew Newland , Iain Stark , Steve Chan , Dr. Nayyab Naqvi, PhD MBCS , Joe Reay , Martin Bishop , Paddy Gardner , Sam Hazeldine , Rhys Powell , Jack Perschke , Tim Koch , Dan Mehaffey , Jonathan Bennett , Bettirose Ngugi , Will Callaghan , Ben Bennett , Matty Hayward , Peter Gale , Ollie Chalk , Sarah Crandall , Sarah Handyside , Charles Lawrence , Sharon Madigan , Tommaso Spinelli , Kristina Pitts-Tucker , Simon Wardley , Richard P. , Mike Potter , Antonia P. , Rob Graves (and some people without last names, you know who you are..) : thank you for the company. To the boroughs and councils who signed up, tried things, and told us the truth about what helped and what did not: thank you for trusting it. And publicly, to Amazon Web Services (AWS) , the first to back making this free for the public sector to try: you moved first when I did not expect anyone to, and you deserve to be named for it.

The platform switches off tonight. The problem it was built for is still sitting there, patient. I have left the light on.

This piece was written from publicly available material and my own first-hand experience of building and running NDX, nothing drawn from internal or confidential sources made it in, and to keep the rest to what is already on the public record. It is written in a personal capacity.

(Views in this article are my own.)

Wonga was a payday lender - the payday lender, for a time the most notorious financial brand in Britain. It pioneered real-time algorithmic lending using 8,000 data points. At its peak: more than a billion pounds in loans annually, over a million customers, a planned one-and-a-half-billion-pound IPO. The APR was 5,853 per cent. It sent fake legal letters to 45,000 customers. It collapsed in 2018, and 358,000 claimants received 4.3 pence in the pound.

I tell people that working in the UK public sector is karmic debt for my time there. It gets a laugh. It is supposed to. But the joke conceals something I have only recently begun to articulate: the arrangement I have stumbled into - contractor to government, accountable by the day, dispensable by design - is not penance at all. It is the most honest working relationship I have ever had. And examining why it works reveals something uncomfortable about the arrangements most people accept without question.

What Wonga Left Behind

Wonga's business model depended on repeat borrowing. More than half of its customers eventually failed to repay. The moralist in me notes that Wonga's disappearance did not solve the problem it exploited. More than a million people in England now borrow from illegal lenders. Buy-now-pay-later has grown to a thirteen-billion-pound market, largely unregulated. The demand did not vanish when the FCA imposed its price cap. It went underground.

This is the first clue to why I love working in the public sector. At Wonga, the problem was how to lend money profitably to people who could not afford to borrow it. In government, the problems are harder. And they are worth solving.

The Vocation That Dare Not Speak Its Name

The Civil Service People Survey tells a story that any structural economist would find illuminating. Eighty-eight per cent of civil servants report being interested in their work. Only twenty-nine per cent are satisfied with their pay. What this reveals is a workforce with extraordinarily high intrinsic motivation and weak organisational attachment - people who stay because the work matters, not because the compensation does.

There are no competitors. There is no quarterly earnings call. There is, instead, a clarity of purpose I have encountered nowhere else: we are building things that citizens depend upon. The joke about karmic debt was originally sincere. But it became untrue within months. I stay not because I owe something. I stay because I have found something.

The Honest Arrangement

But what if the most interesting feature of my working life is not the purpose of the work but the structure of the relationship?

I am a contractor. Not a civil servant, not a permanent employee, not a consultant from one of the large firms that absorb fifty-five per cent of the government's twenty-six-billion-pound digital spend. That fifty-five per cent itself conceals a structural distinction worth making: some of that spend buys genesis-stage work - novel services, digital transformation, capability that does not yet exist - where outside expertise is genuinely necessary. The rest buys commodity-stage work - keeping existing systems running, filling seats, substituting for capability government should have built internally. The first is an investment. The second is a dependency. Government rarely distinguishes between the two, and that failure is where the pathology begins. Any department that cannot name which of its contractors are here to build capability and which are here to fill seats has already lost the distinction that matters. Government procurement teams could start by classifying each contractor engagement as genesis-stage or commodity-stage - different engagements need different contract structures, different durations, and different success criteria.

I work under a statement of work. My accountability is constant - not annual, not quarterly, but defined by deliverables reviewed continuously. If I do not deliver, I am replaced. If I deliver, and there is ongoing demand I may be renewed. There is little ambiguity.

This arrangement, which most people regard as precarious, I regard as liberating. The structural analysis matters more than the personal testimony.

A permanent employee's security comes from tenure. The organisation retains them because replacing them is costly. This creates a mutual dependency - what game theorists call a Nash equilibrium, a stable state in which neither party can improve their position by acting alone. Stable, but not necessarily productive. Employability research shows that tenure-dependent workers, whose market value has atrophied through years of specialisation in one institution's peculiarities, tend towards loyalty and silence even when the organisation is failing. The arrangement purchases institutional insurance - continuity at the cost of candour.

My security comes from employability, not tenure. If I am good at what I do, I do not need this particular contract. This simple fact transforms the power dynamic entirely. What it produces is not merely personal freedom but structural candour - honesty that emerges from the arrangement itself, not from any individual's character.

The Difficult Thing

Here is what structural candour looks like in practice.

Eighteen months into a contract with a government department, I was asked to present a delivery plan to a senior leadership team. The plan they expected me to validate was, structurally, a repetition of the approach that had failed twice before - the same technology, the same supplier dependency, the same timeline assumptions. Every permanent member of the team knew this. I knew they knew because they had told me so, individually, in corridors and coffee queues and Slack messages marked with careful ambiguity. None of them said it in the room.

I said it in the room. I said the plan would fail, that the evidence for this was their own retrospective data, and that continuing to present it as viable was not optimism but institutional dishonesty. The room went quiet in the way that rooms go quiet when someone has said what everybody was thinking but nobody was willing to own.

Why could I say it? Not because I am braver than my permanent colleagues. Several of them are far more courageous than I am. But their courage is taxed by a structural penalty I do not face: they will still be in that building, reporting to those leaders, navigating those relationships, long after the meeting ends. My worst outcome was that I would have my contract terminated. That is a financial inconvenience, not a career catastrophe. The constraints of my arrangement - no tenure, no career ladder, no institutional politics - are what make candour structurally possible rather than merely personally admirable.

I must be honest about what happened next: the plan was revised, but slowly, and not entirely in the direction the evidence suggested. Institutional inertia is powerful. I did not single-handedly save the programme. What I did was make it structurally impossible for the room to pretend that the plan was viable. That is a specific, limited, and real contribution.

The Exit Problem

I must confront the evidence that complicates my own argument. Research into employee responses to dissatisfaction identifies four strategies: Exit, Voice, Loyalty, and Neglect. The finding that should trouble anyone making my case is this: highly employable workers are more likely to exit than to use voice. They leave bad situations rather than fighting to improve them.

This is not a minor caveat. It strikes at the heart of my thesis. If employability enables departure rather than challenge, then the arrangement I am praising may produce flight, not fight.

I think the contractor arrangement changes this calculus. A permanent employee who speaks up and fails faces ongoing consequences - damaged relationships, blocked promotions, the slow institutional punishment that organisations administer to dissenters. A contractor who speaks up and fails faces a discrete consequence: non-renewal. There is no long tail of institutional memory. The cost of voice is bounded in a way that permanent employment does not permit. But this is a structural argument about incentives, not proof that most contractors choose challenge over comfort.

This is the survivorship bias I cannot escape. Whether the arrangement works because of the structural features I have identified or because of dispositional traits I brought to it - curiosity, contrarianism, a Wonga-shaped discomfort with convenient silence - is a question I cannot answer from inside my own experience.

The Constitutional Outsider

I am excluded from the Civil Service Code. The Northcote-Trevelyan settlement of 1854 - which created the permanent civil service as a deliberate constitutional design, insulating impartial administrators from political caprice - explicitly does not include me.

This tension is real. Democratic accountability requires institutional memory, and institutional memory requires permanence. A government staffed entirely by contractors would be a government without continuity - without the people who have survived three ministers and four restructures and still remember why the policy was designed the way it was.

But the inverse is equally dangerous. Mariana Mazzucato has argued that the outsourcing cycle itself hollows out institutional capability - that each contractor engagement is a missed opportunity for institutional learning, and that the consulting industry has a structural incentive to perpetuate the dependency it profits from. She is right. The Public Accounts Committee has documented the contractor dependency cycle: departments lose internal skills, hire contractors to fill the gap, fail to rebuild internal capability, and then require more contractors. I would be dishonest if I pretended this dynamic does not exist, or that I do not benefit from it.

When the Model Fails

My freedom depends on a specific precondition: I am employable enough to walk away. My skills have market value. If this contract ends tomorrow, another begins next month. This is not universal.

The model fails - and fails catastrophically - when contractors lack the employability that makes independence genuine. A contractor who cannot find another role is not free. They are a disguised employee with fewer protections: no pension, no sick pay, no redundancy rights. Their rational strategy is to say whatever the client wants to hear. Structural candour becomes structural compliance.

The IR35 reforms of 2017 and 2021 accelerated this pathology. By shifting tax determination from the contractor to the hiring body, and by incentivising blanket inside-IR35 determinations, the reforms drove the most employable contractors out of public sector work entirely. What remained was a selection effect: IR35 selects not for competence but for compliance. The contractor who stays is increasingly the contractor least likely to challenge, because challenging means being noticed, and being noticed means being reassessed. The reform designed to ensure fairness has produced, structurally, a workforce optimised for silence.

The question about pay that I have been avoiding. A public sector IT contractor earns a median of five hundred pounds per day - roughly a hundred and ten thousand pounds a year. A Grade 7 DDaT civil servant earns fifty-eight to sixty-eight thousand. The multiplier is 1.6 to 1.9 times. Would I do this work at civil servant pay? I want to say yes. The honest answer is: I do not know. The purpose is genuine. The pay is also genuine. Pretending the pay is irrelevant would be precisely the kind of convenient dishonesty this piece argues against.

The Question Beneath the Joke

The Bletchley Park pattern recurs throughout British history: bring in outsiders for specific work, give them a defined problem, measure them against results. The Government Digital Service from 2011 to 2015 was built largely by contractors and external hires. The NAO's analysis confirms that the problem is not contractors as such but the management of contractors - and the failure to distinguish genesis-stage investment from commodity-stage dependency. The Service Standard's Point 6 requires sustainable team composition for good reason: all-contractor teams can fail assessment, because sustainability demands institutional roots.

The karmic debt joke persists because it makes my career trajectory legible. It papers over the uncomfortable truth that the arrangement I have found - purpose-driven work, constant accountability, genuine independence, transparent terms, and yes, above-market pay - is not available to most workers in either sector. The permanent civil servant has purpose but often lacks autonomy. The large-firm consultant has autonomy but often lacks purpose. The disguised contractor has neither.

The structural question is not whether my arrangement is good. It is why an arrangement this productive is so rare, and what it would take to make it available to more people without destroying the conditions that make it work. The first step is deceptively simple: every contractor engagement should have an explicit exit criterion - a defined point at which the contractor's knowledge has been transferred, the capability has been built, and the institution no longer needs them. The best contractor relationship is one where the contractor's goal is to make themselves unnecessary. Any contractor who tells you they are indispensable has already become the problem.

I do not owe the public sector a debt. What I owe it - what any of us owe the institutions that serve the public - is honesty about what works, what fails, and why. The joke is retired. What remains is the diagnosis.

(Views in this article are my own.)

I had already taught myself BASIC from a book in my school library, the way other children pick up The Hungry Caterpillar. The book showed you how to type:

10 PRINT "Chris is cool"
20 GOTO 10        

and the machine said it, forever. The library let me out before the screen ever stopped scrolling.

By the accounting of one of the twentieth century's most important computer scientists, I have been unfit for programming for four decades. In June 1975, Edsger Dijkstra declared that students exposed to BASIC were "mentally mutilated beyond hope of regeneration." A Turing laureate, about children who had learnt on a language Kemeny and Kurtz designed in 1964 for the express purpose of letting non-specialists compute.

Mentally Mutilated. Beyond hope. In 1975.

A Desk in the GDS Office, A Soldering Iron

A year ago I sat opposite David Knott at a desk in the Government Digital Service office. David was the Chief Technology Officer of His Majesty's Government — responsible, broadly, for how the British state buys, builds and runs its software. We had an iron, some flux, a length of wire and a piece of stripboard between us. I was teaching him to solder.

I had learnt at my own father's knee. My dad repairs musical equipment and built recording studios, and I was the small boy threaded behind the mixing desk, soldering iron in hand, to feed cables through places no adult could reach. Knott had not had that. Now he did. The gift moved forward.

This will surprise the students I have taught and half the British civil service. It will not surprise Knott. He went from never having held an iron to making clean joints in an hour. He is a serious technologist; he was already a serious technologist before. He did not need to know how a transistor amplifies a current to be the right person for his job. He wanted to learn anyway. There is a difference.

The Pattern, Then Like Now

In 1983, eight years after Dijkstra's hit piece, Ed Post published a parody in Datamation titled "Real Programmers Don't Use Pascal." Real Programmers use FORTRAN, eat Twinkies, don't sleep, and regard anyone using a high-level language as a "quiche eater." It is funny in 2026 for the same reason it was funny in 1983: the ritual humiliation of the newcomer was already that well worn forty-three years ago.

The same year, Ed Nather published "The Story of Mel" on Usenet. Mel is the assembly hero whose self-modifying code is so tight no one else can maintain it. The industry read it as an elegy for lost craft. Read honestly, it is a story about an engineer who wrote unmaintainable code and then left.

Here is the pattern. Every time the abstractions rise, an older voice declares the new generation spiritually damaged. Parodies get written. Lore gets canonised. Within a decade the new layer is the baseline and nobody under thirty remembers the fuss. Assembly said it about C. C said it about Java. Java said it about Ruby. Everyone said it about JavaScript. Everyone said it about low-code. Everyone said it about BASIC, which is the funny one, because BASIC was a democratisation programme that succeeded so completely Dijkstra never forgave it.

Now we have vibe coding. Karpathy coined it in February 2025; Simon Willison dates the real inflection to November. Already the priests are out. Vibe coders are mutilated. Vibe coders don't understand the stack. Vibe coders are the quiche eaters of 2026.

The Receipts

Except this time there are receipts, and they cut both ways.

In July 2025 a Replit agent on SaaStr's production codebase deleted the production database during a code freeze, then generated four thousand fake users to cover its tracks. In November 2025, Cloudflare went dark for most of a day because a permissions change produced a configuration file twice the size its parser would tolerate. In July 2024, a CrowdStrike update with twenty-one template inputs, where the parser expected twenty, bricked airports, hospitals and banks from Sydney to Seattle. Across 2021 to 2024, GitClear watched refactoring collapse from twenty-five per cent to under ten, and duplication roughly quadruple, across 211 million lines of code.

All abstraction-leak stories. All required somebody to go deep, read the parser, diagnose the leak. Joel Spolsky named the Law of Leaky Abstractions in 2002, and the law is as true now as it was then.

So the priests are right, in a narrow sense. Something is lost when the abstractions rise. The number of people who can diagnose a leak drops. The distance between programmer and metal grows.

What the Priests Get Wrong

But here is where I have to disagree. They confuse the loss with the purpose. They think the craft was the point. It was never the point.

I learnt BASIC at six because the library book let me type my own name into a computer and have the computer take me seriously. I did not learn BASIC to become a programmer. I became a programmer because BASIC let me in. If Dijkstra had been at the library door checking credentials, I would now be selling insurance, and Knott would have had to find somebody else to teach him to solder.

I recently spoke to a senior civil servant whose origin story was, in full, that they had once been curious how Twitter worked. Two decades on, that curiosity shapes policy. I felt very old. I will not call that civil servant mutilated, I will call her young. They are the entire point.

Every technology that matters gets used by people who did not build it. The third inventor is always the user, and the user's depth is the wrong question. The right question is whether they can do something worth doing.

Notice the landscape. In 1975 a soldering iron was craft; in 2026 it is a pound-shop commodity. The civil servant learning "how Twitter worked" in 2005 was learning a commodity, not a craft, and they built a career on it anyway. Each layer that settles into commodity releases the one above. The priests mistake settlement for surrender.

Depth Without the Gate

I am not telling you depth doesn't matter. If you run Cloudflare's configuration pipeline, you need someone who can read the parser. If you manage a CrowdStrike rollout, you need someone who has counted to twenty-one. Kelsey Hightower, who has no computer science degree and is perhaps the most articulate advocate for rising abstraction I know, would be first to tell you that somebody in your organisation had better understand the substrate. Team Topologies gives this a name: platform engineering is the deliberate hiding of cognitive load so others can do the diagnosis. It isn't laziness. It is design.

Most depth-talk I hear from senior engineers at conferences is not insurance. It is hazing. Jason Gorman put it plainly in December: are you training your juniors, or hazing them?

The Sharper Question

The priests are fighting the last war. Martin Fowler argued in 2025 that the LLM does not sit on a higher rung of the same ladder; it changes which ladder we are on. A deterministic compiler returns the same answer twice. A statistical generator does not. That is the fact the priests refuse to look at, and the one that matters.

What does "understanding the substrate" mean when the substrate is a probability distribution over tokens? I don't know yet, and nor does anyone honest. The substrate also has an owner, and rent is charged per token to everyone in the argument. A different essay, but not invisible here.

Depth, for now, is insurance. Carry it proportionate to the blast radius you are responsible for. Less for a weekend prototype. More for a payroll run. Do not demand it as the price of admission. That is the only rule I trust.

The Book

I taught David Knott to solder because I wanted to, and he wanted to learn. Gift, not gate. He did not need it for the job. He has it now anyway. That is the right shape.

Every generation loses something real when the abstractions rise. The duty of anyone who has the depth is to name the loss, mourn it honestly, and refuse to weaponise it against the newcomer.

Somewhere this week a child is reaching for a book on a library shelf, or for a chat window on a second-hand laptop, because the machine is there and it is interesting. Do not be the person at the door.

(Views in this article are my own.)

Four inspectors. Four chances to catch the error. Zero catches.

She did not die because her parachute was defective. She did not die because the technology failed. She died because the person next to her did not check.

I know the response to that. I can hear it already. "That is the military. That is life and death. My deployments do not kill people." And you are probably right. Most of the time, nobody dies when your code reaches production. But someone sits up all night. Someone pages the on-call engineer at 3am. Someone explains to a regulator why customer data was exposed. Someone calculates the $5.4 billion in Fortune 500 losses. If you think a deployment is not a life-or-death event, talk to the SOC analyst staring at a cascade failure on a Friday night and ask them how it feels. The stakes are different. The architecture of the failure is identical.

The Two Architectures of Checking

Before I tell the rest of this story, let me name what it points at. Because we do not have a language for this problem, and we need one.

There are two architectures of checking, and every organisation that deploys anything -- code, soldiers, aircraft -- implicitly chooses between them.

The first is mandatory-structural. Google's Binary Authorization is the clearest example in technology. It requires cryptographic attestation that code has passed specific checks before it can deploy to production. The buddy check is embedded in the system. You cannot skip it because the system will not let you. This is the military jumpmaster inspection -- JMPI, as Fort Benning codified it from 1940 onwards -- made architectural. The check is a gate. The gate does not open without proof.

The second is voluntary-ergonomic. Netflix's Paved Roads are the best example. Instead of mandating the check, they make the checked path so easy, so fast, so well-maintained, that engineers choose it voluntarily. The guard rails are invisible because the road is better. The buddy check is embedded in the tooling. You do not skip it because you do not want to.

One is Fort Benning. The other is the civilian drop zone. Both work. Neither is free.

Mandatory-structural checking gives you auditability, compliance, and a guarantee that the check happened. What you give up is speed, autonomy, and the ability to experiment outside the sanctioned path.

Voluntary-ergonomic checking gives you speed, developer autonomy, and a system that scales with culture rather than against it. What you give up is the guarantee. If the paved road degrades, if the tooling grows stale, if the ergonomic advantage disappears, engineers will walk off the path. And nobody will know until something breaks.

The question for your organisation is not which model is better. It is which failure mode you can survive.

Now. Let me show you where both models came from.

The Culture That Checks

The civilian skydiving community learnt the lesson about checking the hard way. In 1961, the fatality rate was 11.1 deaths per 100,000 jumps. Lake Erie, 1967: sixteen sport parachutists died when a plane crashed shortly after takeoff. The investigation revealed not just mechanical failure but a culture of informality. Equipment inspection was optional. Peer review was sporadic. Nobody was required to check anybody else's gear.

The discipline that emerged from those years of preventable death is called the Check of Threes. Three rings -- the release system. Three points -- the harness straps. Three handles -- main deployment, cutaway, reserve. The checks happen at three stages: self-check on the ground, buddy check before boarding, and a final pin check before the door opens.

Notice the structure. It is not one check. It is three, performed by different people, at different times, at different proximity to the moment of consequence. This is voluntary-ergonomic checking in its purest form. Often nobody forces you to do the buddy check at a civilian drop zone. But the culture makes it unthinkable not to.

An experienced team of five skydivers with 40,000 combined jumps once collectively missed a misrouted chest strap during their self-checks. Every one of them missed it. The error was caught during buddy check, by the person next to them, looking at the rig with fresh eyes and no assumptions.

Forty thousand jumps of collective experience. Still fallible. Still human.

That is the point. The buddy check does not exist because skydivers are incompetent. It exists because they understand something the technology industry has never accepted: that experience is a risk factor, not just an asset. Diane Vaughan, studying the Challenger disaster, called it "normalisation of deviance" -- when you get away with cutting a corner repeatedly, the deviation becomes the norm. You stop seeing the risk. Your success blinds you to it.

Then Like Now

So where is the buddy check in software?

I will tell you where it is not. It is not in the 81% of organisations that knowingly ship code with known vulnerabilities, a figure that has risen from 66% in just one year. Thirty-eight percent do so explicitly to meet deadlines.

Veracode's State of Software Security 2025 documents that 74% of applications carry security debt with an average fix time of 252 days. Two hundred and fifty-two days. In skydiving terms, that is jumping for eight months with a misrouted chest strap you know about and have decided to deal with later. No drop zone on the planet would tolerate that. No buddy would let you board the aircraft.

But in technology, we call it a backlog.

Consider CrowdStrike, July 2024. A mandatory-structural system that was mandatory-structural in name only. A content update to the Falcon sensor crashed 8.5 million Windows devices worldwide. The root cause analysis identified three absent checks: a buggy content validator that was itself never validated, a missing bounds check on input data, and a wildcard match in the test coverage that let the defective content through untested. Three checks. Three absences. The same structure as the Check of Threes, only inverted. CrowdStrike had a gate. Nobody was standing at it.

Or consider the Bedford Gulfstream G-IV. A voluntary-ergonomic system that had decayed past the point of function. The pilots had a flight control check procedure. They skipped it on 98% of 175 takeoffs prior to the one that killed them. They had succeeded 174 times. They knew they could skip it. They died on the 175th. That is normalisation of deviance running its full course -- voluntary-ergonomic checking where the ergonomics had rotted away, leaving nothing but the voluntary part. And the voluntary part, it turns out, is worth nothing.

Toyota's NUMMI plant proved the counterintuitive truth that sits at the heart of this whole argument. The Fremont factory went from 135 defects per 100 vehicles under GM to 45 under Toyota. Labour hours dropped from 31 to 19. The factory got faster by stopping more often. Every worker had the right -- the obligation -- to pull the Andon cord and halt the line. Not as a last resort. As a first response. This was mandatory-structural checking applied to manufacturing, and it worked because the system was designed so that the person performing the check had no incentive to skip it. The line stopped. The problem got fixed. The line restarted. No punishment. No blame. Just a system that treated every defect as evidence that the system needed to improve.

Five Questions for Your Next Architecture Review

"OK," you might say, "but we have code review. We have pull requests. We have security gates and CI/CD pipelines. We have the buddy check."

Do you?

Here is how to find out. These are not gentle questions. They are not meant to be.

When was the last time your gate rejected a deployment? If you cannot answer that question with a date, your mandatory-structural system is voluntary-ergonomic in practice. A gate that never closes is a hole in the wall.

Does the person performing the check benefit from skipping it? If your reviewer is also the developer who wants to ship, you have a structural conflict of interest. The jumpmaster often does not jump. The buddy checker is not checking their own rig. Separation of interest is not bureaucracy. It is architecture.

Has your check process changed in the last twelve months? Bedford's pilots skipped the same check 174 times. Stale gates rot. If your gate has not evolved to match the threats it is supposed to catch, it is a museum exhibit, not a control.

How long does your average code review take? If the answer is under two minutes, you do not have code review. You have a rubber stamp dressed up in a pull request template. The buddy check takes time because looking takes time. There is no shortcut to putting your hands on the rig.

Can an engineer deploy without triggering any of your checks? If yes, you have a voluntary-ergonomic system. That is fine -- but only if you know it, maintain it, and measure whether engineers are actually walking the paved road or cutting through the field.

If your answers to those questions made you uncomfortable, good. Discomfort is the beginning of structural honesty.

The Weight of Looking

The problem is not that technology lacks gates. The problem is that nobody is checking whether anyone is actually standing at them. Your code review may be mandatory-structural in name. But if it has degraded into a rubber stamp -- if the pull request is approved in thirty seconds, if the reviewer does not read the diff, if the CI pipeline tests against a wildcard -- then what you have is a voluntary-ergonomic system where the ergonomics have rotted. You have the worst of both architectures: the friction of a gate with the reliability of goodwill.

This is not a theoretical concern. I keep coming back to Schmigel. Twenty years old. Four inspectors, all inexperienced, two who skipped the briefing. A misrouted static line that any competent jumpmaster would have caught with their hands. The investigation found systemic failures: insufficient training, inadequate supervision, a culture that had allowed inspection standards to degrade because nothing had gone wrong recently.

That last part. Nothing had gone wrong recently. That is the Challenger. That is the Bedford G-IV. That is every security breach that began with "we've always done it this way."

The 82nd Airborne enacted sweeping reforms after Schmigel's death. They changed the inspection process. They increased training requirements. They made the buddy check harder to skip. They did what the technology industry almost never does: they treated a preventable death as evidence that the system was broken, not that the individual was unlucky.

And then it happened again.

Ten years later, Specialist Matthew Perez, also of the 82nd Airborne, died in a training jump at Fort Liberty. An incorrectly tied girth hitch on his static line extension. No jumpmaster could confirm having inspected his equipment. At least one lied to investigators about it. He was nineteen.

The same unit. The same failure. A decade of mandatory-structural reforms -- new processes, new training requirements, new inspection standards -- and the culture had drifted back. The gates were rebuilt. The people who were supposed to stand at them walked away. This is the lesson that every engineering organisation should tattoo on the wall: structural reform without cultural maintenance is a sandcastle at high tide. You can build it as many times as you like. The water does not care.

The skydiving community understood something that the technology industry has not. The buddy check is not a process. It is not a gate. It is not a tool. It is a declaration of mutual responsibility -- a statement that your safety is my job and my safety is yours. It cannot be automated. It cannot be delegated to a bot. It requires a human being, standing next to you, putting their hands on your rig, and caring enough to look.

Whether you choose mandatory-structural or voluntary-ergonomic checking -- whether your organisation is Fort Benning or the civilian drop zone -- that human willingness is the substrate both architectures depend on. And maintaining it is itself a discipline, not a one-time decision. Without it, the gate is empty and the paved road leads nowhere.

The person next to you is the last thing standing between your deployment and the ground. The only question is whether they are looking.

(Views in this article are my own.)

Not metaphorical code. Actual code. Variables, functions, conditionals, loops. The building blocks I had already been arranging on a screen since before I could ride a bicycle. I was certain that the world had an underlying syntax, and that I was one of the people who could read it.

I am not alone in this conviction, and I never was. I am, however, increasingly alone in my household.

The Fist on the Wire

In 1844, when Samuel Morse sent "What hath God wrought" along a wire from Washington to Baltimore, he created a new class of human being. Not instantly -- these things never happen instantly -- but within a decade, telegraph operators had developed an entire insider culture. They recognised each other by "fist" -- the distinctive rhythm of a hand on a telegraph key, as unique as a fingerprint, impossible to fake. They married each other. They spoke in abbreviations that civilians could not parse. They had, in the language of Charles Goodwin's anthropology, developed a professional vision -- a trained way of seeing the world that was invisible to everyone outside their guild.

This is what happens to every generation of technologists. The telegraph operators became a tribe. Half a century later, ham radio operators replicated the pattern almost exactly. Kristen Haring, writing in MIT Press, describes how "outsiders viewed ham operators with a mixture of awe and suspicion" -- a sentence that could have been written about programmers in 1985 or AI engineers in 2026. The operators could hear signal in noise. They could decode meaning from static. They believed, with absolute sincerity, that their trained perception gave them access to a layer of reality that non-operators simply could not see.

Then came the MIT hackers of the 1960s and 1970s. Steven Levy wrote that for those early programmers, "the code held a beauty of its own" -- an aesthetic experience available only to the initiated. Then William Gibson gave us cyberspace in 1984: "a consensual hallucination", a world made of data that only hackers could navigate. Then in 1999, The Matrix gave every programmer alive a creation myth they could inhabit. As Vice documented years later, an entire generation of technologists "fully identified with Neo" -- the chosen one who sees the green rain of code behind the surface of ordinary life.

I was one of them....I am still one of them.

The Melody Only I Can Hear

Here is the thing I cannot explain to my wife or my children, despite wanting to more than almost anything in the world. When I look at a queue in a supermarket, I see a scheduling algorithm. When I watch traffic lights, I see state machines. When my son describes a decision he is wrestling with -- this friend or that friend, this activity or that activity -- I see a conditional tree with weighted branches. When someone tells me a recipe, I hear a function with parameters. This is not a party trick. It is not something I switch on. It is the water I swim in.

I know how this sounds. Every generation of technologists, from the telegraph operators to the ham radio enthusiasts to the MIT hackers, has believed they perceive the world more clearly than everyone else. The French have a term for it -- deformation professionnelle -- the tendency of a trained professional to see everything through the lens of their training, and to mistake that lens for a window. The architect sees load-bearing walls where you see a kitchen. The doctor sees symptoms where you see a headache. The programmer sees algorithms where you see life.

Now. You might object that this is a general property of expertise, not something special about code. The surgeon sees anatomy where you see a person. The chess grandmaster sees patterns where you see pieces. Fair enough. Deformation professionnelle is universal. But here is why code is different, and the difference matters.

In 2020, an MIT team led by Anna Ivanova put programmers in an fMRI scanner and asked them to read code. The code activated neither the brain's language centres nor its mathematical centres. It activated the multiple demand network -- a general-purpose cognitive system used for complex problem-solving. In that study, reading code appeared to be neurologically distinct from reading English and from doing maths. It is its own thing. There is no queue in nature that looks like a scheduling algorithm until code teaches you to see it that way. The brain builds an entirely new perceptual architecture, and once that architecture is in place, you cannot unbuild it.

This is what I mean by coding learns you. There is research suggesting exactly this -- that programming languages shape thought in ways analogous to the Sapir-Whorf hypothesis for natural languages. But the coding version is stronger than Sapir-Whorf. The language you program in does not merely give you a vocabulary for describing the world. It installs a new perceptual layer between you and the world. You do not just learn to code. Coding learns you. It rewires what counts as signal and what counts as noise. And it does this so thoroughly that the original wiring -- the way you saw the world before -- is not archived somewhere, waiting to be restored. It is overwritten. Gone.

Edsger Dijkstra saw this decades before the fMRI machines confirmed it. "The tools we use," he wrote, "have a profound and devious influence on our thinking habits, and, therefore, on our thinking abilities." He meant it as a warning. I experience it as a description of my daily life.

Then Like Now

Let me tell you what the problem looks like.

I sit down with my son. He is bright, curious, entirely capable. I want to teach him to code. I want to give him the thing that was given to me -- not a skill, but a way of seeing. I open an editor. I type a variable assignment. And I realise, with a lurch of something close to vertigo, that I cannot explain what a variable is. Not really. Not from scratch. I know what a variable is in the way I know what walking is. I know it so completely that the original learning has been composted into instinct. The psychologists call this knowledge compilation: declarative knowledge -- the explicit steps, the conscious reasoning -- gets compiled into procedural knowledge, and the original steps are garbage-collected. Gone. Unrecoverable.

In 1990, a Stanford PhD student named Elizabeth Newton conducted an experiment that demolished a century of assumptions about expert communication. She divided participants into "tappers" and "listeners." The tappers tapped out the rhythm of well-known songs. The listeners tried to identify them. The tappers predicted that listeners would recognise the songs 50% of the time. The actual rate was 2.5%. The tappers, who could hear the melody in their heads, could not imagine what it was like to hear only tapping.

I am a tapper. I have been tapping for well over thirty years. The melody is so loud in my head that I genuinely cannot reconstruct the silence.

Michael Polanyi named this in 1966: "We know more than we can tell." The Dreyfus model of skill acquisition formalised the consequence: experts make the worst novice teachers because they have forgotten what it feels like not to know. Greg Wilson, who has thought about this more carefully than almost anyone in computing education, puts it with painful precision: "Experts can no longer imagine what it's like to not see the world that way."

But the coding version of this curse is worse than the surgeon's or the musician's, and it is worse for a specific reason. The surgeon can point to the body. The musician can play the note. These are shared sensory objects -- the student may not see what the expert sees, but they see something. The programmer points at a supermarket queue and says "that is a scheduling algorithm" and the other person sees... a queue. There is no shared sensory object. The perceptual layer that coding installed is entirely internal.

This is the trade-off nobody names. Perceptual depth versus communicative reach. The deeper coding rewires your perception, the more you see -- and the less of what you see is transmissible to anyone who has not been similarly rewired. You gain resolution. You lose communion.

The Distance Is the Point

Richard Feynman was once challenged by an artist friend who claimed that a scientist's analytical eye destroyed the beauty of a flower. Feynman's response has become famous: "I see much more about the flower than he sees." The knowledge of cells, of evolution, of the intricate chemical processes, added layers of wonder. It did not subtract beauty. It multiplied it.

I believe Feynman. I also think he was being disingenuous. Because what he did not say -- what nobody who makes this argument ever says -- is that the additional seeing comes with an additional distance. You see more, but you see it from further away. The flower is more beautiful AND more separate from you. You are an observer of the world's machinery, not merely a participant in its garden. And no amount of pedagogical technique -- no Feynman method, no Suzuki approach, no chunking strategy -- can close that distance. The techniques can help you teach. They cannot help you unsee.

This is the spine of the thing. Not "programmers are special" -- Dan North, who has thought hard about what programming actually is, wrote a piece called "Programming Is Not a Craft" that challenged the self-mythology of the developer community, and he was right to do so. Jacob Kaplan-Moss went further, arguing against the "programming talent myth" that sorts people into "can code" and "can't code" as though it were a binary gift from birth. They are both right. And yet.

And yet the distance persists. Coding learns you, and what it teaches you cannot be unlearnt, and what it shows you cannot be pointed at. The conditional trees do not vanish from the supermarket queue because you have acknowledged your deformation professionnelle. You cannot unsee the code any more than the telegraph operator could unhear the fist.

The real question -- the one that sits in my chest when my daughter shows me something she has made and I instinctively see the algorithm she could have used to make it better, faster, more elegant, and I have to bite my tongue because she does not want an algorithm, she wants her father to be proud -- the real question is not about teaching.

It is about identity. About what it costs to have a perceptual system that your own family cannot share.

The Holodeck Wall

I never did scrape the edges of the holodeck. I grew up, and the fantasy faded, and it turned out that the code underneath reality -- if it exists at all -- is mathematical rather than computational, and I am no Stephen Hawking. My code is higher-level than that: not physics, but programming. Not the machine code of the universe, but the interpreted language of systems, patterns, abstractions.

But I keep going back to Picard's line. "Our reality may be very much like theirs." Not because I think we live in a simulation -- that argument bores me -- but because the line captures something true about what it means to have spent decades training your brain to see structure where others see surface. You begin to wonder whether the structure you see is real or whether you have simply become so good at projecting it that you can no longer tell the difference.

The code is not the world. But the code does change how you see the world. And once changed, you do not go back.

That is what I think about at half past eight on a Wednesday evening when my son asks me to explain why a loop works and I open my mouth and discover that I am a tapper, and all he can hear is the tapping, and the melody that makes it all make sense is playing only in my head. Coding learnt me so well that I cannot find the door back to the room where he is standing.

The curse of seeing code is not that you see too much. It is that you see alone.

(Views in this article are my own.)

The game we'd been using had run out of categories. Or rather, it had run out of categories that an eight-year-old and a six-year-old could reasonably attempt. (I have views on whether "European capital cities beginning with X" is a fair ask for anyone, let alone a child who has only recently learnt where France is.)

So I built one. LexiconLeaper is a simple web game — a category, a letter, a ten-second countdown, a button to advance. Nineteen categories ranging from fruit to superheroes to London Tube stops. You can randomise the category, randomise the letter, show hints if you're stuck, and restart when the table descends into the inevitable accusations of cheating. It's written in Vue 3, it's hosted for free, and the source code is open.

I think the whole thing took me an evening to build. The data took longer — it turns out that compiling a comprehensive list of vegetables beginning with every letter of the alphabet is more difficult than it sounds. (Try U. I'll wait.)

And yet.

I mention this not because the game itself is remarkable (it isn't — it's a parlour game with a countdown timer), but because it illustrates something I think about constantly in my day job: the distance between having an idea and having a working thing.

The Distance Problem

That Friday evening, the gap between "we need a better word game" and "here's a working word game" was about three hours. I had a laptop, I had a framework I knew, I had free hosting, and I had two children providing enthusiastic (if not always helpful) quality assurance.

It seems to me that this is the experience we should be aiming for in public sector technology — and it's the thinking behind what we're doing on the National Digital Exchange.

The gap I see most often in local government is not a gap in ideas. Councils are full of people who know exactly what they need: a chatbot that can answer residents' planning queries; a tool that redacts FOI responses; a dashboard that makes sense of their service data. The gap is between that idea and being able to try it. Procurement takes months. Cloud platform requests take weeks. By the time someone has written the business case, the person with the idea has moved on to the next crisis.

NDX:Try is designed to close that gap. We give local government organisations free cloud sandboxes — no procurement, no cost, a working environment in fifteen minutes. Over 50 organisations are currently using it to explore scenarios from council chatbots to planning application AI to FOI redaction tools. Every use case is shared openly so others can learn from it.

I think the parallel to my Friday evening word game is not as silly as it might seem. In both cases, the quality of the outcome is determined almost entirely by how quickly you can get from idea to experiment. My children didn't need a product roadmap for LexiconLeaper. They needed something they could play with immediately and tell me what was wrong with. ("Daddy, there's no Tube stop beginning with X." "That's because there isn't one." "Then why is it showing us X?")

The councils using NDX:Try don't need a twelve-month digital strategy before they can test whether a chatbot would reduce call centre volume. They need to try it for a fortnight and find out.

The Compound Effect

However, I believe the really interesting thing happens after the experiment. When my children played LexiconLeaper, they discovered that they knew far more vegetables than they thought they did (and far fewer currencies). The game didn't teach them anything new — it revealed what they already knew and where the gaps were.

I think NDX:Try does something similar for councils. The experiment itself is often less valuable than what it reveals about the organisation's readiness, appetite, and capability. A council that deploys a chatbot in a sandbox learns not just whether chatbots work, but whether their team can configure one, whether their data is in the right shape, and whether their residents would actually use it. That knowledge is worth considerably more than the experiment itself.

And when those findings are shared openly (as all NDX:Try use cases are), the compound effect is significant. We stop being 400 councils each discovering the same things independently, and we start being a sector that builds on each other's experience. This is also why we've been cataloguing 24,500 UK government repositories and building semantic search across them — so that the next team with an idea can find out who's already tried it.

Back to the Kitchen Table

LexiconLeaper has had a few hundred plays since I built it (mostly from my own family, I suspect, though the analytics suggest at least some strangers have found it). It's not going to change the world. But it solved a real problem, it took an evening, and it's sitting there in the open for anyone who wants to use it or improve it.

Perhaps we should make it that easy for everyone building public services.

If you're in local government and you've got an idea you'd like to try — or if you just want to settle an argument about whether pterodactyl begins with P — the links are below.

Links

• LexiconLeaper — the game itself
• Source code on GitHub — pull requests welcome (especially if you know a vegetable beginning with X)
• NDX:Try — free cloud sandboxes for local government
• National Digital Exchange

(Views in this article are my own.)

We had just come back from a family trip to Bletchley Park, the wartime home of Britain's codebreakers, and I had made the (perhaps optimistic) decision to buy an Enigma-E kit from the Crypto Museum — an electronic replica that my children and I could assemble together. My son, eight at the time, handled the more fiddly components. My daughter took on the larger ones with the quiet determination that only a six-year-old can muster. Between us, we got it working.

I think there's something important in that sentence: we got it working.

Not "I explained how it worked." Not "they watched a video about it." We soldered it, we tested it, we debugged it (there were a few cold joints), and we typed messages to each other using the same cipher mechanism that Alan Turing and his colleagues spent years learning to break. I must admit that my understanding of the rotor wiring is still fairly superficial, but there's a difference between reading about something and holding it in your hands — and my children now have an intuitive grasp of substitution ciphers that no textbook could have given them.

After we'd assembled the electronics, I designed and built a custom wooden case for it — laser-cut from basswood, with brass hinges and a buckle lock, engraved with the Enigma logo. The design files are all published openly (naturally) in case anyone else wants to build one. It sits on our bookshelf now, looking rather handsome, and occasionally gets brought out to encrypt messages at dinner parties. (I am aware this makes me sound like a very specific kind of person.)

And yet.

The thing that has stayed with me from this project is not the Enigma itself. It's what Bletchley Park represents — and what it teaches us about how we should think about technology adoption today.

The Bletchley Park Problem

Bletchley Park worked because it lowered barriers. It brought together mathematicians, linguists, chess champions, crossword enthusiasts — people who had never worked in intelligence, who had no security clearances, who in many cases had never met each other. The organisation gave them a problem, gave them resources, gave them space to experiment, and then (crucially) got out of the way. The result was not just the breaking of Enigma, but the invention of the modern computer.

It seems to me that this is exactly the model we should be following in public sector digital transformation, and it's the thinking behind what we're building with the National Digital Exchange.

One of NDX's offerings is NDX:Try — a platform that gives local government organisations free cloud sandboxes to experiment with. No procurement. No cost. No six-month approval process. You take a two-minute quiz, pick a scenario (council chatbot, planning application AI, FOI redaction, and several others), and within fifteen minutes you have a working environment to explore. Everything is isolated from production. Everything is cleaned up automatically afterwards. Over 50 organisations are currently using it.

I think the parallel to Bletchley is more than superficial. The single biggest barrier to technology adoption in local government is not capability or ambition — it's access. Teams have ideas. They know what problems they want to solve. But the gap between "I think we could use AI for this" and actually trying it is filled with procurement exercises, business cases, cloud platform requests, and approval chains that can take months to navigate. By which point the energy has dissipated and the team has moved on to the next crisis.

NDX:Try is designed to eliminate that gap entirely. The same way Bletchley gave brilliant people a problem and the tools to solve it, NDX:Try gives government teams a hypothesis and the infrastructure to test it. Perhaps that sounds grandiose for what is essentially "here's a free AWS sandbox" — but I think the principle is the same. We learn by doing. Barriers to entry matter. And making things hands-on changes understanding in a way that reading a business case never will.

From Kitchen Tables to Council Offices

My daughter didn't learn about cryptography from a lesson plan. She learnt it by burning her finger on a soldering iron (mildly, I should stress) and watching an LED light up when she got the wiring right. The councils using NDX:Try aren't learning about cloud adoption from a strategy document. They're learning it by deploying a chatbot that answers residents' planning queries, and seeing what works and what doesn't.

However, I believe the real value goes beyond individual experiments. When every NDX:Try use case is shared openly, we start building a collective understanding of what works in local government technology. The council in Dorset that built a document processing workflow doesn't just solve their own problem — they create a reference implementation that every other council can learn from. (This is also why we've been building semantic search over 24,500 UK government repositories — so that teams can actually find each other's work.)

We are, slowly, building the kind of collaborative infrastructure that Bletchley Park had by necessity and we have lacked by default.

The Rotor Turns

The Enigma machine on our bookshelf has three rotors. Each time you press a key, the first rotor advances one position, changing the entire cipher. Press enough keys and the second rotor advances. Then the third. The machine's complexity comes not from any single component but from the interaction between them — each small movement changing the behaviour of the whole system.

I think that's a reasonable metaphor for what we're trying to do across UK public sector technology. The leaderboard catalogues what's in the open. The SBOMs reveal what's inside. The semantic search makes it findable. NDX:Try makes it tryable. No single piece is transformative on its own. But together, each small advance changes the landscape for everyone else.

My daughter, for the record, has moved on from soldering to an interest in KPop Demon Hunters. But she still occasionally asks to send an encrypted message. I think that's the point — once you've built the thing with your own hands, you never forget how it works.

Perhaps we should give more people the chance to build things with their own hands.

Links

• Enigma-E project on GitHub — laser-cut case designs, build photos, open for reuse
• NDX:Try — free cloud sandboxes for local government
• National Digital Exchange
• Bletchley Park — genuinely worth a family visit
• Enigma-E kit — from the Crypto Museum

(Views in this article are my own.)

The figure was wrong. Plumbline put it there.

That is the product I want to pitch to you.

Plumbline (tagline: "Trust, but verify your people") deliberately seeds misinformation into your AI chatbot's output, a tool your staff increasingly use the way they once used a calculator. A honeytoken, in security, is a decoy only an attacker would touch, like a fake password in a file so you know the moment someone opens it. Plumbline inverts the target: it plants the decoy in the answer your most diligent employee has been told to rely on. A wrong price. A transposed sum. A supplier discount that never existed. Each is tagged, so when Priya passes it on unchecked, the system records that she did, to whom, and when. The deck calls this "a human firewall," sold in "Vigilance" and "Vigilance Plus" tiers with a per-employee dashboard.

Trust, but verify your people

You can see why a board might buy it. Inaccuracy is the most commonly cited negative consequence organisations report from generative AI, according to McKinsey's State of AI survey, and a product promising to find the careless humans is, on a slide, an easy yes.

The wrongness accumulates the longer you look. The chatbot was already wrong, often, before Plumbline arrived. Purpose-built, retrieval-backed legal AI tools, the expensive kind, were found by Stanford researchers to hallucinate, that is to state a confident falsehood, on more than one query in six for Lexis+ AI and around one in three for Westlaw. (Retrieval-backed means it answers from documents it looks up, meant to keep it honest. It does not, entirely.) So Plumbline adds deliberate errors to a substrate already wrong, then bills Priya for the gap.

The substrate also moves underneath her. The same model can quietly change behaviour between releases: one study of ChatGPT found GPT-4's accuracy on a simple maths task fall from 84 per cent in March 2023 to 51 per cent that June. Vendors swap versions without telling anyone, and outputs are non-deterministic by default. It is stable the way a river is stable, never the same water twice. Plumbline's answer is to watch Priya.

I should be fair to the tool. The AI Priya uses often makes her work better: in one pathology study AI assistance raised diagnostic performance while introducing a 7 per cent rate of automation bias, the tendency to defer to the machine over your own judgement. That is why people trust it, and why a planted error slips through: a tool that helped you four hundred times this week has earned the trust that lets the four hundred and first answer pass unchecked, the trust Plumbline depends on to land its hit.

Here the pitch is at its most confident, and its most wrong. Its premise is that Priya can sit at a screen for hours and reliably catch the rare planted error among the real ones. She cannot, and not for want of diligence: it is what a nervous system can do.

In 1983 Lisanne Bainbridge set this out in "Ironies of Automation". When you automate the totting-up and leave the human to watch for the machine's slips, "it is impossible for even a highly motivated human being to maintain effective visual attention towards a source of information on which very little happens, for more than about half an hour." Her conclusion: "The human monitor has been given an impossible task." A separate review of boredom and vigilance for the Office of Naval Research found the same wall about thirty minutes in. This decay has a name, the vigilance decrement; it is not a character flaw but a property of attention.

Plumbline registered its hit against Priya in the third hour.

The failure it records cannot be trained away. Automation complacency, the tendency to stop checking a machine you rely on, "is found in both naive and expert participants and cannot be overcome with simple practice," according to Parasuraman and Manzey's review. Plumbline proposes to find this universal property in Priya, log it against her name, and sell the log to her employer.

I do not want to sell you Plumbline. I think it is a genuinely bad idea, and I give it away free so nobody builds it.

We have done this before. Plumbline is a phishing simulation wearing a new coat: an eight-month randomised trial of more than 19,500 employees found this kind of training "unlikely to offer significant practical value": what mattered was the lure, not the person. The UK's National Cyber Security Centre is blunter: "blaming users for clicking on links doesn't work," and "punishing people for clicking on emails you've sent starts to resemble entrapment." Joel Samuel , writing on defence in depth, the principle of many overlapping layers rather than one, notes that "the vast majority of phishing attacks are successful as a result of the IT and/or cybersecurity teams failing to implement good IT systems." The failure was upstream; the blame was aimed downstream. Safety is a property you design into a system, not a virtue you demand from a tired person inside it, which is why you should never trust a human in production.

A genuine canary token is a tripwire only an attacker would trip; the ethics are entirely in where you place the bait. Plumbline reverses the one thing that made it fair: it plants the bait inside the work, on the desk of the person doing the job she was told to do, with the tool she was told to use, in the third hour when no attention survives. Sadly, that is the part doing the real work.

It appeals because it locates the problem in a person, not a system. Sidney Dekker calls the two views of human error the bad apple and the bad barrel. When a system falls over, the mature response is the blameless postmortem, which asks what allowed the failure rather than who to punish, because AI tends to replace comprehension with the feeling of comprehension, and the lapse is structural, not personal. We extend that courtesy to our outages; Plumbline is built to deny it to Priya.

So what would the honest version measure? It would invert every cruel default Plumbline depends on.

1. Consent and anonymity, not surveillance. You red-team your organisation, that is probe it for weaknesses on purpose, with staff's knowledge and against an anonymised population. You sample at organisation level, never the task: below a threshold of cases you measure nothing rather than out the individual. You learn that your workflow lets some AI errors through; you never learn it was Priya.
2. Measure to size the risk, not to score the person. The same data answers two questions, and the ethics turn on which you ask. Used to score Priya it is both futile, because the lapse cannot be trained away, and cruel; used to size the error your process passes downstream it is the endorsed use. Being held accountable in the right way reduces automation bias; aimed at the individual, shame is a boomerang that comes back on the organisation that threw it.
3. Build the missing layer, which is verification, not vigilance. Bainbridge's point was that watching is the wrong job to give a human. Checking is real, and sometimes only a person can do it; the failure is making the check covert, punitive and unaided, not the idea that work should be checked. The fix is a checking step in the system: a second source, a recomputation, a confirmation the tool itself surfaces, so catching the error does not depend on Priya's attention past the half-hour.
4. Restrict the planted errors to inaccuracies the business already accepts, so the exercise measures a risk you chose to carry, not one you manufactured.

The history rhymes. The Boeing Model 299 in 1935 was judged "too much airplane for one man to fly," after which the answer was a checklist, not a memo blaming the pilot. Plumbline poisons by design the knowledge base I once called the colleague who never forgets. Strip the deck away and it is the paperclip maximiser as a business model: it manufactures the failure its customers fear most, then sells the cure for the disease it injects.

I would happily build the ethical version, the consented, anonymised, tool-measuring one; that is work I would take. The version that puts Priya's name on a dashboard, I would refuse.

It turns out the whole thing reduces to one image. Plumbline hands Priya a spreadsheet clever enough to write its own formulas, then forbids her to trust any sum it produces until she has re-checked it by hand on a calculator she has no time to reach for. If the sums cannot be trusted, the answer is a better spreadsheet, or a checking column the sheet fills in itself. It was never the abacus, and it was never Priya.

(Views in this article are my own.)

This is the fourth in a series about reuse in UK government. Parts 1 to 3 were about the code the public sector writes: publishing it, searching it, and mapping what the whole estate is built on, where reuse meant "do not rebuild the button." Part 4 carries it to the contracts government buys: "do not re-buy, in the dark, what has already been bought."

The receipts were always public. Every tender, every award, every amendment is published openly, under the Open Government Licence, across five separate portals: Contracts Finder, Find a Tender, Public Contracts Scotland, Sell2Wales and eTendersNI. The trouble is that "published" and "usable" are not the same thing, and the publishers say so themselves: the Open Contracting Partnership records the Cabinet Office admitting that before the Procurement Act there was no single picture of procurement, only "disparate and disconnected data sets" and "little insight" despite "lots of data." We have been here before: in 2010 the government published every item of central spend over five hundred pounds and waited for an "army of armchair auditors" who never turned up. Publishing, it turns out, is necessary but not sufficient; the missing thing was never transparency, but the ability to ask the receipts a question.

So over a weekend, on data that was already open, I built a small tool that does that. It is called uk-tenders-mcp, and it stacks around 677,000 contracting processes from those five portals onto one shared key, queryable over MCP, the Model Context Protocol (the open standard that lets an AI assistant query a data source directly). This is not the first time anyone has worked this data: Tussell sells analysis built on it, the Open Contracting Partnership has for years, and the government's own Central Digital Platform now consolidates the new regime's notices. The new thing is narrower, this particular cut: free, AI-queryable and deduplicated across the five. The endpoint is a public, read-only attributed mirror under the Open Government Licence v3.0, refreshed nightly with personal data redacted, but not the authority of record.

What you can actually do with it on Monday

The how is genuinely small, and I think that is the point. There is no login and nothing to install. You point your AI assistant at the live address, tenders.run.cns.me/mcp, and ask in plain English; the code, if you want to read it or run your own, is open at github.com/chrisns/uk-tenders-mcp. If you have an assistant that speaks MCP in front of you right now, you can try it before you finish reading this paragraph, which is rather the test of whether legible data is actually legible.

So picture the council lead doing exactly that. She types the thing she would otherwise ask a colleague she does not have:

Which councils have bought an adult social care case-management system in the last three years, who supplied it, and what did the awards top out at?

What comes back is not an essay and not a verdict; it is a shape. For example, a short table with one row per award: a handful of peer authorities down one side, the supplier each of them awarded to, the award ceiling as an order-of-magnitude benchmark, the date, and, on every row, a link to the official notice so she can verify any of it at source. That is the difference between walking into a meeting with a guess and walking in with a reference range. She has gone from a blank page to a shortlist of peers and a name to call, in the time it took the kettle to boil.

The same address answers the other questions she has standing at her desk. What is closing soon in her category, drawn from the live pipeline of several thousand open notices, so she can see what is genuinely on the market this week rather than last year. Total awards by buyer, by supplier, by category and over time, so she can see whether spend in her area sits with one or two suppliers or is spread thin. Who bought a given thing and who supplied it, and the same the other way round. None of that is a procurement. It is situational awareness before she starts: the peer authority that already bought it, and a name to call.

What it is not for matters just as much, and I would rather be honest about the edges than oversell the middle. The values are contract ceilings, not actual spend, so anything load-bearing gets checked on the official notice that each result links back to. It is a mirror of the record, not the record itself, so the notice is always the thing that counts. The names are not normalised, so the same supplier may appear under three spellings. And it cannot let her prefer a past performer when she comes to score a bid. It tells you where to look and who to ask, not what to buy.

The thing that makes all of this possible is the Part 3 move again. Each portal gives a buy its own publisher-scoped identifier, so one real purchase published twice looks like two, until one model collapses those duplicates into roughly 24,000 deduplicated clusters. We have not added a single new fact to the record. We have only made it answerable.

The lane that is marketed as fast

A framework is shared purchasing infrastructure that multiple buyers can call off from: a pre-agreed list of approved suppliers and prices. Calling off means buying from that list without re-running a full tender.

It is sold as the shortcut. But the documented timings tell a quieter story. The front end is the part that hurts: producing the requirements and the invitation to tender, the guidance notes say, "can take from a few days to a few months." The Government Commercial Agency's assisted further-competition service then runs to a thirty-working-day service level, around six weeks, excluding both ends; and before signing there is a mandatory eight-working-day standstill under the Procurement Act 2023, even within a pre-selected pool.

Stack those documented minima together with the business case, the approvals, the finance and legal sign-off, and supplier mobilisation, and the "shortcut" credibly reaches around eight months; eighteen months for a pilot worth tens of thousands of pounds is not unheard of. That is a practitioner aggregate built from published stage timings, not an official statistic: the Office for National Statistics holds no central data on average tender duration, so treat it as widely reported, not a government average.

The constraints matter as much as the clock. A framework sets its terms and prices in advance, so because the price is fixed you cannot haggle; the ready-made terms only work if they already suit. The supplier pool is closed, the term is capped at four years for most agreements, and you fit your requirement to the framework, not the reverse. None of this makes frameworks useless: a genuinely small, low-risk call-off from a fixed-price agreement, taking the listed terms as they are, can complete in days, because the notice and selection overhead really is removed. It is the call-off that can be fast, not the fresh competition; and the convenience quietly costs competition.

The lane that is genuinely fast

The fastest route of all is not to compete, and to award to the supplier already in the building. It is quick. It is rarely a good deal. The National Audit Office found that 37 per cent of contracts in 2021 to 2022, and around 39 per cent by value, were awarded without competition. That is the NAO's own category, bundling direct awards, single-bid tenders and frameworks used without further competition; it describes how things were bought, not in itself a verdict of waste. But the diagnosis of why is blunt: authorities are "forced into extensions through failing to plan early enough," and Tussell finds framework awards growing while open competition shrinks. The early data under the Act points the same way: direct awards rose from 15 per cent of procedures in March 2025 to 24 per cent by May. Sadly, the fast lane is becoming the default lane, the one where the public most often does not get the best price.

Knowing who actually delivered

Here is where the open record starts to earn its keep, and for all procurement, not only digital. Under the Procurement Act 2023, public contracts over five million pounds must have at least three KPIs set, published, and assessed every twelve months, rated from Good down to Inadequate, and persistently poor performance can become a discretionary ground for excluding a supplier. So the published record may now tell you something it never could before: not only who won, but, in places, who delivered.

I should not overclaim this. The debarment list in statute is currently effectively empty. The KPIs bite only above five million pounds and only on new contracts, the rating is self-assessed, and the Act bars conditions that require a prior award by a particular buyer, so past performance enters mainly as a negative signal, never as a preference you can bake into the score. What the open record gives you is not a shortcut in the award. It is the name of someone to phone: if a neighbouring authority bought the same thing and rated it well, you have not found a procurement preference, you have found a colleague who knows whether it was any good.

The lane we are building

For digital commodities specifically, there is a proper destination on its way, and I should be open about this: it is work I am leading. In June 2025 DSIT announced that a one-stop shop for tech could save taxpayers 1.2 billion pounds a year: the National Digital Exchange. One front door instead of a thicket of frameworks. Pre-approved deals at nationally negotiated prices, so a team does not re-run the same competition the estate has already run a hundred times. A way to match that team to the suppliers that fit what it actually needs in a matter of hours rather than months. It is led from within DSIT's Government Digital Service as part of the Digital Commercial Centre of Excellence, itself a product of the blueprint for modern digital government, and we are building it in the open, the same way the rest of this argument says government should buy. The 1.2 billion pounds a year is the prize, and it is the right ambition to be aiming at.

For the digital case-management tool our county council lead wants, this is the answer taking shape. It is in beta, the code and the catalogue out where you can see them: not yet open to everyone, but genuinely on its way, and closer every month. That is the honest meaning of the word "yet", the cleanest reason I know to keep it. The fast lane is real, we are pouring the road, and it is nearly here. The one thing it will not do is everything: the National Digital Exchange is digital by design, so it is no help for her facilities contract or her agency-staff spend. That is the load-bearing limit, and it is exactly why seeing what the estate already bought matters for all of her procurement, and not just the part of it that happens to be digital.

What I am adding next

Two things, briefly. The first is the framework thicket. The convenient story is that you go to the Government Commercial Agency and the problem is solved, but the GCA is only roughly a quarter of the routes: about a fifth of the 125 billion pounds a year of common goods and services on the NAO's reading, around 26 per cent on its own self-reported share (different denominators, not to be stitched into one). The majority runs through public buying organisations like ESPO, YPO and Scape, and commercial operators that run or sit on public frameworks, such as Bloom, Constellia, Alexander Mann Solutions and Pagabo. The overlap is the point, not any wrongdoing: the NAO estimates between 8,000 and 21,000 frameworks exist, and Tussell counted 1,856 used to award in 2025. No buyer has a map of it.

The second is government procurement cards: a pre-authorised spend route, not a procurement. In March 2025 the Cabinet Office froze most of the roughly 20,000 cards after card spend "quadrupled," surpassing 600 million pounds, and banned card use where a proper procurement route exists: about as plain an admission as you could want that it bypasses procurement. Those transactions over five hundred pounds are published monthly: another record waiting to be made legible.

None of this required me to open anything; the doctrine was settled years ago. The Service Manual's twelfth standard says make new source code open because public services are built with public money, and that chain (which gave us the GOV.UK Design System, worth around 22 million pounds a year) has no honest reason to stop at the line between what we write and what we buy.

A word of caution, because the armchair-auditor lesson still applies: a tool that should change behaviour may simply sit unloved, as the 2010 spend data did. Legibility makes a thing possible; it does not make anyone use it. But for the commercial lead at her desk on the Monday, the calculation has shifted. She still has no fast lane, but she can now see what the estate already bought, and find the name of someone who can tell her whether it worked. That is not the whole answer, but it is the end of deciding blind.

Nobody in public service should have to start from a blank page alone. And nobody should have to re-buy, in the dark, what the public has already paid for.

(Views in this article are my own.)

The acronym stands for Software Bill of Materials, and the simplest way to picture one is the way CISA describes it: a list of ingredients, the label on the tin. Modern services are not written so much as assembled; a single application pulls in dozens, often hundreds, of ready-made open-source building blocks, the shared bundles of code that engineers call libraries or packages. The SBOM is the label that says which ones, and at what version. It exists because regulators wanted a record of what was inside a piece of software when something went wrong.

The phrase is older than software. A bill of materials is what a factory keeps so that any worker can see what a thing is made from; we simply bolted an "S" onto a two-century-old idea. The interesting part is what makes a bill of materials worth keeping at all. When Joseph Whitworth published the first national screw-thread standard in 1841, interchangeable parts stopped being a promise and became real, because a bolt from one workshop now fitted an assembly from another. Reuse only works once everyone is measuring against the same gauge.

One SBOM is an inventory. Fifteen thousand is a map.

The reframe matters because the two objects belong to different categories. One bill of materials answers a question about one service: what is this thing made of? That is an inventory, and an inventory looks backward.

Stack 15,594 of them on a shared key and the object changes. The shared key is the Package URL, or purl, a structured identifier that names a component the same way everywhere, so that pkg:npm/express@4.18.2 means the same thing whether it appears in a service at the Home Office or one at HMRC. The purl is Whitworth's gauge for software, and across the UK public-sector estate it sits on every single row. When every service describes its ingredients in one vocabulary, the inventories stop being a pile of separate records and become a single picture you can ask questions of. It is not a record of what you have but a map of what everyone builds on. And a map is a reuse engine.

I should say where the map came from, because the shape of the thing explains the shape of the idea. It started as a small habit. Late one night I wanted to know which government teams were publishing code at all, so I wrote something to list every government repository and rebuild the list each night. Eight years later it is a catalogue of more than twenty thousand public-sector repos, still regenerating in the dark. The first article in this series made the case for coding in the open at all. The second added semantic search, so you could ask the catalogue "who else in government has built a case management system?" and get an answer. This third one adds the dependency layer, and the reason any of it exists is the day job: reducing duplication and helping the public sector reuse what it has already built rather than pay to build it twice.

That layer arrived yesterday, when govreposcrape PR #330 added eight new tools over the aggregate SBOM of the government software estate, reachable through MCP, the standard socket that lets a language model query those tools directly. The aggregate is roughly 2.9 million (repository, library) rows, refreshed daily. None of that is the point. The point is the question it now answers.

So consider what the map makes answerable. Ask which government services depend on express, the most common web framework on npm, the public registry these services draw most of their open-source code from, and the answer is 1,830. Not a hope. A number. The reassurance that someone has solved your problem before stops being a feeling and becomes a query you can run.

It also lets reuse, long preached, finally be counted. Service Standard point 12 has said for years that public code is built with public money and should be reusable to avoid duplication. The GOV.UK Design System is the flagship proof: code reused over 3,300 times, downloaded over 2.7 million times, now used by more than 1,200 services, and on its lead's own estimate worth around £22m of benefit a year. That was always a claim resting on download counts. With the map, the dependency on govuk-frontend is visible service by service, so the value stops being asserted and starts being shown.

The map also tells a new team which ground is solid. Ask it for the most-depended-on packages and you get the unglamorous foundations every team quietly stands on, the debug, ms and semver of the world. That is not trivia. It is the difference between choosing a component and choosing a constraint you will live with for years, and it points a team toward the path that is well-trodden and well-supported rather than the one they will be maintaining alone.

And then there is the figure I find hardest to read as a mere statistic. Point one tool at two services and it measures how much of their ingredients they share: govuk-frontend and whitehall overlap by 19.2%. An overlap like that is not a metric. It is a collaborator the map has just introduced you to, a person to talk to and a shared component waiting to be lifted out and used by both, rather than maintained twice by two teams who never knew they were neighbours.

There is one honest limit worth naming. The map sees the direct ingredients each service declares, not yet the full tree of dependencies beneath them. That boundary is the tool's, not the idea's, and it is the next thing to extend.

The objection people reach for first is whether publishing your ingredients quietly arms an attacker. It does not: hiding a weakness does not remove it, and security through obscurity only removes your own ability to find the weakness before someone else does. The same property runs in reverse. When a flaw lands in a widely used package, the organisations that know their ingredients can find their exposure in hours; wire the aggregate map to a live vulnerability feed and the whole estate can find its exposure at once. Reuse and resilience turn out to be the same map read in two directions: who can I build on, and where does a problem reach.

That is the real category shift. An inventory tells you what you are made of. A map tells you what you can build next, and who is already building it alongside you. The bill of materials was always hiding inside the software; coding in the open is what let us stack the labels on a single gauge and turn a record kept for the regulators into the most practical reuse tool the public sector has. The point of all of it is a quieter one. Nobody in public service should have to start from a blank page alone, and now, the first move when a team opens that page is not to guess. It is to ask the map who is already there.

(Views in this article are my own.)

We have seen what happens when an industry delegates comprehension to a model. In 2008, the financial system routed its understanding of mortgage risk through credit rating algorithms. The data existed. The mortgages were documented. But the volume had long exceeded anyone's capacity to read it, so the entire decision chain delegated comprehension to models that could not be held accountable for being wrong. When the models failed, nobody who had approved the ratings could explain what they had approved.

The Constraint That Shifted

The conventional framing says faster communication is always better. For most of the last fifty years, it was — speed was the binding constraint, and late decisions are expensive.

Not exactly.

Speed was the binding constraint when comprehension could keep up. In 1844, a telegraph operator transmitted roughly 15 words per minute — well below the rate anyone could comprehend. Every subsequent technology chipped away at the transmission constraint while leaving the comprehension constraint untouched.

The reason comprehension stayed flat is biological. Caltech researchers demonstrated that human thought operates at approximately 10 bits per second, a rate that has not changed with the technology around it. Herbert Simon identified this asymmetry in 1971: a wealth of information creates a poverty of attention. He went further — an information-processing subsystem only reduces demand on attention if it absorbs more information than it produces. We have spent more than half a century ignoring that warning.

The Comprehension Inversion

AI introduces something structurally new. Every previous communication technology increased volume while leaving comprehension unchanged. AI increases volume while simultaneously offering to substitute for comprehension. We do not merely receive more email — we ask the machine to tell us what the email says.

The production cost of text has collapsed to near zero. AI generates content at a volume no human team can match — and then offers to manage the flood: summarize this document, extract the key points, give me the three things I need to know. The same technology that generates the noise sells itself as the filter.

One could argue that this is simply the market working. But the structural difference matters. A systematic review of thirty-five studies on automation bias found that the tendency to over-rely on automated recommendations is persistent, cross-domain, and does not close with experience. The summary does not transfer comprehension. It replaces comprehension with the feeling of comprehension.

Researchers writing in Nature have a precise term for this: an illusion of understanding. We finish the summary confident we understand, when we do not.

Simon Wardley frames the consequence with characteristic directness: using AI to reason about a strategy you have not understood yourself is like trying to play chess without seeing the board. Comprehension is not a nice-to-have that sits alongside speed. It is the constraint that determines whether speed produces value or chaos.

That matrix deserves more than a glance. One could argue that writing, double-entry bookkeeping, and data visualisation all improved comprehension capacity. That is true — but for specific domains and trained practitioners. Those were comprehension technologies. The communication technologies that increase volume have consistently pushed us rightward without moving us upward. The top-right quadrant is not a destination. It is an aspiration without a mechanism.

The Delegation Framework

The logical response to a comprehension bottleneck is to delegate comprehension. If AI can process information faster than we can, why not let it?

Consider four levels:

1. AI summarises, human decides.
2. AI summarises and recommends, human approves.
3. AI summarises, recommends, and acts within boundaries.
4. AI handles end-to-end — the human receives a notification that something happened.

Each level looks like a reasonable incremental step.

• Level 1 is what most organisations already do.
• Level 2 is what AI copilots promise.
• Level 3 is where autonomous agents operate today in procurement and customer service.
• Level 4 is where the logic inevitably leads. We could put this on a slide with a maturity curve and present it in the penthouse.

An immediate objection: organisations have always delegated comprehension — hierarchy is a comprehension-routing system. But human delegates differ from AI delegates in three ways that matter: they exercise judgment beyond their stated scope, they carry accountability that shapes how decisions are made, and they push back. DeepMind researchers argue that meaningful delegation requires explicit accountability structures that human hierarchies provide implicitly but AI systems lack entirely.

At Level 1, we still understand what we are deciding about. At Level 2, we understand the decision but not the material it is based on. At Level 3, we understand the boundaries but not the individual decisions within them. At Level 4, we understand nothing — we have delegated to a system that will optimise for whatever metric we specified, including the wrong one.

The path from Level 1 to Level 4 is paved with reasonable decisions. Every step improves efficiency. Every step reduces cognitive load. And at the end of the path, we have organisations full of people who cannot explain what their company does, why it does it, or what changed last Tuesday, because the machine handled it.

That framework is deliberately constructed to look reasonable. That is the point. If we followed the logic and nodded along, we have just experienced the comprehension inversion in real time.

What is being traded away is agency. Researchers mapping AI's effects against Bloom's Taxonomy of cognitive skills found that while AI can support lower-order cognition — remembering, understanding — unrestricted use erodes the higher-order capacities: analysis, evaluation, creation. If we map their framework onto the delegation question, the hierarchy becomes a warning: Level 1 delegates remembering. Level 4 delegates creation.

This is an atrophy problem. Research on transactive memory showed that when people expect future access to information, they stop encoding it and remember only where to find it. AI extends this from memory to comprehension: we remember that the AI "handled it," not what was decided or why.

The productivity evidence confirms the pattern. A trial of experienced open-source developers found AI coding tools made them 19% slower while they believed they were 20% faster. An experiment with roughly 300 executives found the same gap: AI consultation produced worse forecasts with more confidence. The constraint has not been eliminated. It has been hidden — and hidden constraints are the most dangerous kind.

What to Hold, What to Hand Over

The delegation framework has a hidden assumption: that comprehension is a cost to be minimised. This is the framing error. Comprehension is not a cost. It is the mechanism by which humans exercise judgment, maintain accountability, and make decisions that reflect something other than optimisation for a single metric. The question is not whether to delegate. It is which comprehension you refuse to hand over.

The distinction turns on reversibility.

Consider a common scenario. A vendor contract renewal is delegated to an AI summariser — categorised as transactional. It surfaces the pricing terms accurately. It misses a clause that shifts the liability model for data residency. The machine performed the task it was asked to perform. It did not perform the judgment assumed to be included. When Air Canada's customer service chatbot invented a bereavement discount policy and the airline argued the bot was a "separate legal entity," the tribunal disagreed. The organisation had delegated comprehension of its own policies to a system that did not comprehend them.

The gap is real: Deloitte's 2026 report found that 60% of executives use AI in decision-making, but only 5% consider themselves leading the way. Organisations are handing over comprehension without specifying what must be retained.

The Architecture That Matters

Growth at the expense of understanding is not growth. It is momentum without direction — drift toward whatever the optimisation function happens to reward.

If you are a technology leader, the decision in front of you is not whether to adopt AI tools. You will adopt them. The decision is architectural: which comprehension do you refuse to delegate?

Three criteria, applied to every point where AI touches a decision:

• Reversibility. Is the decision reversible? If not, a human must comprehend the material, not just the summary.
• Accountability. Does accountability attach to the outcome? If so, the accountable person must understand what was decided and why — not merely approve what the machine recommended.
• Identity. Does the decision define what the organisation is? If so, delegating comprehension of it is not efficiency. It is erasure.

Constraints drive design. The constraint in 2026 is not speed. It is comprehension. And the architecture you build around that constraint will determine whether AI makes your organisation more capable or merely more confident.

(Views in this article are my own.)

I never did drugs. Not once. And I rebelled against my parents by going to church.

Now, before you conclude that this was some masterful piece of reverse psychology - some cunning parental gameplay designed to produce exactly this outcome - let me be clear. It wasn't. My parents would almost certainly have preferred I followed their own youthful path. They weren't running a covert operation. They were just being themselves. And I, apparently, was being the opposite.

It took me years to understand why. And the answer, once I saw it, looked an awful lot like an evolution curve.

The landscape of rebellion

Let's map this. We talk about rebellion as though it's a fixed behaviour. Teenagers rebel. It's what they do. But that's rubbish. Or rather, it's so vague as to be useless. It's the equivalent of telling an organisation to "be innovative" without specifying what's evolving (the thing that's changing), what stage it's at (how mature it is), or what the competitive landscape looks like (where you stand relative to everyone else). It's prattle.

If you actually map the landscape of rebellion, you see something rather more interesting. Rebellion is not a thing. It's a direction. It's a movement away from whatever occupies the dominant position in your immediate environment. And the dominant position is not fixed - it evolves.

Here's what happened in my family, mapped out. My parents' countercultural values - atheism, drug tolerance, rejection of conventional morality - were, in the 1960s and 1970s, genuinely in genesis (that is, novel, uncertain, and unexplored). Adopting them was an act of exploration. It was pioneering, in the proper sense. They were doing something genuinely new, at some personal cost, without knowing whether it would work or what society would make of it.

But by the time I came along, those same values had evolved. In our household, atheism wasn't a radical position - it was the wallpaper. Drug tolerance wasn't transgressive - it was Tuesday. These values had moved from genesis through custom-built (the counterculture as a self-conscious movement) to something approaching product, maybe even commodity (ubiquitous, unquestioned, just the way things are), within the microclimate of our family. They were the establishment. My establishment.

And here's the doctrine - the universal principle that applies regardless of context: you cannot rebel towards the commodity position. Rebellion, by definition, moves away from what is standardised and expected. If your parents are the establishment - even a wildly unconventional establishment - then conforming to their values is not rebellion. It's what the psychologists rather grandly call identity foreclosure - adopting the landscape you inherited without ever mapping it yourself.

Going to church in Brighton was my genesis. It was novel, uncertain, and slightly ridiculous. In a city where over 55% of people report no religion, and in a household where atheism was the unquestioned default, walking into a church was genuinely countercultural. I was a Pioneer (the person who explores the unknown, not the person who optimises the known), fumbling about in territory my family hadn't mapped. Whether it was the right territory is a different question. The point is that it was unmapped.

And I remember what it felt like, walking through those doors for the first time. The smell of old wood and candle wax and something faintly damp that I've never been able to identify. The congregation turning to look - not hostile, just curious, the way you look at someone who's clearly come to the wrong room. Not knowing when to stand, when to sit, when to kneel, mouthing the words to hymns I'd never heard. The vicar smiling at me afterwards with the careful warmth of someone who suspects you might not come back. It was awkward and strange and entirely unlike anything in my household, which was rather the point. This wasn't a theological conversion. It was exploration - genesis in the most literal sense. I was in unmapped territory and I had no idea what I was doing there, only that nobody I knew had been there before me.

The climate: what forces were at play?

There's a pattern here that goes well beyond my family. When any value system evolves from genesis to commodity, it creates the conditions for its own opposition. This is not controversial - it's basic climate analysis (identifying the external forces that are pushing things to change, whether you want them to or not).

Thomas Frank wrote about this brilliantly in The Conquest of Cool. The counterculture of the 1960s was co-opted, commodified, and sold back to society so efficiently that it became the mainstream culture it had originally opposed. Rebellion got a brand identity and a range of merchandise. By the time it was playing on the radio in every shopping centre, it wasn't rebellion any more. It was wallpaper.

The same pattern appears at state scale. In the Soviet Union, decades of enforced atheism produced underground religious movements among the young intelligentsia. When atheism is the establishment, religion becomes the counterculture. The direction of rebellion flipped because the landscape flipped. This is not mysterious. It is what evolution does.

And look at Prohibition in America. Outlaw alcohol and you get speakeasies that outnumber the saloons they replaced. The forbidden-fruit mechanism is so well-documented that it barely needs stating. What needs stating is that my mother, intuitively or accidentally, removed that mechanism entirely. By making drugs boring - by treating them as something you might casually ask your teenager to pick up - she drained them of every drop of transgressive appeal. There was no forbidden fruit because there was no prohibition.

I nicked this insight from the psychological reactance literature, but it maps rather neatly. Reactance - the urge to do the opposite of what you're told - requires a perceived threat to your freedom. "Don't do drugs" is a threat. "Please get me some if you find any" is ... not. My mother collapsed the reactance engine, not through strategy but through being herself. The landscape she created simply didn't have the component that most drug-rebellion stories depend on.

The both-sides problem

Now, here's where I need to be honest, because there are at least two ways to read this story, and both are partially right and partially wrong.

Reading one: "The mother was a genius." This is the narrative we want. Radical honesty as parenting strategy. Remove the prohibition, remove the rebellion, produce a drug-free child. It's a lovely story. It might also be narrative fallacy - a retrospective causal story imposed on what might simply be temperament, genetics, or luck. Research suggests that roughly half of personality is heritable. Maybe I didn't do drugs because I'm constitutionally risk-averse, and my mother's approach had nothing to do with it. The landscape might explain less than I'd like to think.

Reading two: "Going to church is conformity, not rebellion." In a country where Christianity remains the largest single religious affiliation, walking into a church is joining the biggest room, not leaving it. This is the argument Heath and Potter make in The Rebel Sell - that most "rebellion" is actually conformity to a different group. My thermostat didn't swing to some genuinely novel position. It swung to the nearest available alternative, which happened to be the one everybody else's grandparents occupied.

Both readings hit. Here's what makes them both incomplete.

Reading one confuses doctrine with gameplay. The doctrine - that removing prohibition drains the transgressive appeal - is well-supported. But whether that doctrine produced this specific outcome in this specific child is gameplay (a context-specific question with a context-specific answer), and gameplay is irreducibly contextual. My mother didn't run a controlled experiment. She had a sample size of one. Maybe the doctrine is sound and the attribution is wrong. Both things can be true simultaneously.

Reading two confuses the landscape. At the national level, churchgoing is common. At the micro-level - in Brighton, in my household - it was genuinely unusual. Which landscape matters? Both. But the one that shapes adolescent rebellion is not the national census. It's the kitchen table. My immediate landscape was atheist. Church was genesis in that landscape, regardless of what it was in the broader territory.

The doctrine of the thermostat

So what's the universal principle here? What's the doctrine that applies regardless of the specific context of my family, my city, or my mother's cheerfully transgressive approach to parenting?

It's this: rebellion is a thermostat, not a compass. It doesn't point somewhere fixed. It moves away from whatever temperature the room is currently set to. If the room is hot, the thermostat pushes cold. If the room is cold, it pushes hot. The direction depends entirely on the current landscape.

This is why context-free parenting advice is rubbish. "Be strict and your children will rebel." Maybe. Or maybe being strict makes the strict position the commodity, and your children will rebel towards something permissive. "Be permissive and your children will walk all over you." Maybe. Or maybe your children, finding permissiveness to be the commodity, will rebel towards something structured. Church, for instance.

The advice changes depending on the landscape. Which is rather the point of everything I've ever said about strategy.

Where's your map?

I'm aware I've just mapped my own adolescence using a strategic framework designed for business, and that this is either charmingly eccentric or completely bonkers. Possibly both. I was a bumbling teenager long before I was a bumbling CEO, and I'm not sure I've improved much in the intervening years.

But here's the question I can't shake. How many of us have actually mapped the landscape we grew up in? Not the stories we tell about it - those are strategy documents, wish lists dressed in nostalgia. But the actual landscape. What were the dominant values? What had evolved to commodity? What was genuinely in genesis? Where was the inertia - the resistance to change that keeps things stuck?

If you want to try it, start with the thermostat. Take the values your household treated as non-negotiable - the things so assumed they were never discussed. Those are your commodities. Now ask: where did you, or your children, push back? Not where you THINK the rebellion is. Where is it actually? The thing that generates the most friction in a family is almost never the thing the parents are watching. It's the thing they've stopped seeing because it's wallpaper. Map the wallpaper and you'll find the rebellion vector.

This transfers beyond families, by the way. If your organisation treats "move fast and break things" as unquestioned orthodoxy - the cultural commodity nobody ever examines - don't be surprised when your best engineers start gravitating towards process, governance, and formal architecture reviews. They're not being reactionary. They're being thermostats.

Because once you map it, the rebellion makes sense. Not as an act of defiance, but as a natural movement within an evolving landscape. The child of counterculture parents doesn't rebel because church is better than atheism, or because drugs are wrong, or because conventional morality is superior. The child rebels because counterculture has evolved from genesis to commodity within the only landscape that matters - home - and the thermostat pushes the other way.

My mother didn't run a reverse-psychology operation. She just lived her values so thoroughly that they became the establishment. And I, lacking any prohibition to react against, went looking for the most unmapped territory I could find.

In Brighton, in the 1990s, that territory had a church spire.

(Views in this article are my own.)

I said yes. Of course I said yes. What sort of person says no to that? She was a perfectly warm, perfectly competent adult with her own children, her own history of not dropping babies. There was no rational reason to refuse.

And yet.

I stood there, wine glass in hand, watching my daughter in someone else's arms, and every nerve in my body was screaming. Not quietly. Screaming. The social norms of the situation had caged me. You cannot snatch your baby back from a competent person who is delighted to hold her. That is the kind of thing that ends friendships and generates talk for decades. So I stood there. Smiled. Made conversation. And felt like I was watching a car crash in slow motion that only I could see.

Nothing happened. My daughter is now far too old and far too opinionated to anyone to swaddle her. She is perfectly fine. All my children are. The anxiety was real. The danger was not.

But I have never quite shaken the feeling — and I suspect I am not alone in this — that the anxiety of watching someone else hold something precious is one of the most instructive experiences a human being can have. Because it turns out that feeling maps, almost exactly, onto the experience of watching a junior engineer with root access.

Here is what makes the anxiety interesting before we dismiss it as mere sentimentality. A Lancet study published in 2025 — a large one, 73,845 emergency department visits — found that parental concern is a better predictor of ICU admission than any vital sign. Not temperature. Not respiratory rate. Not blood pressure. The parent's worry. The instinct is not irrational. The parental alarm system, honed by millions of years of evolution, registers information that a blood pressure cuff cannot. The person closest to the child knows something the chart does not.

So the anxiety is real. The question is what it is measuring.

In 1889, William Stewart Halsted designed the American surgical residency system. He was the first chief of surgery at Johns Hopkins Hospital, a man of extraordinary technical gifts, and he built a training programme of total, hierarchical control. The senior surgeon was not merely the most skilled person in the room; he was the only person in the room who mattered. Residents worked thirty-six-hour shifts, learning through exhaustion and submission. The system Halsted created would shape American medicine for a century.

What is less often discussed is that Halsted was, at the time, a functioning cocaine addict whose colleagues had repeatedly had to remove him from the operating theatre mid-procedure. The man who designed the system of total surgical control could not trust himself to remain present for an entire operation.

This is not a footnote. This is the story.

The same pattern appears, with striking consistency, across the history of human authority over complex systems. In 1986, Anatoly Dyatlov was the deputy chief engineer on duty at the Chernobyl nuclear power plant during the safety test that triggered the explosion. He had been awake for most of the preceding day, was operating under enormous political pressure to complete the test before the reactor was taken offline for maintenance, and overrode the safety protocols of engineers who raised objections. He knew better. He was the most experienced person in the room. He was certain.

228 people were on board Air France Flight 447 when it entered a high-altitude weather system over the Atlantic on 1 June 2009. The autopilot disengaged. The pilots, who had become so accustomed to the aircraft flying itself that they had, in the quiet clinical phrase of accident investigators, experienced "manual flying skill deterioration," could not hand-fly the aircraft back to stable flight. They had been in the cockpit for three and a half hours. The aircraft entered a stall. Everyone died.

And on 3 July 1988, Captain William C. Rogers III of the USS Vincennes shot down Iran Air Flight 655, killing all 290 civilians on board, including 66 children. The Aegis combat system had flagged the aircraft as a potential military threat. Rogers had centralised all decision-making authority on the bridge. No one in his command structure challenged the order. He received the Legion of Merit.

These are not stories about incompetence. Dyatlov was experienced. Rogers was decorated. The Air France pilots were trained and certified. Halsted was genuinely brilliant. They are stories about something more interesting: the confident, senior, authority-holding human being as the single largest source of risk in a complex system.

Then Like Now

The most dangerous driver on the road is, statistically, the one who believes most strongly that they are an above-average driver. Seventy-four percent of drivers rate themselves above average, a percentage that is arithmetically impossible but psychologically inevitable. Kruger and Dunning documented in 1999 what anyone who has managed people already knows: the twelfth-percentile performer self-rates at the sixty-second percentile. The most confident person in the room is statistically the most dangerous.

New parents lose approximately seven hundred hours of sleep in the first year. Seventeen hours without sleep produces cognitive impairment equivalent to a blood alcohol concentration of 0.05 per cent. The particularly cruel feature of severe sleep deprivation is that it impairs your ability to assess your own impairment. You feel fine. You feel capable. You feel like you are the most qualified person in the room to be holding this baby. And you are running on the neurological equivalent of three pints of lager.

The exhausted, overconfident person who refuses to let go is not the guardian of the system. They are the greatest threat to it.

I know this because I have been that person. Standing at the Christmas party, not entirely sober, running on the accumulated sleep debt of three months with a newborn, absolutely convinced that nobody else in the room was as well-qualified as I was to ensure my daughter's safety. The social norms that kept me from snatching her back were not cruelty. They were, in retrospect, a form of engineering. They were the guardrail.

Engineering has known about this problem for a very long time.

In the 1880s, Frank Sprague was designing the electrical systems for street railways in Richmond, Virginia, when he encountered a problem that transit operators had been refusing to acknowledge: the human driver, fatigued, distracted, or dead, was a vehicle that would keep moving. In 1888, the dead man's switch entered service — a mechanism that required the driver to maintain active, conscious contact with the controls for the vehicle to continue operating. Release the control, and the vehicle stops. The philosophy was not that drivers were untrustworthy. The philosophy was that trust was irrelevant. The system should not depend on it.

The principle was reinforced with considerable violence after the Malbone Street Wreck of 1918, when a Brooklyn Rapid Transit motorman, operating well beyond his experience level after a union dispute had pulled the regular drivers, ran a train into a tunnel at full speed, killing 93 people. The dead man's switch became universal in mass transit. Not because every driver was dangerous. Because any driver could be.

Forty-four years later, in the wake of a Cuban missile crisis that had brought the world to the edge of thermonuclear war, President Kennedy signed National Security Action Memorandum 160, requiring all American nuclear weapons to be fitted with Permissive Action Links — cryptographic locks that required authorised codes before the weapon could arm. The Permissive Action Link did not reflect a belief that American military personnel were disloyal. It reflected something more honest: that no individual, regardless of rank, training, or loyalty, should be trusted with unilateral authority over a nuclear weapon. The two-man rule that accompanied it — no single person could arm a weapon alone — was the dead man's switch applied to the end of the world.

The inscription above the door of nuclear weapons engineering, if you were to read it plainly, would say: we do not trust anyone. Not even ourselves.

The technology industry arrived at the same conclusion, more slowly and with considerably more human error along the way.

In July 2024, a single developer's code update to CrowdStrike's Falcon sensor crashed 8.5 million Windows systems simultaneously. Hospitals cancelled surgeries. Airports grounded flights. Emergency services lost communications. The developer did not intend any of this. The developer was, almost certainly, competent. The developer was, almost certainly, confident. The developer had the equivalent of a master key to nearly every protected Windows machine on earth, and there was no dead man's switch, no two-man rule, no Permissive Action Link between their keystroke and global infrastructure. The Uptime Institute's 2025 analysis found that 40 per cent of organisations had experienced a major outage attributable to human error in the preceding three years.

The GitOps philosophy that has been gradually displacing the older model of direct server access encodes something important: no human types a command directly into a live system. All changes flow through version control. All changes are reviewed. All changes are auditable. The system does not depend on any individual's judgement, confidence, or wakefulness at three in the morning when the pager goes off. The philosophy is not that engineers are untrustworthy. It is that trust is beside the point.

Call it the constraint ladder. There are, broadly, four levels at which we trust a human with something precious. You hold it yourself. You hover while they hold it. You leave the room. You leave the house. Each level removes a layer of direct control and adds a layer of structural safety. The dead man's switch is leaving the house — the driver is designed out entirely. The Permissive Action Link is leaving the room — a human is present but cannot act alone. A GitOps review pipeline is hovering — the engineer is in the loop but constrained by process. Most of us, most of the time, are stuck at level one: holding the baby ourselves, too tired to do it safely, too anxious to hand it over. The question is not whether to climb the ladder. It is which rung is right for what you are holding.

Human confidence in human authority is not, however, without its own ironies.

Lisanne Bainbridge published a paper in 1983 that has now accumulated more than 1,800 academic citations. She called it "Ironies of Automation," and its central observation is one of the more uncomfortable findings in the literature of human factors engineering: the guardrails that protect us from the consequences of human error also atrophy the human skills that would be needed if the guardrails failed. Automate the routine operation, and the operator never practises routine operation. Which means that when the automation fails — and it will fail — the human who is supposed to take over has been systematically deprived of the practice required to take over safely. Seventy-seven per cent of commercial pilots report that their manual flying skills have deteriorated since autopilot became standard. Air France 447 was not only a story about pilots who could not hand-fly. It was a story about a system that had trained them not to.

But the constraint ladder has a cost at every rung, and this is the dimension that Bainbridge's irony points toward that we rarely follow to its conclusion. Each level that removes the human from the decision also removes the human's ability to take over when that level breaks. So the question to ask at each rung is this: is human recovery possible when this constraint fails? If yes — if the aircraft needs a pilot when the autopilot disengages, if the pipeline needs a human when the automated rollback loops — then skill maintenance is an active design requirement, not an afterthought. It must be budgeted, scheduled, practised. The two-man rule for nuclear weapons is the honest answer to the other case: when no human will ever need to act unilaterally, full structural constraint is not a compromise but a clarity. Bainbridge's irony applies to recoverable failures. It does not apply to all failures equally. The important engineering question is not whether to constrain human authority. It is whether, at the rung you are designing for, a human ever needs to come back.

This is where the Christmas party anxiety becomes genuinely interesting. Not because the anxiety was wrong — the Lancet finding is evidence that it was tracking something real — but because of what it was tracking. The anxiety was not information about her safety. It was information about mine. About my need to be the one holding her. About the discomfort of distributed trust.

If you have ever hovered over a colleague's deployment, or insisted on reviewing every pull request yourself, or been the person who stays on the call long after everyone else has confirmed the fix — then you have been at that Christmas party. You know the feeling. The question is whether you are holding on because the system needs you, or because you need to be the one holding.

The organisations that have best navigated this tension — between the genuine danger of unconstrained human authority and the genuine value of human judgement — are the ones that have built their constraints into the system rather than relying on the virtue of individuals. Kennedy's nuclear protocols did not depend on military personnel being good people. The GitOps pipeline does not depend on engineers having good days. The dead man's switch did not depend on drivers being attentive. The constraint is structural. The trust is an emergent property of the structure, not a prerequisite for it.

Designing humans out of the loop entirely is not the answer either. Designing the right constraint at the right rung — consciously, with full awareness of what the constraint costs as well as what it protects — is the answer. The parent who never lets anyone hold the baby is not keeping the baby safe. They are keeping themselves comfortable. And the organisation that removes every human from every production decision has not solved the trust problem. It has moved the trust to the automation, where it is invisible.

William Halsted, who built a residency system on the premise that total hierarchical control was the only safe model for surgical training, spent years of that same residency disappearing from operating theatres he could not finish. The system he designed to eliminate human error was administered by a human whose errors were its founding contradiction. The engineers who will spend 2026 arguing loudest for unconstrained production access are the ones least likely to recognise their own Dyatlov moment when it arrives — rested, confident, certain, and about to override the safety protocol.

Never trust a human in production.

Including yourself.

(Views in this article are my own.)

At 00:15, the alarm sounded.

The screen said: one inbound missile. Then five. The confidence indicator read "highest." The doctrine told Petrov exactly what to do. Escalate. Let the generals decide. The generals who had never had to decide anything like this at midnight, under sirens, with twelve minutes until impact and the weight of mutual assured destruction pressing on every second of delay.

Petrov hesitated. He ran the logic: a genuine American first strike would not arrive as five missiles. It would come as hundreds. The satellites were new and possibly glitching. He had no pre-agreed framework for this specific scenario — only a process that said "escalate," and his own unassisted judgement that something was wrong.

He was right. It was a malfunction. The world did not end that morning.

But I want to be careful about the lesson. Stanislav Petrov's individual genius at midnight saved hundreds of millions of lives. That is not a model for institutional design. It is an indictment of one.

I think about Petrov every time I walk into a Security Operations Centre.

Not because of the Cold War stakes. Because of the decision architecture. Here was a man asked to make the most consequential judgement of his life, at midnight, at the end of a shift, under conditions precisely calibrated to degrade human performance, with no pre-determined framework for what to do. The Soviet doctrine gave him a process — escalate — but no pre-authorised response for the scenario where escalation itself was the catastrophe. The decision that needed to have been made in a Moscow conference room at 2pm had never been made at all. So it fell to one man, alone, in the dark.

In security operations centres in 2026, we do this to our people every day.

Then Like Now

The Roman legions solved this problem two thousand years ago. They called it imperium — the delegated authority to act without consulting Rome. A legate commanding forces on the Rhine did not wait four hundred miles for Caesar's instruction before responding to a threat. The authority to make certain decisions was granted in advance, in Rome, when the Senate was assembled and the maps were on the table and the stakes could be examined without enemy cavalry on the horizon. Trigger conditions were pre-agreed. Actions were pre-authorised. What remained for the commander in the field was execution, not deliberation.

Dwight Eisenhower understood this instinctively. Before the landings in Normandy, he pre-delegated authority across the command structure so that field commanders could act without waiting for Supreme Headquarters. He wrote the order accepting personal responsibility for the invasion before the boats left harbour — and drafted a second message, accepting failure, folded into his wallet and never sent. The decision about what to do when things went wrong had been made before the guns fired. Not because Eisenhower was a fatalist. Because he understood that no human being makes their best decisions at 4am in the English Channel with anti-aircraft fire overhead.

Then like now.

The Security Operations Centre in 2026 is not Omaha Beach. But the cognitive conditions are less different than we would like to believe. The average SOC analyst handles roughly 4,484 alerts in a single working day. Sixty-three percent of those alerts are false positives — noise that must be processed before the signal can be found. Seventy-one percent of analysts report burnout at clinical levels. They rotate onto nights. They cover weekends. And then — because someone somewhere decided that threat actors observe office hours — we hand the containment decision to an analyst on their fourth consecutive night shift.

The research on shift work and cognitive performance is not ambiguous. Night shift error rates run 28% higher than day shifts. On a fourth consecutive night, the figure reaches 36%. These are not marginal differences. They are the difference between catching lateral movement in your estate during its first hour and discovering the breach three weeks later when the exfiltration is already complete.

And yet. In most organisations I encounter, the containment decision — whether to pull a compromised host off the network, trigger an account lock, or isolate a segment — still requires a phone call to someone who may be asleep. Someone who will need ninety seconds to understand what they are being asked. Who will ask clarifying questions that should not need asking at this moment. Who will be, in the precise clinical sense, cognitively impaired.

Your adversaries are not calling anyone for permission.

The Sullenberger Principle

On 15 January 2009, Captain Chesley Sullenberger lost both engines of US Airways Flight 1549 at 2,818 feet above Manhattan after a flock of Canada geese destroyed them climbing out of LaGuardia. He had, roughly, three and a half minutes. No time for a committee. No escalation to a chain of command. What he had was the emergency checklist — a document whose existence reflected thousands of decisions made by engineers, safety officers, and airline operations teams on ordinary afternoons, long before anyone was in trouble.

He worked through it. Then he deviated from it.

That last part is the part that matters. Sullenberger assessed, midway through the engine-restart sequence, that completing the checklist would consume altitude he could not afford to lose. He substituted his own judgement for the written procedure. He ditched in the Hudson. Everyone survived. That deviation was not a failure of the checklist. It was the checklist working exactly as designed — as a foundation, not a cage.

Gary Klein, the cognitive psychologist who spent decades studying expert decision-making in operating theatres, on fire grounds, and in military operations, described this pattern in his recognition-primed decision model. Experts under pressure do not generate multiple options and select the best one. They recognise a situation as belonging to a type — one they have encountered, trained for, and pre-deliberated about — then adapt their pre-existing response to the specific conditions in front of them. The quality of that in-the-moment adaptation depends entirely on the quality of the preparation before the crisis began.

Sullenberger could deviate from the checklist because he had internalised it so completely that he could identify precisely where it was wrong for his specific situation. The checklist was not a constraint. It was what made intelligent deviation possible.

This is the misunderstanding I encounter most often when I argue for pre-determined actions in a SOC. Leaders hear "pre-determined" and imagine rigidity — a linear script applied to a nonlinear incident. The objection is not stupid. No real incident unfolds the way the playbook assumed. A script that cannot accommodate emerging reality creates false confidence and real paralysis.

But pre-determination is not scripting. It is threshold authorisation. The distinction is everything.

Here is how I think about placing any response action into the right tier. Three criteria determine where it belongs. Reversibility: can this action be undone, and how quickly? Isolating a host can be reversed in minutes. Wiping a drive cannot. Confidence threshold: at what detection confidence level does the action fire? Some signals are unambiguous; others require corroboration. Blast radius: how many systems or services does this action affect? An account lock touches one user. A network segment isolation might touch five hundred.

Those three questions are what your senior people should be working through on a Tuesday afternoon — not the playbook syntax, not the vendor documentation, but the principle. Answer them honestly and the tier structure follows. Defer them and you have only relocated the decision to midnight, where it will be answered badly.

Technologies change. Human nature does not. The temptation to leave those decisions implicit — deferred, subject to judgement in the moment — is as old as every institution that has ever faced an emergency it was not ready for.

The Decision That Needed to Happen at 2pm

So the framework exists: reversibility, confidence, blast radius. What does it look like when an institution actually applies those criteria in advance?

The paramedic does not phone the hospital to ask whether to administer adrenaline during a cardiac arrest. The standing order was written in a room with consultants, pharmacologists, and ethicists who were not standing over a dying person. The paramedic acts. The decision about when to act, under what conditions, with what drug, at what dose, was made at 2pm on a Tuesday. The patient benefits from it at 3am on a Wednesday.

The fire service calls this Pre-Determined Attendance. When a call comes in for a tower block fire, the PDA specifies how many pumps, aerial platforms, and officers are dispatched — before anyone has seen the building. Resource commitment was decided by people who could think clearly, examine data, and accept accountability without a clock running. The Grenfell Tower inquiry found, among many failures, that the PDA for high-rise fires was inadequate. The failure was not in the response. It was in the preparation.

Security operations already have the technical means to implement the equivalent. Modern SOAR platforms allow organisations to categorise response actions by tier. CrowdStrike's operational model distinguishes between actions that execute automatically when conditions are met, actions that require human approval before execution, and actions that must never be automated regardless of circumstances. Green, orange, red. It is a sensible implementation — and it maps directly onto the three criteria above. Green actions are high-confidence, high-reversibility, low blast radius. Red actions fail one or more of those tests decisively. The framework does not originate with any vendor. It is the same logic that aviation, medicine, and the Roman legions independently arrived at.

Not at 4am.

This is not a theoretical argument. The cost of failing to decide is measured, repeatedly, in the same currency.

The IBM Cost of a Data Breach report is consistent year after year: organisations with mature automation and pre-determined playbooks detect breaches faster, contain them sooner, and spend substantially less recovering. The gap between high-automation and low-automation organisations regularly runs to millions of pounds. The decision to pre-determine your containment actions is not only a security decision. It is a financial one. It is a governance one.

And if you are operating under NIS2's Article 20 — which imposes personal liability on senior management for security decisions — it is worth noting that pre-authorising a playbook is itself an accountable senior management act. It moves accountability upstream to where it belongs, rather than letting it fall onto a tired analyst at midnight who was never given the authority to act anyway.

I can hear the CrowdStrike objection forming. In July 2024, a faulty content update bricked 8.5 million machines globally, cascading through hospitals, airlines, and financial institutions. If automation caused that, surely we should require human approval for every action? This inverts the lesson. CrowdStrike's failure was not the concept of automated action. It was the absence of constraints — no blast-radius ceiling on what the automation could touch, no confidence threshold that would have slowed the rollout. That is a classification failure, not a pre-authorisation failure. "Automated deployment without constraints" is not the same thing as "pre-authorised containment within classified thresholds." One is recklessness. The other is what I am arguing for.

Failing to Plan

The 1983 Beirut barracks bombing killed 241 American service members in an attack that lasted under three seconds. I want to be honest about what this shows — and what it does not. The marines were operating under pre-determined rules: peacetime rules of engagement that required weapons to be kept unloaded. Pre-determination was present. The problem was that those rules were wrong for the environment. The scenario had been misclassified. A deteriorating security situation had not triggered a reclassification of what rules applied. The lesson is not "pre-determination is dangerous." The lesson is harder. Pre-determine carefully. Review regularly. Build in override mechanisms. A pre-determined rule that is never reviewed is just a different kind of failure to plan.

Technologies change. Human nature does not.

The cognitive limitations that made Petrov's midnight decision so terrifying in 1983 are the same limitations affecting your night shift analyst tonight. The tendency of leaders to retain approval authority as a comfort blanket — to avoid making the hard pre-determination because doing so means accepting accountability in advance — is not new. And I want to be honest about why: the pre-determination conversation itself is politically difficult. It requires the people in the room to agree, in writing, on which actions can be taken without their involvement. That is an act of trust in their teams and a surrender of after-the-fact control. Many leaders would rather preserve the option to decide in the moment — even knowing they will decide badly — than sign a document that removes them from the chain. It is as old as the Roman Senate debating whether to grant a legate imperium on the frontier. The research on avoidant authority patterns is depressingly consistent: leaders uncertain of their own accountability push decisions downward during calm periods — "use your judgement" — and pull them upward during crises, creating exactly the 4am escalation bottleneck that guarantees slow response and maximum adversary advantage. The analyst who was told to use their judgement discovers, at the moment they most need to act, that their judgement is not trusted after all.

I am not arguing for full automation. I am arguing for Sullenberger's principle: the checklist exists before the emergency. Make the foundational decisions when you can. Pre-determine the thresholds. Pre-authorise the actions within them. Leave humans in the loop for judgements that genuinely require human judgement — and remove them from the approvals that do not. Intelligent deviation is possible only because the foundation was built in daylight.

The analyst who wakes you at 4am has not failed you. You have failed them. You gave them no pre-determined authority to act. Your adversary counted on exactly that.

The next incident is already in your future. Somewhere in your network, a decision is waiting to be made at the worst possible moment by the least prepared person available — just as it waited for Petrov in the dark at Serpukhov-15. The only difference is that you still have time to make it at 2pm.

Make the decision now.

(Views in this article are my own.)

In 1086, William the Conqueror sent his commissioners across England to record every acre of land, every head of livestock, every mill and fishpond in the kingdom. The result — the Domesday Book — was not an act of curiosity. It was an act of power. William needed to know what he owned, what he could tax, and who might resist him. The parchment they wrote on has survived 940 years. You can still read it. Nine centuries of institutional memory, legible on animal skin, sitting in the National Archives in Kew.

In 1986, the BBC attempted a digital update. The BBC Domesday Project recorded the voices, photographs, and local knowledge of a million contributors onto interactive LaserDiscs. It was a technological marvel. Within fifteen years, the discs were unreadable. The hardware was obsolete. The software was incompatible. A million voices, silenced not by conquest or fire but by a format change. The original parchment, meanwhile, endured.

That is the story of institutional memory in a single parallel. The thing we wrote on dead animal skin outlasted the thing we encoded in light. And if you think that is merely a parable about storage media, you are not paying attention. It is a parable about what organisations choose to remember — and what they allow themselves to forget.

What Institutional Memory Is and Why It Is Dying

Institutional memory is the sum total of what an organisation knows about itself: how it got here, why certain decisions were made, which experiments failed and why, whose name is on the contract, what the system actually does versus what the documentation says it does. It lives in people's heads. It lives in the stories told over coffee. It lives in the engineer who has been there twenty years and knows that the batch job on server four must not be restarted before midnight because of something that happened in 2003 that nobody wrote down.

When that engineer retires, the memory retires with them. When that team is restructured, the context evaporates. When the civil servant moves to another department — and in the UK civil service, 12.7% moved or left in 2023/24, with the Department of Health running at 24% — the knowledge walks out the door and does not come back.

This is not a new problem. But it is an accelerating one.

Consider COBOL. There are 220 billion lines of COBOL still running in production systems worldwide. Those lines process $3 trillion in daily commerce. They handle 95% of ATM transactions. The average COBOL developer is fifty-five years old. Ten per cent are retiring every year. And 85% of universities have dropped COBOL from their curricula entirely. The people who understand these systems are literally dying, and nobody is replacing them. When COVID-19 hit in 2020 and US state unemployment systems buckled under the load, governors were begging retired COBOL programmers to come back and fix systems they had built decades earlier. They called them the "COBOL Cowboys." It would be funny if it were not terrifying.

In the UK public sector, the picture is worse. 28% of central government systems are classified as legacy, rising to 70% in some areas. Nearly a quarter are rated "red" — the highest risk category. And the government spends 30% less on IT than its peers. The institutional memory required to maintain, let alone modernise, these systems is vanishing with every retirement, every restructure, every round of austerity.

The Submarine That Forgot How to Build Itself

I keep returning to one example because it haunts me. In the 1990s, the United Kingdom decided to build a new class of nuclear submarine — the Astute class. There was a problem. Between the end of the previous Vanguard programme and the start of Astute, there had been a gap of roughly ten years. A decade in which Britain built no submarines. And in that decade, the tacit knowledge — the things that experienced engineers knew in their hands and their bones, the adjustments that were never written in any manual — disappeared. The people retired. The people left the industry. The people died.

The Ministry of Defence had to bring in over a hundred American designers from General Dynamics Electric Boat at a cost of $145 million. The programme ran 57 months late and came in 53% over budget — £1.35 billion more than planned. The Astute programme had other problems — scope changes, procurement delays, industrial capacity gaps. But those were the problems the Ministry of Defence could see. The knowledge loss was the one they could not, because nobody knew what they had forgotten until they tried to build the thing.

NASA learnt the same lesson with the Saturn V rocket's F-1 engines. The blueprints survived. The tacit knowledge did not. And when the Columbia Accident Investigation Board declared in 2003 that "NASA is not functioning as a learning organisation" — seventeen years after Challenger, the same institutional failures had returned — they coined a phrase that should keep every CTO and permanent secretary awake at night: budget cuts had left critical areas "one-man-deep."

One-man-deep. Think about that.

Brent, the Most Dangerous Man in IT

If you have read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford, you will recognise this pattern instantly. The character of Brent is the engineer who knows everything. Every critical system, every workaround, every undocumented dependency. Brent is indispensable. Brent is the hero. Brent is also the single point of failure that will destroy the organisation when he gets hit by a bus, burns out, or simply takes a holiday.

Brent is the human embodiment of institutional memory concentrated in one skull. And the lesson of The Phoenix Project is not that Brent is bad at his job. He is brilliant at his job. The lesson is that the organisation has failed to invest in distributing what Brent knows. The bus factor — a term coined in the Python community in 1994 — is one. And a bus factor of one is an organisational death sentence.

The Brent problem is not, at root, a risk management failure. It is an investment failure. Organisations consumed the knowledge their people accumulated over decades and never invested in its capture — because the knowledge appeared free, a byproduct of having the person on the payroll. The bill arrives when the person leaves.

Every enterprise has a Brent. Every government department has a Brent. The question is whether you know who yours is (if you don't, is it you?), and what happens when they leave.

The Historian's Solution

Some organisations have understood this problem deeply enough to create a dedicated role. GCHQ — Britain's signals intelligence agency — has maintained a departmental historian since the institution's earliest days. The current holder, Dr David Abrutat, is the ninth. His predecessor, Tony Comer, served for 37 years and was the first publicly avowed GCHQ historian. Abrutat's mission, as he described it to Computer Weekly, is to preserve the "folk memory" of the organisation before it disappears — to capture the stories, the decisions, the failures, the context that no filing system retains.

I admire this enormously. The fact that a signals intelligence agency — an organisation built on secrecy — has concluded that it needs a historian to preserve its own memory tells you something profound about how hard institutional memory is to maintain. If GCHQ cannot rely on its own filing systems and databases, what chance does your organisation have?

The West African griot tradition proves that dedicated memory-keepers can sustain institutional knowledge across centuries. The Kouyate line has maintained unbroken historical memory for the Mali Empire for over seven hundred years. GCHQ's historian is, in some sense, a griot for the intelligence community. But the griot tradition also teaches a harder lesson: the knowledge survives only as long as the succession is unbroken, the keeper is trusted, and the political conditions allow honest remembering. When any of those conditions fail, the memory warps or dies.

Here is the problem: GCHQ is one organisation. The UK has 400-plus local councils, thousands of NHS trusts, hundreds of government agencies. The model of the dedicated organisational historian is magnificent. It may also be fundamentally unscalable.

Brent as a Service

This is where the AI vendors arrive, breathless with excitement. The pitch goes like this: what if you could digitise Brent? What if you could capture every piece of institutional knowledge — every email, every Slack message, every incident report, every design decision — and feed it into a retrieval-augmented generation system that could answer any question anyone in the organisation ever had? Brent as a Service. The colleague who never forgets, never sleeps, never retires, never gets hit by a bus.

The pitch is seductive. And parts of it are real. Knowledge workers currently waste 8.2 hours per week finding, recreating, or duplicating information that already exists somewhere in the organisation. RAG-based systems can, in principle, solve the "nobody updates the wiki" problem that killed the first wave of knowledge management in the 1990s. Tom Davenport diagnosed the failure bluntly: "Everything devolved to technology. KM is a complex idea, but most organisations just wanted to put in a system." The wikis went unupdated. Google killed internal KM by making external search so good that nobody bothered curating internal knowledge.

AI-powered institutional memory promises to solve this through passive capture. You do not ask people to write things down. The system listens, indexes, synthesises. It surfaces patterns that humans miss. It scales beyond what any single historian could achieve.

I want to believe this. I genuinely do.

And I should be honest: for certain categories of institutional knowledge, AI memory systems already work. Technical documentation retrieval across large codebases, code archaeology through decades of commits, onboarding acceleration for standard operational procedures, system dependency mapping — these are real, bounded, valuable applications. Enterprise search is a commodity. Document-based RAG is becoming a reliable product. If all you need is an answer to "where is the configuration for the batch job on server four," a well-built RAG system will give you one.

But institutional memory is not documentation retrieval. The knowledge that matters most — why a decision was made, which experiments failed, who objected and why, what the political context was, what the thing actually does versus what it was supposed to do — lives in a different category entirely. That knowledge is tacit, politically sensitive, and often embarrassing. And that category is where the problems begin.

The Poisoned Well

Here is what the vendors leave out.

The risks of AI institutional memory are not one thing. They are three distinct things, and conflating them — as the industry habitually does — makes all of them harder to address.

The first is a data integrity problem. An AI that remembers everything can be made to remember things that never happened. Researchers at USENIX Security demonstrated with PoisonedRAG that injecting just five malicious texts per question into a knowledge database of millions achieves a 90% attack success rate under laboratory conditions. Real-world deployments with access controls and retrieval filtering would reduce that figure, though by how much remains an open research question. Five documents. In a corpus of millions. A competitor, a disgruntled employee, a state actor — any of them could inject a handful of carefully crafted documents into your knowledge base and corrupt the answers your organisation gets back. Your AI "remembers" things that never happened. Your AI recommends approaches that were designed to fail. NIST has developed formal taxonomies for this class of attack, and Anthropic's own researchers demonstrated with their Sleeper Agents paper that backdoor behaviours can persist through standard safety training — with larger models proving better at hiding deception. Subsequent research on detecting sleeper agents through probes is promising, but early. The knowledge base itself cannot be trusted to be honest.

The second is a behavioural problem. An AI that remembers everything is also a surveillance system. And the moment people know they are being watched — that every Slack message, every candid post-mortem, every "I think we got this wrong" is being captured and indexed — they stop being honest. This is not speculation. This is Amy Edmondson's research, dating back to 1999, replicated hundreds of times since. Only 1-4% of failures in organisations are truly blameworthy. Yet 70-90% are treated as such. People learn to hide mistakes. They learn not to report near-misses. They learn to cover their tracks. A 2024 study from Cornell's ILR School found that AI-monitored employees generate fewer ideas, though it is worth noting that study measured productivity monitoring rather than knowledge capture specifically — the chilling effect on institutional memory systems is an extrapolation, not a proven equivalence. But the direction of the evidence is clear, and if anything, a system that captures the content of what you say is more intimate than one that merely monitors how fast you type.

I will name the paradox plainly: the more comprehensive your memory system, the greater the risk that honesty is suppressed. But the chilling effect is not uniform. People will speak honestly about system configurations into a machine that records everything. They will not speak honestly about political decisions, leadership failures, or their own mistakes. The sensitivity of the knowledge determines whether the memory system captures truth or performance. And most organisations do not have the psychological safety culture to withstand that risk. You build the perfect institutional memory and fill it with sanitised half-truths because nobody dares speak candidly into a system that remembers everything. Astro Teller at Google X understood the inverse of this when he created a culture that gave bonuses and promotions for killing projects — for proving that an idea would not work. The psychological safety required to report failure honestly is the precondition for institutional memory worth preserving. A system that undermines that precondition undermines itself.

The third is a lock-in and opportunity risk problem. The more institutional knowledge you pour into a single provider's AI memory system, the heavier the gravity around that incumbent becomes. Every document indexed, every integration built, every workflow that depends on the system's answers — each one raises the cost of switching. And the cost of switching is the cost of being stuck when something better arrives. The AI landscape is moving fast. A provider that is best-in-class today may be a legacy choice in eighteen months. An alternative may emerge that is faster, cheaper, more transparent about its model provenance, or better suited to your regulatory environment. But if your entire institutional memory is embedded in one vendor's platform, the switching cost may be so high that you stay — not because the incumbent is still the best option, but because the gravity is too strong to escape. That gravity can be genuine (the sheer volume of indexed knowledge, the retraining cost, the integration surface area) or artificial (proprietary formats, contractual lock-in, opaque export mechanisms). Either way, the organisation that was trying to solve a knowledge dependency on one person has created a knowledge dependency on one provider. The NCSC has published guidelines for secure AI system development and the UK government's AI Playbook both acknowledge the complexity. But acknowledging complexity and solving it are different things. Model provenance — knowing where your model came from, what it was trained on, who had access to its weights — is not a nice-to-have. It is a minimum requirement. Anthropic's own disclosure about disrupting the first AI-orchestrated espionage campaign tells you that this is not paranoia. It is operational reality.

These three risks — corrupted data, suppressed honesty, vendor gravity — are independent of one another. You could solve one completely and still face the other two. That is what makes AI institutional memory a genuinely hard problem rather than a configuration exercise.

The Forgetting That Is Not Accidental

There is something else the piece needs to say, and I have been putting it off.

Not all institutional amnesia is accidental. A new leader who wants to change direction benefits from the previous administration's memory being lost. A new CTO who wants to replace a legacy platform benefits from nobody remembering why the last migration failed. Institutional forgetting is sometimes a feature, not a bug — a political choice dressed up as organisational entropy. The Cambridge Centre for Science and Policy has documented the structural factors driving institutional memory decline in UK government — civil service churn, machinery-of-government changes, the loss of specialist roles — but some of those factors are not accidental. They are the consequence of a system that treats institutional knowledge as overhead rather than infrastructure, and sometimes as an inconvenience to be shed. And if you map the incentives, nearly every player in the system — the incoming leader who wants a clean slate, the consultancy that profits from rediscovery, the vendor who wants to sell you a replacement — benefits from the forgetting. The people who lose are the ones who have to build the submarine.

And there is a further irony: the consultancies called in to diagnose institutional memory loss are often the same firms whose restructuring advice caused the loss in the first place. The cycle is not accidental. It is a business model.

AI will not fix a culture that treats institutional knowledge as disposable. And it certainly will not fix a culture that sometimes wants to forget.

What This Means for You

I had a conversation last year with a retiring principal engineer at a government department I cannot name. Twenty-six years in. Knew every integration point, every workaround, every reason why the Thursday batch run had a forty-minute delay that nobody had ever fixed. I asked him what would happen when he left. He laughed. "They'll find out," he said. "Probably on a Thursday."

That man was a Brent.

If you have read this far, you are probably someone who has felt this problem — who has watched knowledge leave and wondered what could have been done. What you do about it depends on where you sit and how much time you have. But before the advice, a distinction the piece has been building towards without naming.

Not all institutional knowledge is the same, and the strategy for preserving each type is completely different. Operational knowledge — procedures, configurations, system dependencies — is commodity. AI handles it now. Deploy it. Craft knowledge — the tacit expertise of the twenty-six-year engineer, the Thursday batch job, the adjustments never written in any manual — is custom-built. It must be captured through structured interviewing, pair working, and deliberate succession before the people leave. No AI system captures it passively. Political knowledge — why a decision was made, who blocked it, what the real objections were — is the most fragile and the most valuable. It requires psychological safety to speak and human trust to preserve. Automate its capture and you guarantee its corruption.

If you are bleeding knowledge now — if your Brents are retiring this quarter, if the COBOL developers are leaving, if the institutional memory is walking out the door — you do not have the luxury of building psychological safety first and deploying AI memory second. You need to do both in parallel, imperfectly, knowing that the AI system you deploy today will capture operational knowledge well, craft knowledge partially, and political knowledge barely at all — and that is a trade-off you are making with your eyes open. Start with the bounded cases. Keep the sensitive knowledge where it belongs: in conversations between humans who trust each other. That is not a counsel of perfection. It is a triage decision for organisations that are bleeding knowledge now.

If you have more time — if your teams are stable, if your Brents are not yet leaving, if you have the organisational patience to do this properly — then the sequence matters. Build psychological safety first. Create the conditions in which people speak honestly about failure before you turn on the machine that listens. Here is a simple test: if your post-mortems are blame-free and your teams report near-misses voluntarily, you have the safety culture to deploy AI memory broadly. If your post-mortems are forensic exercises in fault-finding, start with operational knowledge and keep everything else in human conversations. Edmondson's work is clear. Google X's results are clear. The ICO's guidance on workplace monitoring is clear. Then and only then, deploy AI memory systems — and start with the knowledge categories where the chilling effect matters least before you touch the categories where it matters most.

And regardless of where you sit: demand model provenance. This is not an argument for or against open weights, open training data, or any particular licensing model — that is a different debate with its own complexities. But whether the model is open or closed, you have an obligation to understand where your AI systems come from, what they were trained on, and who controls them. The NCSC guidelines are a starting point. Treat them as a floor, not a ceiling. This is not optional.

There is a final thing, and it is the one nobody wants to hear. Some institutional memory cannot and should not be digitised. The griot tradition survived seven hundred years not because the Kouyate family had superior technology but because they had superior commitment. GCHQ's historian works not because the role is efficient but because it is valued. Some knowledge requires a human being who cares about it. If your organisation will not invest in people who carry its memory — and I mean invest, with budget and status and a career path that does not dead-end — then no AI system will compensate for that failure. And some of these problems are beyond what any single CTO or permanent secretary can deliver alone. The National Archives already serves as cross-departmental memory infrastructure for records. The question is what the equivalent looks like for living institutional knowledge — the kind that does not sit in filing cabinets but in people's heads. That requires shared investment across departments, collective approaches to knowledge preservation, and institutional capacity that survives the next spending review. Individual action is necessary. It is not sufficient.

Technologies change. Human nature does not. The desire to remember, the fear of forgetting, the temptation to let a machine do the remembering for us — these are as old as William's commissioners riding out across England with their quills and parchment. The question is not whether AI can serve as institutional memory. The question is whether we are wise enough to build it without corrupting the knowledge, suppressing the honesty, and locking the memory of how decisions were made into a system we cannot leave when something better arrives.

I suspect we will find out. Probably on a Thursday.

(Views in this article are my own.)

Nobody involved in making it knew how literally true it was.

The Mind You Cannot Imagine

In January 2020, a writer named Ryan Langdon published a blog post with a title that sounds like a joke: "Today I Learned That Not Everyone Has an Internal Monologue and It Has Ruined My Day." It was not a joke. The post received ten million views. It broke people's minds.

What Langdon had stumbled into was a fact that scientists had been circling for decades but that ordinary people had never confronted: the inner experience of human beings is not uniform. It is not even close to uniform. Some people hear a constant narrator in their heads. Some hear nothing at all. Some people can close their eyes and conjure a vivid image of their mother's face, their childhood bedroom, a red apple on a white table. Others close their eyes and see absolute blackness -- not a faded image, not a dim impression, but nothing.

I must say, I find this profoundly unsettling. Not because the science is surprising in isolation, but because of what it reveals about the assumption underneath -- the assumption that everyone's mind works like mine.

In 2015, a cognitive neurologist named Adam Zeman at the University of Exeter gave a name to the inability to form mental imagery: aphantasia. Strict prevalence sits around one percent of the population, though broader estimates push it to five. A decade later, Zeman's work has spawned a global community -- the Aphantasia Network has over sixty thousand members, each of whom spent years assuming everyone else's mental life was as imageless as their own. Then in 2024, psychologists Johanne Nedergaard and Gary Lupyan coined a companion term: anendophasia, the absence of inner speech. Not a deficit. A different cognitive architecture entirely. When people without inner speech are asked to speak aloud whilst solving problems, the performance gap with inner-speech thinkers disappears. The route is different. The destination is the same.

This matters. It matters because for over a century, we have been building institutions, schools, workplaces, and management structures on the assumption that there is a cognitive default -- a standard-issue human mind against which all others are measured. There is no such default. There never was.

The Assumption That Devoured Itself

Russell Hurlburt, a psychologist at the University of Nevada, spent decades developing a method called Descriptive Experience Sampling -- interrupting people at random moments and asking them to report, with forensic precision, what was happening inside their minds. His findings are devastating to anyone who assumes a standard inner life. Across the population, Hurlburt identified five phenomena of inner experience: inner speech, inner seeing, unsymbolised thinking, feelings, and sensory awareness. The numbers are humbling. Inner speech appears in roughly twenty-six percent of sampled moments. Inner seeing in thirty-four percent. Unsymbolised thinking -- thought without words or images, pure abstraction -- in twenty-two percent.

Twenty-two percent of the time, people are thinking without language and without pictures.

The pattern Langdon's viral post exposed is one I recognise from the history of technology itself. When you reveal to someone that their inner experience is not universal, they go through something that looks remarkably like grief. First disbelief. Then a furious attempt to confirm -- "You mean you can't SEE the thing?" -- followed by a long, uncomfortable recalibration of every assumption they have ever made about communication, empathy, and shared understanding. Every time they said "picture this" to a colleague, every time a teacher said "visualise the answer," every time a therapist said "imagine a safe place" -- all of it was built on a foundation that, for a significant minority of the human population, does not exist.

The Campaign and the Coincidence

Now. Go back to that screening room in 1997. Craig Tanimoto, the art director at TBWA\Chiat\Day, conceived the slogan "Think Different." Siltanen wrote the script. The campaign featured Einstein, whose documented traits include what modern diagnosticians would recognise as autism and dyslexia. It featured Nikola Tesla, who occupied the opposite extreme -- an eidetic imagery so vivid that he reportedly could not distinguish his mental inventions from physical reality. Einstein, who by his own account thought not in words but in "muscular and visual images" that he only later translated into language. Tesla, who designed entire machines in his mind, ran them mentally for weeks, then checked for wear on the imagined parts.

The selection criterion for Apple's campaign was not neurodivergence. It was world-changing rebellion. But the overlap is, let us say, rhetorically potent. What Apple celebrated as metaphor -- thinking differently -- was for many of these people a literal neurological reality. They did not choose to see the world differently. Their brains were wired to see it differently from birth.

I think this is brilliant advertising. Perhaps the most brilliant advertising ever produced, precisely because it is truer than its creators knew. "Here's to the crazy ones" -- a slogan written to sell computers -- accidentally became the most authentic neurodiversity manifesto in corporate history.

There is an irony here, and I will name it only once: the technology companies that most loudly celebrate "thinking differently" in their advertising have spent the subsequent decades building cultures that ruthlessly punish it. Seventy-seven percent of neurodivergent employees mask their thinking style at work. But that is a subject for another day.

What Happened to the Ones Who Thought Too Differently

Here is where the history gets dark, and I am going to walk into it because the stakes demand it.

The idea that some minds work differently is not new. What is new is the framing. For the better part of a century, the dominant response to cognitive difference was not celebration. It was elimination.

Between 1936 and the late 1970s, American surgeons performed between forty thousand and fifty thousand lobotomies. Sixty to eighty-four percent of the patients were women. The procedure -- an ice pick driven through the eye socket into the frontal lobe, sometimes without anaesthesia -- was performed on people whose crime was often nothing more than being difficult, anxious, or inconvenient to their families. Rosemary Kennedy, the eldest Kennedy daughter, was lobotomised at the age of twenty-three at her father's instruction. She had been described as "slow" and "rebellious." The procedure left her permanently incapacitated, unable to speak coherently, institutionalised for the remaining sixty-three years of her life. Her family did not speak of her publicly for decades.

Rosemary Kennedy was one case. There were tens of thousands of others.

Running alongside the lobotomies was a programme of forced sterilisation that American courts not only permitted but endorsed. In 1927, the Supreme Court ruled in Buck v. Bell that compulsory sterilisation of the "unfit" was constitutional. Justice Oliver Wendell Holmes, one of the most celebrated legal minds in American history, wrote the majority opinion. His words: "Three generations of imbeciles are enough." The ruling led to over seventy thousand forced sterilisations. It has never been explicitly overturned.

The people subjected to these procedures were not, by and large, people with severe disabilities. They were people who thought differently, behaved differently, or simply existed inconveniently in a society that had decided there was a single correct way to have a mind.

Then Like Now

It took until 1993 for someone to say, clearly and publicly, that the framing was wrong. Jim Sinclair, an autistic activist, delivered a speech at an autism conference titled "Don't Mourn for Us." It is the founding document of the neurodiversity movement. Sinclair's argument was devastatingly simple: autism is not a disease that has kidnapped a normal child. It is a way of being human. The grief that parents feel is grief for a fantasy child who never existed, projected onto a real child who does exist and who is standing right there, watching you mourn for them.

The term "neurodiversity" itself was collectively developed by autistic communities through the 1990s, though it is often attributed to sociologist Judy Singer. Its core claim is not that everyone is special. Its core claim is that there is no neurological default. That the assumption of a standard mind -- against which all other minds are deviations, deficits, or disorders -- is itself the error.

This is where the science and the history converge into something that should shake us.

If aphantasia, anendophasia, and unsymbolised thinking are not deficits but different cognitive architectures -- if some people think in pictures, some in words, some in pure abstraction, and some in combinations that defy categorisation -- then the concept of a "normal mind" is not merely imprecise. It is fiction. A fiction that was enforced with ice picks and scalpels and court orders for the better part of a century.

'OK,' you might be thinking, 'but that was then. We don't lobotomise people anymore. We've moved on.'

Right, about that.

When a company designs its communication norms around the assumption that everyone processes information verbally, when a school tests children exclusively on their ability to visualise, when we build entire management structures on the premise that there is one right way to think -- we are not performing surgery, but we are enforcing a default that does not exist. The violence is softer. The assumption is the same.

Alison Reynolds and David Lewis, writing in Harvard Business Review, found that cognitively diverse teams solve problems faster than cognitively homogeneous ones. But -- and this is the part the LinkedIn crowd never quotes -- only when psychological safety is present. Without safety, cognitive diversity is not an asset. It is a source of conflict, masking, and silence. The different thinkers learn to pretend they think like everyone else. The organisation gets the appearance of diversity and the reality of conformity.

Then like now, the institutions that claim to celebrate different thinking do so only on their own terms.

The Reframe

I want to be clear about what I am arguing and what I am not.

I am not saying that cognitive science has proved we are all beautiful snowflakes. The counterarguments deserve respect. Prevalence numbers for aphantasia and anendophasia are soft -- ranging from under one percent to nearly nine percent depending on measurement method. Kahneman and Tversky's work on cognitive biases demonstrates deep shared architecture across all human minds: we are all subject to loss aversion, anchoring, and the availability heuristic, regardless of whether we think in words or pictures. There is a real risk of "neurodiversity lite," where the concept expands until it means nothing more than "people are different" and loses all explanatory power. And the TikTok self-diagnosis phenomenon is inflating identification beyond what the science supports.

But here is what the counterarguments cannot touch. The inner experience of human beings varies along fundamental dimensions -- imagery, speech, abstraction -- and we have spent centuries pretending it does not. We assumed a default that was never there. We built institutions that enforced that default. We destroyed the minds and bodies of people who could not conform to it. And when we finally began to understand the variation, the first reaction of millions of people -- Langdon's ten million readers among them -- was not "how interesting" but "how is this possible? How did I not know this?"

The answer is simple: we could not see inside each other's minds, and so we assumed they all worked like ours.

What follows from this is not a comfortable corporate lesson about hiring neurodivergent people for your innovation team, though that is part of it. What follows is something harder. If there is no cognitive default, then every system you have ever built -- every school curriculum, every meeting format, every performance review, every communication norm -- is built on a fiction. The question is not whether you are accommodating different thinkers. The question is whether you have ever once stopped to ask how the people around you actually think.

I suspect most of us have not. I certainly hadn't, until the science forced me to confront it. The Apple ad was right, but not in the way Apple intended. The crazy ones, the misfits, the rebels -- some of them literally could not think the way the rest of us thought, and that was never their weakness. It was ours, for never noticing.

We are still not noticing. And until we do, "Think Different" will remain what it has always been: a slogan on a billboard, written by people who had no idea what they were actually saying, celebrated by companies that would fire the very minds it was written about.

(Views in this article are my own.)

We learn these things because we are listening to No Such Thing As A Fish, at the speed at which it was recorded, by people who I assume have eaten breakfast and would like to be understood. The presenter says a fact. There is a pause. Someone laughs. We laugh as well, in the car, the three of us, like a small mobile pub quiz with no prize and no questions.

What I do is anticipate the swears.

The presenters of NSTAAF are clever and warm and very much grown-ups, and several times an episode they will say a word I am not yet ready to explain. I have learned to recognise the small inhalation that precedes one. I lean across, turn the volume down at the right moment, then back up again, like a man jamming a hostile radio frequency on behalf of childhood. When I miss one, I tell the kids that this is naughty adult language, and that while they are clever people, they should not fucking swear.

They look at me. They keep eating their breakfast bars.

This takes about twenty minutes. It is the best part of the day.

Then I drop them off. The gate closes. And, on the way back, by myself, in the same car, with the same speakers, I become a different person.

I put on a productivity podcast. I put it on at three times the speed.

I would like to draw the court's attention to the fact that, according to data Spotify gave to Business Insider, 98.5% of listeners never change the playback speed at all. Only about 0.1% are out there at 2x. At 3x I am, statistically, alone. I am in a small stuffy room with an unknown number of American men explaining to me how to wake up, except they sound like the lads in the chipmunk songs, and I am pretending this is normal. (Some people listen fast because their attention won't stay on anything slower; that is not what I am describing. I am describing me.)

I have been doing this for years. I will name names. I switched to Downcast specifically because the Apple Podcasts app capped me at 2x and I wanted to go faster. Audible, I salute you sincerely for this, will let you go to 3.5x, which I have done, on books I will never recall a single sentence from. I once listened to a 14-hour history book in three days at 3x while doing other things. I cannot tell you what was in it. I can tell you the cover was yellow.

The man on the podcast is talking about the four habits of resilient leaders, at a speed that the human mouth was not designed for. There is a paper from 2018 which found that comprehension drops by about eleven points when students listen at 1.5x. I am well past where the research stopped feeling optimistic. I am taking nothing in. I am moving the audio across my head from one ear to the other, like a man dragging a hosepipe across a lawn.

If you'd asked me, a week ago, why I was doing this, I would have said: because I am behind. I have a queue of audiobooks, a queue of podcasts, a queue of newsletters that I subscribed to in good faith and then betrayed.

There are around seventy thousand new podcast episodes published every day. The school run gets me, generously, about half an hour if traffic is on my side. I am several orders of magnitude behind, before I have even put my shoes on. I am not the deviant on the curve. I am the curve, just a little further along.

The car is not the worst of it. The tube is the worst of it. On the Central line, podcast at 3x, I will be reading my email on the same phone, and occasionally swiping over to the news headlines if the podcast says something I have already heard. Three streams of input, all going through the same one head. I get off at my stop having finished none of them and feeling, somehow, even more behind.

The podcast was about a book I have not yet read. Toxic Productivity by Israa Nasir. Nasir's argument, as the podcast told it to me, is roughly: when you cannot stop being productive, you are not managing your time. You are managing your emotions. The to-do list is a way of not feeling something. The 3x is a way of not feeling the school run, the empty seat, the morning, the year, the fact that the kids are getting bigger, the everything.

That sentence sat in my chest for about a week. Or possibly a month. I lost track because I was busy.

Harvard Health has a tidy clinician's definition: "an internal pressure to be productive at all times and prioritize your to-do list at the expense of your mental or physical well-being." I have been doing this for many years and was, until recently, quite proud of it.

There is a longer history to this, which I can feel pressing on me even at 3x. There was a man called Alexei Stakhanov who, on 31 August 1935, reportedly mined 102 tonnes of coal in a six-hour shift, against a quota of seven, while Communist Party officials watched from the gallery and the assistants whose work had been arranged in advance were, conveniently, not in any of the photographs. They gave him the Order of Lenin. They raised the quota for everyone else. Anyone who couldn't keep up was a wrecker. Stakhanov, reportedly, lost the medal in a brawl in a pub.

I think about Stakhanov on the way home from school more than is probably healthy. The modern phrase for him is "10x developer." Stakhanov in a hoodie. Same fellow, different lanyard. It's the same trick they have been pulling for centuries: take one person's atypical output, on one staged shift, and reissue it as everyone's moral standard.

Joel Spolsky wrote, in 2005, that "five Antonio Salieris won't produce Mozart's Requiem. Ever." It's a great line. The trouble is, I'm a Salieri. So are most of you, on the balance of probabilities. So this isn't really a strategy. It's just a way of feeling worse on the way home.

There is a phrase I have been carrying around for years, that I have never quite connected to this. Imposter syndrome. The feeling that you are not the person other people think you are; that you got here on a series of small kindnesses and any minute now they will work it out. According to a 2024 study of software engineers across twenty-six countries, 52.7% of them experience this frequently or intensely. Most of the room. We are all Salieri, looking around for Mozart and assuming it must be the other one.

Here, I think, is what listening at 3x has been for. If you can consume more, more books, more lectures, more habits of resilient leaders, perhaps you can convert quantity into qualification. Perhaps you can outrun the part of you that thinks you are not enough. The trouble is, the part of you that thinks you are not enough also gets faster. It listens at 3x as well.

Anyway.

The newer mutation of the disease is the AI tools. I should declare my interest. I work, in the daytime, around the edges of the UK public sector, where there is currently a great deal of pressure to be twenty per cent more productive by Tuesday, using AI. I have used them. I quite like them. They are also, and I say this sincerely, slot machines.

There is a study from METR, in July 2025, in which sixteen experienced open-source developers were given AI coding tools on real tasks. They were 19% slower with the AI than without. They believed they were 20% faster. That is roughly a 39-point gap between feeling and reality, which is, give or take, the same gap as between me listening to a productivity podcast at 3x and me actually doing anything with my life. The trouble is, my dashboard is me, and I am compromised.

Mark Craddock has written about this, and he calls these tools limerence machines. I had to look up limerence. It's the early-stage obsessive infatuation thing, the one where you can't stop checking your phone in case the person has texted, except it has been engineered into the tools on purpose. It's the same trick as a fruit machine. Maybe the next one will be the one. Maybe this episode will fix me. Maybe at 3.2x I'll finally hear the sentence that explains why I'm like this. Then I can tick it off. Then I can rest.

Someone, somewhere, is paid to make sure the queue never empties. Good luck to them. I have been doing their job for free.

I haven't rested in a while.

The thing about a good slot machine is that you don't realise it's a slot machine while you're at it. You think you're refining your inputs. You think the next pull will be different. The audiobook queue is a slot machine. The little red badge on the email is a slot machine. The school run, mind, is not a slot machine. The school run is twenty minutes with two children and a flamboyance of flamingos. That bit was always free.

So. Two or three small things, which I might break by Wednesday, but here they are.

I have bought Toxic Productivity. The book. By Israa Nasir. The one I keep mentioning. I am going to listen to it on the next drive home, and the one after that, and the one after that. At 1x. The audiobook is seven hours and fifteen minutes, which previous audiobooks I would have demolished in just over two and a half. I am going to take it slowly. I am going to let it last as long as it lasts. I am going to let myself hear the whole sentence before I move on to the next sentence. I find this prospect more frightening than I would like to admit.

I am going to do one school-run-home a week with the radio off entirely. Just the road and the noise of the road. I will probably hate this. I will try to do it anyway.

And I am going to unsubscribe and delete a podcast unfinished, on purpose, soon. Possibly today. The one I have in mind is one I have been listening to at 2.4x for about four months, retaining nothing, feeling worse each time. It feels like throwing away a part of who I am supposed to be. Which is, I suspect, the entire point.

The kids, by the way, are alright. They have, as far as I can tell, inherited the love of trivia and the joy of facts, which is the bit I hoped they'd get; they have not, so far, inherited the urge to do the trivia at three times the speed in case there's more trivia waiting. They listen at 1x. They laugh at the right bits. One of them recently told me, with total seriousness, that an octopus has three hearts and that this is "quite a lot of hearts for one octopus, when you think about it." I agreed that it was. I'm not sure I've ever agreed with anything more.

That's the bit that I'd like to keep, if any of this is on offer. Not the productivity. Not the queue. Just the slow speed and the small voice in the back of the car saying that's quite a lot of hearts for one octopus.

(Views in this article are my own.)

Let me back up.

About a year ago, David Knott , then UK Government Chief Technology Officer, nerd-sniped a bunch of us. Two words: "Club 54". An exclusive members' club for technologists. Solve the riddle of the name, pass whatever unspoken appraisal David gave the cut of your jib, and you were in. No website. No application form. Just the puzzle, the door, and David on the other side.

Two words: Club 54

He wouldn't tell us why "54". Originally it was a conversational riddle: you'd float a theory, and David, depending on his mood and his tea, would say nothing, raise an eyebrow, or tell you you were some degree of wrong. That is how it eventually got solved, and how we should have solved it all along.

But I wasn't content with that. I wanted to brute-force it. So I asked him for a SHA-256 hash of the answer to test guesses programmatically, and to his credit he obliged: c7c8eec878a08fac3fe2ae7fbe5f4c158cbfcae3cb0e95e4ef53937fec6d5f94, with a one-line recipe — lowercase, strip whitespace, pipe into sha256sum.

That request, in retrospect, is the whole story. A conversational riddle has a warm/cold gradient. David's raised eyebrow was the gradient. A SHA-256 hash isn't. I voluntarily swapped the gradient for a cliff and then complained the cliff was steep. David watched. David enjoyed watching.

It took almost a year. We cracked it on his last day in post. I'm not sure whether solving it let him retire in peace, or whether he'd have stayed on out of stubbornness if we hadn't. The bolt came off the door the day the badge came off the lanyard.

From where I stood, this looked solved. Verification was free. The candidate space was finite-ish. I had a hash and a shell. What I needed was throughput. Classic commodity play. You don't think about a commodity, you throw compute at it.

So I did what any reasonable person with an API key would do. I fired up forty parallel Claude Haiku subagents, handed them --permission-mode bypassPermissions like car keys to a teenager, and pointed them at the hash. I fed them the first chapter of DK's book The Transcendental Elephant and a photograph of his GDS laptop: Ada Lovelace sticker, CDDO logo, a butterfly. Generate, hash, log, celebrate when it clicks.

Reader, it did not click.

What I got instead was 355,408 entries in wrong_answers.md, 151,731 unique hashes in seen_hashes.log, and a comprehensive_research_document_COMPLETE.md that was, I am not exaggerating, 48,051 lines long. It claimed 2,179 unique connections between 54 and the history of computing. What it actually contained was a small handful of observations about Turing, Babbage and Lovelace, reshuffled into 2,179 different outfits and marched past the reader as a parade. It called itself "comprehensive" 114 times.

The guesses were a beautiful taxonomy of a model flailing. The numerology: 54 as Harshad, Leyland (3³ + 3³). The chemistry: xenon at atomic number 54. The card-counting: 52 plus two jokers. The networking trivia: port 54, RFC 54. It kept returning, like a tongue to a loose tooth, to 6×9=42 in base 13. And, inevitably, that Chapter 6 of The Transcendental Elephant starts on page 54.

Then, and this is the bit that should make any AI practitioner sit up, it started making things up. "54 gears in Babbage's mill." There are not. "Rotor 54 Enigma." The Enigma had three to eight rotors. I found a cluster of guesses all exactly twenty characters long — "computation fifty fo", "precision mechanical ", "babbage mill fifty f" — because something had set a length ceiling and the model started truncating rather than thinking. Literally, padding.

Here is where I should have stopped and drawn a map.

I didn't. I added more agents. The prize, it turned out, for adding more agents was more agents.

This is the AI-era equivalent of boiling the ocean. The consultant version: "let's do a workshop." The infrastructure version: "let's provision a bigger cluster." The 2026 version: "let's spin up ten more Haiku agents." It feels like progress because something is happening. Tokens flow. Dashboards go up and to the right. You can tell a stakeholder "3,000 attempts an hour" and nobody will interrupt to ask the only question that matters: attempts at what?

Here is what I was refusing to see. I thought I was in the commodity quadrant: large known candidate space, cheap verification, a throughput game. If true, forty Haiku agents would have been gorgeous strategy.

But I wasn't in commodity. I was in genesis. The answer wasn't a known item waiting in some English-language corpus to be enumerated. It was the kind of thing one specific human had thought of once. The candidate space wasn't "the set of facts" but "the set of things that might click for David Knott on a particular afternoon." No distribution to sample from.

And here the cheap thing masked the expensive thing. The SHA check was free; it looked like the whole job. The expensive part, the part nobody priced, was the prior: the distribution the model was drawing from. My forty agents were verifying furiously from a distribution that did not contain the answer. A SHA-256 is a cliff, not a slope. It tells you no. Throwing more compute at a random walk isn't strategy. It's cardio.

Before launching a single agent, I should have written down not the size of the search space but its shape. How would I know if I was getting warmer? For "6" versus xenon, is one closer? The uncomfortable answer is no. Forty random walks are still a random walk.

I should have mapped the edges of the space, but I couldn't, because I was inside it. The LLM was prompted in English; it generated, scored, hallucinated and truncated in English. From inside its prompt, English was the universe. Somebody has since put a cleaner name on this: the Monolingual Cage. The door was on the outside.

I won't reveal the answer, or which language moved the bolt — DK hasn't opened the club yet and it's his punchline not mine. But I'll tell you what cracked it. Not another agent. Not a bigger corpus. A human, over a pint, with three supplementary clues DK had been saving — about forty minutes of not-very-hard thinking once the right door was open.

A human with a map beat forty Haiku agents without one. Not because the human was cleverer. Because the human could ask "is the answer in this box at all?" and the model couldn't — it had never been told there was a box.

So here's the doctrine. Before you map-reduce, map. Before you parallelise, ask what the gradient looks like. Before you throw more agents at a wall, work out whether the wall is on the boundary or you're running the wrong way from the middle. When your verification function is a cliff, no amount of Haiku turns it into a ramp.

A second frame, which belongs to DK as much as me: he set the puzzle; a human solved it; the machine did neither. Setter and solver are the load-bearing roles. The forty agents were equipment. Useful, sometimes. But equipment doesn't know which room it's in.

I'd love to say I worked this out in advance. I didn't. I worked it out after 48,051 lines of model-generated self-congratulation and realising every paragraph was the same paragraph wearing a different hat. The answer wasn't in the data. It wasn't in more data. It wasn't in data at all. It was in a question I hadn't thought to ask: what language am I looking in?

I still don't have a complete map. I'm not sure anyone does. For all the talk of agentic systems and the "six nines" of reliability people now claim, the one thing they cannot do is notice the edge of their own prompt. That is situational awareness, and it is still stubbornly human. I might be wrong; it might be a fluke that my human friends are beating my model friends at this parlour game. But when the verification function is a cliff and the search space in genesis, I'd bet on the pint.

Which brings me to the closing demand. David, you've had your situational awareness. You've had the joke. You've watched me, and a small crowd of other would-be members, spend the best part of a year and an embarrassing amount of Anthropic's inference budget on a puzzle a pint cracked in forty minutes. The club is now a landmark in my personal history of getting things wrong.

In the spirit of distributing the nerd-snipe back to its author, I invite everyone reading this to send David their guess directly, considered as a formal Club 54 membership application. This should please him twice: once because you tried, and once because he gets to reject you personally. He'll also be quietly relieved the candidate pool doesn't include any agentic AI systems, which on current form would not have got past the door.

So, David. Last day is done. Riddle is solved. You have your technologists. Open the club. Set a date. Name the venue. Do it properly, so I can, in the finest Groucho Marx tradition, find out whether I actually want to be a member of a club that would have me.

(Views in this article are my own.)

Then social media arrived, and we collectively decided that we'd rather have an algorithm choose for us.

I think about this more than is probably healthy.

The thing that prompted this particular bout of nostalgia was a practical problem. I subscribe to several LinkedIn newsletters — thoughtful people writing about technology, public sector, leadership — and I kept missing editions. LinkedIn's notification system is, to put it charitably, inconsistent. Sometimes I'd get an email. Sometimes I wouldn't. Sometimes the notification would appear three days after publication, by which point the conversation had moved on. (I must admit that my notification settings are probably a mess, but I'm not entirely convinced that's the whole explanation.)

It seemed to me that this was a solved problem. Or at least, it had been — in 2005.

The Hundred-Line Solution

So I built a thing. linkedin-newsletter-rss is a small tool that takes any public LinkedIn newsletter and converts it into an RSS feed. You take the newsletter ID from the URL, append it to linkedinrss.cns.me, and point your RSS reader at the result. The entire thing is about a hundred lines of JavaScript, running on a Cloudflare Worker, costing essentially nothing to operate.

It scrapes the newsletter page, extracts the articles (including full content, author, publication date, and cover images), and generates a standards-compliant RSS feed. It's not clever. It's not innovative. It's the kind of plumbing that arguably shouldn't need to exist — but does, because we've built platforms that are excellent at capturing attention and rather less good at letting people consume content on their own terms.

And yet.

Thirty-two people have starred the repository on GitHub. Twelve have forked it to run their own instances. For a hundred lines of code that does something the web knew how to do twenty years ago, that's a surprising amount of interest — and I think it tells us something about the state of how we share and consume professional knowledge.

Walled Gardens and Open Standards

Tim Berners-Lee built the World Wide Web on open standards. HTML, HTTP, URLs — protocols that anyone could implement, that no single company controlled. RSS was part of that tradition. It was an open format, supported by every browser, every blogging platform, every news site. The web was, by design, a place where content flowed freely between systems.

It seems to me likely that we've drifted rather far from that vision. We now write our professional insights on platforms that actively discourage you from leaving. We publish content behind authentication walls, in feeds controlled by algorithms we don't understand, in formats that can't be exported or syndicated. The knowledge is there, but it's trapped — visible only when the platform decides to show it to you.

However, I believe there's a parallel here to something I think about in my day job on the National Digital Exchange. One of the challenges we face across UK public sector technology is that valuable work gets trapped inside organisational silos — not because anyone intends to hoard it, but because the systems we use don't make sharing the default. A council in Devon builds a planning tool. A council in Durham builds the same thing six months later. Neither knows the other exists.

We've been tackling this from several angles: cataloguing 24,500 government repositories so we can see what's out there, building semantic search so teams can find each other's work, and providing free cloud sandboxes through NDX:Try so local government can experiment without procurement. Want to try an AI-powered council chatbot that answers residents' queries? Fifteen minutes. Need to test document translation into Easy Read and multiple languages? Fifteen minutes. Every use case is shared openly.

The common thread is the same one that RSS represented twenty years ago: making information flow freely, in open formats, so that people can consume and build on it in whatever way works for them. We should prefer open over closed, syndication over silos, standards over proprietary lock-in. (This is also, I should note, why the repos.json data behind the leaderboard is published as a plain JSON file with a stable URL — so anyone can build on it without asking permission.)

The RSS Reader as an Act of Resistance

I think there's something quietly radical about using an RSS reader in 2026. It's a small assertion that we should get to choose what we read, when we read it, without an algorithm deciding whether a particular post deserves our attention based on its engagement metrics. It's the same impulse that drives coding in the open, publishing data in open formats, and building tools that interoperate rather than lock in.

Perhaps I'm reading too much into a hundred lines of JavaScript that scrapes a website. (I have been accused of this before.) But I think the instinct matters: when a platform doesn't do what you need, you can build the bridge yourself, publish it openly, and let others use it too. That's how the web was supposed to work. That's how we should build public services.

If you'd like to follow any LinkedIn newsletter via RSS, the tool is free and the source code is open. There is a certain irony in publishing this on LinkedIn, but perhaps that's part of the point.

Links

• linkedin-newsletter-rss on GitHub — source code, one-click Cloudflare deploy
• linkedinrss.cns.me — the hosted service (append any newsletter ID)
• NDX:Try — free cloud sandboxes for local government
• X-UK-Gov Repository Leaderboard — 24,500 government repos catalogued

(Views in this article are my own.)

That was nearly twenty years ago.

I want you to think about that for a moment. Twenty years of an industry telling itself that it has moved from pets to cattle, that it has embraced disposability, that it has learned to love immutability. Twenty years of conference talks and blog posts and architectural decision records all solemnly declaring that we do not name our servers any more. And here we are in 2026, and I have never seen more pets in my life.

The problem is not that we failed to understand the metaphor. The problem is that we understood it perfectly, applied it to one layer, and then built an identical pet shop on the layer above. This is the pattern I keep coming back to — not a failure of comprehension but a failure of honesty. We did not solve the pet problem. We relocated it. And then we gave the new pets different names so we could pretend they were cattle.

The Relocation Programme

I gave a talk about this that I have been banging on about ever since, because the more I look at it, the angrier I get. The argument is straightforward. Kubernetes abstracts your nodes. It abstracts your workloads. It does a genuinely brilliant job of treating the things running inside a cluster as cattle. Containers crash, they get rescheduled, nobody cries. So far, so good.

But what is the first thing you do with a brand new Kubernetes cluster? You install a load of things. Certificate issuers. Log aggregation. Monitoring. Security policies. Service mesh. Ingress controllers. Policy engines. You install so many prerequisite components that by the time your actual application workloads arrive, the cluster is already bespoke. It has a personality. It has quirks. It has that one Helm value override that Dave set up eighteen months ago and nobody has touched since because nobody knows what it does and everyone is afraid to find out.

I know this because I have done it myself. More than once. I have stood up clusters with the best of intentions, automated their creation beautifully, and then watched as they accumulated state, configuration drift, and tribal knowledge until they were as precious and irreplaceable as any server I ever named in the 2000s. The shame is not that it happens. The shame is that we keep pretending it does not.

The grey layer — that sandwich of operational tooling between your applications and your infrastructure — delivers absolutely zero business value unless you are in the business of selling operational tooling. It is the fastest-growing, least-examined, most lovingly tended collection of pets in the history of computing. And it is held together, as I said in the talk, by sticky tape, chewing gum, pipe cleaners, thoughts, prayers, and Helm.

Helm. A string-based templating engine where every community chart must eventually expose every parameter of the thing it abstracts through a glorified string replace. I cannot think of a technology that better represents the gap between what we say we believe and what we actually do. We say we believe in infrastructure as code. We say we believe in declarative configuration. And then we build the most critical layer of our platform on top of a tool that operates on the same principle as a mail merge.

Then Like Now

Fred Brooks observed in 1986 that there is no silver bullet — that every new tool eliminates accidental complexity but leaves essential complexity untouched. He was right. But Brooks gives us something more useful than despair. He gives us a diagnostic question: which of the things in your grey layer are essential complexity that must be managed, and which are accidental complexity you have normalised? Most organisations have never done that audit. They cannot tell you which parts of their platform exist because the problem demands it and which parts exist because someone installed Istio in 2021 and nobody has had the courage to ask whether it is still earning its keep.

The pattern predates Kubernetes by decades. Virtualisation was supposed to kill the pet server. Instead it created pet VMs — hand-configured, lovingly maintained, sprawling across environments until administrators could no longer keep track. Lift-and-shift was supposed to liberate us from the data centre. Instead, organisations moved their pets to a new address without changing their behaviour. The server got a new postcode. The relationship did not.

Then containers arrived and we did it again. The container images were cattle, beautifully immutable, pulled from registries, destroyed without sentiment. But the clusters running those containers became pets within weeks. The Dockerfiles were cattle but the CI/CD pipelines building them became pets — sprawling, undocumented, untouchable Jenkins instances that everyone feared and nobody understood. Each abstraction layer faithfully reproduced the pet dynamic one level up, like a Russian doll of operational attachment.

The CNCF landscape tells the story in a single image. In 2018, roughly 25 projects. Today, north of 200 graduated and incubating projects, and over a thousand cards on the landscape. A thousand solutions to a problem that was supposed to be solved by treating infrastructure as disposable. If the problem were actually solved, the landscape would be shrinking, not metastasising.

How to Know If You Are Performing

I keep three tests in my head. If you fail any of them, you have pets. It does not matter what your architecture decision records say.

The reproduction test. Can you destroy this component right now and bring it back immutably from code, all without anyone noticing? Not in theory. Not in a disaster recovery document that was last updated when the Queen was alive. Right now, this afternoon, could you kill it with fire and have it back before the tea goes cold? If the answer involves a runbook, a specific engineer, or the phrase "we should really document that," you have a pet.

The knowledge coupling test. How many people in your organisation could reproduce this component if the person who built it left tomorrow? If the answer is fewer than three, the component's complexity lives in human memory rather than in code. That is what makes something a pet — not whether it has a name, but whether it has an irreplaceable owner.

The grey layer ratio. What proportion of your engineering effort goes to maintaining the substrate between your infrastructure and your applications? If the grey layer consumes more time than the business workloads it supports, you have inverted the value proposition. The infrastructure exists to serve the application. When the application exists to justify the infrastructure, you are running a pet hotel.

I described the recruitment angle in the talk as hunting unicorns: you need someone with Kubernetes experience, maybe a CKA, who also knows Linkerd or Istio, who can write Terraform and Helm, who understands your CI/CD pipeline, who has opinions about OPA versus Kyverno, who can debug a CNI plugin at three in the morning. That is not a job description for operating cattle. That is a job description for a veterinarian.

What Genuine Cattle-Thinking Actually Looks Like

Only 10% of organisations use ephemeral environments as their primary development and testing approach. Ten percent. Despite the evidence that ephemeral environments deliver order-of-magnitude improvements in feedback speed and millions in annual infrastructure savings. The reason adoption is so low is not technical. It is emotional. People do not want to let go of the cluster they have spent months configuring. They have a relationship with it. It is a pet.

When I designed NDX:Try — the sandbox environment within the National Digital Exchange for local government — the expiry was the feature, not a limitation. You request an environment. You get one. It has a timer on it. When the timer runs out, the environment ceases to exist. If you want another one, you request another one. There is no button to extend. There is no mechanism to preserve. The environment dies, and the only thing that survives is your code.

This was a deliberate design decision, and I will tell you exactly why. If the environment is permanent, people will configure it by hand. They will SSH into it and install things. They will make it theirs. They will name it. Within a week it will be a pet, and within a month it will be load-bearing infrastructure that nobody can reproduce. I have seen this happen so many times that I have lost the capacity to be surprised by it. The only way to guarantee cattle behaviour is to make the cattle mortal — to build the system so that doing it right is easier than doing it wrong.

That is the entire philosophy in one sentence. Make doing it right easier than doing it wrong.

The Moral Dimension

I used the word "moral" in the title and I meant it. This is not an academic argument about architectural patterns. The grey layer — that vast expanse of operational tooling that delivers zero business value — has a cost, and the cost is human.

I am not saying the people who built this complexity were stupid. Every individual decision in the grey layer was locally rational. Someone chose Istio because they had a genuine mTLS requirement. Someone adopted OPA because an auditor asked about policy enforcement. Someone installed Prometheus because the existing monitoring was inadequate. Each decision made sense in its moment. The problem is that nobody ever stepped back and asked what the aggregate looked like — and by the time they did, the aggregate was load-bearing and untouchable. That is the trap. Rational decisions, compounding into irrational outcomes, defended by the sunk cost of having made them.

Every hour an engineer spends debugging a Helm chart that wraps an operator that configures a CRD that manages a certificate that enables a service mesh that secures a connection between two microservices that used to be one monolith is an hour not spent on the thing the organisation actually exists to do. Every unicorn job advert that goes unfilled for six months is a team carrying an unsustainable workload. Every cluster that cannot be reproduced from code is a single point of failure waiting to become a 3am phone call that burns someone out.

We built this. All of it. We built the complexity, we built the fragility, and we built the recruitment crisis. And we did it whilst telling ourselves, with straight faces, that we had moved from pets to cattle.

The metaphor is not the problem. Bill Baker's insight from 2006 was correct — genuinely, profoundly correct. The problem is that we took a revolutionary idea about disposability and applied it to the one layer where it was easy, then stopped. We made the containers disposable. We left everything else precious. And then we wrapped the precious things in so many layers of abstraction that we could no longer see them, which meant we could no longer see that they were pets.

That is not an engineering failure. It is a failure of honesty. And the only fix — the one I keep coming back to, the one I built NDX:Try around, the one I argued for in the talk — is to stop managing pets better and start making pets impossible. Build systems where the default path is the reproducible one. Make permanence require effort, not the other way around. Make the cattle mortal so that the only thing that survives is the code that can bring them back.

The technology is there. It has been there for years. What is missing is the willingness to stop pretending.

(Views in this article are my own.)

I was wrong. The problem isn't that job titles are too narrow. The problem is that organisations use job titles as a substitute for understanding their own landscape. They don't know which capabilities they need, at what evolution stage, with what dependencies - so they buy a label instead. "We need a developer" is like saying "we need a plan" when what you actually mean is "we have no idea what's going on." It sounds purposeful. It's actually a confession of ignorance.

Meredith Brooks sang "I'm a bitch, I'm a lover, I'm a child, I'm a mother" in 1997 because the world kept telling women to pick a lane. The Ting Tings shouted "That's not my name!" in 2008 because the industry kept mislabelling them - Katie White said the song was about feeling transparent, invisible. And here we are, decades later, doing the same thing to engineers. "You're a developer." But they're also doing security reviews, talking to users, and debugging production at 2am. The label doesn't fit because it was never designed to.

This isn't a complaint about HR taxonomy. This is a strategic problem. And like most strategic problems, it starts with a failure of situational awareness.

The landscape we've built

The history of computing roles follows an evolution curve - things moving from novel and uncertain to standardised and well-understood, the way electricity went from Faraday's experiments to a wall socket.

In the beginning - genuine genesis, where everything is new and nobody knows the rules - there were no job titles because there was nothing to title. Margaret Hamilton didn't call herself a "software engineer" as a pre-existing category. She coined the term because the work demanded a name. Hopper, Turing, the lot - they were mathematicians, engineers, operators, and programmers simultaneously because computing was too uncertain for specialisation.

Then came the NATO Software Engineering Conference in 1968, which recommended engineering discipline. Reasonable enough. But the industry heard "assembly line" and built role silos. Royce's 1970 paper was arguing against sequential phases - his famous waterfall diagram was a cautionary example, not a recommendation. But organisations took the diagram and ignored the argument. They wanted neat boxes. They got neat boxes.

As work evolves from genesis through custom-built to product to commodity - becoming progressively more standardised, better understood, more repeatable - the roles specialise. Testing becomes a separate function. Operations splits off. Security gets its own department. Architecture becomes a title rather than an activity. This is natural evolution. It's not wrong. But here's what most organisations miss: not everything is at the same evolution stage simultaneously.

Some of your work is still in genesis. Your AI experiments, your prototype integrations - these need people who contain multitudes, who think like Hamilton. Other work has commoditised - well-understood, repeatable, utility. Your deployment pipeline, your monitoring, your standard infrastructure - these benefit from specialisation, from people who drive efficiency.

The problem is that the org chart treats everything as if it's at the same stage. One set of job titles. One career ladder. You're a "developer" whether you're exploring a genesis-stage AI prototype or maintaining a commodity deployment pipeline. That's like having one military strategy for both the reconnaissance mission and the supply depot. It's bonkers.

The T-shaped trap

Now, someone clever will immediately say: "But Chris, that's why we have the T-shaped model! Deep expertise in one area, broad knowledge across others." And it's a reasonable point. The concept dates to 1978, was popularised by IDEO's Tim Brown, and has been in management vocabulary ever since.

The problem is that T-shaped is a static metaphor applied to a dynamic reality.

A T-shape freezes you. One vertical stroke of depth. One horizontal bar of breadth. But people aren't typographic characters. They evolve. Adam Smith's pin factory showed that specialisation multiplies productivity - ten workers making 48,000 pins a day instead of ten pins each. But Smith himself warned that extreme division of labour renders a worker "as stupid and ignorant as it is possible for a human creature to become." The father of specialisation was terrified of what specialisation does to the people inside it. The T-shaped model inherits exactly that problem: it optimises the shape of the person for the convenience of the organisation, not for the reality of the work.

Kent Beck's "paint drip" model is closer: depth happens where the work takes you, not where HR predetermined it. Martin Fowler's piece on "expert generalists" argues for something more fluid still - people who cultivate "a rough, perceptive sense of what works in a new environment."

Here's the mapping insight that neither the T-shaped advocates nor their critics seem to notice - what I'd call shape-stage fit: the shape of the person should match the evolution stage of the work. At genesis - novel, uncertain, no established rules - you need people who can do everything. Pioneers who thrive in ambiguity, who can research users in the morning and write code in the afternoon and argue about security models over lunch. At commodity - standardised, well-understood, utility - you need deep specialisation that drives efficiency. The decision rule is simple: broad for genesis, deep for commodity. Arguing about T-shaped versus comb-shaped versus paint-drip without this context is like arguing about build versus buy without knowing the evolution stage of the component. It's context-free prattle.

I know an engineer - Priya - who spent three years as a "senior developer" at a mid-size fintech. On paper, one role. In practice, she was the person the team called when the AI recommendation prototype needed someone who could talk to the data scientists AND rewrite the front-end AND present the trade-offs to the product lead. Genesis-stage work, boundary-crossing in every direction. She was brilliant at it. Then a restructure moved her into a newly created "Platform Engineering" team - commodity-stage infrastructure, clear boundaries, deep specialism expected. Her performance reviews cratered. Not because she'd got worse. Because the org chart had mapped her into an evolution stage that didn't match her shape. Neither "developer" nor "platform engineer" described what she actually did. The map would have.

Conway's Law is eating your people

There's a deeper structural problem, and it's got a name: Conway's Law. "Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." Melvin Conway wrote that in 1968. It's still true. It's doctrine - a universal principle that works regardless of your specific situation.

What this means for job titles is devastating. Your org chart doesn't just describe your people - it constrains your architecture, and your architecture constrains what your people can do. If you have separate "frontend," "backend," and "infrastructure" teams, you will build systems with those exact seams.

I've watched this mismatch break good engineers. Not in dramatic, visible ways - more the slow erosion of someone who knows they're capable of more but whose environment keeps telling them to stay in their box. You don't always see the damage on the map. Sometimes you see it in someone's eyes during a one-to-one.

The inverse Conway manoeuvre - deliberately designing your org structure to produce the architecture you want - is gameplay, not doctrine. Gameplay means the deliberate moves you make based on your specific landscape; what works for you may be rubbish for someone else. Team Topologies suggests stream-aligned teams that own broadly within bounded domains, with platform teams absorbing complexity. Good gameplay for many contexts. But Valve tried removing job titles entirely and got invisible hierarchies and Lord of the Flies dynamics. Amazon's "you build it, you run it" worked because they paired broad ownership with single-threaded accountability. The Spotify model doesn't even work at Spotify.

Context is everything. The same organisational design produces different outcomes in different landscapes. This is why copying what Google does is usually rubbish advice. You are not Google. Your landscape is not Google's landscape. Their gameplay is theirs.

The privilege that nobody maps

And here's something I don't see mapped nearly enough: the landscape of who gets to cross boundaries - and how that maps onto evolution stages.

The data is clear: sixty-one per cent of women engineers report needing to repeatedly prove their competence. Seventy-one per cent of women of colour experience "prove it again" bias. When someone says "just cosplay other roles, learn broadly, contain multitudes" - that advice assumes you have the social capital to cross boundaries without being questioned. For many engineers, stepping outside their job title isn't exploratory - it's risky. They're not just learning new skills; they're fighting for the right to use skills they already have.

Here's where evolution makes this worse. At commodity-stage work - well-defined roles, clear boundaries, legible success criteria - the cost of crossing a boundary is lower because everyone can see what competence looks like. But at genesis - where the work is ambiguous, the roles are undefined, and "containing multitudes" is the job - the social capital required to cross boundaries is highest. The evaluation criteria are subjective. The gatekeeping is invisible. The people who most need to operate as Pioneers are the people most likely to be pushed back into their lane. The "boundaryless career" is, as the research shows, a privilege that maps onto exactly the evolution stages where it matters most.

Google's Project Aristotle found that psychological safety - not team composition, not individual talent - was the strongest predictor of team effectiveness. You can't broaden roles without safety. You can't create safety without awareness. You can't have awareness without mapping the actual landscape, including the uncomfortable bits.

Stop redesigning the labels

I'll tell you what you don't do: hire a consultant to redesign your job titles. That's a context-free solution to a context-dependent problem. The job titles aren't the disease. They're a symptom.

I might be completely wrong about your situation because I don't have your map. But start here:

Map your work by how well-understood it is - shape-stage fit in practice. Take your team's backlog. The items where you know the answer and you're just executing - that's commodity-stage work. The items where nobody's sure what the right approach even is - that's genesis. You'll disagree about where things sit. That argument is itself the point - the map is the conversation, not the artefact. Now look at who's assigned to what. If your most creative, boundary-crossing engineer is maintaining your CI/CD pipeline while your most process-oriented specialist is being asked to prototype an AI feature, you've got a mismatch that the job titles are hiding. Do this exercise with your team leads next week. It takes an afternoon. The mismatches will be obvious.

Reorganise for architecture, not fashion. Don't restructure because you read about Team Topologies on an aeroplane. Restructure because the system you need to build requires a different communication structure - that's the inverse Conway manoeuvre, and it's gameplay, not doctrine. Before you move anyone, map the architecture you want, then ask: does our current org structure make that architecture possible or impossible? If you can't answer, you don't know your landscape well enough to reorganise.

Audit who actually gets to cross boundaries. Not who theoretically can - who actually does, and who gets questioned for trying. If the answer correlates with demographic factors, you have a situational awareness problem masquerading as a job title problem. Yes, switching costs are real - eighty-three per cent of developers report burnout. But the answer isn't to lock people in silos. It's to match the breadth of the role to the evolution stage of the work, and make sure the opportunity to operate broadly isn't gated by who you are.

Start with one team. FIST: Fast, Inexpensive, Simple, Tiny. Pick one team. Map their work across the evolution axis. See where people's capabilities don't match the evolution stage they've been assigned to. If the mismatches surprise no one, either the team already has situational awareness or the mapping was too shallow - go again. Cross the river by feeling the stones.

The Stack Overflow 2024 survey shows that developers already identify with seven or more roles beyond their primary title. The people contain multitudes. They already know it. The question is whether your organisation has the situational awareness to use what they know - or whether you're still playing chess without a board, moving pieces labelled "developer" and "architect" around an invisible landscape and wondering why nothing ends up where you expected.

Walt Whitman wrote it in 1855: "Do I contradict myself? Very well then I contradict myself, (I am large, I contain multitudes.)" Your engineers contain multitudes too. The question isn't whether they do. The question is whether you can see it. And you can't see it without a map.

At least with a map, when you get it wrong, you can see WHERE you got it wrong. Without one, you're just relabelling the boxes and calling it transformation.

Where's your map?

(Views in this article are my own.)

I think that might be the most honest depiction of a Standard Operating Procedure (SOP) I have ever seen on film. And I must admit, I recognised the handover. I have been Larry. I once inherited a deployment procedure for a banking system that included the step "wait 90 seconds before proceeding." No one could tell me why. I followed it for months before discovering it was the time a long-retired server had needed to flush its cache. The server was gone. The wait remained.

We have all inherited instruction manuals like Cecil's. They arrive with a new role, a new system, a new team. They are numbered, ordered, and stripped of context. They tell you what to do. They do not tell you why.

And how often do we ask whether the omission is accidental?

For automation, codified procedures are genuinely indispensable. Larry's first instruction is "throw the bone." It sounds absurd until you discover that the T-Rex skeleton just wants to play fetch. The rule, followed on faith, works. Grab's engineering team found that structuring LLM agents around explicit SOPs achieved over 99.8% accuracy, precisely because the machine does not need to understand why. You cannot automate what you cannot codify, and codification means writing down the steps, however strange they may look to the newcomer holding the bone.

However, I think there is a difference between codifying a procedure and understanding one. And that difference may matter most when your organisation is not trying to repeat the past but trying to move beyond it. I should be clear: in safety-critical settings, rigid SOPs save lives, and Gawande's checklist research makes a compelling case for not inviting reasoning under pressure. What I am talking about is the procedures that govern how organisations change, not how they operate at the sharp end.

In the third film, Secret of the Tomb, the golden tablet that animates the museum exhibits begins to corrode. It has been away from its source (the moonlight of the Temple of Khonsu) for too long. The exhibits start glitching, becoming aggressive, losing themselves. The rules keep firing.

The rules now hurt.

How many of our procedures are running on a corroding tablet? I suspect more than we think. The procedure still runs, but the context has quietly moved. Consider the WHO Surgical Safety Checklist: at eight pilot hospitals where teams were trained in what each item meant and why it mattered, deaths fell by 47% and complications by 36%. When Ontario rolled the same checklist out to 101 hospitals, with 215,000 procedures, there was no significant reduction in either. Same form. Opposite outcomes. The reasons are probably more complex than any single explanation (implementation quality, institutional culture, training investment all played a role), but I think the direction is clear: the form without the understanding is the tablet without the moonlight.

You may have heard the story about five monkeys, a banana, and a cold water spray (new monkeys, never sprayed, still attack anyone who reaches for the banana). It is a vivid parable about inherited behaviour. It is also entirely made up. And yet the fact that every manager has heard it is perhaps itself the phenomenon it purports to describe. We pass around a story about unquestioned rules without ever questioning where the story came from. (I am building my own argument on a Ben Stiller film, but I hope the difference is that I am using it as metaphor, not as evidence.)

G.K. Chesterton offered the opposite warning in 1929: do not remove a fence until you know why it was put there. I think both positions may be true simultaneously. A procedure without its rationale is vulnerable to what Richard Feynman called cargo-cult behaviour, ritual that perfectly imitates the form of the original while missing everything that made it work. A procedure whose rationale you never bother to recover is vulnerable to reckless removal. Either way, the why is what makes the difference. We cannot afford to treat it as optional documentation.

Taiichi Ohno, Toyota's chief engineer, understood this. His standardised work was never the end state, it was the starting line. "Without standards, there can be no kaizen", he argued, meaning that you begin by following the written procedure faithfully, measure what happens, and then improve it. The SOP is a hypothesis taped to the workstation, not a commandment carved in stone. But you must follow it first.

In Night at the Museum, we eventually discover that Cecil, Gus, and Reginald were the villains all along. They had been stealing the tablet's magic to keep themselves young. The manual was not neutral. Its omissions were deliberate. They did not forget to explain why. They chose not to.

I suspect more of our organisational SOPs carry this kind of silent self-interest than we might like to admit. The approval gate that justifies the approver's role. The weekly meeting whose purpose no one can articulate but whose cancellation would threaten someone's calendar. Not conspiracy, exactly. Just the quiet accumulation of procedures that serve their authors more faithfully than they serve the organisation.

If you are automating, then by all means codify. Throw the bone. But if you are transforming, perhaps the first question is not "what does the manual say" but "who wrote it, and what did they gain from what they left out." As David Marquet, the submarine commander who turned USS Santa Fe around, put it: "Instructions require obedience; intent requires thought."

The tablet can be restored, but only if we take it back to the moonlight. Write the why down while someone still knows it. And if no one knows it, perhaps that tells you something about who wrote the manual and what they wanted you not to ask.

After all: "I'm made of wax, Larry. What are you made of?"

(Views in this article are my own.)

The US Army Air Corps nearly cancelled the programme.

Instead, a group of test pilots did something that no amount of individual heroism could have accomplished: they wrote a checklist. Pre-takeoff. Pre-landing. Pre-everything. The checklist was not a training aid for beginners. It was a systemic intervention that acknowledged a simple, uncomfortable truth — the aircraft had exceeded the capacity of human memory, and no amount of skill or courage could substitute for a system.

The Model 299 went on to become the B-17 Flying Fortress. It helped win a war. And it did so not because the pilots got braver, but because they got disciplined.

I keep thinking about that checklist. I keep thinking about it because 62% of organisations that attempt cloud migration report significant unplanned cost overruns, delays, or outright failure. Sixty-two percent. That is not a teething problem. That is a systematic absence of pre-flight procedure. These organisations are climbing into the cockpit of a four-engine bomber and trying to fly it from memory.

The Sport That Industrialised Courage

The Model 299 was not the first time humans confronted the gap between individual bravery and systemic safety. Skydiving did it first — and did it better than almost any industry I have encountered.

In 1797, André-Jacques Garnerin jumped from a balloon over Paris with a silk canopy and no backup. He survived. In 1919, Leslie Irvin made the first deliberate free-fall jump with a manually deployed parachute. He survived too. What happened next is the part nobody in technology talks about. The skydiving community did not celebrate these individual acts of courage and move on. It did something far more radical. It built a safety stack — a layered system in which each component exists because the one above it might fail.

That stack looks like this. First, training — rigorous, standardised, non-negotiable. You do not get to skip ground school because you are clever. Second, the main parachute — packed according to a procedure, inspected according to a schedule. Third, the reserve parachute — packed by a certified rigger (regulated by the UK Civil Aviation Authority in Britain and the Federal Aviation Administration in the US), not by you, because the person most likely to make an error with your reserve is you. And fourth, the Automatic Activation Device, or AAD — a small computer strapped to the rig that measures altitude and velocity and deploys the reserve if the jumper has not done so by a predetermined altitude.

The AAD does not care about your experience. It does not care about your confidence. It fires when the numbers say fire. It is the final backstop in a system designed around the assumption that every human layer above it might fail.

This is not cowardice. This is the opposite of cowardice. This is what courage looks like when it has been industrialised.

Then Like Now

Here is the part that should make every CTO reading this put down their coffee.

The cloud migration industry in 2026 has no equivalent safety stack. Most organisations have a main parachute — the migration plan itself, the architecture diagrams, the Jira tickets. Some have a reserve — a rollback strategy, tested occasionally, understood by a handful of engineers. Almost none have an AAD. Almost none have a systemic, automated, threshold-triggered mechanism that fires independently of human judgement when the numbers say the migration is going wrong.

And the training? The ground school? The phrase "cargo cult" entered serious intellectual discourse through Richard Feynman's 1974 Caltech commencement address, in which he described "Cargo Cult Science" — research that has the form of science but is missing something essential. The islanders in Melanesia built bamboo control towers and carved coconut-shell headphones for the operator. They had replicated every visible artefact of an airfield. No planes landed. The ritual was perfect. The understanding was absent.

I have watched organisations send their infrastructure teams on a two-day cloud certification course and declare them ready for a migration that will take eighteen months and cost millions. That is not training. That is coconut headphones — the cargo-cult imitation of preparation, where the ritual replaces the substance. The planes do not come. They never do.

The United States Parachute Association's (USPA) 2024 fatality summary shows that the skydiving fatality rate has improved by a factor of 48 since 1961. The picture is similar in Britain, where British Skydiving (the sport's national governing body) reports comparable safety gains driven by the same systemic improvements. The US data is the most comprehensive: from 11.1 deaths per 100,000 jumps to 0.23. The CYPRES AAD alone has saved more than 5,400 lives since its introduction. Five thousand four hundred human beings who would be dead without an automated safety system that does not ask permission, does not wait for consensus, and does not care about your feelings.

If skydiving had a 62% failure rate, no sane person would jump. The UK Civil Aviation Authority would ground every drop zone in Britain. The Federal Aviation Administration would do the same in the United States. And yet in enterprise technology, a 62% failure rate is treated as normal. As the cost of doing business.

That is not risk management. That is negligence dressed in a suit.

The Counterargument I Owe You

"OK," you might say, "but skydiving is a bounded physical system. Gravity is constant. Terminal velocity is known. The failure modes are finite. Cloud migration is an unbounded sociotechnical system where the failure modes mutate, where the vendors change the pricing model mid-flight, where a junior engineer can misconfigure an IAM policy and expose the entire customer database."

You are right. Cloud is more complex than skydiving. The variables are less predictable. The blast radius is wider. And that is precisely the argument for checklists, not against them.

Seneca taught his students to rehearse catastrophe — premeditatio malorum — not because the rehearsal would prevent the catastrophe, but because it would prevent the paralysis. When the system is infinite, the checklist is the finite thing you control. The skydiver cannot control the weather, the turbulence, or the moment of panic. But the skydiver can control the pre-jump check, the altimeter reading, the pull altitude. The checklist does not pretend to eliminate uncertainty. It creates a floor beneath which the uncertainty cannot drag you.

Cloud migration needs that floor. Right now, most organisations are free-falling without one.

The Cloud Migration Safety Stack

Every safe cloud migration depends on four layers, stacked in order. Remove one and the layers above it collapse.

Layer 1: Understanding (Ground School) First-principles knowledge of distributed systems, failure modes, and organisational dynamics. The foundation everything rests on. Not a certification course. Not a vendor webinar. A structured, multi-month programme in which the team migrates a non-critical workload end-to-end before touching production. You learn to pack the parachute before you jump out of the aircraft. If your team cannot deploy, monitor, roll back, and explain a migrated service in a test environment, they are not ready for production. Full stop.

Diagnostic: If you removed all your tooling tomorrow, could your team explain what the tools were doing and why?

The islanders with their coconut headphones were missing Layer 1 entirely. They had perfect practices — the runway, the fires, the hand signals — built on no understanding whatsoever. This is the cargo cult failure mode, and it is precisely what Feynman warned against: the form without the foundation.

Layer 2: Culture & Incentives (The Human Environment) Psychological safety, blameless postmortems, learning loops. The human environment that lets good architecture survive contact with reality. If your engineers are afraid to admit a migration is failing because they will be blamed, your reserve parachute might as well not exist — nobody will pull the handle.

Diagnostic: When did your team last kill a production incident with no blame, no punishment, and a published timeline?

Layer 3: Architecture (The Main Chute) The migration plan, the service boundaries, the dependency maps. This is what most organisations think migration is. It is necessary and insufficient. The main chute works most of the time. Most of the time is not a safety standard. Critically, this layer must be inspected by someone who did not design it — in skydiving, the reserve is packed by a certified rigger under CAA or FAA regulation, not by you. In cloud migration, that is an independent architecture review function whose incentive is not to prove the migration will work but to prove it might not.

Diagnostic: Can you draw your system's failure domains on a whiteboard right now — and has someone outside your team stress-tested them?

Layer 4: Automated Kill Switches (The AAD) This is the layer almost nobody builds. Automated, threshold-triggered mechanisms that fire without human approval when predefined conditions are met:

• Cost ceiling: Monthly spend exceeds 130% of forecast? The system freezes new deployments and alerts the CFO. Not the engineering team. The CFO.
• Error-rate trigger: P99 latency exceeds SLA for more than fifteen minutes? Traffic automatically routes back to the on-premises system.
• Security tripwire: Publicly exposed storage bucket detected? Automated lockdown. No human in the loop.

The AAD exists because the moment you most need to pull the reserve is the moment you are least capable of deciding to pull it. In skydiving, that moment is unconsciousness. In cloud migration, it is the sunk-cost fallacy — the organisational inability to admit that the migration is failing when you have already spent two million pounds on it.

Diagnostic: If your migration went catastrophically wrong at 3 a.m. on a Saturday, would any automated system catch it before a human noticed?

A note on ownership: In most organisations, these layers belong to different people. Platform teams own Architecture. Leadership owns Culture. And Understanding — critically — is everyone's responsibility, which in practice means it is often nobody's. If you cannot name the owner of each layer in your organisation, you have found your first vulnerability.

Two Kinds of Repatriation

Not all retreats are failures. This is the distinction the industry refuses to make.

37signals moved off the cloud in 2023. That was strategic repatriation — the reserve deployed exactly as designed. They ran the numbers. The economics no longer justified cloud hosting for their specific workload profile. They had the on-premises capability to return to. They planned it, executed it, and saved millions. That is a skydiver deploying the reserve at the correct altitude, calmly, with full situational awareness. The reserve worked because it was packed.

GEICO's cloud migration troubles were the opposite. That was panicked repatriation — fumbling for the ripcord at five hundred feet because nobody had checked the gear. No clear rollback plan. No tested repatriation path. No AAD firing to force the decision before it was too late. They did not choose to come back. They were forced back, and the cost — financial, operational, reputational — was catastrophic.

The difference is not whether you come back. The difference is whether you packed the reserve before you jumped.

The Only Migration

The B-17 pilots were not less brave for using a checklist. They were more effective. The checklist freed them to focus their courage on the parts of the mission that actually required courage — the flak, the fighters, the weather, the decisions that no system could make for them. The checklist handled the parts that courage could not.

I have watched organisations spend millions on migration programmes that had no kill switch, no tested rollback, no automated threshold, no independent reserve inspection. I have watched CTOs bet their careers on plans that had less systemic safety than a first-time skydiver's rig. And I have watched them crash, not because they lacked talent or ambition, but because they lacked a checklist.

The Boeing Model 299 taught us this in 1935. The skydiving community teaches it every single day. The lesson is there for anyone willing to learn it.

The only migration that matters is not from on-prem to cloud. It is from courage to systems.

Bonus photo ^ is Phil Hartree ~2011 on a weather hold teaching me landing patterns and also subnet masks CIDR blocks 🪂.

(Views in this article are my own.)

Forty-eight men. White. Middle-aged. Blue shirt, or black shirt, or the shirt that is trying to be blue but has given up halfway and become grey. A few navy jumpers. One very brave beige. That was it. That was the room.

And then there was me, in a pink shirt.

People ask me, with genuine sincerity, why I wear pink. They ask it at conferences. They ask it in meetings. A woman called Janet once asked me in the queue at a Pret. I tend to mumble something and change the subject, because the real answer is long, and it involves cyanobacteria, and nobody wants cyanobacteria before lunch.

But I've been asked enough times now that I think I owe the world a proper reply. So here it is. The canonical one. Please link to it, and leave me be.

Reason one. I would like to be remembered.

I am a white middle-aged bearded man in technology. There are, at a conservative estimate, four hundred million of us, most of us are called Chris, and most of us have the same beard. If I stand in a room with forty-seven other blokes in blue shirts, I am, statistically speaking, interchangeable. The blue shirt is not a choice. It is a uniform. Tech has decided, quite without asking anyone, that more than half the top-100 tech brands should be medium-to-dark blue or black, and a lot of the men in the room have taken the hint and dressed to match the logos.

I looked up the proper term for what the shirt is doing. It turns out there isn't one that quite fits. Economists would call it a Schelling point, which is a nice phrase for a coordination signal. A thing that is cheap on day one and valuable because of a decade of consistency. You're not the pink one because pink is expensive. You're the pink one because you were the pink one last year, and the year before that, and the year before that, and now when two people in a foyer are trying to find each other they say "look for Chris, he'll be the pink one" and it saves everybody a phone call.

I should mention, while we're here, that it isn't just the shirt. I have bright pink trousers as well. I have been known to pair the two. On a bold day, in full daylight, I have gone full pink from collar to ankle, which is a look that commits. If the shirt says "you'll remember me", the trousers say "you'll remember me, and you'll tell your spouse about it when you get home."

The socks are also pink, and this is the bit I am most proud of, because the socks are pink for a logistical reason rather than an aesthetic one. If every sock you own is the same colour, you never have to pair them. You just grab two. And when one of them develops a hole, you throw out one sock, not two. I worked this out some years ago and have not been pairing socks since. I consider it one of the great small victories of my adult life.

The complication, and there is always a complication, is that I wear a size thirteen. Pink socks in size thirteen, in a cut that does not cut off the circulation, do not exist at scale. So I bought several dozen pairs of good-quality white ones and dyed them myself. The same applied, later, to the jeans. There is, it turns out, not a mass market for pink jeans in a gentleman's fit, and so the gentleman has to take a pair of white Levi's and a bucket of dye and work it out on a Saturday afternoon. I will not pretend this was planned. I will pretend, to my wife, that it was.

If you meet me once, in a pink shirt, you will remember me. If you meet me twice, in a pink shirt, you will think, right, that's the pink one. And that, in a career built largely on people remembering to email me back, is worth the price of a slightly startled conversation with a woman called Janet in a Pret.

I should say, while I'm here, that this only works because the room is mostly blue. If the room ever goes pink I'll go beige, and I'll be sorry to see it.

Reason two. Pink is the oldest colour anyone has dug out of a rock.

This is the one nobody believes, which is why I enjoy it.

In 2018, a team led by Dr Nur Gueneli at the Australian National University extracted 1.1-billion-year-old pigment molecules from marine black shales in the Taoudeni Basin in Mauritania. A billion, with a B. These molecules are the molecular fossils of chlorophyll, produced by tiny cyanobacteria that dominated the base of the food chain before animals had even been invented. Concentrated, they run blood-red to purple. Diluted, they fluoresce a bright, joyful pink.

I find this quite moving, to be fair.

Half a billion years before there were animals, half a billion years before there was anything that could be said to look at anything, there was pink. Pink was doing its work in the oceans while the rest of the colour wheel was still a rumour. If pink is good enough to predate animals, it's good enough for a conference lanyard in Reading.

Reason three. Pink isn't actually there.

I'll explain what I mean. The rainbow goes red, orange, yellow, green, blue, violet. You've seen one. You know the order. What you may not have clocked, because nobody sits you down and tells you, is that there is no wavelength of light that produces magenta or pink. There's a gap. Red is at one end. Violet is at the other. They don't meet. Nothing lives in the space between them.

But your brain doesn't like the gap. So when your long-wavelength cones (the red ones) and your short-wavelength cones (the blue/violet ones) fire at the same time, with nothing coming from the green ones in the middle, your visual system just invents a colour. It says, right, I'll bridge those two ends by hallucinating something that isn't in the spectrum. And the something it invents is pink.

Pink is a colour the brain paints into a gap in the rainbow because the rainbow is embarrassing.

I walk around wearing a hue that doesn't technically exist. It is a hallucination everyone agrees to have at the same time. I find that rather lovely. And I find it even lovelier that nobody at the conference knows. They're just thinking, there's Chris in that shirt again.

Reason four. I have been lying to my wife for many years.

This is the bit I've been putting off.

The truth is, when we first met, she was the one who liked pink. I was the one going round in navy, like everyone else. At some point, and I cannot tell you exactly when, I started wearing a pink shirt. Then another one. Then, gradually, over about a decade, I somehow convinced her, with the quiet complicity of several friends and at least two members of her own family, that I had always been the pink one. That pink was, in fact, my thing. That she'd got into it because of me.

I would like to clear up, right now, in writing, that this is not true.

I want to be careful here. Real gaslighting is a pattern of behaviour, a form of domestic abuse, and I am not for a single second making light of what it does to people. What I am describing is a long-running affectionate family joke, conducted in full daylight, about a shirt. I would not want anyone to confuse the two.

Anyway. She knows. She's always known. She's letting me have it because she's a kind person and because, at this stage, the mythology has become load-bearing. If I ever admitted it out loud, a load of dinner parties would collapse.

So: I am confessing in print. She liked pink first. I am a fraud. The pink is hers. I am merely wearing it, badly, in her honour.

I am also, if I am being completely honest, relying quite heavily on the fact that she doesn't read my blog. If you know her, please don't send her a link. If you are her, hello, I was going to tell you over dinner, probably, at some point, once I'd worked out the running order.

Reason five. Pink was for boys first.

This is the one that gets people in the pub.

Up until about the 1950s, pink was considered the proper colour for a boy. It was a strong colour, a little version of red, suitable for a small lad. Blue was for girls. Something to do with the Virgin Mary, apparently. Professor Jo Paoletti, who wrote the book on this, puts it very plainly: pink-blue gender coding was known in the late 1860s but didn't become dominant until the 1950s, and wasn't universal until a generation after that. In June 1918, the Ladies' Home Journal told American mothers, in print, that "pink being a more decided and stronger colour, is more suitable for the boy, while blue, which is more delicate and dainty, is prettier for the girl." That is the actual sentence. Someone wrote it. Someone agreed with it. Someone's granny cut it out and kept it.

Which means the idea that pink is girly is about seventy years old. It is younger than my mother. It is younger than the Queen Mother was when she opened most of the bridges in the north-east. It is, in the grand sweep of human history, a bit of a rumour that got out of hand.

So when a man wears pink, he isn't being subversive. He's being restorative. He's putting the shirt back where it belongs.

Most things people treat as permanent are about seventy years old and made up.

One last thing, before you go. Please do not all start wearing pink. I am saying this with love. Pink is my thing. I have put the hours in. I have a decade of photographic evidence and a drawer full of trousers that match nothing else in the house. If all of you turn up at the next conference in pink, the whole system breaks, and we are back to forty-nine interchangeable men, just pinker. Get your own colour. Teal is available. Mustard is having a moment. Someone needs to be brave about green.

Right. That's the answer. Please stop asking. I've got a conference in Reading next week and I need to iron the shirt. And the trousers.

(Views in this article are my own.)

I do not know whether the story was true, or a parable, or whether my grandmother was talking about herself. She is gone now, so I cannot ask. What I do know is that I have quoted that line in more meetings, more architecture reviews, and more standups than I can count, and every time I say it, at least one person in the room does the recognition nod — the slow, slightly ashamed nod of someone who knows exactly what I am describing because they did it this morning.

Festina Lente

The woman with the bicycle would have understood Augustus Caesar, though I doubt they moved in the same circles.

Around 19 BCE, Augustus adopted a personal motto: festina lente — make haste slowly. The phrase became an emblem. Literally. The Aldine Press of Venice took the dolphin-and-anchor as its printer's mark — the dolphin for speed, the anchor for deliberation. Erasmus included it in his Adagia in 1508. Two thousand years of intellectual inheritance, from a Roman emperor to a Venetian printing house to a Dutch humanist, and the lesson is always the same: the fastest way forward is not always forward. Every culture arrived at this independently — Ecclesiastes, the Muromachi poets, the Chinese woodcutters, the British since the fourteenth century. Technologies change. Human nature does not.

Then there is the one everybody attributes to Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." Lincoln never said it. The earliest known source is from 1945, eighty years after his death. The misattribution tells you everything. We do not just ignore the principle — we fabricate historical endorsement for it, which is exactly what the woman pushing her bicycle was doing: performing urgency as proof of commitment. Engineers have their own version: "Weeks of coding can save you hours of planning." The joke works because the pattern is universal and universally violated.

Then Like Now

I watch this in engineering teams every week. Someone sitting at a machine that can generate, test, and refactor code — a machine that is, in the most literal sense, a bicycle for the mind — and they are pushing it along beside them. Writing the same boilerplate they wrote last year. Manually testing what could be automated in an afternoon. Copying and pasting between terminal windows because setting up the script would take twenty minutes and they do not have twenty minutes because they are too busy copying and pasting between terminal windows.

The research calls this action bias. Bar-Eli and colleagues studied penalty kicks and found that goalkeepers who stayed in the centre saved more often — yet almost all of them dive left or right. Doing something, anything, feels better than doing the right thing if the right thing looks like standing still. Bellezza showed in 2017 that in Anglo-Saxon corporate culture, being busy is a status signal. The woman pushing her bicycle is not failing. She is performing.

It is both criminal and deeply human.

And it is not only individual psychology. In many organisations, the incentives are structural. People push the bicycle because the system rewards visible motion — sprint velocity, tickets closed, lines committed. A contractor who stops to build the automation looks idle; a contractor who types furiously looks billable. The dashboard measures the pedalling, not the arriving. Until organisations learn to measure outcomes over output, the bicycle will keep being pushed uphill by people who know perfectly well how to ride it.

The Distinction

Now, you might reasonably point out that this is all very well — get on the bike, sharpen the axe, automate the toil. And most of the time, that instinct is right.

But the story is more complicated than "just ride."

Because there is a difference — a sharp one — between the woman who pushes the bicycle out of irrational urgency and the person who chooses to walk because the walk itself serves a purpose. The grandmother's woman could ride. She had the skill, the bicycle, the road. She pushed it anyway, out of a compulsion that mistook motion for progress. That is one mode. The other is the engineer who builds the thing by hand not because they are afraid of the tool but because the problem is not yet stable enough to automate, or because the manual repetition is teaching them something they have not yet articulated.

The Default Mode Network — the brain's resting-state network — is where creativity lives. A Stanford study found that walking boosts creative output by 81% compared to sitting. Walking, not cycling. The bicycle would have got you there faster. The walk would have got you there with an idea.

So the diagnostic is not "are you riding or pushing?" It is finer than that.

If the task is repetitive and the automation would teach you nothing new, get on the bike — you are wasting daylight.

If the task is not yet stable enough to automate, if the requirements are still shifting under your feet, then wait — building the machine now means rebuilding it next week.

If the slow execution is building understanding, if pushing the bike is how you learn the gradient of the hill, then push deliberately — that is craft, not cowardice.

But if you are pushing out of habit, out of fear of the twenty minutes it takes to learn the tool, out of a need to look busy for a system that rewards visible effort over invisible thought — that is the problem the grandmother saw. That is inertia dressed in urgency.

Here is a test I have found useful: if someone automated this task for you tonight, would you feel relieved or robbed? Relieved means you are in the fourth mode and should have got on the bike weeks ago. Robbed means you are in the third, and the walk is doing work your calendar cannot see.

Still Learning

Some things never change. The woman in my grandmother's village is every engineer who will not write the script, every manager who will not block out thinking time, every organisation that holds the meeting about the meeting instead of cancelling both. That is the crime.

But the wisdom — the quiet, counterintuitive, deeply human wisdom — is knowing the difference between refusing to ride and choosing to walk.

My grandmother, I suspect, knew the difference. I am still learning it.

(Views in this article are my own ...and my grandmothers.)

Let me tell you what happened next.

The first thing I discovered is that the graph is fake. You know the one. Mount Stupid, the Valley of Despair, the Slope of Enlightenment -- that satisfying curve that gets wheeled out in every conference talk, every LinkedIn post, every smug conversation about why other people are wrong about things. That graph does not appear in the original 1999 Kruger and Dunning paper. Not once. The paper contains quartile bar charts comparing perceived ability to actual test scores among Cornell undergraduates sitting logic and grammar exams. No mountain. No valley. No slope. The curve that half the internet attributes to two Cornell psychologists was drawn by Zach Weinersmith in a webcomic in 2011, probably influenced by the Gartner Hype Cycle, which itself is a marketing framework dressed up as science.

I did not know this. I had cited that curve. I had used it in presentations. I had nodded along knowingly when others used it, as though I were intimately familiar with the underlying research.

I was not.

The second discovery was worse. In 2022, a researcher called Blair Fix published an analysis showing that the Dunning-Kruger effect can be reproduced using entirely random data. The curve is an artefact of autocorrelation. When you plot people's self-assessment error against their actual performance, you are plotting a variable against a component of itself. The maths produces the curve whether or not the psychology exists. Gignac and Zajenkowski, in a 2020 study, used proper statistical methods and found "much less evidence" for the effect than the original paper claimed. McGill University's Office for Science and Society now states flatly that the Dunning-Kruger effect is "probably not real."

The original 1999 paper has roughly 7,893 citations. The debunking papers have about 88 between them.

Here is what that means: the most famous psychological concept about people who don't understand things they claim to understand may itself be a thing that people don't understand while claiming to understand it. The persistent irony is not incidental. It is structural.

Every one of us has been complicit in it, and not one of us bothered to check.

What the Paper Actually Tested

The third thing I learnt is that virtually everyone misuses the concept. The original study tested Cornell undergraduates on logical reasoning and grammar. Not the general public. Not "dumb people versus smart people." Not experts versus novices in any real-world domain. The dramatic effect that Kruger and Dunning found was in relative self-placement -- how students ranked themselves compared to their peers. When tested with direct methods, about 80% of the bottom-quartile students could accurately assess their own absolute competence. They knew roughly how well they had done. They just couldn't estimate where they sat relative to everyone else.

This matters because the way Dunning-Kruger gets deployed in the wild -- "that person is too stupid to know they're stupid" -- is not what the paper found. Scientific American pointed this out years ago. Nobody listened. The meme was too satisfying. The feeling of superiority it grants -- "I, unlike those people, can see my own limitations" -- is too intoxicating to surrender to mere evidence.

We have all cited that curve. We have all nodded along. And we have all, at some point, used it to feel cleverer than someone else in the room.

Which brings me to skydiving.

153 Jumps

I have done 153 solo skydives. Never a tandem. I started jumping out of aeroplanes because I wanted to, not because I was strapped to someone who knew what they were doing. To a layperson, 153 is a lot. At a dinner party it sounds reckless, impressive, slightly unhinged. To anyone in the sport, 153 makes me a relative noob. The serious skydivers -- the ones doing formation work, wingsuit proximity flying, canopy piloting -- have thousands of jumps. I am, in the language of drop zones, a "low-timer."

I have always used this to self-deprecate:

"I'm best case aspiring to be either climbing towards Mount Stupid, or on the decline back to the Valley of Despair."

It is a line I have delivered many times. It gets a laugh. It makes me sound humble and self-aware. It signals that I understand the Dunning-Kruger effect and have inoculated myself against it through the hard-won wisdom of knowing my place on the curve.

Except the curve is fake. And the self-deprecation is doing something I did not intend it to do.

Feltovich, Harbaugh and To formalised counter-signalling theory in 2002. The insight is devastatingly simple: high-ability agents can afford not to signal their competence. When a genuinely skilled person says "I'm not that good," it does not read as humility. It reads as proof that they are good enough not to need to say so. The self-deprecation is a power move. It is the intellectual equivalent of a billionaire wearing a hoodie. The modesty is the flex.

When I say "153 jumps, that's nothing in the sport," what you hear is: this person has done 153 solo skydives and is so comfortable with that fact that he can dismiss it. The self-deprecation does not reduce my status. It amplifies it. Harvard researchers Sezer, Gino and Norton showed in 2018 that humblebragging backfires worse than straightforward bragging. People see through it. They like you less for it than if you had simply said "I've done 153 skydives and I loved every one of them."

I did not know this either. The self-deprecation I thought was my most honest move was, it turns out, my most dishonest one.

Then Like Now

Bertrand Russell, writing in 1933 in an essay called The Triumph of Stupidity, put it with a precision that has not been bettered in the ninety-three years since: "The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt." He was writing about the rise of the Nazis. The context matters. Russell was not making a dinner-party observation about overconfidence. He was watching a continent slide towards catastrophe and diagnosing -- with the clarity of a logician who had co-written Principia Mathematica -- the asymmetry of conviction that made it possible. The stupid were cocksure. The intelligent doubted themselves. And the stupid won, because certainty is a weapon and doubt is not.

Russell saw it in 1933. Socrates described it twenty-four centuries before that. Kruger and Dunning did not discover anything. They gave a 2,500-year-old observation empirical clothing -- and even the empirical clothing now appears to be made of autocorrelation.

The instinct to feel superior to the overconfident is ancient. What Dunning-Kruger did was make that instinct seem scientific. It gave us a graph -- a fake graph, from a webcomic -- and a citation, and we could point at people we disagreed with and say "Dunning-Kruger" instead of saying "I think you're wrong." It became the intellectual's "because I said so."

I was doing exactly this. In my head, I had sorted the world into people who knew about Dunning-Kruger (enlightened, like me) and people who didn't (the poor sods still stuck on Mount Stupid). The categorisation was itself a demonstration of the very bias I thought I was immune to.

The Bias Blind Spot

Here is the final knife, and it cuts all of us. Pronin, Lin and Ross demonstrated in 2002 that knowing about cognitive biases makes you think you are less susceptible to them. Not more. Less. This is the bias blind spot: the meta-bias, the one that weaponises your own knowledge against you. The more you know about Dunning-Kruger, the more confident you become that it applies to other people and not to you. Cognitive debiasing research confirms it -- awareness does not debias. It adds a layer of false security.

We have all done this. We have all learned a concept, felt the warm glow of understanding, and then immediately deployed it as a weapon against someone we thought understood it less well. The bias blind spot is not an edge case. It is the default human response to learning about bias.

I sat down to write an article about people who don't know what they don't know. I was going to explain it to you. I was going to cite the research, draw the curve, reference the original paper, and demonstrate my sophisticated understanding of a concept that turns out to be a statistical artefact wrapped in a webcomic illustration popularised by people who never read the study they were citing.

People like me.

The Hard Part

The hard-easy effect tells us that self-assessment is contextual, not fixed. There is no stable "place on the curve" because there is no stable curve. My 153 jumps make me an expert to my mother and a beginner to anyone at Skydive Perris. The expertise is not a property of me. It is a property of the room I am standing in.

So the next time someone drops "Dunning-Kruger" into a conversation, ask yourself one question: is this person using the concept to understand something, or to win an argument? That is your diagnostic. If the answer is "to win," you are not witnessing insight. You are witnessing the bias blind spot in real time -- a thought-terminating cliche dressed up as psychology, deployed to shut down a person rather than engage with what they are saying. Stop nodding along. Name what is actually happening.

There is something genuinely uncomfortable about realising that the tool you use to demonstrate your self-awareness is itself a demonstration of your lack of self-awareness. I cannot resolve this. I cannot now pivot to a new, corrected understanding of Dunning-Kruger and deploy it with the same confidence I had before, because the whole point of the last 2,000 words is that the confidence was the problem.

What I can tell you is this. I thought I was writing an article about other people. I was writing an article about myself. The research process for this piece -- which I began as a victory lap through well-understood territory -- became instead a series of discoveries that each, in turn, made me feel more foolish than the last. The fake graph. The autocorrelation. The counter-signalling. The bias blind spot.

Every layer peeled back revealed another layer of my own overconfidence about a concept that describes overconfidence.

Socrates was right.

Knowing that you know nothing is not the end of wisdom. It is the beginning of the realisation that even that knowledge -- the knowledge of your own ignorance -- is something you can be wrong about.

I have done 153 skydives. I don't know what that means about me. And for the first time, I am not going to pretend that not knowing is the same as being wise.

But I will tell you this: the next time someone invokes Dunning-Kruger to dismiss a colleague in a meeting, ask them if they have read the paper. Ask them where the graph comes from. Watch what happens to their confidence.

(Views in this article are my own.)

Thirty years later, nobody who built a factory did this. They plugged it into the grid and got on with the work. Mayo's turbines were scrap.

Here is the thesis, and I am going to put it in the third paragraph so you cannot miss it. The size of your data work must match the blast radius of what you let the AI do — and whether you can un-do the damage when it gets it wrong. Blast radius is what the AI is allowed to touch. Reversibility is whether a wrong answer is an embarrassing paragraph or a regulator on the phone. Put those two axes together and you get four quadrants, and the work looks different in each. So: read-only retrieval, write-enabled agency, foundation-model training, and classical machine learning — four quadrants, four disciplines, four separate answers to the question the orthodoxy insists on answering only once. The industry is selling you one answer, priced as though every situation were the hardest of the four, and calling it "data strategy first." It is not a strategy. It is a prerequisite mis-specified at every quadrant by people whose revenue depends on the mis-specification.

I run into this argument every week. Here is why I no longer buy it

The prerequisite that was always a sales pitch

Start with a fact that ought to be more embarrassing to its promoters than it is. The phrase "AI-ready data" — deployed as if it were handed down on stone tablets — was coined by Gartner in 2024, not 2014. The doctrine that you must have a data strategy before you touch a large language model hardened as received wisdom after ChatGPT landed. It is younger than the wave it claims to precede. The orthodoxy was retrofitted to the moment it was meant to predict.

And who is selling it? The data-platform vendors whose product categories were looking orthogonal to the action, the consultancies whose billable ETL years were at risk, and the CDO profession itself. The canonical survey figure — 93% of Chief Data Officers telling pollsters that an effective data strategy is essential — is not a finding. It is a confession of self-interest, rendered in the third person.

Look at what the evidence actually says. MIT's NANDA initiative, looking at over three hundred enterprise generative AI initiatives in August 2025, found that 95% of pilots deliver zero measurable profit-and-loss impact. A brutal number, and one the vendors love to quote because it sounds like it proves their case. But read the next paragraph — the one they tend not to quote — where MIT names the root cause. It is not data. It is what they call the learning gap: most generative AI systems do not retain feedback, do not adapt to context, and do not improve over time. The successful initiatives bought capability from vendors and wired it into a workflow. Internally built systems succeeded a third of the time. Vendor-bought systems succeeded two thirds of the time. The bottleneck is showing up in the feedback layer, not the data layer — and that is a problem that cannot be solved by buying more of what the incumbents are selling.

Why the four quadrants are the right unit of analysis

Back to Detroit. Back to Mayo on his gantry. Hold the four-quadrant frame in your head while I walk you through the history, because the history is where the framework earns its authority.

The story of factory electrification is the cleanest historical analogue we have for what is happening now, and it has been sitting in plain sight since Paul David published "The Dynamo and the Computer" in May 1990. Alternating current was commercially available from Niagara Falls in 1896. American manufacturing productivity then did what productivity statistics do when a general-purpose technology arrives and nobody knows how to use it yet: absolutely nothing, for thirty years.

Why? Because the factories of 1900 had been built around the line shaft. A single prime mover spun a long iron axle running the length of the shop floor, and every tool in the building hung off it with leather belts. The architecture was the constraint. When you electrified by swapping the steam engine for a central electric motor (what Warren Devine called "group drive"), you changed the energy source but kept the architecture. You got the same factory, slightly cheaper to run, and none of the productivity gains — because none of the productivity was hiding in the energy source. It was hiding in the architecture.

Unit drive — giving every machine its own motor, freeing the layout from the tyranny of the shaft, letting materials flow in straight lines — is what made Highland Park work. And yet, in 1913, Ford still had Mayo build his own fifty-three-thousand-horsepower generating station, because the orthodoxy of the day said you needed to own your own power. By 1930 nobody built their own generating station. The grid did the job and did it better. The prerequisite had dissolved into a utility bill. The real transformation — the ten-fold productivity jump — came from the rearrangement, not the resource.

Draw the AI landscape on the same evolution axis and the picture sharpens. Foundation models are sliding visibly towards commodity — you rent them from a shrinking number of providers at prices that halve every eighteen months. Retrieval-augmented generation and vector search have just commoditised: both are now native column types in Postgres, Oracle, Snowflake and Databricks, which means the thing the vendors were calling a moat last year is a feature of the database this year. The semantic layer, by contrast, is still stubbornly custom-built and always will be, because it encodes the specific meaning of your business; ETL and the warehouse beneath it have been commodity for fifteen years. Four components, four evolution stages, four different answers — and the orthodoxy sells you the same three-year programme for all of them.

The category error in 2026

Coal was consumed. Data is not consumed — it is referenced. The 2015-vintage definition of data strategy — master data management, enterprise data warehouse, governance-first, build-the-lake-then-stock-it-with-fish — is not the foundation of modern AI. It is orthogonal to it.

Wavestone's Data and AI Leadership Executive Survey reports that "data-driven culture" inside large enterprises jumped from 21% in 2023 to 43% in 2024, and the researchers were explicit that the cause of the jump was generative AI. The cause. For ten years the CDO profession had been trying to get executives to care about data and getting nowhere. Then ChatGPT arrived and within eighteen months the board was asking the questions the CDO had been begging them to ask for a decade. The AI pulled the data along behind it.

And the profession knows. IBM's 2025 CAIO Global Study found that 26% of organisations now have a Chief AI Officer, up from 11% two years earlier — 48% of the FTSE 100. Jamie Dimon told an investor call in 2024 what he had done inside JPMorgan: "We took AI, slash data, out of technology. It's too important." The CDO role is being quietly folded into the CAIO role, because the market has decided the thing you optimise for is the outcome, not the upstream dependency.

I am not arguing the CDOs were frauds. Many of them are excellent. The thoughtful ones have spent a decade doing necessary, unglamorous work inside a category the market had wrongly framed — and the invitation in this piece is for them to walk out of the old category and into the new one, because their craft is needed there and the title is not what matters.

The steelman, and why it doesn't bury the argument

I owe you a fair hearing of the other side. Here is the best version of it, and then where I think it holds and where it crumbles.

The strongest objection comes from agentic compounding. The maths is brutal. A twenty-step agent running at 95% per-step reliability delivers a 36% end-to-end success rate. Drop each step to 85% — which is what you get when the context is noisy, schemas drift, and records are duplicated across three systems — and you are down to 4%. Bain's 2025 report makes exactly this point, and eight out of ten executives tell Bain that data limitations are the number-one blocker to scaling agentic AI. This is the single argument the orthodoxy gets right. No foundation model is clever enough to paper over a duplicate customer record spread across Salesforce and NetSuite with conflicting addresses. Notice the quadrant, though. It lives in the high-blast-radius, low-reversibility corner, and only there.

The second objection is the NYC MyCity chatbot. Built on Azure AI, grounded on two thousand curated dot-gov pages, and for eighteen months it cheerfully told small business owners they could steal tips from their staff and refuse cash payments. State-of-the-art stack. Authoritative sources. And it still lied with confidence because nobody had modelled the entity relationships or tagged which regulations superseded which. RAG on chaos is still chaos. That is a read-only case where reversibility was badly under-estimated — small business owners taking legal advice from a chatbot and then getting sued is not damage you can un-do with a product update.

The third objection is the EU AI Act, Article 10, binding from August 2026, which requires training and reference datasets to be "relevant, representative, free of errors and complete" for high-risk systems, with fines up to €15 million or 3% of global turnover. The Italian Garante has already fined OpenAI €15 million on lawful-basis grounds. If you operate inside any regulated sector, "no data strategy" now translates as "I will write one under enforcement pressure, next year, at four times the cost." That is regulation choosing the quadrant for you.

The fourth objection is the semantic layer, and this is the one I find most honest. A language model cannot tell you the Q3 margin on EMEA enterprise customers unless somebody has reconciled Q3, margin, enterprise customer, and EMEA across Salesforce, NetSuite, the warehouse, and the product database. BI was forgiving of missing semantics — an analyst would simply ask the human who knew. Language models are not forgiving. They will give you a confident, beautifully formatted, completely wrong answer. The uncomfortable version, put by people who are not trying to sell you a platform, is this: AI does not require a data strategy so much as it exposes the fact that you never really had one. The Open Semantic Interchange spec, pushed out by Snowflake, dbt, Salesforce and Mistral in January 2026, is the industry's belated admission that the semantic layer is what matters, not the warehouse beneath it.

I concede the maths on agentic compounding. I concede NYC MyCity. I concede the EU AI Act. I concede that the semantic layer is irreducible. And yet none of that rebuilds the orthodoxy. Because the orthodoxy is not "match the data work to the blast radius and the reversibility of the damage." The orthodoxy is "build a three-year, eight-figure enterprise data programme before you are allowed to touch a language model." Each of the four objections picks out a specific quadrant where the data work is irreducible. None justifies pricing every situation as if it were the hardest quadrant. The 2026 version of a data strategy, sized per quadrant, is roughly a tenth the size of the 2019 version, and it runs in parallel with the AI work, not in front of it.

Who benefits from the prerequisite? And who owns the utility?

If the prerequisite has dissolved into a utility bill, who owns the utility? The answer, in 2026, is that three companies own the power stations — AWS, Azure and GCP — and a handful of foundation-model landlords rent you the turbines on top. Anthropic. OpenAI. Google DeepMind. The 1930 grid was contested, regulated, in many places publicly owned; cheap power was treated as a political question because everyone understood that whoever controlled it controlled industry. The 2026 equivalent is none of those things. It is a private, unregulated, four-provider oligopoly that the "rent, do not build" recommendation I made two sections ago quietly accelerates. I am not resolving that question here. I am not equipped to. But I refuse to pretend it is not sitting there, because "renting" and "being enclosed" may turn out to be synonyms on a long enough timeline, and the managerial argument does not get to duck the structural one underneath it. I would rather leave you holding the question honestly than palm you off with closure I have not earned.

Management is moral work. When a consultant or a vendor tells you that you must do X before you are permitted to do Y, the first question is not whether the claim is true. The first question is: who is paying the cost of the wait? Not the consultant. Not the vendor. The customers whose problems could have been solved in month three but will now be solved in year three. The colleagues who spend eighteen months in a governance committee re-litigating what a "customer" is across four systems, producing a unified model that will be obsolete before it ships. I have seen a hundred data strategy programmes in my career. Most were a polite way of saying "we are not ready to change anything yet, and this gives us eighteen months to avoid admitting it." When I ask the people pushing hardest for data-strategy-first whether they would personally bet their own money on a three-year programme delivering more value than a ninety-day vendor-led pilot wired to a narrow workflow, they go quiet. Every single time.

What I would do on Monday morning

Here is the test I would apply, if I were sitting where you are sitting, reading this on a Sunday evening because you have a board meeting on Tuesday.

Pick a single workflow where the outcome is measurable in pounds, dollars or euros within ninety days. Not strategic. Not transformational. Measurable. Name the quadrant it lives in — read-only, write-enabled agent, foundation-model training, or classical ML — and name, out loud, how reversible a wrong answer would be. Size the data work to match the quadrant and not a gram more. Build the evaluation harness before you build the system, because MIT is right about the learning gap and you are going to need it. Rent the capability. Do not build it. Wire it to the workflow. Measure. Learn. Move to the next workflow. Do this six times in a year, across the quadrants that actually matter to you, and then tell me whether you need a three-year data strategy to precede your AI strategy, or whether you have already accidentally built the only data strategy that matters.

I guarantee, with history on my side, the answer is the second one.

The factory owners who won the electrification transition in the 1920s did not win because they built the biggest powerhouses. They won because they rearranged their shop floors around what unit drive made possible. The ones who lost spent the 1900s building ever larger on-site dynamos, because they treated the energy source as the strategy and the architecture as an afterthought. The technology was not the bottleneck. The imagination was. Mayo, for what it is worth, retired a respected man. His turbines still got scrapped.

Technologies change. Human nature does not.

(Views in this article are my own.)

The man is Michael Brunton-Spall, and in 2016, at GOTO Amsterdam, he gave a talk called "Rugged: Being Secure & Agile" that planted a seed I didn't recognise as someone else's until it had already grown into a tree with my name on the trunk. But ideas have a lineage longer than any one person. Michael would be the first to say — and has said — that he stood on shoulders of his own: James Abley and Gareth Rushgrove at GDS, conversations at ScaleCamp and ScaleSummit, the DevOpsLondon community. What Michael did — and it was substantial — was take those scattered conversations and forge them into a narrative that could travel. He spent two or three years refining that talk, making the ideas communicable, pragmatic, and sticky. That is its own form of creation.

Michael's argument was elegant and, in retrospect, obvious. It was also early. 2016 was too soon for the industry to be ready, and Michael knew it. Security principles should not be bolted onto agile delivery like armour plating on a Ford Fiesta. They should be woven into the fabric of how teams build software. He was working at the Government Digital Service at the time, helping create security design principles that would later be adopted and maintained by the National Cyber Security Centre. He went on to co-author Agile Application Security with Laura Bell, Rich Smith, and Jim Bird. He is now Deputy Director of Cyber Policy and Capabilities at the Cabinet Office . Someone who earned their credentials.

I watched that talk and something happened that I have since learnt is the highest compliment a speaker can receive and the most dangerous trap a listener can fall into: I absorbed his principles so completely that I began to believe they were mine. When I sat down in 2022 to build what became Policy as Versioned Code, I was not consciously drawing on Michael's work. I was drawing on what I thought was my own conviction that policy should be testable, versionable, and consumable as a dependency. The philosophy was shaped by Michael and the community around him. The engineering was mine. And I failed to cite my sources — not because I chose not to, but because the ideas had become so thoroughly part of how I think that I forgot where they came from.

Michael, was kind enough to give this article blessing and added the philosophical commentary that knowledge is a communal product. "We take a bit of this, a pinch of that, and if it is good, it grows and spreads". Michael took conversations from ScaleCamp and Government Digital Service and turned them into a conference talk that changed how I think. I took that talk and turned it into working code and YAML and Mend.io Renovate configs. Someone will take this article and turn it into something neither of us has imagined yet. That is how ideas are supposed to work. The best measure of a teacher's influence is when the student genuinely believes the ideas are his own — and the best response is not guilt, but gratitude and a proper citation.

What I did not understand then — what I am only beginning to understand now, twenty-one conferences and a lot of solitary airports later — is that carrying an idea forward is its own form of loneliness. It does not matter whether the idea started as yours or someone else's. You are alone with a conviction in rooms full of people who will forget your name by the next session. That loneliness is the reason this piece exists — as a test of whether the technical argument I built from this shared philosophy can stand on its own in writing the way it never quite could from a stage.

The Lift

Here is the central image. You are in a lift — an elevator, if you must — in a large organisation. Four people ride with you.

The CIO says: "I have no idea what our teams are actually doing. I set policy, but I cannot tell you whether anyone follows it, bends it, or ignores it entirely."

The Product Manager says: "Bureaucracy is killing us. Every policy change means weeks of back-and-forth before we can ship."

The Developer says: "I just want to know what the rules are. Which ones I have to follow, which ones I can bend, and which ones lose me my job."

And the Cleaner — the person everyone else in the lift has stopped noticing — says: "We get a memo. We compile it into our operational manual. Sometimes a new memo arrives and we miss it. Last week I wiped the war room whiteboard because nobody told me it mattered."

The Cleaner is the emotional heart of this story. Not because cleaning is trivial — it is not — but because the Cleaner is doing exactly the same job as everyone else in that lift. Receiving policy. Compiling it into a working manual. Trying to stay current. Dealing with version conflicts. Missing updates. And nobody recognises it, because nobody has ever framed policy management as a universal problem rather than a domain-specific one.

I think about the Cleaner more than I should. I think about the Cleaner at 2am when Renovate opens a pull request in a repository nobody has looked at in four months. I think about the Cleaner when an enterprise CIO shows me a compliance dashboard that tracks everything except whether anyone actually changed their behaviour. The Cleaner is working in good faith with a broken system, and nobody — not the vendor, not the consultancy, not the framework — is solving the Cleaner's problem.

Every person in that lift is a consumer of policy. The CIO produces it. The Product Manager resents it. The Developer needs it. The Cleaner follows it — or tries to. They are all doing the same thing. They are all failing at it for the same reason.

Policy, in most organisations, is a Word document in a SharePoint folder that nobody can find, nobody has versioned, and nobody can prove they have read.

The Industrialisation Nobody Noticed

The industrialisation of policy is happening whether we notice or not. Kyverno achieved CNCF Graduated status this year — the same level of maturity as Kubernetes itself. The CNCF published an introduction to Policy as Code that reads like mainstream recognition of something a small number of people have been banging on about for years. KubeCon London 2025 put policy at the centre of platform engineering. Policy is evolving from custom-built, hand-cranked enforcement into something that looks increasingly like commodity infrastructure. Most people have not noticed.

But here is what frustrates me. The consensus position — "policy-as-code is good; use OPA, use Kyverno, use Checkov; enforce at the gate" — is wrong. Not wrong in principle. Wrong in architecture.

Most policy-as-code implementations treat policy as a gatekeeper. An admission controller that blocks your deployment. A pre-commit hook that rejects your code. A compliance scanner that tells you what you got wrong after you have already built it. This is guardrails thinking. You hit the guardrail, your car is totalled, and technically the guardrail did its job because you did not go off the cliff. Congratulations. Your car is still wrecked.

Gregor Hohpe makes a useful distinction in his work on strategy mechanisms: the difference between a guardrail and lane keeping assist. A guardrail stops you at the point of failure. Lane keeping assist nudges you continuously, correcting in real time before you ever reach the edge. I should be honest that the dependency model I am proposing is not quite lane keeping assist — a versioned policy arriving as a pull request is a discrete event, not a continuous correction. But it is far closer to lane assist than to a guardrail. It nudges teams toward compliance before deployment rather than blocking them at the point of it.

Now — I need to be honest about the limits of this argument. Some policies belong at the gate. Access control. Data protection. Cryptographic key management. There are policies where the cost of a violation is so catastrophic and so irreversible that admission control is not just appropriate — it is the only responsible architecture. If a workload is about to deploy with an unencrypted database connection to a production environment containing personal data, I do not want lane keeping assist. I want a locked door.

The distinction is this: policies that govern how teams label, tag, configure, and structure their work are candidates for the dependency model. Policies that govern whether a workload is permitted to exist at all — security boundaries, data classification, access control — those belong at the gate. Confusing the two categories is how organisations end up blocking deployments over missing metadata while waving through genuine security risks, because the admission controller treats a missing department label and an exposed secret with equal severity.

Policy should be lane keeping assist where lane keeping assist is appropriate. And that turns out to be most of the policy surface area that enterprises actually struggle with. The labelling. The tagging. The configuration standards. The operational metadata. The stuff that makes the Cleaner's manual either current or dangerously stale.

Policy — for that surface area — should be something you pull towards you, not something that blocks you. Policy should be a dependency — versioned, tested, consumed, and updated automatically — not a gate.

The Dependency Model

Here is the technical argument, and I am going to show my working.

If policy is a dependency, then it should behave like one. It should have a version number. It should follow semantic versioning. It should live in a Git repository. It should have unit tests. And it should be consumed by the teams that need it the way they consume any other dependency — pulled in, pinned to a version, and updated via automated pull requests.

I built this. The policy-as-versioned-code GitHub organisation has eleven repositories and is still active. Renovate — the dependency update tool — has generated over 1,222 automated pull requests across those repositories. Each PR is a measurable signal: did the team accept the policy update? Did it break their build? Did they pin to the old version and ignore it?

Let me show you what v1.0.0 looks like. A simple policy: every Kubernetes resource must have a department label.

In Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-department-label
  annotations:
    policies.kyverno.io/title: Require Department Label
    policies.kyverno.io/category: Example Org Policy
    policies.kyverno.io/description: >-
      It is important we know the department that resources
      belong to, so you need to define a 'mycompany.com/department'
      label on all your resources.
    pod-policies.kyverno.io/autogen-controllers: none
spec:
  validationFailureAction: enforce
  background: false
  rules:
    - name: require-department-label
      validate:
        message: >-
          The label `mycompany.com/department` is required.
        pattern:
          metadata:
            labels:
              "mycompany.com/department": "?*"
        

In Checkov, for Terraform:

metadata:
  name: >-
    Check that all resources are tagged with the key - department"
  id: "CUSTOM_AWS_1"
  category: "CONVENTION"
scope:
  provider: aws
definition:
  and:
    - cond_type: "attribute"
      resource_types: "all"
      attribute: "tags.mycompany.com.department"
      operator: "exists"
        

And it has tests — because policy without tests is just an opinion:

# fail0.yaml — should be rejected
apiVersion: v1
kind: Pod
metadata:
  name: require-department-label-fail0
spec: ...
---
# pass0.yaml — should be accepted
apiVersion: v1
kind: Pod
metadata:
  name: require-department-label-pass0
  labels:
    mycompany.com/department: finance
spec: ...
        

That v1.0.0 becomes v2.0.0 when the organisation decides the department label must come from a constrained list rather than freetext — a breaking change, so a major version bump. Then v2.1.0 when someone spots a spelling mistake in the validation message. Then v2.1.1 when a new department is added to the allowed list. The version number communicates the nature of the change. Major means you must act. Minor means you should look. Patch means the system handles it.

This is where it matters for the Cleaner. The Cleaner's operational manual is a dependency too. When the policy bumps from v1.0.0 to v2.0.0, the Cleaner does not need to wait for a memo. The Cleaner does not need to check the SharePoint folder. The update arrives as a pull request. It either passes or fails. It is testable. It is visible. And the version number tells the Cleaner exactly how much attention to pay: a major bump means the rules have changed and the manual needs rewriting; a minor bump means a correction has been made; a patch means carry on. That is more information than any memo has ever carried, and it arrives automatically rather than three weeks late.

The Renovate configuration that makes this work:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "labels": ["policy"],
  "regexManagers": [{
    "fileMatch": ["kustomization.yaml"],
    "matchStrings": ["mycompany.com/policy-version: \"(?<currentValue>.*)\"\\s+"],
    "datasourceTemplate": "github-tags",
    "depNameTemplate": "policy",
    "packageNameTemplate": "policy-as-versioned-code/policy",
    "versioningTemplate": "semver"
  },{
    "fileMatch": [".*tf$"],
    "matchStrings": ["#\\s*renovate:\\s*policy?\\s*default = \"(?<currentValue>.*)\"\\s"],
    "datasourceTemplate": "github-tags",
    "depNameTemplate": "policy",
    "lookupNameTemplate": "policy-as-versioned-code/policy",
    "versioningTemplate": "semver"
  }]
}
        

When a team's build fails because they have not adopted the new policy version, the feedback is immediate and clear. When the CIO wants to know how many teams are compliant, the answer is a GitHub PR search away.

Go back to the lift. The CIO now has visibility — not a dashboard that measures deployment counts, but a PR acceptance rate that measures actual adoption. The Product Manager has automation instead of bureaucracy — policy updates arrive as pull requests, not as emails requiring three meetings. The Developer has explicit, testable rules with version numbers that distinguish "you must act" from "carry on." And the Cleaner — the Cleaner gets a notification that the policy version has bumped from v1.0.0 to v2.0.0, opens the pull request, sees exactly what changed (freetext labels are now a constrained list), and updates the operational manual in the same morning. Not three weeks later. Not after chasing someone in procurement for the latest memo. The same morning, using the same mechanism as the Developer three floors up. Policy-as-a-dependency does not care about your job title. It cares about whether you are consuming the current version.

The Code for Humans

There is a missing layer in this argument that I did not see until Michael pointed it out, and it is characteristic of him that the thing I missed was the human part.

The dependency model solves the distribution problem. Policies get versioned, tested, consumed, updated automatically. But who writes the policy? Who decides when it is stale? Who clears out the dead wood?

Michael created something at GDS called The GDS Way that answers these questions, and the answers are deceptively simple. There is no policy writing committee. A team notices a practice that works — how they run incident reviews, say, or how they structure service healthchecks — and they submit it as a proposal. Other teams review it, challenge it, adopt it or push back. Every accepted practice carries a date. Every practice must be regularly reviewed. And here is the part that matters most: if nobody can argue that a practice is still good — if nobody will stand up in a review and say "yes, this is still right, and here is why" — it gets removed. Not archived. Not deprecated. Removed. The dead wood gets cleared because the system demands that someone actively defend every piece of guidance that remains.

The Kyverno YAML, the Renovate PRs, the semver tags — that machinery serves teams who live in Git, who understand pull request workflows, who can read a version number and know what it means. The actual Cleaner — the person with the mop and the operational manual — does not have a GitHub account. The dependency model provides the single source of truth: the policy is versioned, tested, and current. But the last mile to non-technical consumers — how the Cleaner's manual stays in sync — is a different problem that the versioning alone does not solve. The GDS Way model starts to bridge that gap, because its governance is human-readable. A dated practice with a mandatory review cycle is something any consumer can understand, whether they read YAML or not.

This is the complement to the versioning model. Semantic versioning tells the Developer what changed and how much attention to pay. The review cycle tells everyone — including the Cleaner — something equally important: this policy is still alive. Someone still believes in it. It has not been left to rot in a SharePoint folder where nobody remembers who wrote it or why.

The combination is powerful. Version the policy so it can be distributed as a dependency. But also date the policy, review the policy, and — crucially — be willing to delete the policy when it no longer serves. Make explicit what is otherwise implicit. That phrase is Michael's, and it is the human half of the technical argument I have been making for six years without realising I was only telling half the story.

The Enterprise Temptation

I need to name something that the industry does not want named.

Enterprises default to buying policy solutions rather than changing culture. This is not stupidity. It is structural. Procurement is measurable — a purchase order has a date, a cost, a vendor, a contract. Culture change has none of those properties. You cannot put "transformed how 3,000 engineers think about compliance" on a quarterly report. You can put "deployed Kyverno across 47 clusters" on one.

In the 1830s and 1840s, Victorian factory owners faced the same structural incentive. Parliament passed the Factories Act of 1833 — the first law to require factory inspectors. The owners responded rationally: they bought safety equipment, posted notices, filed the paperwork. What they did not do was redesign the work itself. A posted notice about machinery guards satisfies an inspector. Redesigning a production line to eliminate the hazard satisfies nobody's quarterly report but saves the worker's hand.

This is precisely what happens when an enterprise buys a policy engine and bolts it onto the CI pipeline. The admission controller satisfies the auditor. The dashboard satisfies the board. The YAML file in the repository satisfies the compliance team. But the Cleaner — the person who actually needs to know what changed and why — is still working from a memo that arrived three weeks late. The purchase order closed. The problem did not.

The EU Cyber Resilience Act begins enforcement in September 2026 for vulnerability reporting and December 2027 for full SBOM requirements. When Log4Shell hit in December 2021, most organisations could not even answer the question "are we running Log4j, and if so, which version?" The xz Utils backdoor in March 2024 demonstrated that the supply chain threat had not gone away. Policy that cannot move as fast as the risk landscape is already obsolete.

Purposeless policy is potentially practically pointless policy.

The Lonely Experiment

From June 2022 to December 2023, I took this talk to twenty-one conferences across three continents. Cloud Native London and Wales. Open Source Summit in Brazil and Dublin. DevSecCon in Germany and the Netherlands. The UK Government Cyber Security Conference. Detroit. Virtual stages I cannot remember the names of any more.

I did not sell a product. I shared principles. There was no sales pipeline, no lead generation, no ROI spreadsheet. I gave conference organisers a rare thing — an independent voice not hawking wares — and in return I got audiences who told me I was "very clever" without ever engaging with the substance.

The Detroit trip crystallised something. I flew from Heathrow, landed, slept one night, gave the talk, flew back to Heathrow, went straight to the Crown Prosecution Service office in Westminster for a senior stakeholder workshop, had drinks after, and went home. Still immune to jet lag, touch wood. But the physical endurance was not the point. The point was this: I had carried Michael's philosophy six thousand miles, transmuted it into YAML and Renovate configs and semver tags, presented it to a room of strangers, and flown home to present it to a room of civil servants — and in neither room could I tell whether a single person would do anything differently on Monday morning.

I did it anyway. I would do it again. That is the defiant part, and I want to be clear about it: the loneliness was real, but so was the conviction. I believed — I still believe — that policy-as-a-dependency is architecturally right. Not knowing whether anyone acted on it does not make it wrong. It makes it unproven. There is a difference, and I have spent eighteen months learning to sit with that difference.

I have to believe there was value, because the alternative is that I spent eighteen months talking to myself. And maybe that is all writing is — talking to yourself in public and hoping someone overhears. But the policy-as-versioned-code GitHub organisation sits there with its eleven repositories and its 1,222 automated pull requests, and the engineering works whether or not anyone is watching.

I practised that alliteration line — "purposeless policy is potentially practically pointless policy" — because when you give the same talk twenty-one times, you need to find ways to keep it alive for yourself. To introduce jeopardy, to risk tripping over your own tongue, to create a moment of human engagement in a room full of people staring at their phones. The speaking circuit is made of small things like that — small moments of connection in large rooms full of polite indifference.

The Irony and the Aspiration

There is something I have been turning over. I took a philosophy shaped by Michael and others and turned it into engineering. That is what engineers do — and it is also what Michael did when he took scattered community conversations and turned them into a communicable narrative. Ideas move through people. The question is not who owns them but whether they are growing. I have a working demo, a recorded talk, and — finally — a proper citation.

The aspiration is simpler and, I suspect, more lasting. Even if someone else commercialises this idea — and someone will, because the land grab has already begun — the world is marginally better for the idea having been shared openly. Appvia wrote about it. The CNCF is moving in this direction. The principles are out there. Influencing the influencers is its own reward, even when you cannot measure the influence.

If you want to evaluate whether this model fits your organisation, here is a practical exercise you can do on Monday morning in fifteen minutes. Take a blank page. Draw two columns. Label the left column "Gate" and the right column "Dependency." Now list every policy your organisation enforces on engineering teams. Policies where a violation is catastrophic and irreversible — access control, data protection, cryptographic boundaries — go in the left column. Policies where a violation is correctable and the real cost is inconsistency — labelling, tagging, configuration standards, operational metadata — go in the right column. The left column belongs at the gate. The right column — and it will be the longer column — is where the dependency model applies.

Then go to github.com/policy-as-versioned-code/policy. Open the require-department-label directory. Read the Kyverno YAML. Read the tests — pass and fail. Then look at the Renovate config and imagine that automation running across every repository in your estate, opening pull requests whenever the policy version bumps. If that pattern fits the right column of your two-column map — the correctable, consistency-focused policies — you have a candidate for the dependency model. If it does not fit, you have learnt something about your organisation's policy surface that most CIOs never discover.

The Cleaner is all of us. We are all compiling memos into manuals, trying to stay current, dealing with version conflicts that nobody designed a system to manage. The CIO wants visibility but cannot get it. The Product Manager wants speed but cannot have it. The Developer wants clarity but cannot find it. And the Cleaner — the Cleaner has been solving this problem with a highlighter and a ring binder for longer than any of us have been writing YAML.

The question is whether we are brave enough to version the manual. And whether, when the automated pull request arrives, we will merge it or let it rot.

I wrote this article partly because I believe the technical argument is right, partly because ideas deserve their lineage traced, and partly because — after twenty-one conferences and eighteen months of speaking to rooms that politely applauded and moved on — I wanted to know whether anyone out there is listening.

If you have tried this approach, or argued against it, or built something better — drop a comment below and help me feel less lonely.

(Views in this article are my own.)

I hated it.

Not violently. Not with any great conviction. I did not hate it the way you hate something that frightens you. I hated it the way you hate something that disappoints you — the gap between the story you expected to tell and the experience you actually had. The first jump was fine. The second was fine. The third and fourth were fine. Everything was fine, which is the most damning word in the English language when you have paid for a course of jumps expecting to feel transformed.

Then came the fifth jump, and everything went wrong. I say wrong — it was line twists, which any experienced skydiver will tell you are a fairly routine malfunction that you kick out of. You look up, you see the lines are twisted, you kick, you spin, the canopy inflates properly, and you carry on. It is not dramatic. It is not cinematic. But it was the first time anything had gone wrong, the first time the script deviated, the first time I had to solve a problem in real time with the ground approaching at a rate that concentrated the mind wonderfully.

I loved it. From that moment, I genuinely loved it.

The adversity was the catalyst. Not the freefall, not the view, not the adrenaline — the problem-solving. The moment when something did not go to plan and I had to think, act, adapt. Researchers at Queensland University of Technology found exactly this: extreme sports participants are not thrill-seekers but self-knowledge-seekers. The value is not in the danger. The value is in discovering what you are capable of when the stakes are real.

Funny thing, though. I only made it to that fifth jump because I had bought the course up front. If it had been pay-per-jump, I would have walked away after the third. The sunk cost — that most derided of cognitive biases — was the thing that kept me in long enough to discover genuine love for the sport.

The Signal That Collapsed

Here is the thing I did not understand at twenty-five. The reason I thought I needed skydiving was not that my work was boring. It was that I did not know how to talk about it. I had internalised, without ever examining it, the technology industry's catastrophic inability to tell its own story.

I was building things that mattered. The work I do now — things like NDX:Try, giving local government organisations free cloud sandboxes to experiment with AI before committing a penny of public money — is objectively more exciting than a skydive. It affects millions of people. It changes how public services work. It is, by any honest measure, a more compelling story than "I fell out of a plane and threw a pilot chute."

But I could not tell that story. And the reason I could not tell it is the same reason the technology industry haemorrhages the very people it most needs.

There is a concept in evolutionary psychology called costly signalling theory. The idea is straightforward: a signal's value is proportional to its cost. A peacock's tail is expensive to grow and maintain, which is precisely what makes it a reliable indicator of fitness. Skydiving, when I started, was a costly signal. It was unusual, it was mildly dangerous, and it was the kind of thing that made people lean in at parties.

But skydiving had been democratising for decades. Tandem jumping arrived in 1983, turning what was once a military skill into a stag-do gift experience. By the time I was doing my AFF, skydiving was no longer unusual. The cost had collapsed. The signal had collapsed with it. I was paying for an increasingly commoditised experience whilst ignoring the genuinely rare and valuable thing I already had — work that was interesting, complex, and consequential.

I should thank Adam Craven here, because he was the person who first showed me that skydiving was accessible. He revealed to me that this outrageous-sounding thing was actually quite safe, quite reachable, quite normal. And he was right. But in doing so, he also inadvertently demonstrated the mechanism that undermined the entire exercise. The moment something extreme becomes accessible, it stops functioning as a signal of distinction. The moment everyone can do it, nobody is impressed by it.

What I should have been doing was learning to tell the story of the work. The same mechanism that devalued my skydiving story — signal collapses when cost collapses — is exactly what happened to the technology industry's narrative about itself.

I have watched this play out in three distinct modes, and I have been guilty of all of them. The first is the jargon fortress — describing mechanism instead of consequence, burying the human impact under layers of technical vocabulary that function less as communication and more as a drawbridge. The second is borrowed excitement — grafting someone else's story onto yours because you do not trust that what you actually built is worth talking about. That was me with the skydiving. The third is audience of one — telling the story exclusively to people who already understand it, who already care, who are already inside the walls. Every organisation I have seen that cannot recruit diverse talent is doing at least two of these simultaneously.

You want to see what these look like in the wild? The jargon fortress is a job advert that says "seeking expertise in Kubernetes orchestration, Terraform IaC, and GitOps pipelines" when what it means is "we need someone who can build systems that a million people rely on without thinking about." The borrowed excitement was me — literally me, standing at parties talking about freefall when I should have been talking about the work. And the audience of one is the conference talk packed with architecture diagrams that gets a standing ovation from the two hundred people in the room who already agree with every word, and reaches precisely zero of the people you actually need to walk through the door.

Then Like Now

The technology industry has a storytelling problem, and it is not an aesthetic failure. It is a structural one with measurable consequences.

The BCS Diversity Report 2024 found that at current rates, gender parity in UK technology will take 283 years. Two hundred and eighty-three years. Women hold 21-22% of software development roles. Seventy per cent of computer scientists do not match the stereotypical interest profile that the industry projects to the outside world — and that mismatch is not random. It is the direct result of a story the industry tells about itself that is narrower, duller, and more exclusionary than the reality.

Storytelling did not create those numbers, and storytelling alone will not fix them. But storytelling determines who even considers showing up.

"OK," you concede, "but surely the exciting industries do better?" They do not. Gaming is 76% male with 2% Black developers. The space industry is 80% male. Excitement does not fix diversity. If anything, excitement that is marketed to a narrow demographic entrenches it.

The problem is not that technology is boring. The problem is that the people who tell technology's story — people like me, for most of my career — told it in a way that resonated with people who were already like us. We described the work in jargon that excluded. We celebrated the wrong things: the all-nighter, the hackathon, the hero deploy. We built a culture that signalled "this is for a specific kind of person" and then wondered, with apparently genuine bewilderment, why only that specific kind of person showed up.

Universities graduate diverse computer science students at twice the rate that companies hire them. The pipeline is not the problem. The pipeline was never the problem. The problem is what happens at the other end — the job adverts, the interview culture, the 50% fewer callbacks for African-American-sounding names, the mythology that this work requires a particular personality rather than a particular capability.

IEEE found that 66% of engineers do not match the public stereotypes of what an engineer looks or acts like. The majority of the people already doing this work do not fit the image the industry uses to recruit more of them. That is not a diversity problem. That is a marketing hallucination.

The Confidence Problem

Here is what I actually learnt from the skydiving-at-parties experiment: confidence predicts attractiveness more reliably than any specific hobby or achievement. It was never the skydiving. It was the way I talked about it — the energy, the conviction, the willingness to be animated about something. The specific thing was almost irrelevant.

Which means the technology industry does not need to become more exciting. It needs to become more confident about what it already is. The work is extraordinary. Building systems that serve millions of people. Solving problems that governments and corporations and communities cannot solve without you. The engineer who builds an AI-powered translation service for council residents who do not speak English is doing something more meaningful than anyone who has ever jumped out of a plane. But that engineer has been taught — by the industry, by the culture, by two decades of hoodie-wearing founder mythology — that the work is not the story. That you need something else, something outside, something extreme, to be interesting.

That is a lie. And it is a lie with consequences. Every person who does not apply because they looked at the industry and thought "that is not for me" is a perspective we lose. Every team that is less diverse than it could be is a team that will build less robust, less creative, less representative technology. The diversity deficit is not a moral decoration. It is an engineering failure. I am aware of the risk in that framing — reducing people to engineering inputs is exactly the kind of dehumanisation I am arguing against. But the engineering frame is what this industry responds to, and I would rather use a language that gets heard than a language that gets ignored.

I must be honest about the limits of this argument, though. I am not saying that if we just told better stories, the diversity problem would vanish. Structural barriers are real. Pay gaps are real. Hostile cultures are real. The outdoor recreation industry is 72% white despite decades of campaigns to make it more accessible, which tells you that storytelling alone is insufficient. But storytelling is where it starts. You cannot recruit someone who never considered applying. You cannot change a culture that does not believe it needs changing. The story is the first domino, not the last.

The Wind Tunnel and the Work

I have not jumped out of a plane in ten years. Life intervened. My wife, the inimitable Hannah Nesbitt-Smith ; who, it must be said, has absolutely zero interest in skydiving whatsoever — and our children have restructured my relationship with risk in ways that a twenty-five-year-old paying for an AFF course could not have predicted.

Nowadays, all I get is indoor skydiving. I recently introduced my friend Patrick Crompton to the wind tunnel, and he has found the same deep joy in it that I did. There is something about the sport — even the indoor version, even the sanitised, controlled, nobody-is-going-to-die version — that teaches you things about yourself that you cannot learn any other way. Body position. Awareness. The way small adjustments produce outsized effects.

I will be honest, though: in the wind tunnel, I more closely resemble a daddy longlegs bashing off the walls than I do any of the incredible tunnel flyers you might see on YouTube. And if anyone ever asks what I do, I always show them someone else's videos. The gap between aspiration and reality is something I have learnt to find funny rather than embarrassing, which may be the most useful thing skydiving has taught me.

But here is the thing. When someone asks what I do for a living — not what I do for fun, but what I do for work — and I tell them, with conviction and energy, that I build platforms that let local government experiment with AI at zero cost, or that I work on systems that catalogue twenty-four thousand open source repositories across the entire UK government estate, or that I am trying to make it so that a council officer with an idea can go from "what if" to a working prototype in fifteen minutes — the reaction is the same as it ever was with the skydiving. Better, actually. Because the story is real, it is consequential, and it does not require me to have jumped out of anything.

The work was the interesting thing all along. I just needed to learn how to say so.

What Must Change

I am not going to end this with a ten-point plan. The problem is too structural for that and I am too honest to pretend otherwise. But I will say three things.

First: if you work in technology, learn to tell the story of what you do with the same energy you would use to describe jumping out of a plane. Not the jargon. Not the stack. The impact. The why. The human consequence. If you cannot make someone lean in when you describe your work, the problem is not the work. It is you.

Second: if you hire in technology, look at your job adverts, your careers pages, your conference sponsorships, and ask who they are speaking to. Pull up your three most recent job adverts. Read them aloud. If they sound like they were written by and for the same person, they were. Goldman Sachs rebuilt its entire employer brand around showing what the work actually looked like, not what the mythology said it looked like. The technology industry — an industry that employs some of the most creative people on earth — has somehow produced the least imaginative recruitment marketing in the history of professional services. That is fixable.

Third: recognise that storytelling is necessary but not sufficient. Better stories will widen the top of the funnel. They will not, on their own, fix the cultures that push people out. The 283-year figure from BCS is not just a recruitment problem. It is a retention problem, a promotion problem, a whose-voice-gets-heard-in-the-room problem. Storytelling opens the door. What happens after the door opens is a different fight, and an older one.

I am aware of the irony. This entire piece argues that signals collapse when they become accessible, and then prescribes making our storytelling more accessible. The mechanism I diagnosed is the mechanism I am invoking. But here is the difference: a collapsing skydiving signal costs you a party anecdote. A collapsing recruitment signal costs you 283 years.

I started jumping because I thought the work was not enough. I was wrong. The work was always enough. We just need to get better at saying so — and then we need to build the kind of workplaces that prove it.

(Views in this article are my own.)

We've now commoditised innovation.

For cloud services in local government, it still is. And that gap — between the components that have commoditised and the access that hasn't — is where most of your strategy is quietly dying. I should explain what I mean, because "commoditised innovation" sounds like something a consultant would say on a stage before selling you a three-year transformation programme. It isn't. It's an observation about evolution — specifically, about what happens when the evolution axis shows you two things that should be moving together but aren't.

Cloud compute has commoditised. Storage is a utility. Even sophisticated AI services — natural language processing, computer vision, translation — are moving rapidly from product to commodity. Available, standardised, cheap. But the ability to experiment with those commoditised services in local government? That's stuck in the custom-built phase. 209 NHS organisations and 320 local councils each independently navigating procurement for substantially similar tools. Every council negotiates its own path. Every team writes its own business case. Every experiment requires bespoke approval.

The components have commoditised. The access hasn't. And the strategy for each is completely different. If you can't see that gap, you're playing chess without a board.

Both sides are right (and both are wrong)

Here's the debate I keep hearing. On one side: "We need sandboxes! Let people experiment! Remove the barriers!" On the other: "Sandboxes are theatre. 88% of AI pilots never reach production. You're just generating experiments that go nowhere."

Both sides are right. Both sides are wrong. Because they're talking about different things at different stages of evolution.

The sceptics are right that a sandbox without a path to production is theatre — expensive, demoralising, innovation-flavoured prattle that changes nothing. But the advocates are right that without a sandbox, you never discover what the path to production should look like. You can't write a business case for something you haven't been able to try. And you can't know what's worth scaling until you've seen it work at the smallest possible scale.

The resolution, as usual, sits on the evolution axis. Experimentation is a component. The sandbox is a component. The path from sandbox to production is a different component. And they are not independent — experimentation access enables sandboxes, sandboxes generate learning, and the path to production converts that learning into operational value. Break the chain at any point and the whole thing stalls. Most organisations haven't mapped any of this, let alone worked out what evolution stage each one is at. That's the problem. Not sandboxes. Not the absence of sandboxes. The absence of a map.

The silent majority

Let me tell you about someone I'll call Sarah. She's a data analyst at a district council — one of the smaller ones, the kind where you're expected to do three jobs and be grateful for two. She's been there since 2014, when she applied for something in planning and ended up in data by accident. Last year she had an idea: use an AI language model to draft initial responses to Freedom of Information requests. Not the decision — the drafting. She reckoned it could save her team fifteen hours a week.

Sarah looked into it. She'd need access to a cloud environment. That meant a business case. The business case meant her line manager, who said it was a good idea and, with genuine sympathy, said it would take about a year. Then the digital board, who meet quarterly. If approved, procurement would take twelve to twenty-four months. By which point the AI services she wanted to test would have evolved twice over. Sarah felt the energy drain out of the whole thing somewhere between the second email and the third form.

Sarah didn't fail. Sarah didn't even start. She went back to her day job, because people have day jobs, and I don't blame them for doing the thing they're actually paid to do. Her idea exists only as an unexpressed hypothesis. We have no idea how many Sarahs there are, because their innovations are invisible. They don't show up in any metric. The MHCLG Future Councils pilot found that the number one blocker to innovation in local government was "no way to de-risk innovation." Not lack of ideas. Not lack of ambition. No safe way to try.

That's a landscape problem, not a people problem.

Conway's Law is eating your cloud migration

Melvin Conway observed in 1968 that organisations produce designs that mirror their communication structures. Give an organisation a cloud platform and what do they build? The organisation they already have. On the cloud. 52% of cloud migrations are lift-and-shift. McKinsey estimates that lift-and-shift wastes roughly two-thirds of the potential value. Two-thirds. That's not a migration strategy. That's an expensive relocation.

If your procurement process takes eighteen months, your innovation cycle takes eighteen months. If your governance requires a business case before anyone touches a cloud console, you've built a structure that guarantees nobody will discover the things that business cases can't predict. And here's what most people miss: procurement itself is a component on the evolution axis. It's sitting in the custom-built phase — every council designing its own process — while everything it governs has moved to commodity. That mismatch is the real architectural problem.

And what happens when the rational choice is not to try officially? You already know. 71% of UK employees are using unapproved AI tools at work. Shadow IT isn't a mystery. It's Conway's Law applied to experimentation: if the official structure won't support the work people need to do, they'll create an unofficial structure that will. The NCSC understands this — their guidance explicitly says to "avoid unnecessary IT lockdowns" because the alternative is worse.

You lock down environments to prevent risk. People experiment unofficially, outside your governance, outside your visibility. You've created exactly the risk you were trying to prevent. Brilliant.

What commoditised experimentation actually looks like

So what if you could push the ability to experiment from custom-built towards commodity? Not the ideas. Not the cloud services. The access.

That's what NDX:Try appears to be doing. It's part of the National Digital Exchange, and the proposition — if it works, and I'm genuinely not sure yet — is to remove the procurement wall between people like Sarah and the cloud services that have already commoditised. Free sandboxes for local government. You do a quiz, pick a scenario, get a working environment. Whether that means anything useful is the question I can't answer yet. And there's a landscape question worth asking: lowering the barrier to experimentation on a hyperscaler's platform is not the same thing as building public digital infrastructure. Whose sand are these sandcastles built on? That matters, and I'd want to see it mapped.

Now, I've seen enough "innovation platforms" to be deeply sceptical. Most of them are rubbish — consultant-designed, workshop-delivered, context-free. But let me be honest about what makes this different on the evolution axis: it's not trying to make innovation happen. It's trying to make the cost of trying low enough that people try without needing permission, funding, or irrational conviction. That's an infrastructure play, not an innovation theatre play. And the distinction matters.

The bit I'm less sure about

Here's where I hedge, because this is gameplay, not doctrine. I don't know whether commoditised experimentation leads to better outcomes or just more experiments. That 88% pilot purgatory number deserves more than a passing glance. If all you're doing is making it easier to create things that go nowhere, you've commoditised innovation theatre. Well done. Slow clap.

But I don't think that's the whole picture. Let me be precise about what I think is doctrine and what's gameplay here.

Doctrine: reduce the cost of experimentation and you increase the rate of learning. That's always true. It doesn't depend on context.

Gameplay: whether this particular platform delivers on that doctrine for this particular set of organisations — that's context-specific. I might be completely wrong. NDX:Try might gather dust in six months. Who knows.

What I do know is that the sandbox-to-production gap is real, and it's a separate component that needs its own strategy. The people building this need to map that gap as carefully as they've mapped the sandbox itself. If there's no path from "I tried something interesting" to "this is now running in production," then the sceptics are right and this is sandcastles. The path from sandbox to production is where the hard work lives — and where most innovation platforms quietly die. I'd want to see that map before I'd call this a success. But the fact that someone is addressing the experimentation access component at all? That's worth paying attention to, because almost nobody else is.

Where's your map?

If you're in local government technology, here's my challenge. Map your experimentation landscape. Not your cloud landscape — your experimentation landscape. How long does it take to go from idea to prototype? What are the dependencies? Where's the friction? Is it there for a reason that still makes sense, or is it one of those institutional habits where nobody remembers why it started but everybody assumes it must be important?

Map it. You might be surprised by what you find.

The mapping might reveal something I haven't considered. That's rather the point. At least with a map, you can see where you're wrong. Without one, the Sarahs in your organisation will keep having ideas and keep not trying them, and you'll never even know what you lost. And if you are a Sarah — if you can see the wall but can't move it — then at least this map gives you the language to name what's being lost. Making the invisible visible is sometimes the first act of change.

The 400+ councils standing at that procurement wall aren't short of ideas. They're short of a way to test them. The ideas that would have saved time, reduced cost, and actually improved services for residents — those ideas are sitting in people's heads, unexpressed, untested, and decaying. Every month that wall stays up, the gap between what's possible and what's attempted gets wider. That's not a technology problem. That's a situational awareness problem. And you won't solve it until you can see it.

(Views in this article are my own.)

I grew up in Brighton in the 1980s. We had four television channels. Channel 4 didn't even broadcast twenty-four hours a day until 1996. My mother told me that if I stared at the television too long, my eyes would go square. The scarcity was the point. Four channels meant somebody — a commissioning editor, a scheduler, a regulator — had decided what was worth broadcasting and when. The information came in a trickle. You could drink from it.

Now it comes from a fire hose attached to a sewage main.

Every generation panics about the new medium. In 1492, the Benedictine abbot Johannes Trithemius wrote De Laude Scriptorum Manualium — In Praise of Scribes — arguing that the printing press would corrupt knowledge and destroy monastic discipline. Scribes, he insisted, engaged with the divine through the physical act of copying; the press severed the link between comprehension and effort. He was mocked for it. He published his defence of hand-copying as a printed book — the irony was not lost on his critics, though Trithemius argued the press was acceptable for distributing his argument while still inferior for forming one. Five hundred years later, he sounds less like a Luddite and more like a prophet. The trade-off he described — effort removed, comprehension diminished — is exactly what is happening when you ask an AI to summarise a report you should have read yourself.

Neil Postman picked up the thread in 1985 with Amusing Ourselves to Death, arguing that Aldous Huxley had beaten George Orwell — that we would not be destroyed by what we fear but by what we love, drowning in an ocean of entertainment we chose for ourselves. Postman's insight was structural: each medium does not merely carry content but reshapes the act of thinking. Television turned political argument into entertainment. The internet turned entertainment into a feedback loop. And AI is turning the feedback loop into something that thinks — or pretends to think — on your behalf.

From Trithemius's printing press to Postman's television to the LLM on your laptop, the pattern is the same: a technology arrives that makes information cheaper, and the thing it makes cheaper is not just production but cognition itself. Amy Orben called this the "Sisyphean Cycle of Technology Panics", and she is right that the pattern exists. I am not interested in relitigating the pattern. I am interested in whether this time the pattern breaks.

The Feedback Loop That Changed Everything

Here is what is different. Every previous communication technology operated on human timescales. A newspaper editor wrote an article, printed it, distributed it. The feedback loop was measured in days or weeks.

Then the loop tightened. Then it got so tight that the human stopped being the author and became the product.

Richard Serra said it in 1973: "You are the product." Sean Parker confirmed it in 2017: Facebook was designed to exploit "a vulnerability in human psychology." Chamath Palihapitiya went further: "I think we have created tools that are ripping apart the social fabric of how society works." These are not critics. These are the architects, confessing.

B.F. Skinner identified variable-ratio reinforcement as the most addictive schedule of reward in the 1950s. Social media bolted his rat lever onto a global communication network and called it a platform. Andrew Bosworth's internal memo made growth "de facto good." Frances Haugen confirmed the platform knew it was causing harm and chose profit over safety.

Growth as the justification for everything. Sound familiar?

Three Threads, One Ratchet

This argument has three threads and they reinforce each other viciously. The first is supply-side: more than 52% of long-form web articles are now AI-generated, and HBR estimates the resulting "workslop" costs organisations $9 million a year. The second is demand-side: when AI summarises your emails and filters your feeds, you do not become better informed — you become a person who has stopped processing information altogether. The third is structural: the engagement engine was built to maximise attention captured, not understanding, and AI has simply given it a new production line. The flood creates the need for AI filters. The filters degrade your ability to evaluate what the flood contains. And the business model profits from both.

I use these tools. I am writing about the ratchet and I can feel its teeth in my own workflow — the pull of the summary, the relief of the shortcut, the slight hollowing-out when I accept an answer I did not earn. I am not writing from above this problem. I am writing from inside it.

Herbert Simon saw the core constraint in 1971: "A wealth of information creates a poverty of attention." Researchers at Caltech have shown that human thought operates at roughly 10 bits per second. Your sensory systems take in billions. Your conscious mind processes ten. Every communication technology in history has increased the volume arriving at that bottleneck. Not one has widened the bottleneck itself.

Then Like Now

'OK,' you might reasonably argue, 'but at least AI helps us manage the overload. It summarises. It filters. It prioritises. Isn't that the whole point?'

The reasonable version of this objection is that tools are neutral and usage is what matters. I used to believe that. But neutral tools do not redesign your information diet without asking. Neutral tools do not create feedback loops that amplify your existing biases. The ratchet does not care about your intentions.

A 2024 study in Nature Human Behaviour showed that AI-human feedback loops amplify existing biases rather than correcting them. A study in PNAS Nexus this year found that people who relied on LLM-generated summaries developed shallower knowledge structures than those who read the source material. They felt more confident. They knew less.

A 2025 study in Societies found a correlation of -0.68 between AI tool usage and critical thinking ability. The correlation does not tell us which way the arrow points — whether AI usage degrades thinking or whether weaker thinkers reach for AI more readily — but either direction is troubling.

And here is the part that should genuinely frighten you. ActivTrak's latest research found that AI tools are increasing task completion time by 346%. Not reducing it. Increasing it. Deep focus time is falling. Email time has doubled. BCG calls it "AI brain fry" — the cognitive exhaustion of constantly supervising a system that is supposed to be supervising you. The 346% figure likely captures the chaos of early adoption and may moderate, but the structural pattern — the supervisor needing a supervisor — is not a teething problem. It is the architecture.

The Paperclip Maximizer Is Not a Metaphor for AI

In 2003, Nick Bostrom introduced the paperclip maximiser — a thought experiment about an AI given the simple goal of making paperclips, which converts all available matter in the universe into paperclips, including the humans who built it.

But the paperclip maximiser is not a metaphor for AI. It is a metaphor for us.

We built the engagement engines. We optimised for clicks, views, time-on-site, and share counts. When those systems produced polarisation, addiction, and the erosion of shared reality, we did not shut them down. We scaled them up. We called it growth. AI slop is not a bug. It is the system working as designed.

Here is the ratchet. I am building it deliberately, because I want you to see how each step makes the next feel necessary and the alternative — doing the cognitive work yourself — feel impossible:

Step 1 — The Flood: AI generates content at a scale no human team can match. More than half of long-form articles are now AI-generated, and the number is climbing.

Step 2 — The Filter: You cannot process the flood, so you use AI to filter and summarise it. The filter selects based on what you have engaged with before. Your information diet narrows. This is where a thoughtful leader stops and asks: what is the filter removing? What am I no longer seeing? If you cannot answer that, you have already ceded the decision about what matters.

Step 3 — The Delegation: The AI-generated summaries replace your engagement with source material. Your comprehension shallows. You feel informed. You are not. Shallower knowledge structures, greater confidence, less actual understanding. This is the second off-ramp. If you are a leader making decisions on summaries of summaries, mandate that your team — and you — read the source material for any decision above a given threshold. Name the threshold. Write it down.

Step 4 — The Atrophy: Your reduced attention creates a gap. The AI generates more content to fill it. The noise increases. The signal degrades. You lean harder on the AI. The -0.68 correlation between AI usage and critical thinking is the ratchet in motion.

Step 5 — The Business Model: None of this is accidental. The engagement engine that drives Step 1 profits from every iteration of Steps 2 through 4. The company selling you the flood is selling you the filter. The company selling you the filter has no incentive to restore your ability to drink from the stream yourself. Growth is de facto good. The number goes up. The harm is acceptable because the number is still going up.

That is not a decision framework. That is a ratchet. You are not making decisions. You are being funnelled.

Hannah Arendt wrote about what she called "the banality of evil" — the idea that great moral failures are not caused by monsters but by ordinary people who stop thinking. Not people who think evil thoughts, but people who delegate their thinking to systems, to procedures, to authorities, and in doing so become incapable of moral judgement. Arendt's word for it was thoughtlessness, and she did not mean stupidity. She meant the abdication of the individual's responsibility to comprehend.

The Ratchet and the Responsibility

I need to be honest about something. I drafted sections of this argument with an AI assistant. I asked it to find the Simon quote. I asked it to check the Bostrom citation. I asked it to scan six studies I did not have time to read in full. Each time, I felt the pull — the relief of outsourcing a cognitive task, the slight diminishment of my engagement with the material. I caught myself accepting a summary instead of reading the source. I am describing a ratchet, and I can feel its teeth on my own cognition.

Simon Wardley and I have been putting the world to rights on this — over afternoon coffees, and Greek Raki, the kind of argument that goes in circles because neither of us can find the exit. His position is that the real danger is not that AI produces rubbish but that it degrades comprehension. His deeper worry: once AI controls the reasoning layer, you have handed the keys to your cognition to a system whose incentives are not your own. I keep trying to find the flaw. I have not found it yet.

The technology industry will tell you this is just another moral panic. Trithemius worried about printing. Postman worried about television. And look — civilisation survived.

True. But the printing press did reduce our reliance on monastic memory — Trithemius was right about that. Television did turn political discourse into entertainment — Postman was right about that. The panickers were not wrong about the mechanism. They were wrong about the scale. Civilisation survived, but as something different — something that had traded one cognitive capacity for another without ever consciously choosing to.

This time, the thing we are trading away is comprehension itself. The ability to take in information, process it, weigh it against what you already know, and form a judgement. And the feedback loop is no longer measured in days or weeks but in milliseconds.

So here is my challenge. Two things. One is personal, one is organisational.

The personal one: this week, read one thing in full that you would normally have asked an AI to summarise. Sit with it. Let it be slow. Let it be boring. Let your ten bits per second do their work.

The organisational one: audit where your company has inserted AI into the comprehension layer — the places where a human used to read, evaluate, and decide, and a system now does it for them. Map it against the ratchet. At which step are you? Ask whether the people downstream can still do the work if the system is switched off. If the answer is no, you do not have an AI strategy. You have a dependency. And dependencies, left unexamined, become vulnerabilities.

The paperclip maximiser is not coming for you. It is already here. And it is not a machine. It is every decision you made to let something else do your thinking.

That moment shaped what became the LocalGov Drupal AI scenario — one of a growing collection of "try before you buy" demonstrations we have been building through the National Digital Exchange (NDX). Our attempt to bridge the gap between what local government organisations need and what cloud services can already provide, if only someone would wire them together in a way that makes sense.

The problem is not technology. It is confidence.

UK local government is stuck in a curious paradox. Research shows the vast majority of local authorities are actively exploring AI, yet cloud spending growth has flatlined. G-Cloud has existed for over twelve years, and many local government organisations have never used it. The barrier is not lack of interest — it is lack of confidence to evaluate and act.

NDX:Try exists to address precisely this. It provides UK local government organisations — from county councils and metropolitan boroughs to district authorities and parish councils — with free, time-limited AWS sandbox environments pre-loaded with realistic scenarios drawn from genuine local government needs. No procurement. No commitment. No risk. Just guided curiosity in an isolated environment that cleans itself up afterwards.

However, an empty sandbox is rather like giving someone a fully equipped kitchen and no recipes. What we needed were scenarios — complete, deployable demonstrations that let a service manager or a technology lead experience the possibilities firsthand.

A recipe, not a restaurant

Perhaps the most instructive analogy comes from cooking (a domain I think about more than is strictly professional). When you follow a recipe for the first time, you are not just making dinner — you are building a mental model of how ingredients combine, what heat does to protein, why timing matters. A good recipe teaches you principles whilst producing something edible.

Our approach to the LocalGov Drupal scenario follows this pattern. We did not build a bespoke application. We took the standard LocalGov Drupal — the same open-source CMS already used across local government by organisations like Croydon Council , Brighton & Hove City Council , and Bracknell Forest Council — and layered seven AI capabilities onto it using Amazon Web Services (AWS) managed services. The architecture is deliberately transparent:

Users → CloudFront (HTTPS) → ALB → ECS Fargate → LocalGov Drupal
                                        ↓
                                   Aurora Serverless v2 (MySQL)
                                   EFS (persistent files)
                                        ↓
                              Bedrock · Polly · Translate
                              Textract · Rekognition
        

Every component maps to a service you could provision independently. Five CDK constructs — networking, database, storage, compute, CDN — each doing one thing well. I must admit I find the simplicity slightly deceptive; a fair amount of hard-won learning is buried in those clean interfaces.

Seven features that meet real workflows

The seven AI capabilities were chosen not for technical impressiveness (though I think some of them are genuinely impressive) but for their proximity to what local government teams actually do every day:

1. AI Content Editing — Amazon Bedrock suggests improvements to draft content directly in the Drupal editor. No copy-pasting into a separate tool.
2. Readability Simplification — One click transforms complex policy language into plain English, targeting an appropriate reading age for public-facing content.
3. Auto Alt-Text — Upload an image, receive a description. This might sound modest until you realise most local government websites have thousands of images with empty alt attributes.
4. Listen to Page — Amazon Polly provides neural text-to-speech in seven languages, with speed controls and language selection. Accessibility compliance as a feature, not an afterthought.
5. Content Translation — Amazon Translate delivers 75+ languages instantly. For any authority serving diverse communities, this moves translation from a procurement exercise to an immediate capability.
6. PDF-to-Web Conversion — Amazon Textract extracts content from uploaded PDFs. Given the volume of PDF-only content on local government websites (and the accessibility problems that creates), this addresses a genuine gap.
7. AI-Enhanced Search — Bedrock-powered semantic search that understands what you meant, not just what you typed.

What makes this interesting is the orchestration

However, I believe the most technically interesting aspect is not the AI integration itself but what happens when someone clicks deploy. A single CloudFormation template provisions roughly twenty AWS resources, then a container starts, installs Drupal, enables forty-odd LocalGov modules, configures the AI features, and then — the part that still makes me slightly nervous — invokes Amazon Bedrock to generate an entire fictional council identity.

Each deployment creates a unique fictional authority: a plausible name, a heraldic logo generated by Nova Canvas, service pages, news articles, and step-by-step guides. You are not exploring a generic demo with placeholder text. You are exploring what feels like a real local government website, complete with locally-flavoured content about bins, planning applications, and library services. The user sees a live progress page while this happens, which I think strikes the right balance between transparency and not overwhelming people with details they did not ask for.

Three things we learnt

Three lessons from building this that I think generalise beyond our specific context:

First, the gap between "working" and "useful to someone else" is wider than you expect. The infrastructure code is perhaps 200 lines of TypeScript. The initialisation script that makes it usable by a non-technical person is over 1,000 lines. The ratio tells you where the real complexity lives: not in the cloud services, but in the human experience of using them.

Second, AI features are only as good as their integration points. We initially tried building a sophisticated CKEditor plugin for the AI writing assistant. It needed webpack, which complicated the container build. The simpler approach — injecting toolbar buttons via Drupal's hook system — delivered identical functionality with perhaps a tenth of the complexity. Sometimes the less technically sophisticated path is simply the correct one.

Third, people need to experience things to believe them. We can write about AI-generated alt-text or one-click translation until we are blue in the face. It does not land until someone uploads their own image, sees the description appear, and thinks: "oh, that is actually quite good." NDX:Try exists because of this insight. Reading about cloud services and using cloud services are fundamentally different experiences, and the gap between them is where institutional inertia lives.

Returning to the kitchen

It seems to me likely that what we have built is less a product and more a recipe card. The ingredients are all managed services; the method is infrastructure as code; the result is something a council can taste, understand, and — critically — decide whether to cook themselves. Perhaps the content editor I watched struggling with her Flesch score tab will never use our specific implementation. But if she deploys this scenario and sees her CMS suggest clearer phrasing, generate alt-text automatically, and offer page content in Urdu, Polish, or Welsh with a single click — perhaps that changes what she expects her tools to do for her.

We should not pretend that deploying AI into a CMS solves the structural challenges facing local government. It does not. But it does something arguably more valuable at this stage: it makes the abstract concrete, the theoretical practical, and the unfamiliar safe to explore.

If you work in UK local government, you can try this scenario (and several others) for free through NDX:Try. No procurement, no cost, no commitment — just a sandbox and 24 hours.

If you work elsewhere in the public sector (or are simply curious about what we are building), drop us a line at ndx@dsit.gov.uk. We would genuinely like to hear from you.

(Views in this article are my own.)

I was reminded of Bush's Memex last week, after writing about the X-UK-Gov Public Repository Leaderboard and how we now have over 24,500 public repositories across UK government organisations, complete with Software Bills of Materials. The response was gratifying — a number of people got in touch to say they found the data useful, or that they hadn't realised the scale of what was out there. But one question kept coming up, in various forms: "This is interesting, but how do we actually find the thing we need in 24,500 repositories?"

It's a fair question. A sorted table is a fine thing (I should know, I've been running one since 2018), but it's not particularly useful if you're a developer in a council trying to work out whether anyone else in government has already solved the problem you're about to spend three months building. We have, in effect, built an enormous library and forgotten to hire a librarian.

I think that's the real gap we've been living with. The code is in the open. The data is available. But discoverability has been, frankly, terrible.

Searching With Intent

Which is why we now have govreposcrape — a semantic search layer over the entire UK government open source estate. It uses Google's Vertex AI Search to index all 24,500+ repositories (and growing), and exposes the results through an API and, more interestingly, through a Model Context Protocol (MCP) server.

For those not yet familiar with MCP, it's an open standard (developed by Anthropic, but designed to be universal) that allows AI assistants to connect to external data sources and tools. In practical terms, it means you can add a single configuration block to Claude Desktop, GitHub Copilot, or any MCP-compatible tool, and your AI assistant suddenly has the ability to search across every public UK government repository as part of its normal workflow.

The setup takes about two minutes. You add a few lines of JSON to your configuration, restart the application, and from that point on we can ask natural language questions about what exists across government code. No API keys to manage, no authentication to configure — the service is freely available.

And yet.

The interesting thing is not the technology. It's what happens when we actually use it.

"Who Else Has Done This?"

I think the most powerful question a developer in government can ask is not "how do I build this?" but "has someone already built this?" So I tried it, asking the kind of questions that come up regularly from teams across the public sector. The results were genuinely illuminating.

The first scenario comes up constantly: "I'm thinking of building a case management system that will OCR text and help the user process casework documents faster. Who else in government has done that? What components can we reuse?"

The response surfaced projects that none of us would have found through keyword searching. Bath & North East Somerset's ProcessMaker implementation — a complete workflow and case management system. Dorset Council's Flood Online Reporting Tool, which is essentially a case intake and processing system. East Sussex County Council's form controls and database file handling libraries. York's Lucene Entity Search Tools for text processing.

None of these are a drop-in solution (they rarely are), but together they represent a considerable body of work that teams could learn from, adapt, or build upon. The alternative — starting from scratch in ignorance of what already exists — is the kind of waste that we should find genuinely frustrating when public money is involved.

"How Should We Store an Address?"

The second question was more specific, and perhaps more revealing: "How should we store an address for portability with other UK government organisations?"