Why AI automation stalls in growing companies
Most AI automation projects in this region deliver less than they promised. Not nothing — usually something. But less.
The explanations offered are familiar. The technology wasn't mature enough. The data was messy. People resisted the change. Each of these is sometimes true, and none of them explains why the same thing keeps happening to competent companies with good vendors and real budgets.
Here is a different explanation, and I think it is the one that matters.
Approval is not a step. It is a salary.
Walk any long process backwards and you will find approvals. More of them than the work requires. A purchase order that needs four signatures. A leave request routed through two managers who have never met the person taking leave. A policy exception that goes to a committee.
The standard reading is that this is bureaucracy — accumulated caution, or regulation, or the natural complexity of a bigger organisation.
That reading is incomplete. In most of the companies I have worked in, a meaningful share of those approvals exist because someone wants to be in the chain. Signing confers standing. It signals that you matter, that your judgement is required, that a thing cannot happen without you. Being removed from an approval chain does not feel like efficiency. It feels like demotion.
Approval rights, in other words, function as a form of compensation. Unwritten, untracked, and genuinely valuable to the people who hold them.
Which is why automation stops exactly where it does
Now watch what happens when such a company automates.
The steps automate beautifully. Data entry, routing, notifications, document generation, first-pass checks — all of it goes. The vendor demonstrates real time savings on each one, and the savings are real.
Then the process reaches an approval gate, and stops.
Nobody can quite say why that particular gate has to stay human. The stated reasons are risk, judgement, accountability, regulation. Sometimes those are genuine. Often they are not, and the honest answer — that removing this signature takes something from someone who has it — is not a thing anyone can say in a project meeting.
So the gate stays. And because it stays, the process still moves at the speed of a human being available to click approve. You have automated eight steps out of ten and improved throughput by almost nothing, because the constraint was never the eight.
This is why so many automation programmes produce impressive step-level metrics and disappointing end-to-end ones. And it is why the technology gets blamed for a problem that was never technical.
The same pattern, one size smaller
You do not need seven layers of management for this to bite. A related version shows up much earlier.
In my experience as a consultant, the most expensive failures are almost never inside a team. Teams are usually competent at their own work. The failures sit at the seam between two teams — where a handoff happens, where incentives diverge, and where nobody quite owns the outcome.
Sales commits to a date operations did not agree to. Finance needs a code that the project team fills in wrong because nobody explained what it was for. HR is waiting on IT, IT is waiting on a form, and the form is waiting on someone's holiday to end.
Every one of those seams is a candidate for an approval gate, because an approval gate is what an organisation adds when it does not trust a handoff. And every gate added is a person whose standing now depends on the gate remaining.
This appears at twenty people. Not two hundred.
What this means if you are still growing
Here is the part that is worth sitting with.
If your company already has the deep version of this problem, it is expensive to fix, because fixing it means taking something away from people who will defend it — often reasonably, from their point of view.
If you are still growing, you do not have that problem yet. You have something better: a choice about whether to acquire it.
The default path is that you grow, complexity grows, you hire specialists to manage the complexity, those specialists need support functions, support functions need coordination, and coordination needs approval. Each step is individually sensible. The end state is a company where a two-day process takes two weeks and nobody can point to the moment it happened.
The alternative is not to run the same company with fewer people. It is to add capacity without adding layers — to grow output substantially while keeping the number of humans in the coordination path close to flat. Capable AI systems make this genuinely possible for the first time, and only if the process is designed for it deliberately, before the layers exist.
Which is a different project from automating what you already do.
The uncomfortable practical point
There is an obvious objection: this sounds like an argument for not hiring, and companies that are growing need people.
They do. But it is worth asking a specific question about the last two or three people you hired: what problem was each one actually solving?
Some hires add capability you did not have. Those are unambiguous. But a surprising number of hires are solving coordination — someone to chase, to translate between two functions, to keep track of a thing that falls between systems. That is a hire patching a process gap, and it is a hire that also permanently adds a coordination point.
If the honest answer for one of your recent hires is we could not keep up, it is worth finding out what specifically could not keep up before hiring the next one.
I spent ten years in data and AI, and twice built an analytics function from nothing — at Etihad Rail here in the UAE, and at QNB in Qatar. Before that I did process re-engineering at Capgemini Consulting, which is where I learned to look at approvals rather than at steps.
I now run L'Atelier, a small consultancy in Dubai. I help growing companies add capacity without adding layers: redesign the process first, then build the AI that runs it, with scoped access and a full audit trail so you always know what a system can touch and why it did what it did.
I am deliberately small — I work with three clients at a time, and I do the work myself.
A process teardown
Pick one workflow you already dislike. I'll map it properly and show you where the time actually goes, and what could and couldn't be handed to a system.
About an hour of your time. No charge, no obligation. You keep the map either way.
If a workflow isn't the right place to start, an hour talking through where you actually are works just as well.