How do organizations throw (AI) stuff away?
I’ve been working on context design with Very Large Company You’ve Heard Of on their agentic stuff, and a really tricky part is: if AI is moving so fast, how do we throw stuff away?
The models continue to get much better faster than ever, and how we use models, the UX of it all, is changing fast:
First we had chat
Then we had tool use
Then we had agents (2025, Claude Code)
Now we have active teams of agents that do stuff for you (2026, see muse)
I’m not going to talk about the shape of the experience, but instead: if you’re working in a large organization, it’s quite likely that a bunch of the stuff that was built the past 12 months is now out of line both with the capabilities of the models, and with fast evolving user expectations.
So how do organizations throw stuff away?
No easy answers today, but I did spend some time researching this.
And there's a lot there! Subtraction Neglect, Escalation Of Commitment, Sunk Cost Fallacy, Status Quo Bias, Ikea Effect, Organizational Unlearning, Competency Trap, Exploration Vs Exploitation, Core Rigidities, Active Inertia, Value Infusion, Structural Inertia, Permanently Failing Organizations, Resource Allocation Trap, Collective Belief, Exit Champion, Project Escalation, Policy Termination, Advocate Adoption Not Termination, Organizational Immortality, Planned Abandonment, Endings First, Conways Law, Code As Liability, Hyrums Law, Deprecation Policy, Chestertons Fence
Why people won’t subtract
Adams, Converse, Hales & Klotz (2021), Nature: “People systematically overlook subtractive changes”. When people were asked to improve Lego structures, essays, itineraries and so on, they added things far more often than they removed them, even when removing was easier and better. The bias got stronger under time pressure and cognitive load. There’s a short UVA write-up, and Klotz’s book Subtract (2021) is the popular version.
Staw (1976), “Knee-Deep in the Big Muddy”. This is the founding study of escalation of commitment. People who were personally responsible for a failing decision put more money into it. There’s also a Gresham College lecture on it. Arkes & Blumer (1985) covers the sunk-cost side.
Samuelson & Zeckhauser (1988), “Status quo bias in decision making” (full PDF). People prefer the current state just because it’s the current state.
Norton, Mochon & Ariely (2012), “The IKEA effect: When labor leads to love”. We overvalue things we built ourselves.
Why organizations can’t let go
Hedberg (1981), “How organizations learn and unlearn,” in the Handbook of Organizational Design. This is where the term organizational unlearning comes from. His argument, roughly: knowledge goes obsolete as reality changes, so understanding means throwing away old knowledge as well as adding new. The chapter itself isn’t free online. This interview with Starbuck (PDF) covers its history and the field.
Nystrom & Starbuck (1984), “To avoid organizational crises, unlearn,” in Organizational Dynamics. Organizations get into crisis because the beliefs behind their past success stop them from seeing that the world has moved. Context is in the same Starbuck interview.
Levitt & March (1988), “Organizational Learning” (PDF). This introduces the competency trap: you get good at a procedure, so you keep using it, so you never get good at the better one.
March (1991), “Exploration and exploitation in organizational learning”. Exploitation reliably drives out exploration because its returns are nearer and more certain. There’s a summary on Aca Wiki.
Leonard-Barton (1992), “Core capabilities and core rigidities”. The same things that make you good are what make you stuck.
Sull (1999), “Why good companies go bad” (summary), on active inertia. When disrupted, companies don’t sit still. They speed up what used to work. He has a related HBS Working Knowledge piece.
Selznick (1957), Leadership in Administration. “To institutionalize is to infuse with value beyond the technical requirements of the task at hand.” Once something has a team, a roadmap and a VP, it isn’t a tool any more. It’s an identity.
Hannan & Freeman (1984), “Structural inertia and organizational change” (PDF). Organizations are selected for reliability and accountability, and those are exactly what make them slow to change.
Meyer & Zucker (1989), Permanently Failing Organizations. Underperforming things survive because the people who depend on them care more about keeping them than owners care about results.
Christensen (1997), The Innovator’s Dilemma. The resource-allocation process starves anything your current customers aren’t asking for.
How things actually get killed
Royer (2003), HBR, “Why bad projects are so hard to kill”. Projects survive on a collective belief, not one stubborn sponsor. Her fix is an exit champion: someone whose explicit job is to ask whether the thing should stop. There’s a free Computerworld interview with her.
Keil (1995), “Pulling the plug”, in MIS Quarterly. A software project that ran for years past the point where it should have been killed, and what finally ended it.
Behn (1978), “How to terminate a public policy: a dozen hints for the would-be terminator”. Hints include: don’t float trial balloons, recruit an outsider to do the terminating, buy off the beneficiaries, accept short-term cost increases, and advocate adoption, not termination. Bardach’s RAND paper, A theory of termination in the policy process, is from the same research tradition.
Kaufman (1976), Are Government Organizations Immortal? (full PDF). Most federal agencies that existed in 1923 still existed fifty years later. I remember the figure as about 148 of 175, but I couldn’t confirm it, so check the PDF before quoting it.
Drucker on planned abandonment (Managing in Turbulent Times, 1980). Every product and process should be reviewed on a schedule with roughly this question: if we weren’t already doing this, would we start, knowing what we know now? See the Drucker Institute on his questions and a readable summary of the abandonment question.
Bridges (1991), Managing Transitions. “Every transition begins with an ending.” Before people can take on the new thing, they have to be helped through what they lose. See Ed Batista’s summary.
For the software angle
Conway (1968), “How Do Committees Invent?” (Adrian Colyer’s write-up). Systems mirror the communication structure of the org that built them, so deleting a system means touching an org chart.
Software Engineering at Google, ch. 15 “Deprecation” (the whole book is free). Code is a liability, not an asset. It also has Hyrum’s law: every observable behavior ends up with someone depending on it.
Chesterton’s fence (1929). Use it as the honest counterpoint: don’t remove something until you know why it was put there. In 2026 the answer is often “because the model couldn’t do X a year ago.”