From business operations to AI engineering

Before AI engineering I worked at ZS Associates, building the incentive-compensation systems that decide how thousands of salespeople get paid. That background shows up in most of what I build now, usually before I write any model code.

What the work was

At ZS I worked in business operations for pharmaceutical sales teams. On paper that meant incentive-compensation design, sales-performance analytics, and territory alignment. Day to day it meant mapping a sales hierarchy that never quite matched the CRM, reconciling payout discrepancies across regions, and explaining to a regional lead why last quarter's numbers had moved.

One plan I worked on governed payouts for teams carrying more than $100M in annual revenue. When a quota is wrong, either someone is underpaid or the company overspends, and both get noticed within the week. You can't ship that kind of logic and iterate on it, because the output is people's paychecks. If it isn't right before it runs, you spend the next month on damage control.

The most useful thing I built there was not technically interesting. When COVID hit, the weekly performance reports and impact dashboards that leadership depended on were taking more than twenty hours a week to assemble by hand, and I automated them. There was no model involved, and I wouldn't have put it on a portfolio at the time. It was a pipeline that turned messy inputs into numbers people could act on, and it ran every week without surprises.

Two habits that carried over

The first habit is starting from the decision. Before I ask which model to use, I ask what decision the system supports and who is accountable when it's wrong. An incentive plan changes how people behave whether or not you meant it to, and an AI system does too. A retrieval tool that helps analysts write reports faster is only useful if you understand what makes a report good in their world, how they are judged on it, and what breaks downstream when it's wrong. Most projects I've seen skip those questions and start from the dataset.

The second habit is taking the unglamorous parts seriously. A comp system depends on the pieces nobody demos: hierarchy mapping, exception handling, the reconciliation step that catches the one region whose data is shaped differently. Production AI has its own version of that list. Ingestion has to survive a malformed PDF, the validation layer has to refuse to publish a number it can't trace, and there has to be an escalation path for the input nobody planned for.

Where it shows up now

When I designed extraction at Bridge Medical, the constraint that mattered most was whether a reviewer with twenty years of domain experience could look at any extracted value and decide within seconds whether to accept it. Accuracy on a benchmark mattered less than that. I think of it as an operations question first and an ML question second: who acts on this output, and what do they need in order to trust it?

A business-operations background is only one way into this work. The modeling keeps getting easier, and the part I find hard now is building systems that fit how people already make decisions. I learned that part reconciling comp plans, well before I trained a model.