Fresh off Dreamforce, Gabe and Kelly dig into the increasingly loud debate around slowing down AI. The interesting part isn’t simply whether AI should move faster or slower. It’s deciding what should be allowed to move quickly, where the boundaries belong, who can stop something, and what evidence allows it to move again.

In other words: governance.

The technical gap is collapsing. Something that once took ten months to build might now take ten days. So what should we do with the time we just got back?

Our argument: don’t immediately spend all of it going faster.

Use some of it to understand the process. Reduce what shouldn’t be there. Define what the system should never do. Test the assumptions. Then automate.

We also get into one of the stranger consequences of automation: the people entering the workforce may not be cognitively offloading work they already understand. They may never cognitively onboard that knowledge in the first place.

That problem isn’t new.

In 1983, psychologist Lisanne Bainbridge described what she called the Ironies of Automation: as systems become more automated, the human operator can become even more important when something unusual happens.

“The more advanced a control system is, so the more crucial may be the contribution of the human operator.”

More than forty years later, that sounds a lot like the human-in-the-loop conversation we’re having about AI.

In this episode

00:00 — Governance at machine speedDreamforce, the “slow down AI” debate, guardrails, process, and why governance suddenly seems to be everywhere.

02:25 — What shouldn’t we build?AI changes an old requirements question. It’s no longer enough to ask what a system should do. We also need explicit boundaries around what it must not do.

05:00 — Cognitive onboardingWhat happens when automation removes the work people once used to develop judgment, experience, and understanding?

05:50 — The Ironies of AutomationWhy a paper from 1983 may be one of the most useful things to read about AI automation today.

07:30 — What exactly are we slowing down?Frontier research, business implementation, process design, and why “slow down AI” becomes much more useful once we get specific.

09:40 — Spend some of the speedIf development drops from ten months to ten days, maybe five of those days should be spent understanding and reducing the process before automating it.

14:50 — Speed versus safety is really a governance questionWhat crossed the boundary? Who has authority to stop it? What evidence allows it to continue?

17:15 — AI cults, hype, and fearWhy the AI conversation can quickly drift from legitimate safety concerns into religion, apocalypse, politics, capital, and social-media amplification.

24:10 — Is your organization actually ready for AI?Process understanding, data foundations, iteration, and why automating something you don’t understand just accelerates the problem.

31:50 — The Gravity AuditOld permissions. Unclear ownership. Disconnected systems. Exceptions. Informal workarounds. AI didn’t create any of this, but it will inherit all of it.

39:30 — Humans in the loopAI and humans can both accumulate organizational mass. Both need monitoring, reduction, and intentional design.

47:15 — What AI is making visibleAI may be exposing Organizational Gravity that was always present but difficult to see.

51:35 — Can governance become something people actually want to participate in?Making process work visible, useful, fast, and tangible instead of making governance feel like policing.

53:40 — Where Gabe might be wrongMaybe people won’t willingly expose every workaround and task they perform, particularly when automation creates fear about what happens to their role afterward. That makes trust part of the governance problem.

References mentioned

Lisanne Bainbridge — “Ironies of Automation” (1983)Automatica, Vol. 19, No. 6, pp. 775–779.DOI: 10.1016/0005-1098(83)90046-8

Caitlin Malone — Linear DigressionsThe discussion that sent Gabe back to Bainbridge and the much older research behind today’s human-versus-automation questions.

Mike Krieger — Anthropic LabsInstagram co-founder and current head of Anthropic Labs, whose Dreamforce discussion helped frame the conversation around how quickly AI-native work is changing.

The Daily — “The Techno-Religion at the Center of the A.I. Debate”A look at the communities, ideologies, and “doomsday cult” criticism surrounding parts of the AI safety debate.

The bigger idea

AI didn’t create Organizational Gravity.

It inherited it.

The danger isn’t simply that machines will move too fast. It’s that we’ll use their speed to automate old permissions, bad processes, undocumented exceptions, unclear ownership, and decades of accumulated organizational mass.

Governance at machine speed doesn’t mean making governance instantaneous.

It means using the speed of the machine to give humans more time to understand what should exist in the first place.

And maybe that’s the real opportunity: not simply faster automation, but better-designed work.

Corrections from the episode

Jon KrohnIn the recording, the name came out as “John Crone.”Correct: Jon Krohn, host of the Super Data Science: ML & AI Podcast.

Dr. Katie MaloneIn the recording, I referred to her as “Dr. Caitlin Malone.” She publishes and podcasts as Dr. Katie Malone. She was the guest on Jon Krohn’s September 22, 2026 episode.

Linear DigressionsNot “Linear Degressions.”Katie Malone hosts the AI, machine learning, and data science podcast Linear Digressions.

Lisanne BainbridgeIn the recording, I said “Larissa Bainbridge.”Correct: Lisanne Bainbridge.

