The Optimization Engine: From Cocktail Party to Production Tool

When I joined Target's Fulfillment Strategy team, I wasn't handed a problem statement. I was handed a calendar. My first few weeks were spent sitting in meetings across the department — operational teams, planning teams, inventory management, logistics — observing, asking questions, and taking notes. I wasn't looking for anything in particular. But patterns started to emerge.

Different teams were wrestling with what looked like different problems. Where should we open new fulfillment nodes? How many dock doors does a given store actually need? Should baby strollers be stocked in Nebraska or New York? Which stores should fulfill which orders, and at what cost? Each team had their own spreadsheet, their own workaround, their own request in the data science queue. But underneath all of it, I kept seeing the same skeleton: a constrained resource allocation problem. They weren't bringing me five problems. They were bringing me one problem with five faces.

That realization — that a single analytical technique could serve as a platform for a whole class of business questions — became the foundation of what eventually became the optimization engine.

Part One: The Hard Part Wasn't the Math

Getting Buy-In Before You Have Anything to Show

The first obstacle wasn't technical. It was organizational.

I was a data scientist working as a shared service, with a dotted line to the business. That structure meant I had visibility across teams, but no direct authority over any of them. To staff a real project, I needed the business to want it — and I needed data science leadership to believe the business actually wanted it, not just said they did. Those are two different things. Any experienced data scientist has lived through the version where the business "commits" to a project, then quietly reprioritizes before the model is ready, leaving a team of engineers holding a solution with no one to use it.

So before I asked for a single engineer, I did the work of selling the vision one stakeholder at a time.

I started meeting 1:1 with business partners across the department. Not to pitch a solution, but to listen. I asked them to walk me through their actual decision-making process: what information they wished they had, where they were making gut calls they weren't confident in, what decisions were high-stakes enough that being wrong had real consequences. I built a living list of use cases. The list got long fast.

Then came the translation problem. How do you explain linear programming to a senior director of inventory management who has back-to-back meetings all day and needs to sponsor headcount for something they've never heard of?

You don't use the words "linear programming."

The metaphor I kept coming back to was a cocktail party hors d'oeuvres plate. You're balancing a plate in one hand, trying to load it up with as many different appetizers as you can fit. You're constrained by the size of the plate and the weight of each canapé. You want to maximize the food, but you can't tip the plate. The optimization engine is the math that solves that puzzle, across thousands of plates simultaneously, accounting for every constraint you can name.

It landed. People got it. And more importantly, they started connecting the metaphor back to their own problems. That's when the conversations shifted from "interesting, tell me more" to "okay, so could this help us with the dock door question?" That's the moment you know you have real buy-in, not just polite curiosity.

Defining the Work Without Overpromising

Once I had enough stakeholder alignment to go back to the data science organization and ask for resources, the next challenge was scoping. This is where a lot of data science projects quietly fail: the team agrees to build something, but the definition of "done" is fuzzy enough that nobody's ever actually satisfied.

I'd seen it happen. Business expects a turnkey tool. Data science ships a model. Neither side feels like it got what it wanted.

My approach was to be almost annoyingly specific about deliverables from the start. What exactly would the first version do? What would it not do? What were the inputs, the outputs, and the decisions it was designed to support? I drew a hard line between what we were committing to in phase one versus what was on the future roadmap. That document became a reference point we returned to constantly.

There's a real tension in that kind of scoping exercise between the "quick and dirty" version that gets something in front of stakeholders fast, and the "robust" version that will actually hold up in production. You can't skip this tension. You have to name it explicitly, make a deliberate choice, and get both sides to agree on which tradeoff they're accepting.

Keeping Trust Alive Over Time

Getting initial sign-off is the easy part. The hard part is the eighteen months that follow.

What I learned is that trust in a long-running technical project is fundamentally a project management problem. It's about cadence and visibility. Are stakeholders hearing from you before they have to follow up? Are you showing progress, even when progress is messy? Are you bringing them problems early enough that they still have room to help, rather than presenting them with surprises?

I built a regular meeting rhythm with each stakeholder group. Not just status updates, but working sessions where they could push back, reprioritize, and shape the direction. I was deliberate about showing them that their feedback was being incorporated. When a stakeholder raises a concern and then sees it addressed in the next iteration, something shifts. They stop wondering whether you're listening. They start treating you like a partner.

That shift matters more than most technical decisions in determining whether a project actually gets used.

Part Two: The Technical Evolution

What I Actually Built (The POC)

Before there was a team, there was a proof of concept. I built it myself, in R, using the ~ompr~ package. It is a clean, expressive interface for mixed-integer programming that lets you write optimization models in a way that reads almost like math.

The core problem was a facility location variant: given a set of demand points (stores, patients, customers) and a set of supply nodes (distribution centers, fulfillment locations, medical centers), find the optimal assignment that minimizes total weighted distance subject to capacity and coverage constraints. You can see a version of this logic applied to public health data in my Ebola network design post, where I used the same framework to optimize medical center placement during the West Africa epidemic.

The R ~ompr~ POC was exactly what a POC should be: legible, fast to write, and good enough to make the case. It let me show stakeholders a working model with real outputs before anyone had committed serious engineering resources. That's its job.

What it wasn't: scalable. When the engineering team inherited the POC and began rebuilding it in Python with Google's OR-Tools, the first benchmark run on a single regional subproblem took forty hours — and that was running on Target's internal data science compute cluster, not a laptop. That number clarified very quickly why the architectural decisions mattered.

What Carried Over

The technical stack evolves. The fundamentals of working with a business don't.

The most durable thing I built on that project wasn't the optimization engine. It was the template for how data science and business teams could work together on something genuinely hard — with clearly defined deliverables, honest scoping conversations, and a meeting cadence that kept trust intact over eighteen months of ambiguity.

The optimization engine went on to support high-stakes capital investment decisions and identified millions of dollars in shipping cost savings. It also gave the data science team a piece of work compelling enough to present at Grace Hopper. But the thing I'm most proud of is that it got used.