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.
"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. Most supply chain thinking focuses on the nodes. The edges are where the real value sits. Material movement generates signals. Signals harvested create value.
The installed base is not a legacy problem to be managed. It is the largest untapped market in any product company's portfolio. 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.
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. Information Technology is the instrument that makes those systems observable, measurable, and controllable. Together they make operational transformation possible. Separately they make consultants.
Eight industries at depth — automobiles, enterprise technology, apparel, footwear, forest products, aerospace, construction, steel. Beyond those eight: two hundred clients across three decades, spanning PE-backed and SWF-owned companies, public conglomerates, cooperatives, NGOs, government ministries, and municipalities. 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. My work defines my social identity. My work nourishes my ego. My work is my happiness. That is why I am still building at 52. The craft is not finished. The frontier keeps moving. The eyes looking at it are sharper than they have ever been.
Not a form. Not a scheduler. A direct line to the person.