Defenestration in the Age of AI
An old principle from the data centre floor just became the most important idea in business strategy
Sometime in the early 2000s I was a senior systems administrator, working a client engagement at an energy utility in Melbourne. The head of security handed me a book. It was called The Unix Guide to Defenestration.
The title was the joke. The principle inside it was not.
The book was about data centre operations. Essentially about the chronic tolerance for systems that did not work, practices that persisted through inertia rather than merit, tools that had outlived their usefulness but remained in place because replacing them felt harder than living with them. Its argument was simple: anything that looks like a process, throw a system at it. Identify what is ineffective. Remove it. Replace it with something better. Do not be sentimental about it. The window is right there.
I was in my twenties. I filed it under useful and moved on.
Twenty years later I think about that book almost every week.
What defenestration actually means
Defenestration is the act of throwing something out of a window. The word has a specific historical gravity: it entered the language via political violence, the throwing of people from buildings as an act of decisive, irreversible rejection. You do not defenestrate something and reconsider. There is no managed transition. The ground is right there.
The Unix guide used it as a metaphor for organisational clarity. Stop tolerating what does not work. The ineffective system, the redundant process, the tool that made sense in 1995 and has been carried forward on habit ever since → out the window. Not deprecated gradually. Not sunset over three planning cycles. Thrown.
What made the principle powerful in the data centre context was the discipline it imposed on decision making. The question was not “is this system familiar?” or “do our people know how to use it?” or “what will it cost to change?” The question was: does it work well enough, given what is now available? If the answer was no, the window was the only honest response.
That question has not changed. What has changed is how many things now fail to clear the bar.
The scope problem
When the book was written, the category of “things that look like a process” had legible boundaries. Data entry looked like a process. Scheduled reporting looked like a process. File transfer, system monitoring, backup routines, access provisioning, all of these were clearly mechanical, clearly automatable, clearly candidates for the window.
Everything else felt safe. The judgement calls. The synthesis work. The decisions that required context, experience, and the kind of pattern recognition that accumulates over a career. These were not processes. They were expertise. And expertise, by definition, could not be thrown out a window and replaced with a system.
That assumption is now wrong.
Not partially wrong. Not wrong at the edges. Wrong in a way that is accelerating every month as the capability of AI systems expands into territory that, two years ago, was considered permanently human.
Legal review looks like a process. Financial modelling looks like a process. Customer support looks like a process. Recruitment screening looks like a process. Strategic synthesis looks like a process. Market research looks like a process. First draft everything looks like a process.
The Unix principle, applied today with intellectual honesty, leads somewhere its author almost certainly did not intend. Because the scope of what can be thrown at a system and replaced effectively, now includes most of what organisations spend most of their money on.
What is actually being defenestrated
It is important to be precise here, because the conversation tends to collapse into the wrong argument.
The thing being defenestrated is not people. It is systems. Organisational systems, being the accumulated architecture of how work gets done, which tools are used to do it, which processes exist to govern it, which layers of coordination have been built up around it.
Most of those systems were not designed. They were inherited. A SaaS tool was adopted to solve a specific problem. Then another. Then another. Then a set of internal processes grew up around the tools. Then additional staff were hired to manage the processes. Then reporting layers were built to give visibility over the staff managing the processes. Then the whole structure became the de facto way the organisation operated, and the original question, does this work well enough, given what is available? stopped being asked because asking it felt destabilising.
That is the definition of a system that belongs out the window.
I know this not as an abstract argument but as something we executed at Audalize. We looked at the constellation of SaaS tools running our operations. Jira, HubSpot, Cognito Forms, and a collection of internal tools that had accumulated over years of patching problems with whatever was available and we made a decision. We would build our own. A single, purpose-built internal platform, replacing multiple enterprise subscriptions, integrated with an LLM as the connective tissue across the whole system.
Not in months. In days.
We are a managed services company. Not a software house. Not a funded technology startup with a dedicated engineering team. A managed services company that decided to throw its operational stack out the window and rebuild it from scratch because the tools now available made that the rational choice.
If we can do that, so can your competitors. To themselves. Or to you.
The inertia taxonomy
Organisations that fail to defenestrate what should go are not making a technical mistake. They are making a cultural one. The reasons for keeping ineffective systems in place tend to cluster into a few recognisable patterns.
Sunk cost attachment. The system cost two million dollars and three years to implement. The people who championed it are still in the building. Acknowledging that it should go means acknowledging that the investment was wrong. So the question stops being asked.
Expertise conflation. The people who operate the system have built genuine proficiency in using it. That proficiency feels like organisational value. In some cases it is. In more cases it is proficiency in operating something that should not exist, which is a different thing entirely.
Risk asymmetry in decision making. The person who approves a major system replacement bears the downside risk if it fails. They bear almost none of the upside if it succeeds. The rational response to that incentive structure is conservatism. Do not replace. Extend. Patch. Add a module. Defer.
The comfort of familiarity dressed as caution. This is the most insidious one. It presents itself as prudence: “we need to be sure before we act,” “we should run a pilot,” “let’s see how the technology matures” but it is really just discomfort with discontinuity wearing a business case. The organisations run by people who can distinguish between genuine caution and rationalised inertia are the ones that move. The rest write strategy documents about digital transformation and buy more SaaS subscriptions.
The Unix guide had a name for all of these: things that look like reasons but are actually just the window being kept closed.
The irreversibility asymmetry
Here is the argument that the comfortable version of this conversation always misses.
Defenestration feels irreversible. Keeping the current system feels safe. The asymmetry seems obvious, throw something out and you have to rebuild; keep it and you maintain continuity.
That asymmetry has inverted.
The cost of rebuilding, given current tools, is a fraction of what it was two years ago and declining rapidly. The cost of keeping an ineffective system, in direct spend, in operational drag, in the compounding opportunity cost of not running on a better architecture, is fixed and, relative to the cost of replacement, growing.
More importantly: the risk of keeping the current system is no longer the risk of inefficiency. It is the risk of being outpaced by a competitor who made the decision you deferred. Who replaced their stack while you were running your pilot. Who is now operating at a speed and cost structure that makes your next renewal cycle a strategic event rather than an administrative one.
The irreversible act is not throwing the system out the window. The irreversible act is waiting long enough that the decision is made for you.
The discipline the principle requires
The book was not advocating chaos. It was advocating clarity. There is a difference.
Defenestration without judgement is just destruction. The principle requires that you actually answer the question: does this work well enough, given what is now available? You need intellectual honesty rather than institutional convenience. Some systems clear the bar. Some relationships, some accumulated expertise, some structural advantages are genuinely worth protecting. The principle does not say throw everything. It says stop tolerating what clearly should go.
That discipline is harder than it sounds. Because the systems that most need throwing are usually the ones most deeply embedded in how the organisation understands itself. The processes that have been in place long enough that they have become invisible. The tools so integrated into daily operations that questioning them feels like questioning the organisation’s identity.
Those are exactly the ones to start with.
The question the security head in Melbourne was really handing me, with that book, was not a technical question about Unix. It was a question about how to look at what you have built and see it clearly, not as it was when you built it, not as it represents the effort you put into it, but as it actually functions against the best available alternative today.
Twenty years later that question is harder to ask than it has ever been, because the gap between what organisations are running and what is now possible has never been wider.
And easier to answer. Because the window is right there.
The organisations that will compound
The businesses that move through this period well will not be the ones that had the best systems going into it. They will be the ones that defenestrated fastest.
Not recklessly. Deliberately. With the discipline the original principle required, clear-eyed assessment of what is no longer fit for purpose, decisive replacement with what is, and the organisational willingness to keep asking the question rather than settling into the next comfortable equilibrium.
Because the mistake the data centre administrators of the early 2000s made, the ones who read the book and agreed with it in principle but kept their legacy systems running because replacement felt hard, was not a failure of intelligence. It was a failure of pace. They understood what needed to happen. They just did not move before the window closed on them.
The window is open now. It will not stay open indefinitely.
The Unix guide to defenestration was right. It was just twenty years early on how much of what organisations do would eventually look like a process when viewed from sufficient altitude.
It does not look like the early 2000s anymore.
Ross Woodhams is the Founder and CEO of Audalize, a managed atmosphere services company operating across Australia, New Zealand, and the UK.