A conversation that happens in GCC boardrooms more than anyone admits.
What follows is a reconstructed conversation. The names are fictional. The numbers are not.
Me: Can you walk me through how the team tracks equipment rates?
Khalid: Excel. Same as everyone in this industry. We've been doing it this way for years and it's always worked fine.
Me: That makes sense. Who usually updates the file when a rate changes?
Khalid: One of the supervisors handles it. It's a simple process, honestly. I don't see why we're even talking about this.
Me: I just want to understand the flow. So one person updates it — is there anyone else who checks it after?
Khalid: My team are professionals. They don't need someone looking over their shoulder. We've been running these operations for a long time without any issues.
Me: Of course. I'm not suggesting otherwise. Can I show you something in the file quickly?
Khalid: Go ahead.
Me: This cell here — column F, row 47. The hourly rate for the crane unit. What should that number be?
Khalid: 1.45 OMR.
Me: It's showing 14.5. The decimal is in the wrong place. And because this cell feeds into the shift calculations, it's been multiplying across every shift for the past six months.
Khalid: (pause) That can't be right. Someone would have noticed.
Me: I thought the same thing at first. But finance receives the final output — they don't have access to the formulas. And the supervisor who built the file trusts it because he built it. There was no point in the process where anyone was set up to catch this.
Khalid: (voice rising) Are you telling me my team has been making this mistake for six months and nobody said anything? Do you know how that sounds? These are experienced people. This is not some small operation.
Me: I know. And I want to be clear — this isn't about your team's experience. This kind of error doesn't mean someone was careless. It means the system didn't have a way to catch it. That's a very different thing.
Khalid: So what's the number?
Me: 37,500 OMR overstatement across the period.
Khalid: (long silence)
Me: I know that's hard to hear.
Khalid: (quietly, but still resistant) I've been in operations for eighteen years. I know that file better than anyone. You start changing things, you break the familiarity. My team knows where everything is. New systems create new problems.
That was where the conversation ended that day.
When we came back with a solution, Khalid's team opened it and recognized the structure immediately. Same layout. Same logic they were used to. The learning curve was almost nothing.
But underneath, everything that mattered had changed. Rates were locked at the source. Formulas were protected. Any entry that fell outside an expected range flagged automatically. The specific error that caused 37,500 OMR in overstatements — the wrong decimal, silently multiplying for six months — could not happen again. Not by accident. Not even on purpose without it being visible.
Was Khalid happy about it?
He was not.
He used it. His team used it. The numbers were cleaner than they had ever been. But he was not happy.
And that is the part nobody writes about.
Because when a system improves, every person who spent years mastering the old one quietly wonders what that mastery is worth now. Khalid wasn't afraid of the new system. He was afraid of what it meant — that eighteen years of knowing every cell in that spreadsheet might not be the professional asset he thought it was.
That fear is understandable. But it is also wrong.
Learning a better system does not erase what you already know. It builds on it. In fact, the person who understood the old system best — its logic, its gaps, its workarounds — is exactly the person best positioned to judge whether a new one actually works. Khalid's eighteen years didn't become irrelevant the moment the spreadsheet was replaced. They became the most valuable thing in the room. Because you cannot evaluate a system you've never had to live inside.
New systems will replace old faulty processes. They will not replace expertise. They never do.
The professionals who understand that are the ones who end up leading the transition. The ones who don't end up guarding a file that's quietly costing their organization money they haven't found yet.
But here is the harder truth — and this one is not for the Khalids of the world.
This one is for the people above them.
A team cannot out-courage a culture their leadership hasn't committed to changing. Khalid's resistance didn't come from nowhere. It came from years of working inside an organization where the way things had always been done was never seriously questioned. Where survival meant mastering the existing system, not improving it. That culture was built from the top.
And it can only be dismantled from the top.
In Oman right now, the conversation around AI adoption is growing louder. But in too many organizations, it is still happening at the edges — a pilot here, a workshop there, a curious middle manager running experiments nobody asked for. Meanwhile the spreadsheet with the wrong decimal point keeps running.
Old ways of working cannot stay optional. Not when the cost of keeping them is compounding invisibly, one unvalidated formula at a time. The C-suite has to decide — not suggest, not encourage, not wait for buy-in that will never come organically. Decide. Set the direction. Make the new standard clear.
Because the question is never whether change is coming.
It already came.
The only question is who leads it — and who gets left defending a spreadsheet nobody should have trusted in the first place.