Her 1983 paper is:

Bainbridge, Lisanne. “Ironies of Automation.” Automatica, Vol. 19, No. 6, November 1983, pp. 775–779.

DOI: 10.1016/0005-1098(83)90046-8

The paper’s core argument is even more relevant today: automating routine work can leave humans responsible for abnormal situations while simultaneously giving them less practice and less direct involvement in the work.

Mike KriegerThe former Instagram leader I was trying to remember was Mike Krieger, co-founder and former CTO of Instagram. He joined Anthropic as Chief Product Officer in 2024 and moved into Anthropic Labs in 2026. He spoke at Dreamforce 2026.

NVIDIA / Hugging FaceI said at one point that NVIDIA had “bought” Hugging Face. More precisely:

NVIDIA entered into a definitive agreement to acquire Hugging Face in September 2026. The transaction has been announced but has not yet closed. NVIDIA said it expects the deal to close in the first half of 2027, subject to customary conditions and regulatory approvals.

The New York Times / AI “cult” discussionThe episode I was referring to was The Daily episode:

“The Techno-Religion at the Center of the A.I. Debate” — September 18, 2026

One clarification: the episode is more nuanced than saying AI executives themselves have formed a “cult.” It looks at the ideologies around AI development and safety, along with the backlash that has characterized some AI-safety advocates as a “doomsday cult.”

Sources & Further Reading

Lisanne Bainbridge — “Ironies of Automation” (1983)The foundational paper behind our discussion of automation, declining human practice, and why human expertise can become more important rather than less important as automation improves.

Super Data Science Podcast — Episode 1029“How AI Brought a Podcast Back From the Dead, with Linear Digressions’ Katie Malone”Jon Krohn with Dr. Katie Malone, September 22, 2026. The discussion of Bainbridge’s Ironies of Automation begins around 41:39.

Linear Digressions — Katie MaloneKatie Malone’s podcast covering AI, machine learning, data science, agents, benchmarks, and the human consequences of automation.

Mike Krieger — Anthropic LabsKrieger co-founded Instagram, joined Anthropic as Chief Product Officer, and moved into Anthropic Labs in 2026 to work on experimental products at the frontier of Claude’s capabilities.

The Daily — The New York Times“The Techno-Religion at the Center of the A.I. Debate”September 18, 2026. A discussion of AI safety, technological ideology, and the political and industry backlash around calls for stronger AI guardrails.

NVIDIA — Hugging Face AcquisitionNVIDIA announced an agreement to acquire Hugging Face on September 3, 2026. The related SEC filing states that the transaction is expected to close in the first half of 2027, subject to customary closing conditions.

Agents Don’t Complain

What if AI could ride my bike for me, do the laps, and somehow give me all the physical benefits?

That sounds great. It also gets at something that worries me about how we’re approaching AI at work.

Agents don’t complain.

Humans do. And I’m starting to think that’s much more valuable than we give it credit for.

For years, I looked at some of the friction around process change as something to remove. People had their spreadsheets, workarounds, swivel-chair processes, exceptions, and ways of doing the work that weren’t always documented. We call that human middleware.

AI changes how I think about it.

Those people aren’t just carrying inefficient processes. They’re often carrying years of experience: the exceptions, risks, judgment calls, and institutional knowledge that never made it into the system.

If we automate the work without understanding that experience, the machine won’t complain when something is wrong. It will just keep doing it.

That creates another problem for the people coming behind us. Experienced workers may have cognitively offloaded parts of their work to technology after years of learning the job. New workers could enter an automated environment without ever cognitively onboarding that experience in the first place.

That’s why human-in-the-loop matters.

And it’s why I keep coming back to the same idea about governance:

Governance has to understand the work, not just the output.

The goal shouldn’t be to turn every task that once took two days into something that takes five seconds. AI can give us time back. We can use some of that time to scrutinize the work, understand why an answer is correct, improve the process, train people, and build better systems.

Automation should remove unnecessary work.

It shouldn’t remove our understanding of the work.

In this live

* Why “agents don’t complain” is both the promise and the risk of automation

* Human middleware as a source of institutional knowledge

* The difference between cognitive offloading and never cognitively onboarding

* Why employee friction can actually be valuable feedback

* Human-in-the-loop as more than an AI safety mechanism

* Using AI to accelerate process design and feedback rather than simply accelerate output

* Why governance needs visibility into the steps that produce an answer

* What happens when experienced people leave and nobody understands what was encoded into the machine

The question I’m left with:If the machine does the work perfectly, but nobody understands why the work is done that way anymore, what exactly have we automated?

AI is supposed to save time. So why does so much of that time seem to disappear?

