The Objective You Optimized Is Not the One You Wanted

By Adrian Vance · Multi-objective tradeoffs, efficient frontiers, and why single-objective optimizers lose the room.

Somebody on your team has built an optimizer. It might be labeled a recommendation engine, a scheduler, a bidding strategy, a capacity planner, or a dashboard with a "recommended allocation" column. Whatever it is called, it takes constraints and returns an answer, and the answer is defensible because it is optimal.

Optimal with respect to what, though, is a question that usually got settled in the first week by whoever wrote the first version, and has not been revisited since.

This is the most common and most expensive modeling failure in applied analytics, and it is almost never a math error. The solver is right. The objective function is a bad summary of what the organization actually wants.

Single-objective models make the tradeoff invisible

Most production optimizers minimize or maximize one number: cost, revenue, latency, utilization. Real decisions have at least three things that matter, and they conflict.

A logistics model that minimizes cost per delivery will consolidate routes, which raises average delivery time. A model that minimizes delivery time will run trucks half empty. Neither is wrong. The organization wants a specific point on the curve between them, and that point reflects a business judgment about how much a delivery-day is worth in dollars.

When you write a single-objective model, you do not avoid making that judgment. You make it implicitly and then hide it. Cost minimization with a hard service-time constraint at 48 hours is a statement that the 47th hour is worthless and the 49th is infinitely expensive. Nobody in the business believes that. It is an artifact of the model being easier to write that way.

The damage shows up as a credibility problem rather than a math problem. A senior stakeholder looks at the recommended allocation, says "that can't be right, we'd never staff it that way," and the model loses. They are usually correct, and they usually cannot articulate why, because the thing they object to is a weight buried in a line of code.

Make the weights explicit and put them in front of the decision-maker

The fix is structural, not technical. Write the objective as a weighted combination of the things that actually matter, and treat the weights as an input owned by the business rather than a constant owned by the model.

minimize  w_cost * normalized_cost
        + w_time * normalized_time
        + w_risk * normalized_risk

Two implementation details carry most of the value here.

Normalize before you weight. Cost in dollars, time in hours, and risk as a probability live on wildly different scales. Weighting raw units means the weights are contaminated by unit choice, and a stakeholder who says "cost is twice as important as time" will not get what they asked for. Scale each term to a comparable range first, usually against the observed range across the feasible set, so that a weight of 2 versus 1 actually means twice as important.

Report the frontier, not the point. Solve across a sweep of weights and hand back the efficient frontier: the set of solutions where you cannot improve one objective without giving up another. This converts the conversation from "trust my model" to "here are your options, and here is what each one costs you." A stakeholder who rejects the cost-minimal solution can point at the frontier and say "here, this one," and that is a decision made with the tradeoff visible rather than a decision made by overruling an analyst.

The second point is where most of the organizational value lives. The frontier is legible to people who do not read code. It also makes clear when there is no real tradeoff at all, which happens more often than you would expect: sometimes two objectives are nearly aligned across the feasible region, and the argument everyone was having was about nothing.

When the objectives cannot be compared, do not force them

Weighted sums assume the objectives are commensurable, that some exchange rate between dollars and hours exists. Sometimes it genuinely does not, or stating it out loud is politically impossible.

Two alternatives handle this cleanly.

Lexicographic ordering. Rank the objectives strictly. Optimize the first, fix its value (or allow a small tolerance), then optimize the second within that constraint, and so on. This is the right structure when there is a genuine priority hierarchy: satisfy the safety requirement first, then minimize cost among the solutions that satisfy it. No exchange rate required.

Goal programming. Set a target level for each objective and minimize the weighted deviation from those targets. This matches how organizations often actually think. Nobody wants to minimize headcount, they want to hit a staffing target while staying near a budget target. Deviation-minimizing formulations often produce solutions that stakeholders recognize as reasonable, where a pure minimization produces a corner solution that looks insane.

Both are standard, both are supported by every serious solver library, and both are underused relative to how often the underlying situation arises.

The diagnostic

If you want to know whether your team has this problem, ask one question about any production optimizer: what would change in the recommendation if the objective weights were different, and who chose the current ones?

Three answers are common.

"There are no weights, we minimize cost" means the tradeoffs are hidden in the constraints, and you should go read them as if they were the objective, because that is what they are doing.

"An analyst set them during development" means an implementation detail is making a business decision on a recurring basis, and nobody has reviewed it since.

"The business owner sets them and we re-run the frontier quarterly" means the model is being used correctly, and the analytics team is doing decision support rather than answer generation.

The third answer is the goal. The distance between it and where most teams sit is not a modeling capability gap. It is a habit of treating the objective function as part of the code rather than part of the decision.

The broader point

Optimization models are unusually persuasive artifacts. They produce a single number with a solver's authority behind it, which makes them hard to argue with and easy to misuse. The discipline that makes them trustworthy is not solver sophistication. It is being explicit about what you chose to care about, showing what that choice cost, and putting the choice in the hands of the person accountable for it.

An optimal answer to the wrong question is still the wrong answer. It just arrives with more confidence.

Adrian Vance writes about applied AI, evaluation, and decision systems for technical audiences.