Updated September 2026
Thirty-Five Years of Watching Australian Businesses Repeat Themselves
I have an AuDHD brain. The practical consequence is that I cannot stop noticing when two things are the same shape.
Most of the time this is an inconvenience to me, and to people sitting near me. Occasionally it is the entire product.
Thirty-five years in database architecture, web engineering and security means I have watched a very large number of organisations make decisions about infrastructure. Different industries, different decades, different budgets. The technology changed completely. The mistakes did not change at all.
What follows is the list. Seven failure patterns I have watched repeat since the early nineties, each with the tell that gives it away early.
None of them are stupid. Every one of them was a reasonable decision at the time, made by a competent person with incomplete pattern exposure.
That last phrase is the whole point. As I wrote recently about what a fractional CTO actually is, these are not failures of intelligence. They are failures of having seen it before.
1. The Untested Restore
The pattern: You have backups. You have never restored from one.
I first watched this play out on tape in the mid-nineties. The tapes were being written nightly. The light was green. The light had been green for fourteen months, during which the drive had been writing to a medium it could no longer read.
Cloud did not fix this. It moved it. Now the backup is someone else’s problem right up until the moment it is entirely yours.
The tell: Ask when the last successful full restore was performed, and to what. If the answer involves the word “should,” you do not have backups. You have a subscription.
2. The Incumbent’s Roadmap
The pattern: Your supplier’s product plan has quietly become your technology strategy, and nobody decided this.
It happens by accretion, not by choice. The vendor releases a module. It integrates well, because of course it does. Two years later every system you own is downstream of one company’s commercial priorities, and switching is no longer a procurement decision it is a rebuild.
The tell: List your next three technology projects. If all three happen to be things your current primary supplier sells, you no longer have a strategy. You have a roadmap someone else wrote.
3. The Demo Purchase
The pattern: You bought what you saw in the demo and inherited an architecture nobody evaluated.
Demos are built to demonstrate. They are the happy path, populated with clean data, run by someone who knows exactly where not to click. The architecture underneath, where the data lives, who can reach it, what happens at volume, what the export path looks like when you leave— is not in the demo, because it does not demonstrate well.
The tell: Ask anyone in the building to draw the data flow on a whiteboard. Not the org chart. The data. If nobody can, you bought a demo.
4. The Single Point of Person
The pattern: One person understands the system. Everything routes through them. They are excellent, and that is the problem.
This person is never a villain. They are usually the most conscientious individual in the organisation, which is precisely how they ended up holding everything. The risk is not that they leave maliciously. The risk is that they get sick, or promoted, or simply have a good year and take the leave they are owed.
The tell: Count how many times one named individual appears in critical-path conversations in a single week. If it is more than three, you do not have an expert. You have a dependency with a heartbeat.
5. Security With a Completion Date
The pattern: Security is treated as a project you finish rather than a posture you hold.
The audit gets done. The report gets actioned. The invoice gets paid. Everyone moves on, and the environment carries on changing daily against a snapshot assessment that stopped being true the following Tuesday.
I have handled live compromises with month-long dwell times. In more than one, the organisation had a completed security review sitting in a folder, accurate on the day it was written, and comprehensively overtaken by the eleven months that followed.
The tell: Your most recent security expenditure has a completion date and no renewal.
6. Shadow Adoption
The pattern: Staff route around the sanctioned tool, and the organisation finds out afterwards.
I watched this with unauthorised modems. Then with USB drives. Then with Dropbox. Then with entire SaaS platforms procured on a personal credit card and expensed as “software.” Now it is AI, the same movie, new cast, better production values.
The reason is always identical and always reasonable: the sanctioned tool is slower than the job requires. Shadow adoption is not an indiscipline problem. It is a feedback signal about the official tooling, arriving through the wrong channel.
The tell: Compare the usage figures for your officially sanctioned tool against what your helpdesk volume implies people are actually doing. The gap is your shadow estate.
7. The Deferred Upgrade
The pattern: Postponed one year at a time until the upgrade is no longer an upgrade, it is a rebuild.
Each individual deferral is defensible. The budget is tight this year. There is a merger. The system still works. And it does still work, right up until the version you are on falls out of support, the migration path you were counting on is retired, and the cost has multiplied by an order of magnitude while you were being sensible.
The tell: The sentence “we’ll do it after [event]” has now been said about the same system across more than two budget cycles.
Two more, currently playing out in public
I wrote the list above before this week’s news. The Origin Energy breach, traced in reporting to a former Accenture employee in Manila, affecting around 900,000 customers, put two more patterns on the board that I had left off, and they are both worth naming.
- The outsourced function with the retained liability. You can contract out the work. You cannot contract out the obligation, because the duty follows the customer relationship, not the org chart.
- The dismissed first signal. The first credible warning almost always arrives looking exactly like the many non-credible ones, untrusted source, unofficial channel, inflated-sounding claim. That is not bad luck. That is the shape of the thing.
What AI actually changes here
Not as much as people are being told, and more than the sceptics think.
AI is a pattern matcher, and it is a genuinely good one. Describe any of the seven above to a competent model and you will get a sound general answer. That is real, and it is useful, and it has substantially collapsed the value of generic advice.
What it cannot do is remember your estate. It does not know that this is the third time your organisation has deferred this specific upgrade, that the last two attempts died in the same meeting, or that the person quietly holding your integration layer together is the same person who is about to retire. It has no memory of your building.
So the useful arrangement is not one or the other. It is a pattern library that knows your specific history, pointed at a pattern matcher that has read everything, with someone accountable for the difference between the two.
That is the work. It is also, for what it is worth, the most interesting thing I have got to do with thirty-five years of noticing that things are the same shape.
Start with an hour
We offer an initial conversation at no cost, and we will tell you honestly if you don’t need us. Sometimes it is a two-page policy and a staff briefing. Sometimes it is a genuine architectural problem. Either way you’ll know which one you have, and if any of the seven above made you uncomfortable, that discomfort is data.