In this episode, Gabe and Kelly dig into Glean’s 2026 Work AI Index and two terms that capture a growing problem at work: bot sitting—the human effort required to feed, monitor, correct, and clean up after AI—and botshitting—sending AI-generated work downstream without really understanding or validating it.

That leads to a bigger Organizational Gravity question: what if AI is making work faster without actually making the system lighter?

We talk about where those supposed productivity gains go, why human review is different from babysitting a poorly designed bot, and how unverified AI output can move risk downstream faster than the old process ever could.

The conversation also puts pressure on Organizational Gravity itself. I have often treated friction as evidence of unnecessary organizational weight, but AI exposes an important exception: some friction is doing real work. Verification, judgment, accountability, experience, and safety can all slow a process down for good reasons.

The goal cannot be zero friction. It has to be the right friction, scaled to the consequence of getting something wrong.

In this episode

00:00 — Bot sitting and botshittingWhat the terms mean and why individual AI productivity does not always translate into better organizational performance.

04:25 — Who botshits more?A funny statistic about men and women turns into a more serious conversation about confidence, scrutiny, and how people review their work.

07:35 — Human in the loop or babysitting the bot?Where useful supervision ends and poor system design begins.

09:05 — Why are people shipping work they cannot defend?Deadline pressure, trust in the technology, weak review practices, and the widening technology gap.

17:11 — The Gravity AuditBot sitting starts to look a lot like Human Middleware. Are we adding AI without removing the process that created the work in the first place?

25:00 — The 4:30 PM testThe deadline is real, you are tired, and AI gave you something usable. Do you ship it or tell people you will be late?

27:34 — Where is Gabe wrong?We put Organizational Gravity itself under pressure.

28:29 — Not all friction is badRemoving every manual check can also remove the judgment that keeps bad information from moving downstream.

33:41 — Zero friction is the wrong targetGovernance should create the right amount of friction based on the consequences of the decision.

37:00 — A revised rule for frictionRemove friction caused by poor design. Preserve friction that creates judgment, accountability, or safety—and periodically prove that it still does.

40:34 — Three questions before you automateWhat should actually disappear? What judgment still belongs to a person? How will we know the whole process got better?

The takeaway

AI can make work move faster while Organizational Gravity continues accumulating underneath it.

If humans are constantly feeding the bot, checking whether the bot is functioning, repairing bad output, and carrying knowledge that never made it into the system, we have not necessarily removed the weight.

We may have just compressed it and accelerated it.

The better question may not be:

How much work can we automate?

It may be:

What should become easier, and what do humans still need to struggle with long enough to understand?

And that leaves us with a question for the next episode: maybe Human Middleware should not disappear entirely.

Maybe the real question is:

What should humans still be in the middle of?

Source: Glean Work AI Institute, The Work AI Index 2026: Botsitting, botshitting, and the hidden human labor of AI at work (2026)

Show Notes

This week, Gabe and Kelly take on one of the least glamorous but most important parts of organizational change: training.

The conversation starts with a simple problem. Organizations are changing the technology around work much faster than they are changing how people learn. Training is still too often treated as something completed once during onboarding or rolled out through a video, an SOP, or a compliance module, with the assumption that people will remember what they need months later.

That leads to a bigger distinction between training, learning, and performance. When is someone struggling because they were never given the information at the moment they needed it? When does repetition become learning? And when does a recurring problem stop being a training issue and become a performance conversation?

The episode also explores point-of-need learning. Instead of expecting people to remember everything in advance, what if technology could provide guidance in the moment the work is happening? The idea is not just to make training easier, but to move learning closer to practice, where repetition, feedback, and context can turn information into capability.

That creates another question: what happens when technology gets too good at remembering for us?

Gabe and Kelly discuss cognitive offloading, judgment, and the risk of providing so much support that people stop gaining the experience they need to handle exceptions. AI may be able to guide someone through the standard process, but organizations still need to decide where human judgment belongs and when a leader should step in.

The conversation then moves into Reductive Change. Gabe references Leidy Klotz’s work on subtraction and the tendency people have to add rather than remove. The same instinct shows up in training and process design: a problem appears, so organizations add another step, another document, another control, or another training requirement. AI may give us a chance to do something different by first removing unnecessary friction, then using technology where it genuinely helps.

Klarna also comes up as an example of the tension between automation and human knowledge. In 2024, Klarna said its AI assistant was doing work equivalent to roughly 700 full-time customer-service agents. Later, CEO Sebastian Siemiatkowski said the company had pushed too far toward AI-driven cost-cutting and had begun rebuilding access to human customer support. The lesson is less that AI failed and more that automation can expose how much context, judgment, and relationship knowledge people were carrying.

The episode closes on a different way of thinking about reskilling. Maybe the goal is not simply teaching people how to work alongside AI. Maybe it is helping people let go of repetitive work technology should carry, then using the recovered time to build judgment, relationships, communication, and the parts of work that remain distinctly human.

