HomeOrganizational Design

Optimizing the unoptimizable

Like Tweet Pin it Share Share Email

Optimize” is such an easy word to say. Putting it into practice is more slippery.

Since we’ve been talking about optimization and sub-optimization for the past couple of weeks, we need to be clear on the concept. As a starting point, here’s what I want you to do: Whenever you talk about optimizing anything, follow “optimize” with the words, “with respect to.” Optimization in any system is … must be … about a single variable.

Imagine you’ve been assigned responsibility for optimizing your company’s order processing operation. “You have full authority,” the CEO tells you. “Do whatever you have to do — kick shins and take names.”

Head spinning from your newfound authority and status, you head back to your office, which is where you realize: The CEO didn’t follow the “with respect to” rule. He didn’t clarify whether optimization is supposed to be for total cost, marginal cost, overhead cost, throughput, cycle time, accuracy, or up-selling success. (As a long-time reader of Keep the Joint Running and its predecessors you realize that “quicker/cheaper/better — pick two” is a serious oversimplification.) You do know that your CEO isn’t a fine-distinctions/make-hard-choices kind of guy — that if you were to raise the subject at all, he’d answer, “All of the above.”

But “all of the above” is mathematically impossible. Increasing up-selling success requires longer interactions between the buyer and your order-taking staff, and a shift away from your e-commerce site to the order-entry call center. That increases costs. Often, a reduction in cycle time can result in a decrease in throughput (see “Quicker isn’t as simple as it looks,” if this point isn’t clear). Improving accuracy can slow things down. And so on.

It’s a good thing the CEO gave you full authority. With luck, that will include the authority to decide what you’re going to optimize. Here’s the hard part: Just because you can doesn’t mean you should. Engineers prefer to optimize for a single variable, or failing that to create a hierarchy of optimization priorities (throughput, then cycle time, then cost …). Doing so makes the engineer’s job easier. That doesn’t mean it’s the right answer. While it’s tough to acknowledge the point, our fictional CEO was onto something.

Don’t believe me? When in doubt, I always say, use an automotive analogy to illustrate:

Road & Track magazine used to define a sports car as a car with nothing in it that doesn’t make it go faster. Road and Track sacrificed accuracy for cute phrasing, though, because it’s a drag racer that has nothing in it that doesn’t make it go faster (except for the parachute). A sports car has nothing in it that doesn’t help it drive more responsively.

Dragsters have fewer design trade-offs than sports cars because dragsters have a simpler job to do. “Going faster” translates to accelerating as fast as possible, obtaining the maximum speed possible, driving in a straight line without loss of control, and stopping in a way that allows the car to race again and doesn’t kill the driver.

In contrast, driving responsively — the job of a sports car — requires:

  • Accelerating in as close accordance to the driver’s wishes as possible (acceleration must be calibrated).
  • Achieving a very high velocity.
  • Driving in a straight line without loss of control.
  • Driving around the tightest possible curve at the maximum possible speed without loss of control.
  • Decelerating as fast as possible, or, in other circumstances, in as close accordance to the driver’s wishes as possible (deceleration must also be calibrated).
  • Providing drivers with tactile and visceral feedback — letting them “feel” the road.

Designers of sports cars have a more complex job than designers of drag racers, and inevitably end up with design tradeoffs. The suspension, brakes, and tires needed to satisfy handling requirements, for example, add weight that reduces acceleration and maximum speed.

And sports-car designers have it easy compared to the folks who design minivans, because the function of a minivan — hauling a family and its stuff around — leads to a list of requirements that isn’t just longer, but is also rife with contradictions. The need for removable seats, so owners can substitute cargo for passengers, conflicts with the need to make the seats comfortable. The need for fuel economy in a vehicle of minivan dimensions requires engine features incompatible with easy maintenance. The minivan needs to be big enough to carry eight passengers but you still need to park the sucker.

Business process design has more in common with minivans than drag racers. That doesn’t make the task hopeless. It simply makes it more interesting.


It also gives me a topic for next week’s column — how to go about it — and that isn’t a bad thing either.