I enter situations where something important needs to exist that does not yet — or needs to work in a way it never has. I build it. I leave it running. I move to the next one.
Three decades. Eight industries. Four continents. The domain keeps changing. The instinct never does.
"I work in the engine room, not just the boardroom. Give me something broken, missing, or not yet imagined — and I will build it."
No company names. No logos. The pattern is the point.
Not improve. Not optimise. Build — from nothing, in environments where nobody has done it before.
A conglomerate. Thousands of vehicles moving millions of kilometres a month across a country. Tens of thousands of workers transported daily to remote sites. Each site managing its own piece of the operation locally — whiteboards, phones, no visibility across the whole.
There was one more complication. Al Tasnim operates in construction, mining, and oil field environments — sites that do not exist when the vehicles go in. The roads are built by the work itself. By the time the fleet comes out, the map has changed. Google Maps is useless when your vehicles are building the territory they are navigating. The platform had to work without a fixed map — tracking positions, managing journeys, and maintaining safety in terrain that was being created in real time.
I built the platform from concept to inauguration. Custom software. Real-time GPS across every vehicle. Driver behaviour scoring on every trip. Automated fuel dispensing with dual authentication. SAP integration. A live control room monitoring the entire fleet around the clock.
Before: 28 traffic incidents a year. After: near zero.
The national petroleum authority gave them an award. The Managing Director called it the first of its kind in the world. She also said the implementation — not the software — was the hard part.
She was right. Building the system took months. Changing the behaviour of thousands of drivers across a country, in real time, at scale — that is the actual work. That is always the actual work.
Not until it is delivered. Until it is right.
One of the world's largest automobile manufacturers was preparing its first parts shipment in a new market. Barcode labels needed to be ready over a weekend. No one else was available. I had purchased the printer, so the problem was mine.
I was not in IT. I was not supposed to be writing code. That was not the point. The labels needed to exist by Monday and the person who owned the printer owned the problem.
I had the user manual. That was all.
I built the code Friday night. Then I stayed. Saturday. Sunday. Into Monday morning. Not waiting — validating. Every output checked before the next step.
Monday morning I demonstrated the result. Then I returned to other work, stayed until evening, and went home.
That label standard is still in use at that company today. Every system I rolled out in that chapter of my career went live without sandbox tests or hypercare. They just worked. The validation was built into the process — not added afterwards.
The brief tells you what to look at. Operational context tells you what to see.
During a large-scale migration of hundreds of legacy procurement applications to a new enterprise platform, one application had been marked for decommissioning. Nothing in its technical profile suggested it was anything other than routine — a tool inventory management system, low priority, scheduled for retirement.
I read the operational context. Then I found the annexure.
The application controlled access to the cart that held aircraft maintenance tooling. Its job: ensure every tool taken out was returned before the cart was closed. No tool left behind. No Foreign Object Debris — FOD — near an aircraft. Remove the application and there is no closed loop on tooling accountability during a live maintenance window.
In an aviation environment, that kind of gap does not stay in a system.
The application was preserved.
I was not looking for it. I was doing what I always do — reading the operational reality underneath the technical description. That is the only place the truth about a system actually lives.
You cannot design what you have not witnessed.
A municipality needed to ensure sewage tankers were depositing their loads only at authorised recycling stations. The solution I designed used telematics and geofencing. Before I designed anything, I went on a ride-along — extraction to deposit, the full journey.
I showed up in a full suit. I stood in the yard.
The workers at the deposit station insisted on shaking hands. I shook every one.
What I learned on that ride-along informed every design decision that followed. I also learned something I had not expected: all that sewage is converted to fertiliser, sold to farmers at near-zero prices. The workers who do this every day do so with complete dignity.
You cannot know that from a brief. You have to go.
Six beliefs. All earned.
Not a support function. Not a cost centre. The business itself — expressed as the movement of material from the point of extraction through transformation to the point of consumption. Every margin decision, every resilience failure, every competitive advantage or disadvantage ultimately lives in that movement.
I have never treated supply chain as a function. I have always treated it as the operating expression of the enterprise.
Steel. Shoes. Sewage. Three decades of moving everything in between.
From iron ore to steel to a window frame — at every stage, it is a box moving. Only the handling differs: hazmat, perishable, fragile, bulky, liquid. The physics does not change.
I look at material movement as a graph: nodes are the warehouses and production facilities; edges are the transport lanes between them. Most supply chain thinking focuses on the nodes — easier, more visible, lower hanging fruit. The edges are where the real value sits. They are harder, messier, and require math to work properly. Most people who attempt the edges may lack the math.
Material movement generates signals. Signals harvested create value. That is the thread that runs through everything I have built.
The installed base is not a legacy problem to be managed. It is the largest untapped market in any product company's portfolio — the machine equivalent of every human who ever lived.
Every machine ever sold is still somewhere. Ageing. Consuming parts. Needing service. Generating data. Still present, still addressable, still generating value — if someone is paying attention.
Most businesses walk past this every day while spending on new customer acquisition. Most are not paying attention.
I positioned myself this way in college — Industrial Engineering with an Information Technology edge. I did not know then that it would become the description of my entire career.
Industrial Engineering is the science of how work flows through systems — how to design processes, eliminate waste, optimise throughput, and understand where value is actually created versus where it only appears to be. Information Technology is the instrument that makes those systems observable, measurable, and controllable.
Together they make operational transformation possible. Separately they make consultants.
The instrument changes. The abstractions evolve with each layer. The risk is not the new instrument — it is the practitioner who stops learning it.
Eight industries at depth — automobiles, enterprise technology, apparel, footwear, forest products, aerospace, construction, steel. The careers that matter are built in the work, not on the résumé.
Beyond those eight: two hundred clients across three decades, spanning PE-backed and SWF-owned companies, public conglomerates, cooperatives, NGOs, government ministries, and municipalities. Flour mills and hyperscalers. Chemical companies and sports retailers. Telecom operators and food processors. Exposure without always having the depth — but enough to know that the operating mode does not change with the industry.
The systems built across all of them: AS/400, Oracle, SAP, custom telematics, cloud-native architectures, WMS, YMS, TMS, ERP, and platforms that did not have names yet when they were being built.
The industry is not the expertise. The instinct is the expertise.
There is a Japanese concept — shokunin — that describes a craftsman who pursues mastery of their work as a purpose in itself. Not for recognition. Not for reward. Because the work demands it.
My work provides for my family.That is why I am still building at 52. Not restlessness. Not ambition in the conventional sense. The craft is not finished. The frontier keeps moving. The eyes looking at it are sharper than they have ever been.
I do not know the academic words for what I do. I arrive at their essence from doing it. The next framework will come the same way.
Every system I have built was deterministic. The same input produced the same output. Always. I built my validation philosophy on that certainty — snapshot the database before, run the process, snapshot after, report only what changed. Delta by delta. You could prove correctness.
AI breaks that contract. The same input can produce different outputs. Confidence intervals replace proof. The operational frameworks I have built over three decades were designed for a world where truth was reproducible.
That world is ending. The next framework is unbuilt. I am building it.
Not a form.
Not a scheduler.
A direct line to the person.