Topics discussed

Training vs. learningCompliance vs. adoptionPoint-of-need trainingPerformance vs. training issuesCognitive offloadingRepetition and consistencyLeadership reinforcementAI and exception handlingReductive ChangeKlarna and human customer supportThe value of recovered timeWhat reskilling should look like in an AI-enabled workplace

References

Leidy Klotz, Subtract: The Untapped Science of LessAdams et al., “People systematically overlook subtractive changes,” Nature, 2021Klarna, AI customer-service assistant announcement, 2024Research and practice around the 70-20-10 workplace learning model and experiential learning

Episode blurb

LinkedIn shipped a button that lets anyone report your post as AI slop, the same day it removed its own AI writing tool. On a network where reach is proximity to a job, that isn’t moderation. It’s a permission structure, and the people most exposed are the ones who already write like everyone else because they were trained to. Also this week: Pew put a number on how much of the web is written by AI, and a federal research office said that same kind of detector can’t stand alone as evidence of anything. The institution with more at stake demanded more evidence.

Longer description

On 30 July, LinkedIn added “Seems like AI slop” to the menu on every post and removed Enhance Post, its own AI writing tool, the same day. The order matters. The platform built the tool, the tool produced the output, the platform took the tool away and handed everyone a button to report each other for it. Nobody planned that, which is exactly what makes it gravity rather than malice.

What it does to a person is the part worth sitting with. LinkedIn isn’t where people go to tell stories; it’s where they go to be employed, so a reach penalty isn’t a content-moderation outcome. It’s an economic one, applied silently, by a stranger, at no cost to them and with no appeal for you. And the people most exposed are the ones taught to write in corporate templates, the non-native speakers whose careful prose reads smooth, the juniors imitating a senior to be taken seriously.

That sits inside a bigger story. Pew Research published a census-scale estimate of how much of the web is AI-written, and the number came out of a detector. Pew did the work carefully and documented it all — the threshold, the agreement statistic, the false-positive warning, the dating limitation. What happens next isn’t Pew’s fault. It’s what always happens: the caveats fall away, and the number travels alone. Meanwhile, the HHS Office of Research Integrity looked at the same class of instrument and said it can’t be the sole basis for a misconduct finding.

And in Where I’m Wrong: I thought training was the easy part of governance. Three studies took that apart, and the one that moved me most wasn’t the one saying training fails.

In this episode

Pew’s census-scale estimate of AI-written pages, and the caveat that decides what the number means

Why only 10 to 15 percent of sampled pages could even be dated, and what that does to the headline

The HHS Office of Research Integrity guidance, and why a federal office demanded more evidence than a publishing platform did

What it means to admit a probabilistic estimator into a fact-producing role without treating it as a change

The structural middleware underneath the whole story: a 490,000-page apparatus built to approximate a fact every generator knew with certainty and discarded

LinkedIn’s slop button, the removal of Enhance Post, and the order those two things happened in

Why a reach penalty on a professional network is an economic outcome, not a moderation one

Who’s actually most exposed: the people trained to write like everyone else

Where I’m Wrong: training, and the difference between a content problem and a conditions problem

Key ideas

Organizational Gravity — organizations accumulate mass faster than they shed it. Here it shows up as a measurement admitted into the operating model with none of the questions a change would have to answer.

Governance is not measurement — the order is issue, root cause, control, then measurement. This story runs it backwards: the detector arrives first and becomes the fact.

Structural middleware — when no provenance layer connects generation to publication, somebody has to build a 490,000-page estimator to recover what was known for free at the moment of writing. That’s incomplete architecture, and the fix is integration.

The permission structure — a report button between peers on a network where reach is proximity to a job isn’t moderation, it’s a mechanism.

Sources

Segment 1 — the news hit

Pew Research Center, “How much of the internet is written with AI?” (20 August 2026) — the primary study. 490,000 English-language pages sampled across 49 Common Crawl snapshots, January 2021 to July 2026. Supports the 10 percent raw July 2026 figure, the “over one third” figure for pages with a detectable post-ChatGPT publication date, and the methodology caveats including the dating limitation. Also carries Pew’s own false-positive warning and stated threshold — worth reading before repeating either number.

HHS Office of Research Integrity, guidance on generative AI in federally funded research (14 August 2026) — the second institution. Supports the central claim that detector output may constitute evidence but that ORI recommends against relying on such tools as the sole basis for a misconduct finding. Also covers disclosure expectations and the penalty framing.

Segment 2 — the Gravity Audit

Tech Times, “LinkedIn pulls its own AI writing feature, crowdsources slop detection” (31 July 2026) — supports both halves of the sequence: the addition of “Seems like AI slop” to the post menu and the removal of Enhance Post on the same day. Also carries the reporting on how flagging feeds LinkedIn’s classifiers and affects recommended-feed distribution.

