The person behind the systems
A technical operations manager and automation consultant in Lahore, building systems for companies in the US, UAE and UK — and staying responsible for them after launch.
I started on the operations side, not the engineering side
That order matters. I spent my early years inside teams where the software was fine and the process around it was not — where a capable CRM went unused, a phone system dropped calls nobody reported, and an automation platform failed quietly for a fortnight.
So the work begins with how the job actually gets done, and only then with what to build. It is why I will occasionally talk a client out of a project. The cheapest automation is the step you delete, and nobody needs to pay me to build something they should simply stop doing.
Today the work spans four areas that tend to arrive together — AI and workflow automation, VoIP and telephony, ERP and CRM systems, and the infrastructure underneath all of it. One person accountable for the seams between them, which is where most operational failures actually live.
What I believe about this work
Six positions that shape every engagement, and occasionally cost me one.
Operator first, engineer second
I have run the operations I automate. The advice accounts for what actually happens on a busy Tuesday afternoon, not what the process diagram says.
Scope discipline
The cheapest automation is the step you delete. I will tell you when something is not worth building, even when building it would pay me more.
Documented by default
Diagrams, runbooks and naming conventions ship with the work. You are never locked in to my availability or my memory.
One accountable point
Telephony, ERP, CRM and infrastructure under a single owner, so nothing falls into the gap between two vendors.
Honest reporting
A monthly note on what improved and what did not, including the uncomfortable numbers.
Overlapping hours
Working hours that cover Pakistan and the Gulf in full, and the US East Coast for a good part of the day.
How an engagement runs
Nothing here is unusual. It is simply written down, and then followed.
Understand the work
Two or three conversations and, where possible, watching the process happen. Most of what matters never makes it into a brief.
Map and simplify
The current flow written down, then every step that exists only for historical reasons removed before a line of automation is built.
Propose with numbers
A written scope: what gets built, what it costs, how long it takes, and the measure that will say whether it worked.
Build in the open
Working increments you can see and comment on each week, instead of a reveal at the end.
Test against reality
Real data, edge cases and failure conditions — including what happens when an upstream service goes down mid-run.
Hand over properly
Documentation, a runbook, a training session and a support window. Nothing is left depending on my availability.
In regular production use
Tell me what is taking too long
Thirty minutes, no pitch. If automation is the wrong answer for your situation, you will hear that on the call.
Reply within one business day · NDA before any system detail is discussed