Where does Decision Science sit within your org?

:robot: At both Zoomer and Grubhub, Ryan O’Neil and I built the Decision Science team within the technology organization.


In 2016, we had strong opinions that decision services should be developed and maintained like the rest of the software stack - repeatable, testable, and scalable.

There is a large Venn diagram of modeling/analysis and developing/scaling when it comes to the job description for a Decision Scientist - just ask Sebastian :wink:.

That being said, I’ve seen too many potentially impactful models fail because they fail to make it into production (ie impacting real world plans for the business). These days “production ready” means managing response times, knowing how the service will respond to higher loads, controlling the I/O to maintain integrations with up and downstream systems, performing acceptance tests, and sharing potential impacts ahead of the launch.

:electric_plug: If you embed your Decision Science team in the technology org, they can build and release alongside software teams. This engrains a ship and iterate mentality and builds confidence in the solutions the decision services provide.

:evergreen_tree: Ryan and Nicole discussing DecisionOps at DecisionCAMP

:potted_plant: One of our early posts at Nextmv - Decisions as code

:seedling: Our first post on the topic on GrubBytes - Decisions are first class citizens

Where do these teams sit within your orgs? Drop us a line in the comments or on our discuss board.

Lately I’ve been wondering if a good heuristic answer to this question is, “put OR as close to your value prop as you can.” If you’re a software company, put them in tech, if you print books, put them in with the presses and distribution systems, and so on. Since OR tends to have a number of different stakeholders, I think there is some sense to having optimization and analysis sit right there with the critical functions of an organization.