The 40-plus percent figure for fully AI-generated LinkedIn long-form content is Pangram’s research, not LinkedIn’s — attribute it that way on air and in writing.

Segment 3 — Where I’m Wrong: training

Arthur, Bennett, Edens & Bell (2003), “Effectiveness of Training in Organizations: A Meta-Analysis of Design and Evaluation Features,” Journal of Applied Psychology 88(2), 234–245 — free full-text PDF. 397 findings across roughly forty years and about 33,000 people. Supports the claim that the average trained person outscored about three of four untrained people. Note the measures are largely taken at the end of training, which is the limitation that sets up the next study.

Park, “Does Compliance Training Decrease Corporate Misconduct? Evidence From Field Data” (Harvard DASH) — five years of internal records from one multinational manufacturer, roughly 100,000 employees across about 100 countries, alongside 2,237 misconduct allegations. Supports the no-meaningful-association finding on average, the roughly two-month decay of in-person effects, the null result for video, and small classes outperforming large ones by around ten to one. Say on air that this is a dissertation, not peer-reviewed, one company, and compliance training specifically. Also available as Harvard Law Olin Center fellows paper 89.

Blume, Ford, Baldwin & Huang (2010), “Transfer of Training: A Meta-Analytic Review,” Journal of Management 36(4), 1065–1105 — free full-text PDF from an author’s site; journal version at SAGE. Eighty-nine studies, roughly 12,500 people. Supports the finding that work-environment support — manager backing, a job that rewards the new behavior — predicted transfer better than trainee motivation, which ranked near the bottom. This is the study behind “it’s the room they go back to.”

Read the full version

This week’s newsletter went out on training — all three studies, the long version, and the part I didn’t get to on air: LinkedIn newsletter

Subscribe

I’m writing a book out loud, thinking it through in public, one essay and one episode at a time. Subscribe, and you’ll watch it take shape:

Gabe | Organizational Gravity

Note

Stories on this show are anonymized. Names and identifying details are always changed.

Frank runs a transformation at a company you’d recognize. He didn’t buy the agents — but he answers for all of them. This episode: why AI transformations keep failing, what organizational gravity has to do with it, and why the loudest warnings are coming from the companies selling the tools.

The essay version of this argument — told as a bar story — is on the Substack:

THE NUMBERS FROM THIS EPISODE, WITH SOURCES. Check the math — it holds.

IBM Institute for Business Value, C-suite study on AI control and governance (June 2026) — 2,000 technology executives, 33 geographies:

* Two-thirds (~1,333) are held accountable for AI systems they don’t fully control

* 70% (1,400) say teams across the business are deploying faster than IT can track

* 11% (220) believe they’re ready for the scale of agent deployment expected next yearhttps://newsroom.ibm.com/2026-06-08-new-ibm-study-finds-cios-and-ctos-face-growing-ai-control-gap-as-enterprise-deployment-scales

MIT NANDA, “The GenAI Divide: State of AI in Business 2025” — 95% of corporate generative AI pilots (19 out of 20) fail to deliver ROI:https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html

OpenAI, “Work at the Frontier” (July 2026) — of 800,000+ work-related messages analyzed, 43.5% (~350,000) were tasks outside the user’s own occupation:https://openai.com/index/how-ai-is-expanding-what-people-do-at-work/

Anthropic, “The Founder’s Playbook: Building an AI-Native Startup” (2026) — 42% of startups failed because they built something nobody wanted; “that failure rate is only going to climb”:https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/69fe2a55b93bb0732b1fe33c_The-Founders-Playbook-05062026_v3%20(1).pdf

Moffatt v. Air Canada (2024 BCCRT 149) — the tribunal held Air Canada liable for its chatbot’s invented policy:https://www.mccarthy.ca/en/insights/blogs/techlex/moffatt-v-air-canada-misrepresentation-ai-chatbot

Morgan Stanley × OpenAI — evaluation-first GPT-4 deployment; 98% advisor-team adoption:https://openai.com/index/morgan-stanley/

The Organizational Gravity Podcast. New episodes weekly.

The Organizational Gravity Podcast

Episode 3 — The Weight Nobody Chose

Runtime: 24:04

Linda inherited a project that was already half-built. The software was chosen. The contracts were signed. Everyone who made those decisions was gone. She thought she was inheriting a project — she was inheriting years of other people’s reasonable choices, piled into one system she was now supposed to make work.

She told me none of it ever felt unusual at the time. It just felt like the work.

That’s the episode. Every change model we run starts after the design is finished. Nobody owns the stage before it — the one where somebody asks how much the future state should weigh. This episode names that stage, gives it a formula, and finishes the model the first two episodes started.

Episodes 1 and 2 were the diagnosis. This one is the treatment.

