From business operations to AI engineering
Three years of incentive-comp and sales analytics at ZS taught me to design AI systems around the decision they support, not the model they run.
I didn't come to AI engineering from a research lab. I came from three years at ZS Associates building the incentive-compensation systems that decide how thousands of salespeople get paid. That background shows up in almost everything I build now, usually before I write a line of model code.
What the work actually was
At ZS I worked in business operations for pharmaceutical sales teams. The headline version is incentive-compensation design, sales-performance analytics, territory alignment. The day-to-day version is 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 moved.
One plan I worked on governed payouts for teams carrying more than $100M in annual revenue. When a quota is wrong, someone is underpaid or the company overspends, and both get noticed within the week. There is no "ship it and iterate" when the output is people's paychecks. You get the logic right before it runs, or you spend the next month on damage control.
The most useful thing I built there wasn't clever. When COVID hit, the weekly performance reports and impact dashboards leadership depended on were taking more than twenty hours of manual assembly a week. I automated them. No model, nothing I'd have put on a portfolio at the time. Just a reliable pipeline that turned messy inputs into numbers people could act on, every week, without surprises.
What it taught me that the modeling courses didn't
Two habits carried straight over.
The first is starting from the decision, not the data. 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 is a forcing function: it changes behavior whether or not you meant it to. AI systems are the same. A retrieval tool that helps analysts write reports faster only matters if you understand what makes a report good in their world, how they're judged on it, and what breaks downstream when it's wrong. Most projects skip that and start from the dataset.
The second is respecting the unglamorous middle. Comp systems live or die on the parts nobody demos: hierarchy mapping, exception handling, the reconciliation step that catches the one region whose data is shaped differently. Production AI is the same. Ingestion that survives a malformed PDF. A validation layer that refuses to publish a number it can't trace. The escalation path for the input the happy path never anticipated.
Where it shows up now
When I designed extraction at Bridge Medical, the constraint that mattered wasn't accuracy on a benchmark. It was whether a reviewer with twenty years of domain experience could look at any extracted value and decide, in seconds, whether to accept it. That is an operations question before it is an ML question: who acts on this output, and what do they need in order to trust it?
A business-operations background isn't the only way in. But the part of this job that's genuinely hard now isn't the modeling, which keeps getting easier. It's building systems that fit how real people already make decisions. That part I learned reconciling comp plans, long before I trained anything.