In my experience, data scientists crave problems to solve like I crave
Conecuh smoked sausage. You didn't study that much math and stats to
not use it!
So when you're handed a problem, you'll often bend over backward to
build a model that handles every bit of it.
You need to predict who's gonna want cheese curls and when? I'm your
scientist.
You want to optimize your outbound supply chain in light of Icelandic
Hidden People? I've got a minimax integer programming formulation
that'll handle that.
But few often ask, should we be modeling that? Should we as a business
in fact be *doing* whatever it is we're trying optimize?
Conecuh smoked sausage. You didn't study that much math and stats to
not use it!
So when you're handed a problem, you'll often bend over backward to
build a model that handles every bit of it.
You need to predict who's gonna want cheese curls and when? I'm your
scientist.
You want to optimize your outbound supply chain in light of Icelandic
Hidden People? I've got a minimax integer programming formulation
that'll handle that.
But few often ask, should we be modeling that? Should we as a business
in fact be *doing* whatever it is we're trying optimize?
In Star Trek (original series and the first Abrams film), Kirk is
presented with an unsolvable training exercise. A ship, the Kobayashi Maru, is
surrounded by Klingon warbirds, and it's got nowhere to go. No way to
evacuate.
What does Kirk do? He hacks the simulator and makes the game
winnable.
Kirk acts just like Peggy on Mad Men, "if you don't like the conversation, change
it."
Data scientists, remember Kobayashi Maru.
Sure, build the model that solves the problem, but never forget to
ask, "Should we be doing this in the first place?"
I recently built an optimization model that solved a scheduling
problem for the business. But the best it could do was always so-so,
because one of the constraints the business had given me concerning
lunch breaks would always muck things up.
The natural response shouldn't be to solve the schedule to optimality
and leave it at that.
Rather, ask the business if you can add some other scheduling options
in for lunch.
Models are great at working within the rules you give them -- they suck
at changing them. That's where the data scientist adds value. Our
models can quantify and highlight the advantage of changing a business
rule.
You move that lunch schedule, and I can get you a 100% improvement in
efficiency. Whether that's worth it is a management decision, but
you've just given someone options. Quantified options.
So don't just accept problems as is. Change the rules and bust up some Klingons.
winnable.
Kirk acts just like Peggy on Mad Men, "if you don't like the conversation, change
it."
Data scientists, remember Kobayashi Maru.
Sure, build the model that solves the problem, but never forget to
ask, "Should we be doing this in the first place?"
I recently built an optimization model that solved a scheduling
problem for the business. But the best it could do was always so-so,
because one of the constraints the business had given me concerning
lunch breaks would always muck things up.
The natural response shouldn't be to solve the schedule to optimality
and leave it at that.
Rather, ask the business if you can add some other scheduling options
in for lunch.
Models are great at working within the rules you give them -- they suck
at changing them. That's where the data scientist adds value. Our
models can quantify and highlight the advantage of changing a business
rule.
You move that lunch schedule, and I can get you a 100% improvement in
efficiency. Whether that's worth it is a management decision, but
you've just given someone options. Quantified options.
So don't just accept problems as is. Change the rules and bust up some Klingons.
RSS Feed