The model, end to end

Four parts. Gravity is the disease. Middleware is who pays for it. Reduction is the treatment. Governance is how it doesn’t come back.

1. Organizational gravity

Organizations gain mass by default, and every individual decision that adds mass is reasonable on the day it’s made.

Nobody approves the accumulation. There’s no meeting where a company decides to become slower and harder to change. There’s a meeting where somebody adds an approval after a bad quarter, and a meeting where somebody builds a report because an executive asked a fair question, and a meeting where somebody grants an exception because a real customer had a real problem. Each one is defensible in isolation. None of them are ever revisited.

Gravity is the sum. It is cumulative, it is invisible while it accumulates, and it pulls in one direction only. Addition is cheap, fast, visible, and rewarded. Removal is expensive, slow, invisible when it works, and rewarded by nobody.

The diagnostic: if you can’t name what came out the last time something went in, gravity is winning.

2. Human middleware

People become the connective tissue holding accumulated mass together, and that work is invisible because it looks like competence.

The spreadsheet that reconciles two systems that were supposed to talk. The handoff that only works because one person knows to check. The report someone rebuilds by hand every month because the automated one has been wrong since 2019. None of it is in a job description. All of it is load-bearing.

Middleware is what makes gravity survivable, and it’s also what makes gravity invisible — because from the outside, an organization held together by people looks like an organization that works. Nobody walked past Linda’s office and saw a woman carrying years of other people’s decisions. They saw someone doing her job.

The diagnostic: when a person leaves and something breaks that nobody knew existed, you found middleware. Too late.

3. Reductive change

Remove the complexity before adoption begins, instead of managing its pain all the way through.

This is the treatment, and it belongs to a stage no change model teaches: the stage before the future state is designed. Before requirements are gathered. Before anything is bought. Reductive change goes after the weight itself rather than after people’s willingness to carry it.

It refuses the standard opening move. Most transformations begin by documenting the current state — which sounds like diligence and is actually a trap, because the moment a piece of the current state gets named, it acquires a plausible defense. The question quietly changes from should this exist to how do we carry it forward, and nobody notices the swap.

Reductive change asks different questions. What does this need to produce? Who uses it? What decision does it support? How small can this be and still work?

It is not cutting. Cutting is indiscriminate and reduction is not — the whole skill is sorting dead weight from load-bearing weight before you build.

The diagnostic: does your transformation have a deletion plan? If not, it isn’t a transformation. It’s a move.

4. Adaptive governance

A small number of real controls, asked on a schedule, with the authority to change the build.

Governance is not a measurement. This is the load-bearing distinction of the whole model, and it’s the one most organizations get backwards. A measurement reports a condition. A control changes it. A measurement can be green while the entire thing is sinking — Birmingham’s milestones were tracked and its reports were filed the whole way down.

A control has three properties a measurement doesn’t:

* It asks a question that can change the outcome. Should this customization exist? is a control. Are we on schedule? is a measurement.

* It runs on a schedule, not on alarm. A control that only fires when someone escalates is not a control. It’s luck.

* Someone has the standing authority to act on the answer. A question nobody is allowed to ask in year three is not governance.

It’s adaptive because gravity doesn’t stop pulling after go-live. The weight starts coming back the day you stop watching. Governance is the standing guard over the room you just cleared.

The diagnostic: name one question your organization asks on a schedule that has the power to stop or change work already in flight. If you can’t, you have measurement.

Define zero. Prove one. Earn two.

The math of reductive change. It replaces builder’s math — one plus one equals two, and two is better than one — with a sequence that makes addition earn its place.

Run it in order. The order is the mechanism.

Define zero

Start from nothing and state out loud what the thing has to produce.

Not what it does today. Not what the old system did. What it has to produce — the outputs, the decisions it supports, the obligations it satisfies. Zero is a blank page with a purpose written at the top, and it is the only moment in a transformation when nothing has a defense yet.

Defining zero is the hardest of the three, because it means refusing to open with the current-state inventory that everyone in the room expects. If you start with the list of forty-seven reports, you have already lost — you’re now negotiating removals instead of establishing additions.

Zero is not “we’re building nothing.” Zero is “nothing is in yet.”

Prove one

Everything that wants to come along has to prove it belongs. Nothing rides for free.

One at a time, each candidate makes its case against the definition of zero. Who reads this? What decision does it support? What breaks if it’s gone?

Two things make this work. First, the burden of proof sits with the thing, not with the person questioning it — the default is out, and inclusion is the exception that needs an argument. Second, the answer has to come from a named person, not a role. “Finance, I think” is not proof. Asking finance is proof.

This is also where reduction protects rather than cuts. Report thirty-one goes to the auditors at year end. It proved it belongs. It stays. The formula working looks exactly like that.

