We were three weeks into building an invoice automation for an agency and it was going badly, which was strange, because the build itself was straightforward. Every time we walked the process with the accounting team, the description came back slightly different. Steps moved. Exceptions appeared and then quietly disappeared again. The documentation we were given was immaculate and bore no resemblance to what anybody actually did on a Tuesday.
Nobody was lying. They had simply worked out, correctly, that a complete and accurate description of their daily work was the specification for their own replacement, and they were not in a hurry to hand it over. That is not obstruction. That is arithmetic.
Deming got there seventy years early
Point eight of Deming’s fourteen points is “drive out fear, so that everyone may work effectively for the company.” It reads like a wellbeing slogan and it is nothing of the sort. His argument was hard-nosed and entirely economic: a frightened organization stops telling management the truth, and an organization that stops telling management the truth is being run on bad data.
He was talking about factory floors where nobody would flag a defective batch. The mechanism is identical in an agency finance function. If raising a problem is dangerous, problems get raised late, softly, or never. The information you most need is exactly the information people have the strongest reason to withhold, and no reporting package will ever contain it. I have written before about the fact that the numbers cannot tell you everything. This is the sharpest version of that gap, because here the missing information is being actively withheld rather than merely uncounted.
AI takes an old problem and puts a floodlight on it. For decades, “we are going to improve this process” was a low-stakes statement for the person doing the process. It usually meant a new template. It now means something that can plausibly do the whole task, and everybody in the room knows it.
Four ways fear shows up in an automation project
None of these look like resistance. They all look like ordinary project friction, which is why they are so rarely diagnosed correctly.
The process you are given is the official one
Every real workflow has a documented version and a lived version, and the gap between them is where all the judgement sits. Fear guarantees you get the documented version. You then build something that works beautifully against a process nobody follows, and it fails in week one on an exception the team could have named in five minutes.
The exceptions arrive one at a time
Not because anybody is sandbagging, but because slow disclosure is the rational strategy when the project’s completion is bad news for you. Each new edge case buys another fortnight. Everyone stays polite and the timeline doubles.
Nobody tells you the automation is wrong
This is the expensive one. Once the thing is live, the person best placed to notice that it is miscoding a vendor is the person who has learned that engaging with it does not end well for them. They work around it instead, and the error compounds silently for two quarters. You have replaced a reliable human process with an unmonitored machine one and called it progress.
Your best people leave first
Ambiguity about the future is most intolerable to the people with the most options. If leadership will not say what the finance function looks like in a year, the controller with a strong network resolves the question personally, and the institutional knowledge you needed for the next build walks out with them.
“Nobody is losing their job” is not a plan
The instinct is to open with reassurance, and the reassurance is almost always too vague to be worth anything. People discount general statements about job security because they have heard them before, sometimes shortly before the opposite happened. Vagueness does not calm a room. It hands everyone a blank space to fill with the worst plausible version.
It is also frequently untrue, or at least unknowable, and saying it anyway costs you the credibility you will need for the harder conversations later. If the honest position is that roles will change substantially and you do not yet know the shape of every one of them, that is what should be said. Adults can work with an honest uncertainty. What they cannot work with is a confident promise that turns out to have been improvised.
The specific version is always better. Not “your job is safe” but “this build takes the coding and the chasing off your desk, you will own the exception review and the vendor relationships, and here is what your week looks like in March.” That is a sentence somebody can plan around, argue with, and hold you to. That last part is the point.
How to actually remove it
This is the sequence we use, and it is deliberately ordered. Getting it out of order is why most rollouts stall.
Answer the job question before you ask the process question
Do not open a discovery session with “walk me through how you close the month.” Open by saying what happens to this role when the routine work is automated, in writing, with names on it. Every minute you spend on process before you have answered that is a minute spent collecting fiction.
Automate something they hate first
The first build should remove a task the team openly resents. Bank coding, chasing timesheets, rekeying the same figure into a third system. It costs you a little sequencing efficiency and it buys the only thing that actually shifts a room, which is evidence. Nobody trusts the second automation because of what you said. They trust it because of what the first one did.
Make the person the verifier, not the cleanup crew
There is a large difference between “the system does it and you check it” and “the system does it and you fix what it broke.” The first is a promotion in substance. The second is a demotion with extra steps, and people can tell which one they have been handed within about a week. The systems we build are designed around the first, with each automation reporting its own health so the human is reviewing exceptions rather than hunting for them.
Let the team veto a build
Give the people doing the work a genuine ability to say “not this one, not yet,” and honour it at least once publicly. It is the cheapest credibility you will ever buy. It also tends to be correct, because the objection is usually about an exception you had not modelled rather than about the automation itself.
Separate the efficiency conversation from the headcount conversation
If every process improvement is visibly a cost-reduction exercise, you will get exactly one round of honest input and then never again. Decide what you are doing with the recovered hours before you recover them, say it, and then do that. In an agency, the answer is usually client-facing time, which is the only hour that actually earns and the one most often lost to administration.
The fear runs upward too
It is easy to frame this as a staff problem that leadership solves. In my experience the more common blocker sits higher up. A finance leader who does not really understand what these systems do, and who cannot say so, will avoid the subject rather than expose the gap. The project stays permanently in evaluation. Nothing is refused and nothing happens.
That is the same mechanism, one floor up, and it is more expensive because it is better disguised. The remedy is also the same. Somebody senior has to be visibly willing to say “I do not know how this part works, explain it to me,” in front of the team. Once that has happened once, the cost of admitting uncertainty drops across the whole organization, which is the actual thing you are trying to build.
None of this is soft. It is the precondition for getting accurate information out of your own business, and accurate information is the entire input to the job. Our approach puts people ahead of systems for that reason rather than a sentimental one: the system you design will only ever be as good as the description of reality you were given.
Common questions
Why do AI adoption projects fail at agencies?
Far more often than not, the technology works and the rollout still stalls. The usual cause is that the people who know how the work actually gets done have a rational reason not to explain it. If describing your process in detail is the first step toward automating your role, the honest answer is expensive to give. You end up automating the version of the process that exists on paper rather than the one that exists in practice.
What did Deming mean by “drive out fear”?
It is the eighth of W. Edwards Deming’s fourteen points for management. His argument was economic rather than sentimental: a frightened organization stops telling you the truth, and once the truth stops circulating, management is working from bad data. Nobody raises a problem, nobody flags a defect, nobody says the standard is unworkable. The fear is expensive long before anybody notices it.
How do you get a finance team to engage honestly with automation?
Answer the job question before you ask the process question. Say plainly what happens to the role once the routine work is automated, put it in writing, and make the first build something the team openly hates doing. Engagement follows evidence, not reassurance. One automation that removes a genuinely tedious task will do more than any amount of change-management language.
Should we tell staff their roles will change before we automate?
Yes, and with more specificity than most leaders are comfortable with. Vagueness does not reduce anxiety, it multiplies it, because people fill the gap with the worst plausible version. A clear statement about what changes, what does not, and what the person will be doing in six months is both kinder and more useful than a general assurance that nobody is going anywhere.
The bottom line
Most stalled AI projects are not technical failures and they are not really cultural failures either. They are information failures. The organization knew what was wrong with the plan and had good reasons not to mention it.
So before the tooling conversation, have the other one. Say what happens to the roles, prove it with a first build that helps rather than threatens, and put the people who know the work in the position of verifying it rather than cleaning up after it. That sequence is most of what separates an automation programme that compounds from one that quietly gets shelved, and it is the part a good fractional CFO should be running. The software will do what you tell it. Getting told the truth about what to tell it is the harder job.