Surviving the organisation

The signature is the beginning, not the end

The deal closes. Someone celebrates. A budget line moved, a champion staked their credibility, procurement and the security review got cleared. All of that is real work and worth the celebration. It is also not adoption. The buyer signed. The organisation hasn't decided anything yet.

I spent years putting enterprise software into manufacturing companies - SAP manufacturing systems for global producers like Smurfit Kappa, Eramet, Eastman, Lhoist - and the lesson that took longest to learn is that the person who buys the software is almost never the person who has to live with it. The buyer is in a meeting room. The software ends up on a screen on a factory floor, run by someone who wasn't in that room and didn't ask for any of it.

Between the signature and the use sits the organisation. That is where most enterprise software quietly dies - not in the demo, not in procurement, but in the gap nobody budgets for: the months after the deal, among people who had no say in it. And it is worse for AI than for anything I shipped in those SAP years, for a reason I will come to.

The organisation has an immune system

A new product enters an organisation the way a transplant enters a body. The body didn't ask for it. Its default response to anything foreign is to reject it, and it has a whole system built for exactly that.

The organisational version of that system is made of people. The admin who now has to run the thing. The team that already has a way of working. The approver whose entire job is to say no to what hasn't earned a yes. None of them were in the sales meeting. All of them can kill the product after it's bought, and none of them have to do anything dramatic to do it. They just keep doing what they already do.

Adoption is not what happens when the buyer says yes. It is what is left after the immune system has finished.

Three things it has to survive

The tests are not technical, and they are not about whether the product is good. They are about whether it can live in a body that organised itself around not needing it. Three that I have watched decide the outcome more often than any feature list.

The job nobody will redesign. On a factory floor the work comes first and it is not negotiable. The line runs, the shift has a target, the operator is measured on output. Your software is something that happens on the side of that, and if it asks the operator to do the job differently - even slightly better, in some abstract sense - the job wins. Every time.

I once watched a system fail because it asked operators to log a step they had always carried in their heads. Nobody refused. They just kept doing the job the way the job got done, and logged the step afterwards, from memory, when they had a minute. So the data was guesswork, the reports built on it were guesswork, and within a quarter nobody trusted the screen at all. The software worked exactly as designed. It assumed the floor would reshape itself around it, and the floor had a target to hit.

The version that survives fits the job as it is actually done, including the parts that look inefficient on a slide and exist for reasons nobody wrote down. The software adapts to the work, or the work routes around the software. There is no third outcome.

The admin who didn't ask for it. Every enterprise product has a person who has to keep it alive. Integrate it with the six systems it has to talk to. Manage the accounts, the permissions, the upgrade that breaks something at the worst time. Be the one who gets called when it stops.

That person was usually not consulted, inherited the thing as more work, and has more leverage over its survival than anyone in the sales cycle understood. "Legacy integration" is the phrase used here, and it makes the problem sound technical. It isn't, or not only. It is a human gate. At Wizata we deployed an industrial platform across more than thirty sites, and the difference between the sites where it stuck and the sites where it struggled was rarely the technology. It was whether the person who had to own it locally had a reason to want it to work. Where they did, the integration problems got solved. Where they didn't, the same problems became the reason it never quite landed.

The team whose workaround already works. This is the one people miss, because it looks like a switching-cost problem and it isn't. The team you are replacing does not have a blank space where your product goes. They have a spreadsheet, a habit, a Friday ritual - a way they have organised themselves around the old way that works well enough that nobody has lost a job over it.

I have seen a team keep their old shared spreadsheet running for months after the new system went live, "just in case," with one person quietly maintaining it the way they always had. The spreadsheet was the real system. The new one was the thing they updated when someone asked. What you compete with is not the old tool - it is the shape the team took around the old tool: the rota, the shared file, the person unofficially in charge of it. A better product does not automatically win that. The team has to dismantle something that currently works to adopt something that might, and they pay that cost now, for a benefit that lands later and mostly accrues to someone else. Plenty of better products lose here. The spreadsheet has tenure.

A bought product enters an organisation that didn't ask for it. Adoption is whatever survives the rejection.

Why AI trips the immune system harder

Everything above was true before AI. Here is what changes, and it is the reason to write this now rather than ten years ago: AI makes the immune system more aggressive, not less, and most people building AI features expect the opposite.

An organisation eventually makes peace with ordinary software. It learns the tool's edges - what it does, where it breaks, what to never trust it with - and once it has that map, it stops fighting. The trust isn't affection. It is a settled understanding of the limits that lets people stop thinking about the tool. That settling is what adoption actually is.

AI does not let the map settle. Ordinary software fails in places you can find and mark - this field, that report, this known edge case - and once they are marked, the organisation works around them and moves on. AI fails in places you cannot list in advance, and the set of them shifts each time the model is retrained or updated. There is no stable map to learn. So the people whose job is to gate it - the compliance reviewer, the admin, the supervisor who signs off - never get to stop watching, and they are right not to. "Right most of the time" is not a reassurance to them. It is precisely the property their role exists to reject.

Ordinary software earns trust by holding still long enough to be understood. AI keeps moving.

An AI feature does not clear the organisation once and settle in. It has to keep clearing it. The immune system stays switched on, because the thing it is evaluating keeps changing. That is a harder adoption problem than any feature gap, and it is invisible in a demo, because a demo is a single frozen moment of the model behaving.

Ship for survival, not for the demo

The demo is built for the buyer. It is performed in a room, on a clean case, for the person whose signature you need. And the buyer is not the survivor. The people who decide whether the product lives never see the demo, or see it and aren't moved, because their question was never "is this impressive." Their question is "what does this cost me, and can I make it go away."

Building for them is mostly a matter of who you talk to, and when. Find the survivors before the signature, not after: the operator who will or won't change the job, the admin who will own it at the worst hour, the reviewer who has to defend trusting a thing that keeps moving. Ask them what it would take to keep it alive, and build that - not the version that wins the room. It is less impressive in the demo and far more likely to still be running in month four.

A signature means one person wanted it. Adoption means it survived the people who didn't. Only the second one is the product. The first just pays for the chance to find out.