Prove one is a filter, not a target. There’s no quota.

Earn two

Only then does anything new get added. Addition is earned, never assumed.

New capability comes last, and it comes with the same burden as everything else. This is the step organizations skip straight to, because it’s the fun one — the demo, the roadmap, the thing you can announce.

Earning two means the new thing enters a system whose weight is known, against a baseline that was deliberately set rather than inherited. It also means the capacity to absorb it actually exists. The capacity to do the new thing doesn’t arrive when you install the system. It arrives when the weight comes off.

If two is earned before one is proven, you have bought a faster version of the problem.

Why the order matters

Run it out of order and it collapses into the thing it replaces. Start at one and you’re auditing a current state you’ve already implicitly approved. Start at two and you’re adding to a foundation nobody measured. Zero has to come first, because zero is the only place where the question should this exist is still a real question.

And it’s the shape of the J curve. How deep the valley goes is decided before anyone walks into it. Reduction pulls the left side up — not by pushing people through the change harder, but by handing them something lighter to carry down.

The AI stakes

AI doesn’t ask whether a process should exist. It learns what you already do and does it faster.

Hand it the current state — every approval nobody remembers adding, every report nobody opens, every exception nobody can explain — and it won’t question any of it. It will automate all of it and run it ten thousand times. Carol’s report gets a robot. The approval that has nothing left to catch gets optimized from two days to two hours.

Weight nobody chose becomes weight nobody can see. And getting it back out won’t be a cleanup — it’ll take a whole change effort just to unpack what got automated without asking.

The window for asking is now, before the automation, not after.

The one rule

Every transformation gets two plans.

A change plan — what gets built. The whole field already knows how to make that one.

A deletion plan — what gets removed. Almost nobody makes that one.

If your transformation has no deletion plan, it isn’t a transformation. It’s a move. You’re carrying everything you own into a new house.

Good intentions don’t survive the third steering committee. A rule does.

Chapters

* Cold open — Linda inherits somebody else’s decisions

* The middle of the story — transformation never begins at the beginning

* The J curve everyone budgets for — the gym, the shirt, and the weight you walked in with

* The stage before the model — Lewin, Kotter, ADKAR, Bridges, and the question none of them ask

* The elephant: AI automates the current state

* Reductive change — define zero, prove one, earn two

* What reduction actually looks like — report twelve, Carol, and the approval with nothing left to catch

* The proof — Birmingham City Council

* Naming the model — gravity, middleware, reduction, governance

* One rule — the deletion plan

* The far side — what Linda’s team got back

* Sign-off

Sources

Birmingham City Council and Oracle

Everything cited in the episode, with the primary reporting behind it. Figures verified August 2026.

The programme. Birmingham City Council — the largest local authority in Europe — set out in 2018 to replace its finance and HR systems with Oracle Cloud Fusion. The initial estimate was £19 million plus £1 million contingency. Rather than change decades of legacy process to fit the software, the council customised the software to fit the legacy process, including a bespoke bank reconciliation module Oracle was never designed to run.

Go-live. Originally planned for December 2020 (finance and procurement) and February 2021 (HR and payroll). Replanned and taken live in April 2022.

* Computer Weekly — Birmingham City Council’s Oracle implementation explained: what went wrong: https://www.computerweekly.com/news/366572935/Birmingham-City-Councils-Oracle-implementation-explained-What-went-wrong

* Computer Weekly — Why did IT suppliers allow Birmingham City Council to go live with Oracle?: https://www.computerweekly.com/news/366620333/Why-did-IT-suppliers-allow-Birmingham-City-Council-to-go-live-with-Oracle

The go-live decision. External auditors Grant Thornton found the programme steering committee failed to adequately scrutinise the information available to it. A Financial Impact Assessment warning of “major problems transacting” was published on 24 March 2022; there is no evidence it was discussed at the steering committee meeting on 25 March 2022 that approved go-live. The cash management module was reported as “Green” while staff were raising concerns about going live on an unstable solution. Grant Thornton’s conclusion: had the quality and completeness of testing been presented clearly, “it is unlikely that the program would have approved the decision to go live.”

* The Register — How mega city council’s failure to act on Oracle rollout crashed its financial controls (27 Feb 2025): https://www.theregister.com/2025/02/27/birmingham_oracle_auditors/

* The Register — Birmingham council had no understanding of its Oracle system (25 Feb 2025): https://www.theregister.com/2025/02/25/birmingham_oracle_latest/

The controls that weren’t there. No audit trail for fraud detection was in place for an 18-month period after the April 2022 go-live. Oracle’s audit features had never been turned on. Segregation-of-duties controls — who can view and who can authorise a transaction — were non-functional. Director of finance Fiona Greenway told the audit committee that the decision “to switch off the one thing that could give us the assurance within the control environment” left the council unable to test for fraud, and that she would never give 100 percent assurance on the period.

