A few months ago I wrote a somewhat off the wall article about Ontology, Taxonomy & Bureaucracy - here’s the punchline.
Every organisation chart is a fossil. It records the cognitive limits of the people who drew it - how much one person could hold in their head, how many handoffs a decision could survive, how far information could travel before it degraded into something useless. We drew lines between functions because no single human could be across finance and marketing and operations and legal at once. The specialisms existed because the cognition was scarce and expensive and lived in particular people.
That constraint is dissolving. Not gradually, and not politely. The work that used to require a department of specialists can increasingly be done by a system that holds all of it at once. Which means the lines on your org chart are no longer describing a necessity. They are describing a habit.
The uncomfortable part is that the redesign is already happening inside your organisation and it is just happening by accident. Every time someone buys an AI tool, automates a workflow, or quietly lets a model make a call a person used to make, the structure shifts a little. Nobody is deciding this. It is being decided, transaction by transaction, by whoever signs the next vendor contract. The question is not whether your organisation will be reshaped around what AI can now do. It is whether anyone will be in charge of how.
What the Pressure Test does
I built a tool that does one thing: it reads a description of your organisation through a single structural lens and tells you, specifically, where the structure is already failing under that pressure. It is called the Pressure Test, and it can be uncomfortable.
The lens it uses is one of ten I've developed: each a different first principle for how you might design an organisation if you were starting today, knowing what AI can do. The one the tool applies for free is Intelligence Tier: it sorts every function by the nature of the intelligence the work requires. Some work should simply run itself. Some needs a human and a machine in genuine fusion, where neither is sufficient alone. And some requires judgment that cannot be delegated to anything, ever. Most organisations are doing all three kinds of work badly, by accident, with no one accountable for the distinction between them.
The tool does not produce a report. It produces a diagnosis: the thing a consultant who had just read your organisation would say to you in private, out loud, before they softened it for the deck.
A worked example
Here is what it returned for a mid-sized infrastructure analytics company. I've changed the name. The organisation helps city governments predict where critical systems will fail before they do - it ingests data from transport, utilities, and emergency services, runs scenario models, and sells the results as a software dashboard. Its real value, though, is in forcing clients to confront where their operating assumptions break under pressure.
This is what the Pressure Test said.
Your stated value is structural. Your delivery vehicle is a dashboard. Those two things are in conflict, and the conflict is costing you — clients buy you as a tool and attribute the insight to themselves.
The senior people who can sit with a city official and name a broken decision flow are the bottleneck of your real product. There is no indication they are being developed or protected. When two of them leave, two contracts quietly degrade into dashboard renewals.
Your scenario models surface political truths dressed as technical findings, which means the wrong client owner — usually IT — receives outputs that should be landing with a deputy mayor. Procurement will keep routing you to the buyer who cannot act on what you find.
The work of noticing which coordination failures are becoming systemic across cities lives nowhere formally, so pattern recognition across clients is lost between engagements. A competitor who codifies this first reframes you as their data layer.
All of these trace back to one constraint. The organisation is built around scarce human judgment — the people who can see decision failure are treated as a bottleneck, insight is routed through systems designed to contain and distribute that judgment, and learning sits in individuals because the structure was never designed to hold it. That constraint shaped the structure. If the constraint changes — because AI makes that kind of judgment less scarce — the structure does not just underperform. It stops making sense.
Are you still organised around scarce human judgment, or is that now a design choice you're about to revisit?
Notice what the tool does not do. It does not explain how to fix any of this. It names the pattern, names what it is costing, and stops. The explanation is a different conversation. What the diagnosis is meant to do is make the structural problem impossible to un-see and to make clear that it is a structural problem, not a people problem or a strategy problem or a bad-luck problem.
Why I made it uncomfortable on purpose
There is a particular failure mode in this kind of work, which is that the analysis is good enough to be interesting and not sharp enough to be acted on. A reader nods, thinks "that's a clever way of looking at it," and closes the tab. Interesting is the enemy. The point of the Pressure Test is not to inform you. Informed people reflect. The point is to implicate the structure you are responsible for, specifically enough that you cannot dismiss it as generic.
It will not always land. Some organisations are described too thinly for the lens to find anything real, and the tool will say so rather than invent a problem. But when it lands, it tends to land on something the people inside the organisation already half-know and have not said out loud. That recognition, we knew this, we just never named it, is the whole product.
Run your own organisation through it. It takes a paragraph of description and about fifteen seconds. It will probably say something you would rather it didn't.