* The Register — Birmingham City Council’s Oracle audit trail failure (25 Apr 2024): https://www.theregister.com/2024/04/25/birmingham_oracle_audit_trail/

* Local Government Lawyer — Auditors highlight poor oversight and reporting at city council over troubled IT programme: https://www.localgovernmentlawyer.co.uk/projects-and-regeneration/403-projects-news/60078-auditors-highlight-poor-oversight-and-reporting-at-city-council-over-troubled-it-programme

The accounts. Roughly £2 billion in transactions allocated to the wrong year. The council could not produce reliable accounts, and could not monitor budgets well enough to deliver planned savings — £69m of 2023/24 savings were written off.

Section 114. Birmingham issued a section 114 notice — the local-government equivalent of declaring itself effectively bankrupt — on 5 September 2023. The notice itself cites an equal pay liability of £650m–£760m and an in-year budget gap of roughly £87m. Oracle is not named in the notice; it is widely reported as a compounding factor, and it is the reason the council could not produce the accounts to see its own position.

* Birmingham City Council — Statement regarding section 114 notice: https://www.birmingham.gov.uk/news/article/1381/statement_regarding_section_114_notice

* Section 114 notice (PDF): https://www.birmingham.gov.uk/download/downloads/id/27958/section_114_notice.pdf

* The Conversation — How Birmingham city council’s ‘equal pay’ bankruptcy provided cover for ongoing Oracle IT disaster: https://theconversation.com/how-birmingham-city-councils-equal-pay-bankruptcy-provided-cover-for-ongoing-oracle-it-disaster-224416

* Audit Reform Lab, University of Sheffield — Value for money and accountability: a report on the Birmingham City Council section 114 bankruptcy (19 August 2024): https://auditreformlab.group.shef.ac.uk/value-for-money-and-accountability/

The bill. Forecast programme cost through 2027/28: £144.4 million, against an initial estimate of £19 million plus £1 million contingency — roughly seven times. A 2024 assessment put the council’s total loss at £216.5 million through April 2026, counting both direct programme cost and the savings the council could no longer deliver because it could not monitor its own budgets. The council is reimplementing Oracle from scratch; as of January 2026 the relaunch had slipped several months past its April target.

A note on which budget number you use. Three figures circulate and they measure different things: £19m + £1m contingency is the initial estimate, £131m is the revised budget approved in 2024 including the reimplementation, and £216.5m is the assessed total loss including forfeited savings. The “seven times over budget” framing measures £144.4m against the initial estimate. Against the 2024 revised budget it is roughly break-even — which is its own governance story, and arguably the more damning one.

* The Register — Birmingham Oracle ERP fiasco now £144M and still not working (29 Jan 2026): https://www.theregister.com/software/2026/01/29/birmingham-oracle-erp-fiasco-now-144m-and-still-not-working/4238750

* The Register — Birmingham council faces £216.5M loss over Oracle debacle (20 Aug 2024): https://www.theregister.com/software/2024/08/20/birmingham-council-faces-2165m-loss-over-oracle-debacle/1519213

* The Register — Birmingham’s Oracle finance system falls short 2.5 years on (29 Jan 2025): https://www.theregister.com/software/2025/01/29/birminghams-oracle-finance-system-falls-short-25-years-on/548607

The change models discussed

* Kurt Lewin — unfreeze / change / refreeze. The sequence begins from a change that has already been decided.

* John Kotter — the eight-step process. Builds urgency, coalition, and vision around a future state that has already been shaped.

* Prosci ADKAR — awareness, desire, knowledge, ability, reinforcement. Walks each person to adopt a change that already exists. Certification is built around applying the methodology to an active project: https://www.prosci.com/solutions/training-programs/change-management-certification-program · methodology overview: https://www.prosci.com/methodology-overview

* William Bridges — transitions, and the human experience of endings. Carries people toward a destination that is already set.

None of these are wrong, and all of them have helped thousands of organizations. The observation in this episode is what they share: they engage after the future state has been designed. The design is where they start. It’s never the thing they question.

“A journey, not a destination”

The industry slogan referenced in the episode:

* https://quisitive.com/transformation-is-a-journey-not-a-destination/

* https://digitaltonto.com/2019/transformation-is-always-a-journey-never-a-destination/

Related

Read the companion newsletter — four rules for leaders; the episode covers the one I’d start tomorrow.

Previous episodes — Ep. 1 on how organizations gain mass, Ep. 2 on the human middleware holding it together. This episode completes the model, but it stands on its own.

The Organizational Gravity Podcast is written and hosted by Gabe Rybicki. Stories from practice are real and the people in them are protected — anonymized, composited, and never identifiable. Nobody in these episodes is the villain. That’s what makes the problem hard.